Triage the open "performance" issues on cpython repo

[iritkatriel]

There are 243 open issues with the "performance" label on cpython repo:

https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Aperformance+created%3A%3C2022-08-01+-label%3A3.12

[erlend-aasland]

Create a GH Project for it so it is easier to break it into smaller, manageable pieces.

[iritkatriel]

What would a project give us?

[erlend-aasland]

IMO¹, it is easier to break a large pile of issues into smaller, more manageable pieces, mainly because of its grouping and filtering features, which are, in my opinion, superior to the filtering found in GitHub Issues.

IDLE has almost 300 issues; they are managed/triaged here: IDLE Issues

Footnotes

1. What works for me may not necessarily work out for others; this is just my personal opinion. ↩

[iritkatriel]

I've assigned this to everyone on the team because it's a collective effort.

The way I've been doing this is:

1. If the issue is still relevant, put a 3.12 label on it.
2. If it can be closed, close it.
3. If it's not really a performance issue, remove the performance label.
4. If I think it can be closed but not sure I ask a question and put a pending label (after a few weeks with no response we can close).

The link in the first comment of this issue excludes the 3.12 issues, so it shows only untriaged items.

[erlend-aasland]

The way I've been doing this is:

1. If the issue is still relevant, put a 3.12 label on it.

... and put a triaged label on it, I presume:

• Adding a new "validation" step to our issue handling workflow python/steering-council#130

[iritkatriel]

The way I've been doing this is:

1. If the issue is still relevant, put a 3.12 label on it.

... and put a triaged label on it, I presume:

No, I haven't been doing that.