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.