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

Ideas
1

Last night @dstufft and I were both reading through the proposed governance PEPs. When we compared notes, we discovered that we both felt like there was a proposal missing – and it turned out to be the same proposal!

Here’s what we’re thinking: this poorly-defined process we’re going through right now, where no-one knows what’s going on and we have to somehow get consensus between dozens of core devs – it sucks. We would like to avoid doing it again.

Why might we find ourselves having to do it again? One risk is that we adopt a proposal that turns out to be missing crucial details that need to be filled in later. (We feel like a this is a non-trivial risk
with several of the existing proposals that we otherwise like.) Another risk is that after adopting some proposal, we discover it isn’t working the way we want, and needs to be changed. In fact this
seems inevitable to some extent – we’re surely going to want to fine-tune things as we go. And while we’re intrigued by some of the more experimental proposals – maybe they’ll work great! – being the
first project to try a new governance model is inherently risky.

How can we minimize these risks?

Our idea is to have a minimalist model that defines a core “steering council” or “oversight committee” or whatever you want to call it. They’d have broad authority on paper, but the expectation is that in
practice their main purpose would be to ratify more detailed workflow PEPs, handle bureaucratic necessities, etc. And if some unexpected situation arises where we need an ad-hoc decision then they will, but their goal should be to minimize that as much as possible. So… think of them as a kind of governance-sig, that can generate formal decisions when formal decisions are necessary, and other core devs don’t have to get involved unless they want to. Or for our US readers, the idea is: we don’t need to define all the laws at this point, we just need a constitution.

This minimizes the risks because:

  • There are lots of major projects that use this kind of mostly-hands-off steering council model (e.g., Django, NumPy, Node.JS, …), so it’s “boring”, in the good way that mature technology is boring.
  • By narrowing our scope like this, it becomes easier to be really rigorous in defining the details, so we can have more confidence we haven’t missed anything important.
  • By deferring governance details to later, we keep the flexibility to fine-tune processes and experiment with new decision-making workflows without having to go through this process again. (For example: if we want to try out PEP 8013, the steering council could start by
    appointing an auditor to handle a single PEP, and see how it goes.)

What’s this thread then? where’s the PEP text?

That’s the basic idea. But of course there’s a bunch of details to work out. And since we know a lot of people want to get all this settled ASAP, our plan is to get a complete draft submitted to the
PEPs repo by the end of tomorrow (Thursday). But we haven’t written it yet.

I guess the traditional thing would be to go off in private and write it all up and present it as a finished work, but we figured it can only help to get more feedback / discussion as early as possible. So
instead of a private chat we’re going to use this thread to do the writing instead. Feel free to jump in! Co-authors welcome! Let’s see if this Discourse thing works as well as advertised!

Okay so what will the PEP actually look like?

The Django governance document
looks like a good starting point. (See also: PEP 8002’s summary of how it’s worked in practice.) Basically it defines:

  • The process for electing the steering council
  • The process for people joining/leaving the core team
  • The process for changing the constitution

This seems like the Minimal Viable Governance to me – everything on that list is necessary. (The steering council election process says that core team members are the electorate, so in order to define one you have to define the other.)

So to keep this simple and as boring as possible, I’m thinking we’ll steal text and details from that Django document wholesale, except where we have specific reason not to.

My initial to-do list for things I’d like to discuss beyond that:

  • CPython-specific language about the steering council’s mandate (e.g.: formalize and maintain relationship with PSF; try to make Python development process humane and sustainable, and reflective of Python’s diversity of use cases and users; serve as a “court of last
    resort” for technical decisions when all else fails; …)
  • A written-down process for handling unexpected vacancies on the steering council, both for the obvious reason (life happens) and to reassure members that if they need to step down then it won’t cause a disaster.
  • Maybe some rule to avoid the appearance of conflicts of interest, e.g. no more than 2-out-of-the-5 members can share an employer?
  • I liked some of the language in PEP 8011, like this
    and this, maybe we should steal some of that too.
  • Donald wants to talk about recall procedures (may be more relevant for us than for Django, since Django’s terms are super-short – 8 months, if I’m reading it right).

