Yeah, I think it’s time to create a new topic for this.
Is that the consensus here? Are triagers and core devs happy to deal with duplicate new issues over commenting on closed issues?
One strategy I’ve found for dealing with an overwhelming list like this is to regularly tackle a random, fixed-size subset. I think the tag-based queries is similar to this, and should help
@admins @moderators Could you please execute a thread-split starting with @AA-Turner 's comment #27 with all following comments except @EpicWink 's comment 31 immediately above this one and my comment following this one (if its posted by then)? Suggested title something like “Labeling of documentation-related issues” (we can change it if needed) in the #documentation category.
At least on other projects, I’ve found release-based milestones to be extremely helpful in other projects, particularly as a way to quickly tell at a glance what issues/PRs have already landed or will land in each release without digging through the changelogs of each one, being able to quickly list all of them, and making searching and browsing much faster and more effective. Projects could be used to categorize issues by other cross-cutting themes and further improve discoverability.
It does add some measure of overhead and a degree of at least semi-automation would be needed, though projects could help with that. Considering the number of other tags and metadata that CPython issues (BPO and GH) already have, the cost seems relatively small relative to the potential long-erm benefit. But there may be reasons it doesn’t make sense for CPython.
One potential distinction here is that CPython doesn’t have a single all-powerful maintainer with a single monolithic set of goals, it has over a hundred of them all with their own unique perspectives, priorities, vision and values, which are on display here in this very thread. Sure, there’s the SC, but they typically only step in in relatively extra-ordinary cases, and certainly are not going to be making a decision on each of 5k+ open issues. Even back when Python had a BDFL, the de-facto process was, as I understand it, still mostly decentralized and consensus-based, with a set defined process for making major decisions.
Considering that even proposals to do something like this after 6 months or a year have not been uncontroversial, a timeline anywhere near this aggressive seems very unlikely, but something much longer could potentially be acceptable. However, having issues be locked after closing them and forcing users/devs to open new ones to continue the discussion adds more friction and implications to closing an issue, more work to keep everything linked together, creates more issues overall and increases the friction of actually solving the issue, so it seems to be at cross purposes to the original motivating problem here, of too many issues being open.
Hi, I’m not part of the team but I was following the conversation out of interest.
I was expecting this topic to be fairly uncontroversial, and only focus on the fine details. After a private conversation, I suspect there might be some misunderstandings at play that are making an agreement harder to reach. To summarize:
- The proposal is not about closing issues more aggressively than before
- It’s acknowledged that old feature requests are not the only source of noise
- The goal is to document a shared understanding of what is obviously noise to everyone
- This shared understanding serves a pragmatical purpose to reduce friction and emotional work, so it ought to be translatable into action
- Specifically, the goal is not to reduce the scope of what is a valid issue, but to let the existing agreement emerge
- The value of the proposal is not only the immediately actionable, but the principles that could emerge in the discussion, because they can unlock improvements in the issue tracker workflows
- The details of the improvements are probably out of scope, but some folks are already working on this
Happy to rectify in case I misrepresented anyone’s thoughts.
I’m leaving only the tl;dr here, but I had originally written some excessively verbose comments that can be skipped because I don’t want to hijack the conversation.
I’d suggest to add a comment to the ticket saying exactly what you expect. It’s better to be explicit about such expectations rather than implicit (as usual in Python ).
The approach to try to put everything into tags or other mechanisms helps with discoverability, but it doesn’t help with improving the communication between people submitting PRs and core devs who can actually merge those PRs.
The latter can only be improved by actually putting comments on tickets and showing that real people are communicating, rather than bots.
Agreed. Tags often don’t communicate very well, especially not to those new to the community (we’ve seen even Triagers confused by tags). Write a sentence! Use GitHub’s “canned responses” feature if you tend to write the same over and over.
When closing issues on GitHub, you now can mark why the issue was closed and that state can be used in a search.
This is why I would argue an even short time horizon than a decade.
For me, the options are we either get way better about closing issues (which requires a more collective feeling of ownership and thus more empowerment to close things people don’t think are useful), are we have to lean in hard on labels to make it easier to filter things (obviously both options are possible, but I think at minimum one of them has to be taken). If we don’t take some approach, then our issue tracker is going to continue to be intimidating to new users and near impossible to find anything in w/o a massive amount of dedication.
Perhaps it would be easier to agree on a process for closing issues rather than on criteria. I got the impression that we have an informal process, something like close if 3 core devs/triagers vote -1 and nobody votes +1.
Should we make this established policy, and can we support it somehow technically? (We have the pending label already, should we formalise how we think it should be used?)
I think we often feel, and would like to be able to say, ‘I think this can be closed but I’m not sure enough to make the final call’.
This seems quite a high requirement – requiring on the order of 15,000 votes to work through the backlog of issues. But perhaps formality is what is required – I’m not sure, for instance, if I can close issues for platforms unsupported per PEP 11 currently, or for EOL versions of Python – this would cut down the backlog significantly (at least a couple of hundred issues, if not 4 figures).
It was intended as a sufficient signal for closing, not a required one. If you are sure the issue is no longer useful go ahead and close it (as we do now).
I have opened Should we close issues for platforms not covered by PEP 11 or under active development? to discuss this.
Perhaps we just need a better understanding of when to reopen issues to resolve
It is well possible that an old feature requests gets a bump in priority again
after a few years (see e.g. the desire to have an os.chdir() context manager).
If we can agree on making it easy to reopen issues, we’d not lose older context.
This would also mean that older rejections should deserve reevaluations after a
With such an understanding, the action of closing an issue would not have the
perceived final pronouncement character and instead get a more project
management oriented meaning: we’re putting this issue into the backlog for
someone else to potentially pick up in the future.
You don’t even need to reopen old issues. You can just as easily say “open a new issue (and link to the old one) if you want to re-propose a feature request”. Then triagers can evaluate that new issue based on current standards and its own merits, rather than trying to evaluate possible decades of discussion.
This doesn’t solve the problem of finding the old closed issues in the first place: if the it’s not found, then all the context, discussions, linked PRs/patches, showstoppers and issues are lost and the effort will have to be duplicated.
On bpo we even switched the default search from “open issues” to “all issues” because people often created duplicated issues that were already fixed/rejected. The GitHub search also defaults to open issues/PRs, so assuming people search before posting, they might end up missing the previous issue.
I don’t consider that a problem that needs solving.
The problem is Open issues that clutter the view of what is actually relevant rather than Wishful Thinking.
Leaving something Open implies that we’re ready to accept PRs for it. So closing is always the right choice when we likely won’t.
I agree. Note that in my original post I mentioned exceptions to closing, one of them being that the issue contains discussions or analysis that we don’t want to lose. This is the rare rather than the typical case.
The old issue, if found, is more likely to be used as a reason to quickly close the new one (whether the old issue is open or closed). This usually happens because someone remembers that the idea had already been proposed.
It’s not a major loss if we sometimes have to reconsider the same idea again from scratch, a decade later. Especially if we make it less of a big deal to close it again.
To repeat - if someone spent a significant amount of time investigating the suggestion, or attached a non-trivial patch, then we should think harder about whether there is something there which is worth keeping.
To me, this is backwards: An assigned committer should encourage PRs because it should indicate that PRs will be reviewed and possibly merged. Also, an issue with an assignee should not be closed without asking.
… and if there’s a risk of the assignment being misinterpreted as “I’m working on a PR, so don’t bother”, then presumably it’s easy enough to add a small comment when assigning the issue to yourself - “I’m not working on a PR myself, but I would be happy to help someone who wants to contribute one”.
Hm. That does sound like a rather “creative” interpretation of issue assignment.