My thoughts on core process and roadmaps
Much of what is proposed here is a large shift from Drupal's traditional feature addition process which has been largely informal. In the past because of our long release cycles consideration of such a process would have been foolish and this degree of formality would only have discouraged involvement. Now that we're moving towards semantic versioning, the release of Drupal 8 and a move to regular six-monthly minor releases means we're now in a position to consider this kind of formal process. Its a sign that we're maturing as an open source community. Parts of the process, in particular the voting, are modelled on other successful open-source projects that have the same level of maturity as ours. The thoughts proposed here are just that, thoughts. They've been influenced by core conversations at Drupalcon Amsterdam as well as a significant twitter thread on the topic. Please read the whole thing before commenting. So without any further ado, here's my thoughts.
Core steering committee
A core steering committee would be created consisting of core committers, initiative leads and anyone listed in maintainers.txt.
When a new volunteer is put forward to join maintainers.txt, the existing steering committee are given a vote to endorse. Once a critical point of yes votes is reached, the new maintainer is added. A voting window is announced to time box this process.
The steering committee may deem a maintainer too inactive and vote on their removal. Note inactive does not relate solely to patches but primarily to taking part in the decision process.
Core roadmap meta
A core roadmap is created by the core committers. Members of the steering committee can propose themes and concepts but the committers' decision is final. This roadmap might describe broad directions and concepts as well as specific issues. It will be the broad strategy document for Drupal core. There would be one roadmap per minor version and the broad direction should be decided before work on that version commences.
Each initiative lead and each module/component maintainer then comes up with a roadmap meta for their initiative/component/module. Where there is a team, they do so collectively. Each of the items on their roadmap is created as an issue and added as a child using the parent issue field. Each roadmap is put to vote by the steering committee. Majority of yes votes sees it adopted and linked to the core roadmap using the parent issue field.
Thoughts on voting process
Whilst this degree of consideration/scrutiny for features is new to Drupal, it is something that has been widely adopted in our peer communities. The PHP Framework Interoperability Group (FIG) and the PHP Request for Comment (RFC) voting process are existing examples of where this has been used to success.
Using the roadmap
The roadmap should be the focus point for development. New features proposed by the community should be vetted by the relevant committee member and then brought forward to the committee for vote. To streamline the process there would be a proposal window during which issues would be considered for the next point release. After this window the proposal would need to wait for the next release cycle. With the move to six monthly point releases this becomes manageable. Compared with a three year release window, waiting an extra six months is completely reasonable. Only a core maintainer can override this and add a worthy feature proposal to an already approved roadmap. In addition, having a roadmap makes it clear to organisations that there are specific things they could sponsor - which circles back into @Dries keynote's desire to provide greater credit for organisations.
Obviously bugs don't fall into this process.
When two parties disagree on a technical approach then the issue is put to vote before the steering committee. Same rules apply as for new maintainers - critical point of yes votes within a time box wins. In this instance the committee's decision is final and failure to abide by the decision will be seen as a breach of the code of conduct. This item is intended to address the concept of 'bullying a patch into core' by using tactics such as repeated RTBCing of a patch or intimidating other community members. We have no place in our community for those who cannot show respect to people or processes.