Working discussion for PEP 8016: The boringest possible steering council model

Ideas
61

One year is currently not even a single release. In the future it might be exactly one or maybe two tops.

Can we make term limits two years which even today overlaps at least a single release a bit?

My thinking is that by electing every year:

  • we risk inconsistent handling of “the vision for Python”;
  • we distract from actual work;
  • we risk low voter turnout which in turn risks councils which are not really representative.
1 Like
62

My reasoning for one year being okay is that I expect we’ll quickly fall into a routine of reelecting the same people each year anyway. Then the annual election simply means if someone wants to leave the council they can probably last until the next election and avoid triggering a one-off (or the council can run with one person missing until the next election).

Of course, if there are term limits or reelection that I missed, then I’d prefer much longer terms (five years or more) for stability. But I’m pretty sure I didn’t miss anything.

63

I have a self-centered reason for preferring a shorter term… I’m more likely to run if the commitment is only 1 year instead of 2 :-). And @ambv, I thought you trusted the group to maintain a consistent vision? :slight_smile:

But… November 28 is a terrible day to actually debate anything. If the desired tweak isn’t immediately obvious, then let’s leave it for later? Like I said above, if we do end up selecting PEP 8016 then it’s not a big deal to tweak the terms later. And anyway it sounds like a lot of the things we’re worrying about are things that will be much clearer after we’ve had an election and experienced what it’s like…

1 Like