Scope of the governance PEPs

(Discussion that had started in private email, transferring to Discourse as it’s probably of general interest)

Oh, this discussion is becoming interesting. I would prefer to have it
in public. Would you mind to create a topic on Discourse?


Le ven. 16 nov. 2018 à 18:50, Paul Moore <> a écrit :
> On Fri, 16 Nov 2018 at 16:59, Victor Stinner <> wrote:
> >
> > Le ven. 16 nov. 2018 à 16:17, Paul Moore <> a écrit :
> > > Yes, I read that bit after my posting. I’m not sure I agree - after
> > > all, this is supposed to be about governance specifically, and I’m not
> > > keen on having to agree to (for example) your proposal on how core
> > > developers are promoted (which I disagree with - I find it too
> > > bureaucratic and prescriptive) if I want to say that I prefer a
> > > “steering committee” model over a “new BDFL” model (I’m not sure if I
> > > do want to state that preference yet, but you understand my point).
> >
> > Aha, why do you think that my process to promote a core developer is
> > too bureaucratic? Is it so different from the current process?
> :slight_smile: I don’t really want to get into too much detail here because I
> haven’t really thought my position through (that’s also why I’m
> bothered about this being part of the governance decision). But
> basically the thing that bothers me is that having precise “this many
> votes equals yes, this many equals no” rules feels to me like it risks
> edge cases like someone getting promoted based on one more than the
> minimum vote, or people getting promoted with not many people having
> voted. The current process is much more informal, and is based on
> broad consensus (a deliberately imprecise measure which basically
> means “is it obvious that the current core devs approve?”) When I was
> invited to be a core dev, I’d have been a bit bothered if I found out
> once I’d joined that I had only been voted in by a small margin.
> Also, I feel that formal votes for new core devs puts more pressure on
> existing devs to “make the right decision” (specifically, I would
> feel under pressure), which in turn might lead to people being put off
> voting. Whereas an informal comment on a discussion along the lines of
> “I’ve always found such-and-such to have good judgement and the work
> I’ve seen of theirs seems of high quality, so I’m in favour” seems
> much easier to give - and it also provides better feedback to the new
> core dev when they get accepted and go looking at the discussion after
> the fact (I don’t know if others do that, but I did, and it was quite
> pleasant reading the nice comments, much better than seeing a sterile
> tally of +1/-1 votes).
> Well, that’s getting into more detail than I intended to, sorry :slight_smile:
> > We are already voting on the python-committers mailing list with +1
> > and -1 votes. But I dislike that each -1 is a veto. In practice, it
> > wasn’t the case. See this discussion:
> > Private ballot for voting on promoting a contributor as a core developer?
> Well, that’s not what the current process feels like to me. For me,
> it’s always felt more like a general discussion resulting in consensus
> (or not - but -1 votes don’t “feel like” vetos to me, just indications
> that we haven’t got consensus yet). But maybe my memory is missing
> some examples.
> By the way, I’m a very strong -1 on private votes to accept new core
> devs. If we’re going to work with the new dev, we should be open with
> them about our views. I’m not going to read that whole thread about
> core the dev process, and I certainly don’t want to jump into it 4
> days after discussion has died down, but if we’re going to have
> private ballots about new devs (as opposed to open discussion on a
> forum that the proposed candidate will be able to see if they get
> accepted) then I probably won’t vote. Picking up on another aspect
> of your governance proposal which, while not something I disagree
> with, is nevertheless out of scope of “governance”, we expect core
> devs to be exemplary in terms of the CoC. Surely that means we can
> expect people to be able to discuss whether they think an individual
> is ready to be a core dev in a considerate and sympathetic manner,
> that they would be happy to post publicly? Negative comments that
> you’re not willing to make in public don’t exactly sound like
> “exemplary behaviour”…
> > Core developers have specific permissions, like voting on a PEP and
> > elect Steering Committee members. IMHO it’s important to explain the
> > full process: contributor => core dev, core dev => committee.
> Explain, maybe. Propose changes to, not so much. The proposal should
> be restricted to only proposing changes needed to replace Guido.
> Otherwise it’s hard to judge this proposal on an even basis against
> others that don’t propose changes that are outside that limited
> scope.
> But the proposal is what it is - we’re now in the discussion phase and
> I have to judge what’s there, not what I’d like to be there. That’s
> why I originally made my comment on the “how do we feel about the
> proposals now they have been submitted” thread.
> > I am working on the process to promote core developers for 2 years. I
> > wrote a draft PEP, but I never brave enough to propose it:
> >
> I dislike that process, sorry. Not least because I would not be a core
> developer if I’d had to follow it. IMO, there are many routes to
> becoming a core developer, and insisting that one route is the only
> valid one denies people who follow a different path.
> It should be noted here that I view “being a core Python developer” as
> much more than getting the commit bit (I can commit, but very rarely
> do). It’s about involvement in the community, having gained respect
> and possibly even authority. All sorts of things that result in
> comments like “I didn’t know they weren’t already a core dev” when
> people get proposed. And being able to say “I am a core Python
> developer” is a privilege, and something to be proud of, definitely
> not just an additional burden of responsibilities and commitments.
> > Even if Guido asked me two or three times to propose it :slight_smile:
> Well, that Guido guy, what does he know? :slight_smile:
> I’m a little sad this discussion is private - it really ought to be
> happening in public (or not at all, I guess). That’s a consequence of
> being able to post something then delete it on Discourse, I guess -
> the connection to the original thread is lost. I don’t know how we’d
> even graft this back onto the Discourse thread now, or even if it
> makes sense to. The discussion has ranged pretty widely and I feel
> that people might expect it to be split into multiple topics (which
> I’m not particularly inclined to try to do, as in my head it’s all
> linked together under a common theme). I’ll probably add a new comment
> there summarising my view a bit better than my original post did.
> Paul

As I stated in Straw poll: Which governance proposals do you like best? - #20 by brettcannon, I think PEPs which give core developers the vote are within their rights to also clearly define what it means to become a core developer as it means the position now comes with new powers and responsibility.

For example, let’s say we had a “Core Dev of the Month” for whomever merged the largest number of PRs in a month. When the recognition was established all you got was your name on some website. IOW it didn’t really matter that you could game the system since the relation of receiving the “power” of being recognized didn’t really outstrip what it took to receive it.

Now imagine that one of the governance PEPs said the Core Dev of the Month got to decide on all PEPs presented the following month. Suddenly you very much care about how the Core Dev of the Month is chosen. I would argue the same is happening here: when core devs suddenly gain the vote for PEPs, you then start to care differently about how someone becomes a core dev which gives them that vote.

It will also make becoming a core dev that much more enticing to those who would like to have that sort of power with Python. While PEP 8010 and 8011 have fairly powerful positions, the voting of people into those positions helps prevent any random person walking in and saying “I think I should become the GUIDO!” But when all core devs suddenly get to vote on PEPs, that lowers the difficulty of wielding some power that we all didn’t have before.

So I do think it is totally within the scope of the governance PEPs to define what it means to become a core developer when the powers that the title bestows upon them will be increasing in a consequential manner.

I think part of it is also that with Guido, we had an easy answer as to who was the final arbiter for anything, it was Guido. So while we currently sort of vote on core developers, there’s also an implicit idea that if someone declares “And now this person is a core developer” when the vote doesn’t have enough +1s, that Guido can step in and say “No”.

So things could be a lot more freeform, because we knew that if we over stepped our bounds, that Guido was there to act as the final say to course correct any problems we come across. Any proposal that removes that, pretty much has to (or should anyways) deal with the ambiguity left over when we no longer have Guido to fall back on.

1 Like