This might have the opposite effect though. For example Generator-based HTMLParser · Issue #61612 · python/cpython · GitHub is a 9 years-old feature request. The proposal is reasonable, but it’s low on my priority list (even though it came up again just the other day). If I assign it to myself, people might avoid working on it, since they might interpret that as “someone is already going to work on it”. I left it unassigned to indicate that whoever can pick it up and create a PR (which I might then assign to myself for review and merge).
For the problem at hand, this might be useful as a way for core-devs to indicate some “high-priority” issues that contributors could pick up. It might also be useful for RMs and core-devs themselves for tracking issues/PRs, but otherwise it might just add overhead. For most issues, if they miss a release they will just be included in the next.
I think this can definitely be useful, and I wrote about this in this post: Using GitHub (beta) projects in our workflow
Projects have two main advantages:
- They can make discoverability easier by grouping related issues (see e.g. html.parser issues · GitHub)
- They can have additional custom labels (that can indicate how difficult they are, if they are available, how long it’s going to take to fix them, and other useful things)
On bpo we had both priority and severity. I’m not sure if severity was ever used (it’s in Roundup by default and at some point it was removed), but 95.7% of the open issues had “normal” priority. Because of this, only release blocker and deferred blocker were kept (and also added to a project). In an open source project, the importance of an issue doesn’t matter too much if there is no one willing to work on it, and we can’t force people to work on issues.