688464 - Declare request bankruptcy

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Gervase Markham [:gerv]]

As part of the proposal for dealing with the request backlog:
https://wiki.mozilla.org/BMO/Request_Queue_Proposal
we should declare a partial request bankruptcy.

Specifically, we should unilaterally cancel all requests older than a certain date - let's start with 6 months for everything and see how we go. (Later, if it seems to be a good idea, we can do further mass cancellations of categories like e.g. closed bugs, or reviews requested of inactive people.)

We should add an apologetic message, like the example below.

Gerv


One or more requests on this bug (such as review, etc.) have been cancelled because they have been outstanding for more than six months. This is, perhaps surprisingly, part of a Mozilla initiative to be _better_ at responding to requests. We are "declaring bankruptcy" on old requests, and asking people to reinstate them if they are still applicable. We then are setting up a community expectation of a timely response.

So, if any requests which were removed are still applicable, or would be after the patch is refreshed, please do that and then reinstate the request. Thanks!

The bugzilla.mozilla.org Admin Team

Comment 1

[Ed Morley [:emorley]]

Is it worth adding a whiteboard annotation in addition to the reply message, along similar intentions to bugs that are currently marked as [patchlove] / [has patch] ?

Comment 2

[Gervase Markham [:gerv]]

Ed: in what way would that be useful?

The point of declaring bankruptcy is that your former debts have no hold on you. Therefore it would be counter-productive to make it easy for core Mozilla contributors to go back through the list and judge all of the requests. We want bug reporters, or interested parties, to do that. Core contributors will be busy enough dealing with the requests which are not older than six months :-)

Gerv

Comment 3

[Ed Morley [:emorley]]

(In reply to Gervase Markham [:gerv] from comment #2)
> Ed: in what way would that be useful?

Perhaps it isn't, I don't know.

I was just thinking more in terms of a variation/next step on from |good first bug| whereby potentially complete, but just needing rebase+review patches could be sifted through by volunteer contributors if desired. I have seen the [patchlove] whiteboard annotation (and a few variations) being used manually on bugs in a similar state, which is the only reason I mentioned it :-)

However, I imagine the utility of such annotations is somewhat dependent on what percentage of these reviews were ignored due to major problems with the attached patch/the bug no longer being relevant, vs those that are almost ready to land and just need rebase+review.

Comment 4

[timeless]

Offhand, i don't think this is the right approach.

Instead, start whining about requests that are say 10 years old. Demand that all owners of such requests review those requests and close them.

Once you've dealt with those requests -- which shows you have people capable of dealing with requests, move your target to 9 year old requests.

Change the target monthly (or ever two weeks).

Eventually you'll get to a point where you've shown that you have people capable of dealing with requests.

Bugzilla has declared bankruptcy repeatedly (see RESOLVED INCOMPLETE), but it doesn't fix the fundamentals of the economy (ask Tanner).

Comment 5

[Gervase Markham [:gerv]]

I agree that declaring bankruptcy on its own does not fix the problem, unless you have other things in place to prevent a recurrence. That's why I have not proposed bankruptcy in the past. But now, I have written a request whining extension which will hopefully help us keep a lid on the problem.

We could whine about every request in Bugzilla rather than just the last 6 months, but there's a cost-benefit analysis. If a request is open more than 6 months, it almost certainly needs some work from the requester.

Gerv

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to Gervase Markham [:gerv] from comment #5)
> I agree that declaring bankruptcy on its own does not fix the problem,
> unless you have other things in place to prevent a recurrence. That's why I
> have not proposed bankruptcy in the past. But now, I have written a request
> whining extension which will hopefully help us keep a lid on the problem.

This theory seems to assume that the primary cause for review requests not being addressed promptly is that reviewers are not aware of the requests. That may be a factor, but my impression is that it isn't significant compared to the real problems of reviewers being overburdened, and some areas of code not having [m]any suitable reviewers. Whining doesn't really address those problem in any significant way.

I think that very old requests should be canceled rather than left pending indefinitely, but I think it would be highly preferable to first encourage requestees to do that themselves (where possible) rather than it being automatically (the encouragement could be automated, though!). It's not pleasant (I've had to do it myself), but it forces you to explain what caused the delay in review and what can be done to avoid it in the future. It also helps identify problem areas (if I can't come up with "ways to avoid review delay in the future" for a given patch in my module, that's a problem I need to address separately).

Comment 7

[Gervase Markham [:gerv]]

gavin: so you are saying we should enable the automated review notifications without first doing a bankruptcy, and perhaps consider doing the bankruptcy later?

Gerv

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Yes, I suppose. I think it would be good if the notifications specifically encouraged requestees to cancel requests that they know they won't get to, or that have been pending for significant amounts of time. And it probably makes sense to do it as a one-time thing, at least initially, and see how much it helps.

Comment 9

[Gervase Markham [:gerv]]

OK. We'll not implement a bankruptcy for now. We'll turn on the whiner instead, and see what happens.

Gerv