Goals:
Here are some ideals I'd like to see in Drupal core development:
- There is a process by which the quality of Drupal can improve.
- Non-coders can participate in planning.
- Maintainers have a well-understood reason for saying, "No."
- Everyone can do a better job of estimating their real level of participation in core development.
- Time is structured such that we respect the time and effort of others.
I want to talk about that last one: Everyone's time and effort is valued.
After being an 'issue mover' in Drupal 8, I realized the single biggest waste of time in the Drupal core process is the 'Needs reroll' tag. It is the canary in the coal mine of Drupal. Generally, it says: This issue has gone unaddressed for so long that core changed underneath it.
Needing a reroll means that the time that went into a) deciding to create the issue and then b) fixing the problem and then c) making a patch is still not enough.
Thus, even though it's important to reroll things when it's necessary, it's also a signifier of wasted time.
I hereby declare that the atomic unit of wasted time in Drupal development is the 'Needs reroll' tag.
This is why I've adopted the attitude that an issue marked 'Needs review' is more important than 'Major,' because if we don't review it, it will waste someone's time.
As of this writing there are around 200 issues tagged 'Needs reroll' in the 8.0.x branch.
So, given this, we need to retool.
We need to redesign our process such that we have a time for design, a time for building, a release time, and a short cycle which can feed back on itself. This structures time such that we can address what needs to be addressed, and avoids wasting time on stuff that's not relevant.
We also need to strike a balance so that there is room for a little chaos which can benefit everybody.
Agile. Right?
Well, not quite.
To Begin With
Drupal 8 has adopted a semantic versioning release cycle. Soon we'll see a release of Drupal 8.0.0. Soon after that, there will be 8.0.1, 8.0.2, and so forth.
Then, six months later, there will be 8.1.0.
This means there is a finite time to accomplish things. But what to accomplish?
Let's take it as read that there will be bugfix issues filed against 8.0.x, and these might end up being filed against 8.1.x, so those need to be addressed.
But that sort of fix aside, we can and should engage in a planning process for the bigger picture of the minor release.
Make A Plan 1: The Plan Directory
The first third of the Drupal 8.1.x process should be a planning process. If the interval is six months, then two months should be spent planning only.
The aforementioned existing bugfixes aside, no code changes should be made to the 8.1.x branch during this process.
Instead, there should be 'Plan' issues filed against 8.1.x.
These issues should contain patches. The patches will add or amend text files in a new directory called plan/. The text file will be named for the issue number.
E.g. Issue #23 would patch a file called plan/23.txt.
This gives all interested parties the opportunity to discuss the desired outcome before any code is written.
Specifically: This also allows non-coders to participate in the discussion.
The text file will contain a proposal, feature request, or requirement. Plans should have as narrow a focus as possible and be something that can be accomplished in 4 months.
Ideally, plans should not contain implementation details.
Plans can have harder requirements, such as 'Must run in PHP7.'
Plans must be limited in scope so that they can be easily discussed and summarized, and eventually implemented.
Here's an example of a plan:
Plan: Support MySQL, PostgreSQL, and SQLite.
Reason:
Lots of users with different databases.
Requirements:
- Support recent versions of these databases.
- Use databases in continuous integration.
- Pass all tests.
If that looks a little like BDD, it's intentional.
During this phase, the normal issue process applies. Plan patches are marked as Needs Review, criticism comes with Needs Work, consensus is marked with RTBC.
At the end of the planning proposal phase, all RTBC plan text files are committed to the repo. All other plan issues are marked as postponed.
Make A Plan 2 - The Vote
Now that we have requirements from the plan files, we need to know which ones are more important in the larger consensus.
So we vote in order to determine priority.
Some system is invented which allows drupal.org users to vote on their favorite plan. They only get at most 3 votes.
The voting phase lasts for at most a few weeks.
This is not a vote for inclusion or exclusion; this is a vote to discover the priority of the plans.
At the end of this phase, the plan/ directory is modified so that file names begin with their vote tally, allowing an alphabetical file listing to represent priority.
Follow The Plan
Since the work phase is relatively short (4 months), it will be relatively easy to stick with the highest-voted issues. Complaints of not getting something in to core can be ameliorated by offering that the next plan phase is less than 4 months away.
Issues should have a plan issue as the parent. This way the connection between the plan and the code can be clear to everyone.
Any issue without such a plan can still be considered, but gets lower priority than any plan-related issues.
When it comes time for a maintainer to review issues, they can start with issues related to the current highest-voted plan.
Similarly, developers can start at higher-voted plans and begin work, or they can work on other plans. Or, as noted, they can work on whatever they want to.
When all of a plan's child issues are marked fixed, and the plan issue is deemed to be accomplished, a patch is generated to remove the plan file from plan/.
This removal gets RTBC'd, the patch is committed, and the plan has been accomplished and can be closed.
Beta/RC
The last month of the release cycle is the pre-release phase. At this time, all remaining items in the plan/ directory are removed, and their associated issues are set to Postponed.
During this time, issues must have beta summaries, similar to those used during the 8.0.x process.
We can allow test improvements, documentation changes, and critical bugfixes.
Release!
Since the release cycle is fixed to six months, this pre-release phase only lasts for a month, and then the final release happens.
There is cheering and happiness.
Plan issues which were postponed get re-assigned to the next minor version and are marked Needs Work.
Why Go To The Trouble?
Because we always go to some kind of trouble, so we should choose the kind of trouble that makes sense and doesn't force us to duplicate effort or otherwise waste time.
Or, to put it in better terms, here is what everyone gets from sticking to the process:
- There is a process by which the quality of Drupal can improve.
- Non-coders can participate in planning.
- Maintainers have a well-understood reason for saying, "No."
- Everyone can do a better job of estimating their real level of participation in core development.
- Time is structured such that we respect the time and effort of others.