Problem/Motivation
This proposal is based on a core conversation from @webchick and @Gábor Hojtsy, discussed at DrupalCon New Orleans: https://events.drupal.org/neworleans2016/sessions/potential-drupal-8x-an...
Drupal 8 took 4.5 years to complete. We already decided not to do that again and focus on shorter cycles of incremental improvements with semantic versioning instead. That allows predictable timelines where a contribution is released within 6 months, so there is more incentive to contribute. It is also better for users because they see Drupal improving in positive ways twice a year. The release process adjustments did not yet address how we make decisions about what to do and how to do it though, and based on our experience with Drupal 8.0.0 (and prior versions), that needs to be fixed too.
Problems from Drupal 7 and Drupal 8.0.x that we still need to address:
- Bikeshedding, especially of user-facing changes makes it hard to tell who is in charge
- You may work hard on something and it may still get rejected at the end because there is no good way to get the right feedback at the right time
- People don't give directional feedback when needed, standards nitpicks are common even in early stage review
- We don't validate ideas until after shipping; when it is too late to fix
As for where are we working on making those big changes:
- Giant core patches are hard to maintain and review, it is hard to collaborate on them
- Sandboxes are tucked away and not looked at as part of the core process, even though they are easier to collaborate on
- Contributed modules allow experimentation but often have little visibility
- Core reviews are too rigorous, not experimentation friendly
Proposed resolution
- Iterate quickly and cheaply on ideas without needing to implement anything
- Add clear sign-off points to avoid wasting time
- Involve the right stakeholders at the right time
- Gain visibility for proposals from committers
- Reduce barriers to entry into core for new ideas
- Clear visibility of priorities for the community
- Find a middle ground between rigorous core/sandboxes/contrib/huge patches
Introduce steps where a proposal is only developed to the level required to provide the right kind of feedback. At the idea stage, a few sentences explain what is proposed and stakeholders can decide whether the idea is a no-go, or it should move forward to a planning stage. The plan is fleshed out more with requirements, etc. but no implementation is done yet. When goals are agreed on, prototypes are made, which allows user testing and feedback on the interaction / integration level:
(larger version) →
Drupal 8.x also introduced the concept of experimental modules which fit with the goals of this proposal very well. Experimental modules allow us to ship with new features and improvements without needing to go through the whole rigorous process of stable core inclusion first. An experimental module is not bound to the same stability requirements that a core modules is and can have its own versions. At the same time, it gives visibility to users and is included in the general core process, therefore serving as a middle ground between the previous options for working on bigger changes.
Quicker iteration is enabled thanks to the refinement circle, while meeting all the rigorous requirements for stable core inclusion can be left to the stage where a module matures from experimental to stable. Some time limits should be set on a case by case basis for when we remove an experimental module if it never matures into a stable module. The module in this case could move to being a contributed project.
Applicability and limitations
As for what constitutes an "idea", and how big or small it needs to be to go through this proposed process, practice will tell. Documentation improvements for existing things, bug fixes for functionality, etc. are not ideas while "Make contact module more like a simple form builder" is.
The use of experimental modules is only applicable to self-contained changes. While services can be swapped out in modules (and most things are services in Drupal 8), larger systemic changes are not possible with experimental modules. We may still need to explore feature branches at one point.
Remaining tasks
Discuss!