Maybe we should make an etherpad or google doc or something to use as
a working document?

3 Likes
2

In my mental model of this idea, and where it differs from the other models, is that we’re effectively electing a council/committee/whatever to replace the BDFL, but we’re not rigidly defining how a PEP gets accepted other than making decisions ultimately rests within that committee (including how to make those decisions).

This feels to me like the most natural conversion of the BDFL role into something that is an elected council style. For the status quo with a BDFL was effectively everything was up to the BDFL, if the BDFL wanted to try out or change the process, they’d just… do that? It wouldn’t require some complicated meta procedure or what not.

However if you say “Ok, we want a committee of people that are going to handle things”, then you have to at a minimum define how that committee is chosen, how long they serve, etc. Thus this PEP would rigorously define those things.

It would also specifically call out this “constitution PEP”, as being explicitly outside of the purview of this committee, where changes to it would require a vote or the core developers. This protects against this council being able to effectively declare themselves king, by making it so changes to their personal structure require consent of the governed.

The intent is that by keeping the vast bulk of things flexible, we avoid the need to have to have this meta discussion and go through this voting process any time we want to tweak the decision making process but we ensure that power ultimately comes from “the people” in that if the committee is making decisions people don’t like, then they won’t get re-elected (and in the rare cases that they are actively malevolent, they can possibly be recalled).

Ultimately, another way to think of this, is a representative democracy, where we choose our representatives, but we leave the details of day to day procedural stuff up to those representatives.

3

In which ways do you see your general idea incompatible with PEP 8014? It seems to me they are similar in spirit.

1 Like
4

PEP 8014 simultaneously tries to define how the PEP process works into the future, and tries to be ambiguous. It defines that deciding on a PEP is handled by a vote of the electorate, but that the role of the council is to decide if that vote is “good enough”.

To me, that effectively is just creating a sort of shadow government, where the stated purpose of the council is to decide if the vote happened correctly or not, but in actuality, given we’re all humans, the council is almost certainly going to take a stricter view of what is a “good enough” vote on proposals they personally dislike, and a broader view for ones they like.

Meanwhile the idea behind this is that while we’re electing this council to represent us, the decision for how that translates into day to day decisions ultimately rests within that council. They could decide that they want to be very BDFL like and and personally pronounce on each and every PEP, they could decide that they want to take a tact closer to PEP 8014 and put each PEP up for a vote and function largely as the guardians of process, while decisions are taken through a direct democracy.

One key idea here is that we’re not rigidly defining how decisions get made. I think this is important because if you look over the history of PEPs, Guido himself would experiment with different ideas for the decision making process. Originally all PEPs had to go through Guido to make a choice, but eventually he found that didn’t quite scale and there were some things he simply didn’t care to rule on, so the process was adjusted to include the idea of a BDFL-Delegate. Further on, packaging ended up being in a state where we didn’t have a clear decision making process, but Guido wasn’t really involved in packaging so it didn’t make sense to have him decide on packaging PEPs, but it was also cumbersome to have to get Guido to sign off on a Delegate for each and every one, so the idea of a “standing delegation” was added to Nick (and then to Paul and Myself).

For each of these experiments, any of these PEPs which define how a PEP gets decided on, none of these experiments could have happened without engaging a vote of the electorate (and then if that experiment failed, undoing that experiment would then again require another vote of the electorate).

If I had to pick a PEP it was most like, I’d say it’s probably closest in spirit to 8011, although it has similarities with 8014 as well. However it’s effectively taking those ideas, and stripping them down to the minimum amount of things we actually need to define, and leaving everything else up to that council, which grants us the flexibility to continue to adjust our decision making into the future, without invoking some heavy handed process that we all pretty much hate every time.

