diff --git a/core/lib/Drupal/Core/Entity/EntityForm.php b/core/lib/Drupal/Core/Entity/EntityForm.php
index c80daa4..06abcd6 100644
--- a/core/lib/Drupal/Core/Entity/EntityForm.php
+++ b/core/lib/Drupal/Core/Entity/EntityForm.php
@@ -13,6 +13,8 @@
 
 /**
  * Base class for entity forms.
+ *
+ * @ingroup entity_api
  */
 class EntityForm extends FormBase implements EntityFormInterface {
 
diff --git a/core/modules/system/core.api.php b/core/modules/system/core.api.php
index 0787f0b..a57a046 100644
--- a/core/modules/system/core.api.php
+++ b/core/modules/system/core.api.php
@@ -127,28 +127,39 @@
  * https://drupal.org/developing/api/8/configuration for more details.
  *
  * @section sec_storage Configuration storage
- * In Drupal, the active configuration information can be stored in files or in
- * the database. Module developers do not generally need to worry about which is
- * in use on a particular site; they should use the configuration API to access
- * the active configuration at run time, which will automatically use the
- * correct storage. Configuration can be transferred between sites, imported,
- * and exported using files.
+ * In Drupal, there is a concept of the "active" configuration, which is the
+ * configuration that is currently in use for a site. The storage used for the
+ * active configuration is configurable: it could be in the database, in files
+ * in a particular directory, or in other storage backends; the default storage
+ * is in the database. Module developers must use the configuration API to
+ * access the active configuration, rather than being concerned about the
+ * details of where and how it is stored.
+ *
+ * Configuration is divided into individual objects, each of which has a
+ * unique name or key. Some modules will have only one configuration object,
+ * typically called 'mymodule.settings'; some modules will have many. Within
+ * a configuration object, configuration settings have data types (integer,
+ * string, Boolean, etc.) and settings can also exist in a nested hierarchy,
+ * known as a "mapping".
  *
  * @section sec_yaml Configuration YAML files
- * The file storage format for configuration information in Drupal is
- * @link http://en.wikipedia.org/wiki/YAML YAML files. @endlink Configuration is
- * divided into files, each containing a related set of configuration
- * settings. Some modules will only have one configuration file containing all
- * of the settings for the module; some will have several. The file name,
- * without the .yml extension, corresponds to the name of the configuration
- * object. (If the active configuration for a site is stored in the database,
- * the logical separation of configuration into files still applies.)
- *
- * Each module needs to define its default configuration by putting
- * configuration files in the config/install directory under the top-level
- * module directory, so look there in most Core modules for examples. This is
- * true regardless of whether a particular site is using the database or files
- * for its active configuration storage.
+ * Whether or not configuration files are being used for the active
+ * configuration storage on a particular site, configuration files are always
+ * used for:
+ * - Defining the default configuration for a module, which is imported to the
+ *   active storage when the module is enabled. Note that changes to this
+ *   default configuration after a module is already enabled have no effect;
+ *   to make a configuration change after a module is enabled, you would need
+ *   to uninstall/reinstall or use a hook_update_N() function.
+ * - Exporting and importing configuration.
+ *
+ * The file storage format for configuration information in Drupal is @link
+ * http://en.wikipedia.org/wiki/YAML YAML files. @endlink Configuration is
+ * divided into files, each containing one configuration object. The file name
+ * for a configuration object is equal to the unique name of the configuration,
+ * with a '.yml' extension. The default configuration files for each module are
+ * placed in the config/install directory under the top-level module directory,
+ * so look there in most Core modules for examples.
  *
  * Each configuration file has a specific structure, which is expressed as a
  * YAML-based configuration schema. The configuration schema details the
@@ -219,6 +230,15 @@
  * - Your module may also provide a few configuration items to be installed by
  *   default, by adding configuration files to the module's config/install
  *   directory; see @ref sec_yaml above for more information.
+ * - Some configuration entities have dependencies on other configuration
+ *   entities, and module developers need to consider this so that configuration
+ *   can be imported, uninstalled, and synchronized in the right order. For
+ *   example, a field display configuration entity would need to depend on
+ *   field instance configuration, which depends on field and bundle
+ *   configuration. Configuration entity classes expose dependencies by
+ *   overriding the
+ *   \Drupal\Core\Config\Entity\ConfigEntityInterface::calculateDependencies()
+ *   method.
  * @}
  */
 
@@ -264,8 +284,8 @@
  *     \Drupal\Core\Config\Entity\ConfigEntityListBuilder or [content entity
        list builder], to provide an administrative overview for your entities.
  *   - add and edit forms, or default form: Define a class (or two) that
- *     extend(s) \Drupal\Core\Entity\EntityFormController to provide add and
- *     edit forms for your entities.
+ *     extend(s) \Drupal\Core\Entity\EntityForm to provide add and edit forms
+ *     for your entities.
  *   - delete form: Define a class that extends
  *     \Drupal\Core\Entity\EntityConfirmFormBase to provide a delete
  *     confirmation form for your entities.