Re: Incentives for review

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> > It’s not about urgency but rather about not contributing to the 
> > growth
> > of our patch backlog, which is a real problem.
>
> I have often seen folks on various projects worried about the 
> size of
> various backlogs: bugs, issues, etc. I think it is human to want 
> to
> try and contain something that appears to be growing, unbounded.
>
> I think the thing that bothers us is a sense that the backlog is
> becoming unmanageable, or too large to triage. I submit that 
> this is
> actually a tooling and organizational issue, and not an 
> intrinsic
> issue to be solved. Bugs may still be valid; patches may still 
> have
> valuable bones to modify.
>
> I think the real issue is that as a backlog grows, the tools 
> we're used to using cannot answer the questions we want to ask: 
> what is most relevant to me or the project right now?
>
> To me, this sounds like a search and display problem.

I agree with your analysis.  And with your earlier comments about 
the vagueness of what review means and how it can lead to a 
failure to communicate.

At least on the side of presenting submitted issues I’m sure we 
can do better.  One attempt in the past was to automatically bring 
up “forgotten” issues to the fore; Thiago’s idea to allow people 
to subscribe to certain *kinds* of issues when they are reported 
is also good.

I would be happy if people used this opportunity to change mumi 
(the tool behind issues.guix.gnu.org) to present the backlog in 
more helpful ways.

Here’s the code for reference: 
https://git.elephly.net/gitweb.cgi?p=software/mumi.git

--
Ricardo