[python-committers] And Now for Something Completely Different

[Brett Cannon]

On Tue, 24 Jul 2018 at 16:51 Victor Stinner <vstinner at redhat.com> wrote:

> Brett:
> > This will also make it harder to become a core developer. In the past we
> > have been willing to give people commit privileges for showing they know
> how
> > to code to our standards, make decisions when it came to PRs, and knew
> when
> > they were outside of their depth (e.g. giving someone commit privileges
> to
> > work on Python code but not C). We've also given commit privileges away
> like
> > candy to people who have attended sprints in the past, so we have not
> even
> > held up that level of requirement for all of Python's history.
>
> I don't think that giving core dev priviledge just if you attend a
> sprint is a good practice :-)


It isn't now, but it was what we thought made sense at the time. Remember
the team used to be quite a bit smaller. :)


> Maybe we did that in the past, but it
> seems like nowadays the process is more formalized and stricter.
>

Yes.


>
> Some people wrote that they are "100+" core developers. If everyone
> vote on each PEP, one additional core dev just has 1 vote on 101
> voters. I don't see any pressure here.
>

There has been more than one person who has joined the core team since I
did. ;) From my perspective this isn't about the next person, but the next
10, 20, or 50 people who will heavily influence the outcome of a vote.
Remember, we are measuring time in decades here.


>
> > Now we're being asked to also trust someone's design acumen as they will
> be
> > voting on PEPs. Up until this point I didn't have to worry about whether
> > every core dev would take the language in a direction I disagreed with
> > because they simply didn't have the authority to; it rested with Guido.
> This
> > proposed change, though, means I now have to judge all core developers
> not
> > just on whether I can trust them to code appropriately but whether I
> think
> > they would vote on PEPs that I agree with. That would mean I wouldn't
> have
> > voted to give Pablo commit privileges because I simply do not know his
> > contributions well enough to know if he would make decisions in a way I'm
> > personally in favour of.
>
> IMHO it's ok if people make mistakes on voting if we are enough
> voters. Making mistakes is part of the learning process.
>

I would rather we didn't learn on language changes we will be living with
for decades if we can help it. ;)


>
> If the vote results are public during the vote, if a voter "does a
> mistake", you are free to lobby to vote against this mistake to guide
> people to the right choice :-)
>

I don't think any of us want to lobby against how an individual already
voted. That seems like scare tactics against individuals.


>
> Again, I expect that the discussion before a vote will already
> highlight the popular opinions. The vote result shouldn't be a
> surprise for anyone if the discussion goes well.
>

Right, and your proposal means I now have to judge proposed core developers
on which side of popular opinion they will come down on in hopes that they
vote in ways I agree with and thus help take the language in a direction I
think is appropriate.

My point isn't about being surprised in an outcome. My point is it will
shift how we judge people becoming core devs and the barrier to join will
go up. So unless there's reasonable expectation of an increase in
participants in the project due to a governance shift like this then we
would need to be ready for having slower team growth if this is the
governance model that is chosen.


>
> Honestly, in many cases, I just follow the expert that I trust, when
> I'm unable to have my own opinion on a PEP.
>

Sure, and that's you. But that doesn't mean the 90 other people think that
way. ;) And that's my point: I now have to find out how people will think
going forward in language design and screen future core devs on this new,
extra criteria.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180725/4d5928a9/attachment.html>