Re: Incentives for review

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> writes:

> 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 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.

I don't have time to work on this, but here are some ideas. Some of these 
capabilities are present, but maybe not discoverable or a pre-built clickable 
link while viewing a patch/issue.

- Contextual search based on a path.
  - Show me issues/patches for this file/directory
  - Show me the rate of change of this file/directory

- Contextual search based on a patch
  - Show me bugs which mention any top-level public symbols changing in this
    patch, or if packages, the package name.
  - Show me patches which conflict with this one.
  
- Contextual search based on author.
  - Show me other patches by this author
  - Show me the median time-to-commit for this author's patches

- Show me patches/issues, grouped by author, sorted by median time-to-commit,
  descending.
- Show me the paths/files with the highest number of bugs reported.

A lot of this requires static analysis which may not be trivial to implement. 
Still, I think being able to say "we don't have time to build what would fix 
this" is a helpful progression from "we don't know how to manage this backlog".

Thanks for pointing out the source code to mumi!
  
-- 
Katherine