Triaging Drupal 8
A month ago, I wrote about the growing technical debt in Drupal 8 core, and the impact this would have on Drupal 8's release date. Since that post, 88 of Drupal 8's major and critical issues have been fixed. The week of API freeze, we reached an all-time record of 35 of these top-priority issues fixed in a single week, among 84 total core commits that week. Given the dozens of volunteer hours that might go into every single issue, this is a truly phenomenal effort by the Drupal community. We're making great progress, and there's lots of work still to be done, so we need your help on these important issues.
Technical debt discovered and fixed each week. Eventually, the blue line should remain negative.
You might notice that the first month of this graph looks a little different from the one in the last post. The reason for this is that the community continues to reassess the status and priority of issues. (So, an issue that was discovered back in April, but only prioritized recently, won't appear as a new issue here.) We call this reassesment triage, and it's an important part of finishing essential work on Drupal 8.
So how are we doing? Let's take a look at the data from drupalreleasedate.com, which tracks snapshots of the major and critical counts in real time:
Yikes!, you might think. What's going on? Why did our critical account shoot up right before API freeze, and why does the number of majors continue to increase?
Once again, it mostly comes down to issue triage -- and it's actually a good thing. During Drupal DevDays Dublin, we took the time to re-evaluate many issues. In particular, we looked for issues that must be resolved before we can release Drupal 8, and made sure these were filed as criticals. We also increased the priorities of sub-tasks for "meta" issues. Where previously one critical issue might have been a "wrapper" for five issues, now, those five issues have been promoted to (say) three criticals and two majors. So, it's not that there are many new problems, but rather that we're doing a better job of identifying the serious problems that already exist.
Another thing worth pointing out is that many of our "new" critical issues in the graph above actually reflect work that's already done! When we make API changes, we add critical tasks to document the API changes, to ensure that core developers and contributed module authors have the information they need on converting code to Drupal 8. Once this documentation is written, those issues are removed from the list.
Still, the high issue counts are worrisome, and the problem is even bigger than we previously thought. Not only is there a lot of work to do, it's hard to know what's most important when there are so many issues.
We need your help to clean up the major and critical queue
There are six important ways you can help triage issues in the major and critical queue to help Drupal 8's velocity.
Write change notifications
Currently 29 issues are in need of API change notifications. As I described above, these are critical documentation tasks that are added when we change public APIs. Help trim down the critical count by drafting this important documentation and having the patch authors review it.
Update issue summaries
Issue summaries are a key tool to help contributors and core maintainers understand the goals and status of an issue. Update issue summaries to include:
- A concise, scannable explanation of the issue's goal and why it matters.
- Why it is major or critical. (Example.)
- A concise explanation of the proposed resolution.
- The remaining tasks or next steps.
- A complete list of even minor API changes. (See below.)
Identify API changes
- Read patches closely for even minor API changes.
- Document every specific API change in the issue summary. (Example.)
- Tag any issue that introduces a change with API change.
- Ask a core maintainer about proposed API changes as soon as possible, when or before posting the patch that contains the API change.
The Drupal community needs to know what post-freeze API changes are approved by maintainers. If you think an API change is necessary, speak up as soon as possible so that a core maintainer can provide direction.
De-prioritize less important issues
Just as we've increased the priority of some issues, we need to decrease the priority of others. It might be set incorrectly, and it might also have changed over time. Help focus attention on more important issues by demoting less important ones. If you suspect an issue should have its priority reduced, but aren't entirely sure, ask for help to decide. You can ask a core or component maintainer, or ask in the #drupal-contribute IRC channel.
Move or close issues that are no longer relevant
Some issues might no longer be relevant, especially older issues that have been obsoleted by more recent changes:
- If the issue is a problem that exists in Drupal 7, but not in Drupal 8, move it back to the 7.x branch.
- If you think a task or feature request is too broad a change to be accepted after API freeze, consult others to confirm whether the issue should be moved to the 9.x branch.
- If the issue does not exist in Drupal 7, is no longer relevant in Drupal 8, and would not be relevant in Drupal 9, locate and reference the issue that made it obsolete, and either mark it Closed (won't fix) or Closed (duplicate). (See the issue status documentation for more information.)
Focus on what matters
Finally, focus on what is most important. The Drupal community's time is valuable, so we need to spend that time wisely. Every Drupal core commit needs to move Drupal 8 closer to a releaseable state.
Please help out however you can, and be sure to thank the over 1500 contributors who have worked on Drupal 8 so far, especially those who tackle major and critical issues every week.
Raw query results
Core metrics queries are documented in the Drupal.org handbook.