Keeping the issue tracker healthy

[JelleZijlstra]

There are currently 2.1k open issues, and it's increasingly difficult to find duplicates and keep track of what's important to fix. I just spent some time adding more labels and applying them to issues without informative labels, based on this search result.

Topic-specific labels help in a few ways:

• Users reporting an issue can look through other related issues to find duplicates or workarounds
• Maintainers looking for duplicates can look just at issues in a specific area
• Contributors interested in a specific area can find related issues

Help is appreciated from anyone active on this tracker. Here's a few things anyone can do:

• Identify any other clusters of similar issues that we can label together.
• Feel free to ping me on any issue to suggest applying labels or closing the issue.
• Old issues that are no longer relevant or that are better proposed on the python/typing tracker can be closed.
• I'd support giving out triage permissions easily to anyone with some record of useful work on this tracker or other typing-related projects. Let me know if you're interested, but note that this isn't a decision I can make by myself.

Here are some notes on specific labels:

• bug mypy got something wrong , false-positive mypy gave an error on correct code , feature – the distinction between these isn't always very clear. Not sure how useful they are.
• crash – Not good that we have 76 open crash bugs! We should review them to see if they are still valid and if so, how hard they are to fix.
• https://github.com/python/mypy/labels/new-semantic-analyzer – Was "new" a few years ago. Not sure this label is still useful.
• priority-0-high – High priority doesn't mean much with 110 open issues. Maybe we need a new way to track priority.
• topic-join-v-union Using join vs. using unions – This is a great example of finding a useful pattern in the issue tracker (thanks @erictraut). Finding other similar patterns should give us more high-impact bugs to fix.
• topic-type-narrowing Conditional type narrowing / binder – It's very common to see bugs of the form "mypy doesn't narrow types when I do if <something complicated>". Probably a lot of them are duplicates or should be closed as not realistically fixable.
• topic-type-variables – I feel like most nontrivial type checking bugs involve type variables. We should look for something more precise to classify these.

[AlexWaygood]

I'd be interested in becoming a mypy triager. Python-typing CV:

• typeshed maintainer (366 merged PRs)
• flake8-pyi maintainer
• CPython triager
• 11 PRs merged into mypy
• Many, many typing-related questions answered on Stack Overflow

I'm far from an expert on mypy's internals, but I'm interested in helping apply appropriate labels to issues as they come in and identifying possible duplicates.

[jhance]

I think bug vs feature is pretty useful - but things are often misclassified as bugs when we haven't documented what the expected behavior is so therefore it is a feature.

[KotlinIsland]

I'm very interested in volunteering as a triager.

[JukkaL]

@JelleZijlstra Great stuff! I agree that the issue tracker has not been very well maintained. We've periodically done some spring cleaning when meeting other team members in person, but that stopped during the pandemic.

I have a few concrete ideas that might help:

• We could add a label such as "affects-typeshed" for things that block typeshed PRs. I think that we should prioritize fixing these issues, but right now it's hard to keep track of all the issues.
• Maybe we could declare some medium-term project-wide goals, such as "let's close as many crash bugs as possible in the next 6 months". We could prioritize code reviews of PRs that target these goals, and I can volunteer to have 1:1 meetings with contributors who wish to help but would like to have some guidance. We could have a meta issue where we discuss the relevant work.
• If contributors are able to meet in person, we can continue with issue triage meetings/socials. Anybody with triage access to the repo would be encouraged to organize these.
• Schedule periodic virtual meetings (e.g. over Zoom or chat) where we can triage issues, discuss prioritization, etc.

@KotlinIsland Thanks for the offer! To start onboarding, are you okay with emailing me so that we can discuss the next steps offline?

[AlexWaygood]

Having put a bit of time into triaging over the last week or so, here's a few notes from me:

• The number of crash reports has gone up over the last two weeks from 76 to 90. Some of those are new crash reports that have been filed in the last two weeks, but several are also issues that were incorrectly marked as bug reports, when they were actually crash reports. (I found these by searching for AssertionError or Internal Error in issues with the "bug" label.)
  • 11 12 13 crash reports are related to dataclasses.
  • 7 crash reports are related to NamedTuples.
  • 7 crash reports are related to protocols (nested classes inside protocols seem to be a particular pain point).
  • 6 7 open crash reports have the line AssertionError: Must not defer during final iteration in the traceback:
    • AssertionError: Must not defer during final iteration #12113
    • AssertionError: Must not defer during final iteration #12252
    • Crash when using total_ordering and a Generic class #11728
    • Mixin class factory crash #12112
    • Unexpected behavior on using NamedTuple and Generic when bounding TypeVar in different ways #10672
    • Generic bounded dataclass crash #10140
    • Crash when TypeVar of Generic dataclass has undefined bound #12527
• I think an "affects-typeshed" label would be useful. Some other labels that I think might be useful:
  • "topic-metaclasses" (and/or "topic-types-of-types"). There are a lot of issues about metaclasses, there are also a lot of issues about type[T] not being treated correctly by mypy.
  • "topic-async"
  • "topic-variable-scope". A more specific label than "topic-runtime-semantics", for discussing things like situations where mypy doesn't catch UnboundLocalError, or where mypy thinks that a variable is referencing a class variable but it's actually referencing a global variable.

[JelleZijlstra]

• I think an "affects-typeshed" label would be useful. Some other labels that I think might be useful:

  • "topic-metaclasses" (and/or "topic-types-of-types")
  • "topic-async"
  • "topic-variable-scope"

I added all these

[hauntsaninja]

In the spirit of keeping the issue tracker healthy