Janitor in the issue queue

2 minutters læsning

For completely selfish reasons, I have helped clean up the issue queue for a couple of projects. I say selfish because, I figured if I could reduce the number of bugs (read: distractions) from the developers of the modules, then maybe they would pay attention to my issue quicker.

Therefore I have been cleaning up in the issue queue for entityreference, colorbox and media gallery and to a lesser extent for some other projects. The issue queue often grows out of control, if the developers are too busy.

That is where most Drupal users can lend a hand. Here are some of the things, that I do, when digging into the issue queue.

Getting rid of those stale, old issues. First I arrange the issue queue by date and takes the oldest issues first. Then I start to see whether I can get some of those issues closed. Either I set the status to postphoned (the maintainer needs more info) and asks whether this issue has been resolved.

Getting bugs confirmed in newer versions. Then I arrange the issue queue by version number, and I dig into all those issues that are open for older versions. I ask whether the creator of the issue has tried with the latest development version of the project. I set the status to postphoned (the maintainer needs more info).

Answering support questions. Then I try to answer the questions in the issue queue, that I know the answer to.

By now, there is already progress.

Close issues for inactivity. Then I wait for 14 days and I come back. I choose all the postphoned (maintainer needs more info), and if nobody answered within that period, I set the issue to closed (won’t fix) by reason of inactivity.

Doing that work, I hope, make the life easier for the module maintainers, so they have more time to help me with my issues :)

Some work could be automated

Some of this work could be automated a bit. There is already the automated approach, that a fixed issue will be set to Closed (fixed) after 14 days. But a lot of the questions in the issue queue are questions that nobody remembers. Here is my proposal:

Issues on old versions should be reprompted. The issue tracker could create a new comment in an issue, if a new version of a project is published, and there is still issues on an old project. The comment could simply be: “Is this still an issue in the new version of this module”. If nobody updates the version number for that issue within a given period of time, the issue is closed.

Open issues with no activity. If issues are open let us say half a year, a new comment could be made: “Is this still an issue for you”. If nobody replies, the issue can be closed automatically.

That way the issue queues could be a little easier to manage.

Start digging into the issue queues

So start digging into the issue queue of your choice. Actually, you will end up learning something along the way. And what is your opinion about the automated issue queue?



Thanks for all of your work in the issue queues! I’m sure the module maintainers appreciate it. Hopefully, other users will follow your lead and also start to help keep things in order. I think that you have some good ideas about automating some issue queue activity, but it would have to be done with caution. I think it would be a good idea to close “maintainer needs more info” issues after 1~3 months of no activity, but auto-promoting old issues might create unnecessary noise not desired by module maintainers. Some issue queues are quire large – Drush has nearly 600 open issues right now. That could lead to a fairly steady stream of old issues getting promoted back to the top of the list. If no one has touched an issue in a long time, perhaps it is not a very important issue, and doesn’t need to be promoted. On the other hand, if the automated system also set the status of these old issues to “maintainer needs more info”, then perhaps it would be easier to filter these old issues out when dealing with new reports. With this addition, automated promotion might be a useful thing to have.


So, you ask if the issue is resolved, and then close the issue if no one responds in 14 days? That seems rather cruel and disrespectful to me. If the issue description has enough detail for you to reproduce it, then you owe it to the reporter to TEST the issue before you suggest that it might be resolved. If you’re too lazy to test the report for yourself, then you aren’t “cleaning” the issue queue, you are vandalizing it. I know I’m going over the top here, and I suspect that the vast majority of your actions are totally justified! But your process as described is too disruptive. If there isn’t enough information to test the issue against dev or the latest release, then by all means go ahead!


Is there any (n)etiquette surrounding doing this kind of work? Should one contact the maintainer before diving in and changing issue statuses or just go ahead and do it?


Thanks for your comment. Off course, I do not close important issues which have a lot of detail without trying to reproduce it. But the majority of issues have very little details. I am probably wrong sometimes, but the reporter can always reopen the issue again.


I’d be very wary of doing this automatically, particularly the “is this still a problem in the current version” question. From the bug reporter’s point of view such an email is a reminder that work is being done on the module, but there bug isn’t important enough to be fixed. It might be true, but it’s not a very friendly message to send!

Skriv en kommentar

Din e-mail bliver ikke offentliggjort. Obligatoriske felter er markeret *