Triaging and labelling the backlog

[Pierre-Sassoulas]

Current problem

We introduced new label to know what needs to be done for an issue recently (actionable label starting with "needs", "require" or "waiting") in #6999. We also have a backlog of issues with numerous issues, some outdated (fixed, or not relevant anymore), some duplicated, some where a decision needs to be taken. Once all issues are labelled it's easier to know what needs to be done and for contributors to help us.

Desired solution

Check the issues that do not have any actionable label, and label them. If a decision is hard to come by fast then it's possible to add the "need investigation" or "need reproduction" labels. I encountered some issues that are both high effort and minor and I think we could close those directly (but I did not close them yet).

Additional context

I've done some digging recently and closed around 40 issues. A third of the issues are labelled with something actionable now. It triaged the oldest issue first so I don't expect to close 80 issues with the two third that are left but every closed issues helps (especially to prevent new duplicate from being created as the broken windows theory apply to the backlog imo).

[DanielNoord]

Well done @Pierre-Sassoulas. I saw a lot of notifications of stale and old issues getting closed.

I'm adding this to the 2.15 milestone so we don't forget to close this at some point.

[Pierre-Sassoulas]

I don't expect to triage 450+ issues (plus additional activity) until 2.15. This is a never ending effort so I'm going to close this issue with a documentation PR that add a "labels" and "searching for something to do" part in the contributor guide (with useful links like the one to get issues that do not have actionable label).

[DanielNoord]

Just one more thing about the Needs PR label. I think it would be good to try and narrow down stuff like edge cases, message names and designs before adding it.
That way the PR review can focus on implementation review instead of on semantics which could be resolved without any actual code being written.

[Pierre-Sassoulas]

I like that. I added a "need design proposal" label this afternoon, but I had only very big issues / features in mind when creating it. What about "needs specification", it feel lighter and we can detail what we means in the label description ?

[DanielNoord]

I think name and smaller design decisions can still fall under Needs decision. While Needs design proposal signals that we appreciate somebody else to propose something that we can respond to, Needs decision just signals that a maintainer has some more smaller choices to make before a contributor can start working on it.

Needs decision: a maintainer needs to make decisions
Needs design proposal: we're looking for a suggestion on how to solve this to which a maintainer can then respond
Needs PR: this design is finished and can be implemented.

Ideally Needs PR leaves issues in such a state that a new contributor can read them once and start implementing without having to come back to the issue and asking follow-up questions. Stuff like test and edge cases, names, where to put the file etc. could all be helpful.
That's not to say every issue needs all of those, but the contributor shouldn't need to make too many decisions themselves.

[Pierre-Sassoulas]

I think name and smaller design decisions can still fall under Needs decision.

I'd prefer to keep a clear distinction between "This issues is approved, could be added to pylint and we need to think about the edge cases, message names and small details" and "We're not even sure we want to do that".

[DanielNoord]

I'd prefer to keep a clear distinction between "This issues is approved, could be added to pylint and we need to think about the edge cases, message names and small details" and "We're not even sure we want to do that".

Isn't thinking about the name and edge cases part of that approval process? If we haven't thought about that how can we be sure that we want to add it?

[Pierre-Sassoulas]

I think we can recognize something would probably be valuable without entering into too much detail it's a signal that it evolved from a proposal to something we need to specify correctly. It's a "checkpoint" to reach for the person opening the issue : proposal accepted. It means it's not a waste of time to think about edge cases and a really proper naming both for the original poster and would be contributors.

For example in this issue labelled "needs PR": #5047 if we were going to reject the general principle, it would be a waste of time to think of all the edge cases. This would be a prime candidate for "needs specification".

[DanielNoord]

Yeah, perhaps that's a good in between step. We should be wary not to complicate this too much though. I agree that Needs PR doesn't need to have everything set in stone, but we should at least try to fix some of the basics. Having 2/3 labels that all indicate the same but slightly different state of an issue adds complexity which is what we're actually trying to remove 😄

[Pierre-Sassoulas]

Only 250 issues lefts to triage, and we closed yet another 60 issues ! When something stays open it's often control flow or false positive when creating the ast for a library, something that would require enormous work in astroid. I'm wondering if we should group these "my variable is initialized as None but can never be None at line x" issues together or close them as duplicate. This would sure make one hell of a cleanup.

[jacobtylerwalls]

"my variable is initialized as None but can never be None at line x" issues together or close them as duplicate. This would sure make one hell of a cleanup.

+1. One issue is plenty for that. Some of them could be turned into test cases for the first astroid constraint PR.

I started styling #1162 as the master duplicate for isinstance type-narrowing.

[Pierre-Sassoulas]

There's also #4795 to discuss the control-flow design.

[Pierre-Sassoulas]

The result is here : https://pylint.pycqa.org/en/latest/development_guide/contributor_guide/contribute.html#finding-something-to-do