State of the issue queue

The past two-three weeks I've spent a lot of time in the Drupal 6 issue queue. This involved a mixture of reviewing patches I really wanted to see get into Drupal 6, writing or re-rolling some small patches for small bugs and typos, and trying to clear the issue queue as much as I could down to a manageable size. I commented on something like 160 issues in seven days, and read through many more.

Looking at so many issues in a small space of time gave me a pretty good overview of the situation in the patch queue as a whole, and an IRC conversation with webchick, senpai and chx prompted me to write this up.

Although I didn't keep notes as I went along, these are my rough impressions of how things are in general. It's hopefully a bit better than this now of course.

The vast majority of patches in the review queue needed work, of these, most needed a re-roll because they weren't reviewed for months after being posted. Probably 5-10% of patches are duplicates of other patches needing review or work, and another 5% have already been fixed somewhere along the line.

There are several factors contributing to this, many feeding of each other.

1. More people are writing patches than reviewing them.
2. The issue queue is so big that it's hard to know if you're creating a duplicate issue without extensive searching (especially bug and performance fixes).
3. This results in duplication of issues and patches, often by people who may be one of a small number who could adequately review each other's patches.

Berating people to do more reviews won't work most of the time, so here's a few suggestions as to how this could be dealt with:

1. Developers (and regular reviewers) should be encouraged to write up 'how to review this patch" instructions especially for simple bug fixes and functionality reviews. There are instructions on how to report bugs in the issue form, but not how to present patches. Chx's e-mail to the development list meant that the temporary tables in search module patch got a review where it otherwise wouldn't have. Wim Leer's encouragement on the drupal_lookup_path whitelist issue got me properly interested in working on the issue queue seriously.

2. "Duplicate" and "won't fix" issues shouldn't be hidden from "My issues" when marked as duplicate - reviewers often link to the active issue when marking as duplicate, but between my issues and the other contributor links, you'll not find them again easily. Ideally they should be treated the same as fixed - left in 'my issues', then eventually marked closed via a cron job to keep things tidy later on. Some of these issues have dozens of posts on, and decent code, so it's worth having them stick around for a few extra days.

3. When looking at the issue queues itself, there's no way to know what's required in a review usually - is it code/code style, functionality, removing notices, ui, benchmarking, concept, architecture? Rather than more fixed categories, webchick suggested a free-tagging vocabulary. This would be useful for say marking patches for particular types of review, and when going to needs work, things like "re-roll" or "code style" or "doxygen". This would require the issue followup form to allow for setting the taxonomy terms though, but I reckon it could make quite a big difference and break to main queue into more manageable chunks.

Will open feature requests against drupal.org for those last two now.

I also think the fact that core modules (forum/taxonomy) etc. don't have their own dedicated issue queues (or branches for testing) as available to modules in contrib is negatively impacting the attention they get, but have already said the same here so won't repeat those arguments.