Declare request bankruptcy



6 years ago
6 years ago


(Reporter: gerv, Unassigned)







6 years ago
As part of the proposal for dealing with the request backlog:
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.


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 Admin Team

Comment 1

6 years ago
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

6 years ago
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 :-)


Comment 3

6 years ago
(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

6 years ago
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

6 years ago
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.

(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

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

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

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

Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.