1 Like
5

PEP 8014 leaves tons of basic stuff undefined (e.g., how the Council of Elders is selected), and it also seems clear that the CoE isn’t expected to impose additional structure beyond “a subset of devs votes on everything”. The goal here OTOH is to provide a stable foundation for building additional structure on top of, so details should be specified, and there’s an explicit expectation that the council can/should use its powers to set up additional structure. So like for example, of the current proposals I probably like 8012’s general approach to decision-making the best, but I think the best way to formally implement 8012 is to adopt something like this proposal as the “constitution”, and then have the council adopt 8012 as the “laws”. (I noticed that in 8012 you cited Django as an example of a project using the 8012 system, and I guess you mean that they use exactly this kind of two-level structure?)

6

Okay let’s start outlining.

Baseline: what does Django do?

Django says:

  • Core team:
    • Their equivalent of a CPython “committer”
    • Emphasizes that code contributions are not the only way to become a core team member
    • But if you are a core team member, then you’re trusted with commit access if you want it, unless vetoed by the technical board
    • Includes a nice set of examples of the kinds of contributions that can count towards becoming a core team member
    • Requirements to become core team member: candidate is voted on by the exiting core team; success requires 80% supermajority, of votes cast (no quorum), plus no veto by the technical board
    • If people don’t contribute, are asked to move themselves into an alumni category after 2 years (or people can voluntarily place themselves in this category at will)

My thoughts:

I really like most of this. I’m confused about the category “people who are trusted to be core team members, but the council still feels the need to exercise a special veto power to prevent them from getting commit access”. If they’re that untrustworthy, maybe they shouldn’t be core team members? My inclination is to not have any distinction between “core team members” and “committers”. Speaking of which, we probably want some way to kick people out of the core team if necessary. (Hopefully never comes up, but I can imagine circumstances where it’s better than the alternatives.)

It’s not specified whether the vote on core team candidates is public or private. CPython’s tradition is to do it publicly. Most projects I know of do it privately, to avoid awkwardness. Maybe we can leave it ambiguous here (i.e., either way is fine).

Django says:

  • Technical board
    • Two enumerated powers: “making major technical decisions when no consensus is found otherwise”, and “veto a grant of commit access or remove commit access”
    • “the technical board is a last resort”
    • “In addition, at its discretion, the technical board may act in an advisory capacity on non-technical decisions.”
    • names specific mailing lists, I think for communicating the result of the votes?
    • Technical board votes:
      • Performed in private
      • every member must either vote or explicitly abstain (so I guess if any member is not answering their email, then the board simply can’t do anything)
      • “Then the board communicates the result, and if possible the reasons, on the appropriate mailing-list”
    • Membership:
      • 5 people
      • Must be “committers” (maybe they really meant “core team members”? the document does make this distinction, and it’s a bit strange)
      • Timing: New election after every feature release, which elects the whole council (no staggered terms)
      • No term limits or anything like that
      • “The election process is managed by a returns officer nominated by the outgoing technical board”
      • 1-2 weeks for candidates to declare themselves, and then 1-2 weeks for the vote (exact length chosen by the outgoing board)
      • “Each team member can vote for zero to five people among the candidates. Candidates are ranked by the total number of votes they received”, so approval voting with a limit on the number of “approves” that each person can give. (Does this have a name? It’s common – IIRC PSF board elections use it too.)
      • In the case of a tie for 5th place, the winner is whichever candidate joined the core team first

