Skip to content

Instantly share code, notes, and snippets.

@larowlan
Created October 11, 2014 00:17
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save larowlan/7864a8987e2ebbc24260 to your computer and use it in GitHub Desktop.
Save larowlan/7864a8987e2ebbc24260 to your computer and use it in GitHub Desktop.
Thoughts on core process and roadmaps

My thoughts on core process and roadmaps

Prelude

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.

New maintainers

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.

Inactive maintainers

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.

Roadmap metas

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.

Bugs

Obviously bugs don't fall into this process.

Technical disputes

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.

Thoughts? @larowlan

@dawehner
Copy link

Thank your for writing down your thoughts, in a reasonable, non-self-centered way.

Having a sane 6 months time between releases could help a lot, especially in terms of fast-iteration.

While roadmaps are a nice thing in a controlled eco-system, I think they simply don't work in day to day Drupal development.

Drupal as a community and as a software has kind of a different position compared to many other frameworks / CMSs out there. They can choose what they want to support, we can't. We do have a huge code and usage base which is all the power of Drupal. We do have so many usages and flexility, which is and will ever be our main value. Its not our clean architecture, design or whatever, its the amount of tools we provide the users. I hope most people agree here.

Let's assume your plan of using roadmaps etc. would be adapted you would have to know in beforehand what kind of features you all need, but can we know that? I doubt we can, none of the """initiatives""" actually worked like that. CMI realized that they need to step away from using manifest files, needed dependencies and schema validation. The entity team for example realized that having just entities everywhere doesn't cut it, so they decided to add OptionsProviderInterface later, WSCCI realized later that they need to rewrite the different kind of menu links, etc. To summarize it, Drupal development is too complex to be able to create a roadmap in beforehand which has any value in the day to day work.

What I though think we really need is a bunch of people which do concentrated reviews in certain topics. Development will happen, as long there is interest in the community, but reviews is at least at the moment from my perspective the main slowdown of progress. Yes I know, this cannot be easily sold to companies paying core development.

@larowlan
Copy link
Author

Let's assume your plan of using roadmaps etc. would be adapted you would have to know in beforehand what kind of features you all need, but can we know that?

You're right - that's why I said

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

But the nature of minor releases is they have to ensure BC, so we should have a clearer picture about where we want to get to. These don't need to be of the level of detail of Fix x,y,z by doing a,b,c instead just Fix x,y,z, the details of a, b, c can emerge in the process (and will be BC) - if a, b, c, become contentious then the technical disputes section comes into play.

@catch56
Copy link

catch56 commented Oct 13, 2014

I think it's likely we'll want to come up with a list of things to aim for in minor releases - this got discussed at DrupalCon Amsterdam a bit. I've been meaning to write a up a meta-issue to talk about post-RC changes, but have not done so yet.

The big difference with some kind of minor version roadmap vs. 8.x initiatives:

  1. Getting something in within 6 months means the change needs to be quite focused and self-contained if it's going to be started/committed within that time frame.
  2. Sticking to a strict 6-monthly release cycle means even things that are encouraged shouldn't be merged if they might introduce critical bugs/follow-up. So it's possible something originally intended for 8.1.x might not actually be ready until 8.4.x or 9.0.x in the worst case.
  3. While things that were actively encouraged might not be ready, things that weren't but people worked on anyway might be.
  4. For both #2 and #3, they can probably be implemented in contributed modules until they're included in core which takes some of the final commit pressure off a bit.

So a list of "if people worked on this and it was ready we'd love to have it in core" sounds good. A roadmap per minor version seems like a lot of things would slip and potentially result in unrealistic expectations.

@larowlan
Copy link
Author

Agree with concept of 'if people worked on this and it was ready we'd love to have it in core' rather than formal roadmap, and notion of contrib first

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment