We want to take some action about outstanding requests (review, approval, feedback, etc.) in Bugzilla. Leaving requests outstanding for a long time is particularly demotivating to new contributors. There is a plan.
One action we are taking is that we will be enhancing Bugzilla to send out weekly emails to anyone who has an outstanding request older than 7 days, listing the bugs on which all their requests can be found. A sample of such an email can be found below. So we want to warn you to expect it, and we hope that this gentle reminder will encourage people to keep their turnaround times short.
We have written a draft guide to what is and isn’t acceptable community practice in responding to requests. Review of this document, and whether the community norms it attempts to establish are realistic, would be appreciated.
The metrics team plan to roll out some Bugzilla metrics very soon, which will enable us to track how successful this drive is.
Sample request whine mail:
Here are your outstanding requests older than 7 days:
review
------
Bug 1: Hollywood Bowl has majority market share (76 days old)
http://bmo-4.0.localhost/show_bug.cgi?id=1
Bug 11: Lane 12 keeps racking up only nine pins (75 days old)
http://bmo-4.0.localhost/show_bug.cgi?id=11
Bug 12: Bowling ball holes are too small (71 days old)
http://bmo-4.0.localhost/show_bug.cgi?id=12
Bug 13: Pins keep getting racked upside down (65 days old)
http://bmo-4.0.localhost/show_bug.cgi?id=13
wanted
------
Bug 3: Vending machine does not accept 10p pieces (8 days old)
http://bmo-4.0.localhost/show_bug.cgi?id=3
To see all your outstanding requests, visit:
http://bmo-4.0.localhost/request.cgi?action=queue&requestee=email@example.com&group=type
For guidance on handling requests, see:
https://wiki.mozilla.org/BMO/Handling_Requests
Hmm. Formatting on the sample mail is a bit off – some WordPress issue with <pre> tags, I suppose…
Gerv
I hope there is a way to disable these notifications. It’s a pain to get such emails every week. We all know we have reviews to do, and we do our best to review them. But unless you are employed by MoCo, the “what is and isn’t acceptable community practice” doesn’t apply to reviewers, as we all do Mozilla stuff on our free time. I hope that each reviewer does his best to review patches as soon as possible, but that’s not always possible. Such emails would be considered as spam by me (“spam” meaning “undesired emails”). I already have my own whine events to track what I need to track.
You can, of course, do with the emails what you like, but consider the person who has made the request. Particularly if they are new, it’s very demoralizing to get as far as making a patch, and then have it ignored. If you can’t do it inside two weeks, why not pass it to another member of the Bugzilla team?
Gerv
I’m surprised that the request queue proposal document doesn’t cover two things:
1) Requests from the “wind” (no-one requested)
2) Requests on closed bugs
The first is frequently just a mistake, but shouldn’t be allowed to go on for more than a day or so without correction. The second is something I think there is general agreement that doing things on closed bugs is generally bad and they should either be reopened or a follow-up filed. If a bug has been closed and a review posted for at least a week, why is either the bug closed, or why is the review still present on that bug (could it be that someone got multiple reviews and just closed the bug without removing the old reviews).
IMHO a request from the wind should be taken care of by any owner or peer of the relevant module passing by — not necessarily by handling it himself but at least by designing as reviewer someone who is known to be competent and available. Of course owners and peers should watch all bugs on “their” modules. What this of course leaves open is the quesion of unowned modules — and some very important modules are unowned, e.g. Firefox tabbed browser.
Requests on closed bugs sound like an error to me: a patch which is obsolete but wasn’t marked as such, or forgetting to REOPEN a bug before correcting an error in the fix, or posting an attachment on the wrong bug, or posting a followup on the bug itself when a new bug would have been better. And of course the error should be corrected as soon as it is noticed.
The usually accepted meaning of spam is UBE/UCE, i.e., undesired bulk or commercial email. Such a “request reminder” email would be neither bulk or commercial, and IMHO anyone accepting a position of owner or peer of a module implicitly accepts to review proposed fixes for that module, and, if necessary, to be reminded of outstanding reviews if they wait for too long. Normally a week, or two at the outest, sounds about right to me, except if the reviewer is on holiday or on a business trip, or maybe very busy professionally (I’m thinking of a teacher correcting end-of-semester exams but I’m sure there are other examples), in which case he ought to take measures to have his reviews handled in some fashion while he isn’t available.