My thoughts:

  • I think the “advisory capacity on non-technical decisions” part is because they have the DSF to handle necessary bureaucracy? The relationship between CPython and the PSF is traditionally much more distant, with the PSF mostly handling conferences and stuff. I don’t know exactly what the relationship between CPython and the PSF will look like in the future, but it seems plausible to me that it might look like other fiscally-sponsored projects, where the project itself sometimes wants to make decisions about how to handle assets, instead of just leaving it up to the non-profit board to decide. I think we should give our steering council the power to negotiate such arrangements. (In fact this is one of the major reasons we need some written down formal governance! When it comes to spending money it’s important to have clear yes-or-no decisions.)
  • size: 5 people, sure, why not. I wouldn’t want to go smaller, because looking across projects that use similar models, 5 is already on the small side (django = 5, numpy = 11, node.js = [19](https://github.com/nodejs/node/blob/master/README.md#tsc-technical-steering-committee, Debian CTTE = 8, etc.), and having more people increases redundancy and opportunity for load-sharing, ability to cover a broad range of expertise and perspectives, etc.
  • quorum = everyone? Sure why not, our council is supposed to avoid voting as much as possible, so this requirement shouldn’t be too onerous. Though we probably want some procedure for handling a council member who goes AWOL
  • I don’t think we should bother making a distinction between “core team members” and “committers”, it complicates things for no good reason I can see
  • I’m a little dubious about the council’s votes being private – my bias is that votes on policies should be public when possible? But I can also see how the council might need to vote privately sometimes (e.g., think about CoC-related matters). Maybe we should leave it up to the council.
  • the whole voting process seems fine to me.
    • I know we’re using condorcet for 8001, but condorcet gets substantially more complicated when you have multiple winners, and this is simple, works fine, and has solid precedent
  • It’s weird that they don’t specify whether the vote for the council is private or public. My bias is private, because again, voting for people is kinda awkward if you do it in public.

And then the last piece is: changing the constitution requires “a four fifths majority of votes cast in a core team vote and no veto by the technical board”. Seems fine to me.

Things we need to add on to the above

Text:

  • CPython-specific language about the steering council’s mandate (see initial post)
  • Comparison to other proposals (could potentially add this after the initial draft)

Additions to the formal policy:

  • Procedure for handling steering council vacancies
    • Straw man proposal: to pass anything, the steering council always needs 3 votes (and the quorum is “however many people are on the council currently”). If the steering council has <5 members, then they can add new members to serve out the current term by a regular vote. (So if there are 4 members, at least 3 need to agree on the new member; if there are 3 members, it has to be unanimous.) If the steering council ever drops to <3 members, then it’s dissolved and we hold a special election, using the usual procedure.
    • If a council member can’t be contacted for >1 month, remaining members can vote to remove them and then fill the vacancy as usual
  • Procedure for avoiding the appearance of conflict of interest, since I’ve heard grumblings about this and this is the kind of situation where the grumblings themselves can be harmful even if everyone’s acting totally above-board
    • Straw man proposal: no more than 2 people on the council can work for any given employer. During a regular election, if 3 of the top 5 candidates work for the same company, then we drop the one with the fewest votes, and move on to the 6th-ranked candidate. If someone changes employers during a term in such a way that would violate this policy, then they step down and it’s treated as a regular vacancy.
  • Procedure for removing people from the core team
    • We already have that the council can veto a core team member joining. And after thinking about it for a bit, I think having this veto a good idea. For example, there are people in this world who I know things about that I’m reluctant to say publicly for various reasons, but where if they were trying to join the core team then I might speak privately to the council and they might choose to veto based on that. It’s a shitty option, but when you’re in a shitty situation sometimes the alternatives (doing nothing, having a giant public debate) are worse. Anyway, the situations where I can imagine the council using its veto on someone joining are basically the same situations where I can imagine we might feel we need to kick out an existing member. So:
    • Straw man proposal: extend the veto power to say that the council can also kick out an existing core team member.
  • Procedure for removing people from the council (“recall”)
    • Straw man: can be proposed by any core team member. If seconded by another core team member, then core team votes, similar to when electing the council (though without the candidacy declaration period). The council’s power to kick out core team members is suspended for the duration of such a vote. Question: what’s a successful recall election look like – simple majority in favor? 4/5ths majority?

What else am I missing?

[Edit: we should probably have some text to explicitly say that the council can decide to delegate its powers. E.g., we could have a PEP to establish a CoC committee that’s delegated to handle things directly, possibly with an appeal process to the steering council.]

1 Like
7

Regarding how this relates to the other PEP proposals: actually I think the proposal that’s closest in terms of overall intent is @vstinner’s PEP 8015. The implementation is different in lots of ways (in particular, I feel like this will be much more focused and crisply scoped?), but it’s possible that the two could be merged if @vstinner was into that.

8

Thanks a lot @njs for doing this!

I’d like the votes to be public. If people on the council are elected, then electors need to know how they stand in reality on the various topics at hand (and, also, know whether someone possibly doesn’t do the job at all by always abstaining).

Right, I think 5 is a bit small, since people can be unavailable at times, and CPython spans a wide range of topics.

Agreed.

That probably makes it incredibly hard to change the constitution. But perhaps that’s a desired outcome.

I think this is important. Bias is often unconscious, so it’s not only about striving to be honest.

What would be the procedure? A single majority? That makes it a bit too easy to kick out someone IMHO, especially with a small council.

Let’s make it 2/3 majority, so that it’s hard but not practically impossible?

9

My intent is not to have my own personal PEP but see my PEP as a starting point to design a new governance. I’m ok to pick ideas from others and change my PEP. But I am also reluctant to some ideas, so let’s talk :slight_smile:

10

I dislike the idea of giving too much power to this council. Some people don’t like them each other, it should not prevent a contributor to come a core developer. If there is something obviously wrong with a contributor, I expect to negative votes blocking the promotion.

… If the contributor is promoted anyway:

Again, I dislike the idea of giving such power to the council. In my PEP 8015, I designed a “Python Core Board” with the least power.

It’s fine to disagree with someone arguments, this happen all the time on PEPs. What is not correct, is when people misbehave. This is where I picked the PSF Code of Conduct Workgroup. IMHO it’s better to have an autonomous group who decide which behavior is appropriate or not.

Let’s say that one of the member of your council has a long history with a core developer. Should this member be allowed to kick this core dev just because they don’t like each other? Or can an external group decide if the core dev mishave? You may see the workgroup as a court which analyze facts and make their own judgement. If the council has this power, what does it mean to others core devs? Be careful, the board can kick you anytime on their wish and don’t have to justify themselves?

See my PEP for my proposal: PEP 8015 – Organization of the Python community | peps.python.org

11

My PEP 8015 tries to formalize this: Python Core Board roles.

I also insisted on “[Guido] found that didn’t quite scale”, IMHO it’s an important point. It seems like the time to approve a PEP becomes longer and longer last years, maybe because Guido was less available, or because there were more and more PEPs proposed, maybe both.

The main difference between my organization and Guido as BDFL is that the Python Core Board doesn’t approve the PEPs anymore. Their only role (on PEP) is to decide how the decision will be take: select a PEP delegate or choose between a democracy vote (majority).

I consider that a small group a 3 people (the Python Core Board) doesn’t know everything and so may take the wrong choice if they would have to approve all PEPs. Or worse, never take a decision on a PEP because they consider that they don’t know enough the topic. My PEP 8015 moves back the responsibilities on our existing local “experts”. See Annex: Examples of Python Teams for examples (incomplete list).

IHMO Lukasz’s PEP 8012 has the “same spirit”, but … is different :slight_smile: It doesn’t include PEP delegate and so doesn’t need a Board to decide how a PEP is approved. First I really liked the full democracy vote with majority, but when I talked with Yury Selivanov, I understood that it doesn’t work because in practice, many people have strong opinions even when they don’t know the topic. Moreover, some people are reluctant to change their mind, even after a long discussion with many arguments showing how wrong they are. I’m describing many past discussions on PEPs. By the way, it’s also common that I have very strong opinions (especially against a change), so I also include myself in these people :slight_smile:

… No I’m not sure that I understood properly your view on the PEP process, but I tried at least to better introduce mine :slight_smile:

1 Like
12

Not all governance PEPs describe that. I tried to formalize all aspects of the Python community, because I consider that you cannot simply explain how a PEP is approved, just by explaining the vote process. IMHO we have to explain how core developers are promoted, how the steering council works, etc. Everything :slight_smile:

For example, “The process for changing the constitution” is an important point. I explained in my PEP How to update this PEP that we should (must?) update the governance PEP:

So if my PEP 8015 is not selected, I would love to see all these aspects described (maybe later) in the chosen governance PEP.

13

On purpose, I didn’t described how the Python Core Board is organized in my PEP 8015 to give they freedom to work as they want. For example, if someone is in holiday but agreed to delegate their role to others when they is away, that’s fine. They can also decide to give the opinion of each member when they announce a decision. IMHO there is a need for freedom there.

This is also where I like the idea of having a small group of only 3 people: it should be easy to guess the opinion of each member if you know they enough. I expect them to be involved in PEP discussions, before they take a decision (how the PEP will be approved).

With a group of 5 people or more, you start to expect more transparency, organization and may even require to formalize how these people take decisions.

Note: the Python Core Board of my PEP 8015 doesn’t approve PEPs. They only decide… how the PEP is approved (PEP delegate or vote). So I’m not sure that there is a real need of transparency.

14

@dstufft Hey co-author, any comments you want to get in before I start working on a first draft?

15

I think that a 2/3 majority to agree on the things that we want to be harder than a simple majority seems to make sense (so changing the constitution, recalls, etc). I think this can extend to the removing someone from the existing core team as well (and since 2/3 of 5 isn’t a whole number, we’d round up so it’d require 4/5 of the steering committee to agree to remove).

I think 5 probably makes sense for a good minimum size, if we go much bigger than 5 we probably want to look at staggered elections, because it may be hard to get a large enough bench of candidates all at once if there is too large of a group needed.

16

I totally agree for routine matters. But like I said, I also see how for some kinds of sensitive matters you might need to do some discussions+votes in private, with only the results announced publicly. The general approach in this proposal is that we don’t try to write lots of nitpicky words to try to anticipate every issue, but rather give the council broad powers, trust that they’ll use them with discretion, and if they do anything that outrages the rest of the core team then they get recalled. So I’m thinking: put in some text saying that votes should be done in public unless there’s a good reason not to, and leave it at that. What do you think?

The way I’d gloss it is: you can change the constitution, but only if it’s uncontroversial.

Debian has used a constitutional model for ages, and requires a 75% supermajority to change it, so it’s a good source of examples for how this might look in real life. The amendments I found on a quick scan of vote.debian.org:

In my straw man proposal this would be a regular council motion, so yeah, 3 council members would have to agree. I certainly hope that council members would be very reluctant to exercise this power, and I’m sure that if they were abusing it then it would piss off a lot of core team members and make it very easy to do a recall.

I think in practice the council probably will want to delegate this power to whatever CoC committee structure we end up with (along with appropriate safeguards, appeal process, etc.). That kind of delegation seems like it’s easier to do if it’s a regular power? But I’m not super-wedded to the straw man either, it’s just the simplest thing that could possibly work.

I agree – the veto power is something that should only be exercised in very exceptional cases. (The Django board has this power, but has never used it.)

So I guess this points to the difference in how we’re approaching this. We’re thinking of the steering council as something like a certificate authority’s root certificate. Nearly unlimited power, only used to on special occasions to set up delegations to more restricted roles that get used for day to day operations, and otherwise kept locked carefully in a box – but when you need it, it is there.

I definitely agree that it’s better to have a separate dedicated group handling CoC issues. The difference is that PEP 8015 tries to set that up directly, and if some details turn out to be vague or unworkable, then we have to do more whole-team votes to amend PEP 8015. With PEP 8016, we don’t have to figure out how the CoC team works up-front before voting – instead whoever’s interested works with the PSF conduct working group to figure out the best approach, we all discuss it, and then the council ratifies whatever we come up with and works with the conduct working group to make any necessary adjustments over time.

I feel like… these are both perfectly reasonable options, but there are also lots of other reasonable options that aren’t on your list? The general philosophy here is to do something minimal and flexible, so we don’t have to decide up front that yeah, these are the only two options we’ll ever need.

Right, basically our approach is: we want to be comprehensive on the things we cover. But trying to be comprehensive about everything up front is really hard! So we’re trying to prune down what we include to the bare minimum, and then be comprehensive about what’s left.

17

Here’s a big chunk of first-draft actual-PEP-text – not quite complete, but as far as I got tonight:

https://github.com/python/peps/pull/827

18

Aha, let me see the PEP 8016.

Powers: Choose how to manage project resources (in collaboration with the PSF)

Which kind of resources? People, money? If it’s money, I guess that PSF remains the group who decide how the money is spent, but the Council can help to organize grants with core developers? If it’s people, I don’t get it. A few core developers are paid by their employer, the other are unpaid to contribute to Python. I’m not sure that the Council is in position to ask people to do something.

A new council is elected after each feature release. There are no term limits.

Did you consider to not change all members at once, but renew 1/3 every N months? It can be scary to replace 5 people with 5 other people, all new. The new council may be lost the first weeks, since they don’t know how do you the job. It can be scary for new members but also for core devs and the Python community to change everything at once (isn’t it the current situation since Guido resigned?). For example, the PSF Board only renew a few members every year.

Whenever there is a vacancy during the regular council term, the council may vote to appoint any willing core team member to serve out the rest of the term.

4 members of council can force the 5th member to resign, and so they are free to pick someone else? Well, this case should not happen, I’m not thinking aloud how to trick the system :slight_smile:

What about also organizing a regular vote in such situation?

In exceptional circumstances, a council member may be recalled by a vote of the membership.

What does “recall” mean? Evict a member out of the council?

Very few areas are reserved to core team members: Reviewing security reports

No all members of the PSRT are core developers :slight_smile:

It is granted by a four fifths majority of votes cast in a core team vote and no veto by the technical board.

Hum, 80%. One of the latest vote was for Pablo: if we count Serhiy vote as -1, Pablo got exactly 80%. It’s very close to the limit. And it’s unclear to me if you request >= 80% or > 80% :slight_smile:
https://mail.python.org/pipermail/python-committers/2018-June/005621.html

I suggest to request less majority, like >= 2/3 (>= 66.6%).

I read “Four fifths” as “we are conservative and don’t need fresh blood”. I would like to get fresh blood and move on to be less conservative! It’s ok if there are some -1 votes.

(My PEP 8015 only requires > 50%.)

In order to provide the general public with a reasonable idea of how many people maintain Python (…) Those who haven’t made any non-trivial contribution in two years may be asked to move themselves to this category

It’s also important for security.

Changes to this document require a four fifths majority of votes cast in a core team vote and no veto by the technical board.

IHMO giving a veto to the board is giving too much power.

–

In your draft, you mention a “technical board” … is it the surname of the “steering council”?

19

In practice they will probably not be all new. I expect that some people will be elected for several terms. That’s what happens with the PSF board as well.

There’s nothing mysterious or difficult about the Council’s job in this proposal, AFAIK.

I think you’re wrong. The whole PSF board is renewed every year.

20

Latest election, 2018: PythonSoftwareFoundation/BoardCandidates2018 - Python Wiki

“There are currently 4 open seats on the Board of Directors - 3 for 3 year terms (as part of the cycle established in the 2017 PSF Members vote), and one to fill the 2 years remaining on a departing board member’s 3 year term.”

The board is made of 13 people: https://www.python.org/psf/members/#board-of-directors

2 Likes