First office hours are this week, see http://drupal.org/node/1242856
A few of us have been discussing in irc ways to improve the triage of the core issue queue.
Several times per week, people join #drupal-contribute and ask for help getting started contributing to Drupal. Depending on who's in the channel at the time, they might be pulled into reviewing a specific core issue or contrib module, writing documentation, or if the channel is quiet just ignored.
To help structure this process better, we're proposing holding 'core issue queue office hours' a couple of times per week (or more regularly if enough people volunteer). This is not a new idea, Views already has a bug squad, jQuery has a a bug triage team (and fancy graphs), and the Usability team and some Drupal 8 initiatives are holding regular office hours or irc meetings.
There is no 'core development team' as such, however there are people who regularly work on core issues, as well as people who are regularly in the #drupal-contribute irc channel. For new contributors, it is not at all obvious who those people are, or how to get involved. Regular office hours will make it easier for people to join the effort.
There are a few different goals:
- provide a way for new contributors to get involved in a more structured way.
- actually get the core issue queue in better shape
- set up something that happens regularly, has its own momentum, and does not have a single person as a bottleneck as far as possible.
Drupal 8 and 7 now have 'issue thresholds', where a mini-code freeze is instituted if the number of critical and major bugs and tasks goes over a certain limit. This doesn't guarantee that any particular bug gets fixed, but it prevents new features being committed if there are too many serious unresolved bugs and clean-up tasks in the system.
This (so far) works for major and critical issues - at least in the sense that new issues in those queues tend to be closely scrutinized, and core committers give them priority. While the thresholds were being discussed, and shortly after they were agreed, the number of major bugs and tasks in the queue was reduced from over 300/150 to around 100 - due to a combination of recategorising issues, closing duplicates, and some of them actually got fixed as well.
However the 'normal' and 'minor' bug queues have no such thresholds (nor would it be possible to set a meaningful one with more than 2,000 in there).
There are over 2200 open bug reports against Drupal 8 and 7.
There are over 1750 open bug reports against Drupal 6.
There are over 500 patches at "needs review" status against Drupal 8 and 7.
Nearly 200 bug reports against Drupal 6/7/8 have 0 replies.
Why is this a problem?
There are a large number of duplicate issues in the queue. There are dozens of people who regularly contribute code to core, and hundreds over the course of a major release cycle. This means it is very easy for different sets of people to spend weeks, months, or even years working on the same bug in different issues - each without knowledge of the other. This not only wastes people's time, but in some cases (especially low traffic issues) people working on the bug may be completely separated from others who are reporting or confirming the bug and could test patches.
It can be demoralizing to contributors to post bug reports and get no response.
It can be demoralizing to contributors to post patches and get no response.
Some important bugs get 'lost' amongst all the others, then when they're eventually found get promoted to major/critical status and can hold up releases.
patches that are left untouched in the queue at CNR or RTBC status for a very long time go 'stale' - develop conflicts due to changes elsewhere, update numbering goes out of sync etc.. This adds a lot of overhead to each individual issue. Triage doesn't remove the problem of conflicts in general, but could increase the velocity of each individual issue.
new contributors who would like to help with patching core can be overwhelmed by the number of issues, and sometimes end up jumping in on an issue that should long ago have been closed.
How is triage done currently?
Core triage over the past few years has generally been done by a few regular core contributors, usually taking an afternoon or so out of actually working on patches to 'attack' the queue overall. This never scaled particularly well but has become increasingly unmanageable over the past 2-3 years as the amount of core issues in general has increased significantly.
There are also occasionally 'sprints' at Drupal camps, DrupalCons etc. on particular areas of the core queue. In person sprints are great but do not necessarily suit the way the core queue works (where issues tend to take a few days, weeks or months before resolution). Also sprints (rightly) tend to focus on getting patches written for specific issue, rather than focusing on the issue queue as a whole.
What will happen during 'core issue queue office hours'?
While this hasn't happened yet, the general plan is that experienced contributors mentor new people who want to get involved in the core issue queue. 'Experienced' and 'new people' does not necessarily mean 'chx' and 'newbies' though.
Tasks that can be done, this isn't an exhaustive list but gives an idea:
- verifying active bug reports, marking 'needs more info' if they look invalid, closing duplicates etc.
- writing up steps to reproduce and issue summaries
- writing up change notifications for issues that have been committed
- reviewing patches
- re-rolling patches
- writing test cases for bugs
This is the kind of thing that could use more documentation, there is some at http://drupal.org/project/patch but it is out of date and incomplete. We also need some dedicated documentation for the core issue queue since it has its own conventions. We could improve that documentation during the office hours as issues come up :)
A great place to start is to read Jacine's post about using GIT and creating Patches
To have effective office hours, we need at least the following two kinds of people to be around:
- Those who are familiar with core APIs should be available to answer questions/clarify specific issues - some core issues are a bit esoteric.
- Those who are familiar with tools like git, patch, dreditor and setting up LAMP stacks on Windows/Mac/Linux should be available for people who don't have a suitable local environment for core patch review.
We also need to promote the office hours, so that people who are interested show up (whether brand new contributors or people who want their own patch reviewed etc.).
Volunteers so far
Just these people are spread over multiple continents and time-zones, so we've started a doodle. At this stage we're trying to find overlap on weekly/daily availability rather than set actual dates/commitments. Adding yourself to the doodle does not mean you have to turn up at all those times or guarantee availability, it is mainly to find good time slots that may suit multiple people.
http://www.doodle.com/xk6s3yq8u76c2u2q (switch to the weekly view to see the time slots)
Ideally we'll set up two or more slots per week, with at least three volunteers per slot. Ones the slots are set we can then advertise this more widely and get it rolling.
This write up is based on (but not at all the same as) some piratepad notes worked on collectively by some of the people listed above, see http://piratepad.net/5wC7N6kF15.