GeezerVison

Hmm, not sure if we need this? And I'm not sure about the triage label suggestion, it doesn't really say anything more than "issue is accepted by a triager".

Actually, it's for a visual tag. Sometimes I don't remember the issues I've triaged. And if I see an issue with weird label I would say "oh this one could have been mistriaged maybe". But with a triaged label, I know that I don't need to change the labels (same for when I lack a topic-* or a directory for an issue; when there is just "type-bug" it's kind of .. hard to know that there is actually a project associated to the issue; projects can't be seen on the issue page)

Maybe add a recommendation about whether to keep type-bug in type-security issues (are they truly redundant?)?

I think that the place for that is beside the type-security doc?

@hugovk Something like this?

Note: another acceptable 3.N label is when we implement a PEP. It's good to have both feature & 3.N labels at the same time because the PEP is meant to be implemented in that version.

I'm a bit confused :)

Filling in numbers to make this concrete:

Assume that we are currently in the beta period of 3.14.0,
that is, the latest version under development is 3.15.0a1.
If a feature implemented in the alpha period of 3.14.0
requires a non-trivial extension, a new feature issue must be
created and be given the 3.14 label.

The 3.14 beta was May to July 2025.

3.15 was still in pre-alpha, versioned 3.15.0a0 (from May to October 2025).

Did you mean 3.{N+1}.0a0 rather than 3.{N+1}.0a1?

In any case, I'm not sure we really need to document such exceptional things.

(Nit: "there are a few exceptional cases" but then we list just one case.)

Yeah I meant 3.15.0.a0 sorry.

I think we need to document at least this case because we explicitly state that betas are feature frozen. As for the list, I thought I would have more but I do not think there will be more so I can rephrase this!