Last updated on
19 December 2016

Features is guided by the following principles:

  • Interoperability baked in. Interoperability between different features and feature sets is not an add-on or an option but a core principle reflected in the basic design of the project. Default Features settings should facilitate creating and maintaining interoperable configuration modules and distributions. See the page on interoperability features.
  • The site/feature set as a whole. The primary unit of interest is the site as a whole as it maps to a feature set. Creating and editing individual features is also of interest, but is a derivative problem.
  • Work with core. Wherever possible, we should work with Drupal core. This includes working directly with core's configuration management API. Overriding default core patterns should be reserved for scenarios where doing so satisfies a critical requirement and is absolutely unavoidable. For example, the installation of configuration from features-type modules should work out of the box with core's default configuration installer without any non-core dependencies.
  • Configuration only. Features is concerned only with handling configuration as defined and managed by the core configuration API. Any special case handling for data that isn't managed by the core configuration API should be done in a separate module. For example, since menu links are provided in non-configuration .yml files, they should not be handled by Features.
  • Packaging problem only; best shared solutions. Effort and functionality should focus narrowly on the problem of "packaging a collection of Drupal entities which taken together satisfy a certain use-case". Wherever feasible, solutions should be moved out of the project into more generic solutions that address configuration management needs beyond those specific to the packaging problem. This solution or solutions should be added as dependencies. Where functionality is added that is potentially generic, it should be done on an interim basis with the longer term aim of moving it to a generic solution.
  • Comprehensive test coverage. Code should include comprehensive test coverage. Primary reliance should be on unit tests, with Simpletest-type tests reserved for functional tests when a unit test is not feasible.
  • Core-worthy quality. All proposed changes to the code base should be assessed on the criterion: is this code worthy of Drupal core in terms of quality and elegance? In particular, rather than introducing dubious workarounds with the hope of later refining, it's preferable to leave a feature out.
  • A issue for every change. All changes, even relatively trivial ones, should be done through the issue queue, including peer review whenever feasible. That said, broad tickets may cover several related changes.
  • Maintained on The project should be maintained on rather than some external site (e.g., GitHub).
  • Site builder toolset. The focus should exclusively be on the use case of site builders developing features. The module should never be required on any client site in order for the functionality it packages to be available.
  • Modularity. We will keep things as modular as possible via submodules.
  • Some "compatibility" with Features 2.x. We don't mean true compatibility here, but rather translation of concepts. With variations where appropriate, Features 3.x should support the basic concepts and Drush commands of Features 2.x.