Voting starts in March for the Drupal Association Board election.
In threads like, we've been discussing a variety of different approaches for improving the process of maintaining Drupal core. One of the most popular solutions is taking stuff out, but other than a few whipping-boy modules (cough profile cough trigger), there's very little consensus on what should be removed, and why it should be removed.
Moving forward, we need some good heuristics that can be used in three situations:
- When new functionality is being proposed for Drupal core
- When existing core functionality is being evaluated for removal
- When major refactoring of existing core functionality is being proposed
These heuristics can't be hard and fast rules like our coding standards, or a task-oriented checklist like the Drupal 8 Gates -- they're intended instead as a general measure of how well a proposed change aligns with the Drupal Project's shared needs. Specifically, the questions should help guide new "Code Gardeners" as they evaluate patches and proposals. Being able to say, "Yes!" to all of these questions doesn't automatically mean a patch is RTBC, but it certainly indicate that something is a good fit. Similarly, getting "No!" answers doesn't mean that a change would be rejected or a module would immediately be jettisoned, but it would definitely raise red flags.
Based on my own brainstorming, and subsequent conversations with Catch and Sun, I'd like to propose the following "rules of thumb":
- Is it needed for Drupal web sites, automated tests, installation profiles, or drush commands to operate properly?
- Is it a "defining" quality of Drupal or an important differentiator from other web CMS projects?
- Is it a "building block" that can be used to implement many different user-facing features?
Can it be controlled or managed from a variety of tools (drush, GUI admin tools, install profiles, packaged configuration, etc.)
- Would it be impractical or impossible to implement as an optional plugin or contrib module?
- If more robust solutions to the same problem exist in contrib, is it compatible with or "easily migratable to" the contrib solution?
- Does it have a positive or neutral impact on the number of "tightly coupled" connections and dependencies between different parts of Drupal?
- Does its presence significantly improve the experience of first-time evaluators, experienced builders, or developers building on top of Drupal -- without significantly diminishing the experience of the others?
- Does it match common patterns and best practices for similar tools and web applications?
All of the questions above are positive criteria, and none are specifically intended to "catch" a particular hated or loved piece of functionality. They can apply equally to modules, specific features, and underlying API changes. There are some domain-specific questions that aren't covered (like accessibility, UX concerns, and product/api separation), and it doesn't include any specific guidance for how removal of functionality should be handled for upgrade purposes, but those are implementation questions that have to be ironed out on a patch-by-patch basis, or are already covered by our "Drupal 8 Gates."