On Tue, 11 Oct 2005, Richard Archer wrote:
Steve raises an issue that has really been bugging me this week.
There are currently 260 or so patches in the Drupal issue tracker. Lots of these are worthy patches... like the two Steve mentioned. But so many of them have little or no chance of being reviewed and applied.
Anybody can review patches.
There must be dozens of people beavering away making improvements to Drupal and submitting patches only to have them get lost in this ocean of issues. Such a waste of resources.
There are many worthy patches, but there are also many patches that simply lack the quality to make it for Drupal core. Or also implement features which apparently nobody but the original author needs or wants.
Something needs to be done to address this issue.
Yes.
I have looked through the issues tracker reading the comments and following the progress over time of quite a few issues. It's actually quite sad to see a patch get written, reviewed, finalised and then not committed only to see the issue revived 6 months later, the patch gets updated, reviewed, approved and not committed. 6 months later the issue gets revived by someone else bitten by the same bug.
It also happens that some patches get finally committed after more than six months time. :p Some of them were simply not ready (revisions patch) others were ready but not deemed worthy (node modules controll title patch).
What can we do about it?
I would like to see ten or so issues at a time nominated as "hot" issues which are targetted, resolved and committed. I think that by focusing on just a few issues at once that these ones will get completed and all Drupal users will benefit from these incremental improvements.
This is an excellent idea which has been brought up on the conference list, too, and will be executed in Amsterdam. Since I will get to chair this particular session, I'd very much like everybody to make lists of their favourite bugs or patches and send them to me off list. One restriction: Patches should address bugs, not new features. I will consider new features that you claim to be usability bugs, though. Please make a list like this: http://drupal.org/node/xxxxx bug about foo.module being broken on screen bar Only core module bugs should be on the list. I will publish the concatenated list somewhere on drupal.org. I'll probably add a book page for this so you can also post comments there.
These need not be big patches or implementations of extensive new features. Small patches like Steve's help text improvements are just as worthy of inclusion as a new forms API - and a whole lot simpler :)
As I understand it Steve now gets to update the handbook.
There just needs to be some mechanism to focus resources on a small subset of patches so that they get reviewed, approved and committed.
There will be one one-hour bug squashing meeting per day. The way I envision it to work is that I will assign one bug per developer, they look at it, come up with a patch or revive an existing patch, demonstrate that it is a) working and b) up to standards. Ideally Dries and Steven can then just commit the patches. Since there will be a lot of developers the bug list can get lengthy, don't be shy. Cheers, Gerhard