Thank you! I have just one more concern, but then I’m willing to withdraw my proposal and throw my full support behind this one.
A new council is elected after each feature release. Each council’s term runs from when their election results are finalized until the next council’s term starts. There are no term limits.
I suspect we will need to schedule this after feature freeze, since that is when people will be preparing PEPs for the following release. This probably means that councils will have to overlap, while the previous one finishes up 3.N and the new one begins 3.(N+1), though I suspect we’ll have a decent amount of continuity from council to council.
One possible workaround would be to dissolve the old council at feature freeze, make the RM solely responsible for everything to do with their release, and the new council responsible for everything that is not specifically to do with the release. Or perhaps that could just be a suggestion for the council that they may delegate all code responsibilities to the RM at that point (I guess it’s also within scope for the council to abolish the RM role entirely?).
In any case, since decisions about a new version begin at the previous version’s feature freeze date rather than release date, I believe the council needs to be elected at the feature freeze rather than the release.