Katherine Cox-Buday <cox.katherin...@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