Update PSRT inactivity policy - #1911
StanFromIreland wants to merge 1 commit into
Conversation
Documentation build overview
|
|
|
||
| Members of the PSRT who are a Release Manager or Steering Council member may | ||
| remain in the PSRT regardless of inactivity in vulnerability reports. | ||
| When a Release Manager's term ends, their PSRT membership becomes a regular |
There was a problem hiding this comment.
Do we need to define the end of an RM's term, or is it obvious? I'd define it as after the official EOL of the last release they are an RM for.
There was a problem hiding this comment.
I think it's obvious, but we can be explicit.
That definition makes sense: they no longer need to make any security releases for their versions, so there's no need for them to be present unless they want to be active.
Aside: The "may" in "Members of the PSRT who are a Release Manager or Steering Council member may remain in the PSRT regardless of inactivity in vulnerability reports" suggests membership is optional for RMs (and SC). I was told I had to join, and membership is now required by PEP 101.
There was a problem hiding this comment.
I'd define it as after the official EOL of the last release they are an RM for.
This however, is technically not what we've been doing. We list Steve and Ned as RMs, however as per PEP 101 they're the {W,M}Es. To continue this practice, I suggest something like "as specified in PEP 101" since we're including the slightly broader release team?
There was a problem hiding this comment.
Yes, RM members should be mandatory, and optional for SC members. I'd list release experts (WE, ME) as optional but allowed even if they aren't active. But yeah, we can cross reference PEP 101 if you think that's better.
warsaw
left a comment
warsaw
left a comment
There was a problem hiding this comment.
Other than one question, LGTM!
3 participants
Changes based on the recent PSRT decisions that:
CC @ambv please note that I've removed your RM manager note, in concordance with python/peps@03bdeb3.