Nixpkgs: Proposal: improve triaging workflow

[ericsagnes]

Current state

We have a high flow of issues, few triagers that results in many forgotten/oudated issues and an always increasing number of issues.
This is not healthy for the project, and improving triaging could only bring benefits.

Propositions

Add triaging guidelines

Looking around, I found that angular.js has a triaging.md with guidelines for triaging.
It could be a good starting point to set triaging guidelines in nixpkgs.

Call for more triagers

At the moment, there are only a few triagers. They cannot catch with the high flow and number of issues that a project like nixpkgs get.
We could get bring more focus on this part of contributing by for example sending mail on the ML and give more people the rights required for triaging.

Increase responsibility

On the 1222 opened issues, 1117 are unassigned.
Assigning more issues would improve responsibility, and hopefully get issues closed faster.

Reduce the number of issues

We have too much issues compared to the available resources.
And many of the issues are outdated and inactive.
Until we get a realistic issue number, I propose a more aggressive policy, specially on old and inactive issues.
For example, any issue that is not an enhancement and is inactive for more than 2 months without an assignee or a related PR, could be closed. (and reopened if someone show interest in it of course)

Add priority labels

We have a high number of issues and github issue tracker make it easy to overlook older important issues.
Priority labels could be a way to bring focus on more important issues.

List

• [ ] add triaging guidelines in a triaging.md
• [ ] call for more triagers
• [ ] reduce issues number
• [ ] add priority labels
• [ ] increase responsibility

Feedback is welcomed.

cc @joachifm @domenkozar @FRidh @vcunat

[danbst]

Another improvement, IMO, would be to force issuers to write proper test cases
Like in https://github.com/NixOS/nixpkgs/issues/16614#issuecomment-229611057, but also pinning nixpkgs version.

[FRidh]

I generally open issues with things that need to or could be improved. These are not necessarily bugs, but we need a place to write those issues down as well. Some might fit in the Nixpkgs documentation, some not.

The question I think we should ask ourselves is what the issue tracker really is for. If it really is for issues as in bugs, then fine, kick out everything else. But not before we have a place for those items as well.

[domenkozar]

For priority labels we have blocker, I wouldn't really go further by micro-optimizing since the priority could differ a lot based on who the issue impacts the most.

[ericsagnes]

Another improvement, IMO, would be to force issuers to write proper test cases
Like in #16614 (comment), but also pinning nixpkgs version.

The issue template is already asking for "step to reproduce", but there could be a need: more info label for cases where there is not enough information.

I generally open issues with things that need to or could be improved. These are not necessarily bugs, but we need a place to write those issues down as well. Some might fit in the Nixpkgs documentation, some not.

There should definitely be a special case with kind: enhancement issues and let them live as long as there are not implemented or obsolete.
Same should go for kind: question.

For priority labels we have blocker, I wouldn't really go further by micro-optimizing since the priority could differ a lot based on who the issue impacts the most.

My guess was that blocker is tied to a milestone and its usage was mostly before a major release of NixOS.

For example, in my opinion, while not being a blocker handling auto-generated data (#15480) should have higher priority than missing icons (#10419).

So having priority could help the other way, labeling less important issues with a lower priority, but you are right that it might bring some unneeded granularity.

[FRidh]

For example, in my opinion, while not being a blocker handling auto-generated data (#15480) should have higher priority than missing icons (#10419).

And that's what I think @domenkozar was referring to. It's an opinion, it's personal, it depends on who is affected, on who needs to do the work. Most labels we have describe a certain fact, e.g. that the issue is related to Python. Some not, like blocker, and with those you have to be a bit more careful then.

We should maybe emphasize more that those opening PR's or issues should cc maintainers. In the case of PR's we at least have the bot. It would help a lot if we had something like https://github.com/NixOS/nixpkgs/issues/13602.

[domenkozar]

@FRidh put it very nicely. Our priorities differ, instead of focusing on prioritization (meaning pressure most of the time) in OSS I've found that you gain maginutes of productivity by rather improving communication.

[vcunat]

I do agree that priorities are rather personal. There are many open issues and PRs, but I believe almost all of them just aren't interesting/important enough for most of the active contributors, so that's why they're left behind; I don't really see any problem in it, although the utility of such issues being open typically isn't too high.

_My personal workflow:_ I regularly skim the titles of all new issues and PRs, and participate in those that seem most important to me, and tag them, solve/self-assign them, etc. This includes stuff that I consider important to the whole project, e.g. vulnerabilities in commonly used packages, but that's still not fully objective. I prefer fewer and deeper participations. The auto-mention bot is also nice for this, as it's more efficient to keep around the same code than to jump around randomly. Then I try to keep up with those threads...

[Profpatsch]

triage: is this still a problem?

:smiley:

[baracoder]

(code triage again :grin: )
There are currently 2940 issues open. Looking at the project pulse there are slightly more issues created then closed in the last month, so it might be still relevant.

[Profpatsch]

I’ll help the situation a bit.