Re: [python-committers] And Now for Something Completely Different

2018-07-25 Thread Antoine Pitrou 

Le 25/07/2018 à 01:50, Victor Stinner a écrit :
> 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 :-) Maybe we did that in the past, but it
> seems like nowadays the process is more formalized and stricter.

It seems at some point it was believed that giving commit rights early
would boost participation.  Now we know that doesn't work.

Regards

Antoine.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] And Now for Something Completely Different

2018-07-25 Thread Brett Cannon 
On Tue, 24 Jul 2018 at 16:51 Victor Stinner  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.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] And Now for Something Completely Different

2018-07-25 Thread Donald Stufft 


> On Jul 25, 2018, at 2:01 PM, Brett Cannon  wrote:
> 
> 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.

It makes me think a bit of the US Supreme Court, where judges who might someday 
want to be on that court, learn to be very careful about hiding their true 
opinions (without directly lying of course) on a number of very controversial 
topics, knowing that coming out for/against them is likely to blow up their 
changes of ever progressing to that point.___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] And Now for Something Completely Different

2018-07-25 Thread Antoine Pitrou 

Le 26/07/2018 à 01:21, Donald Stufft a écrit :
> 
>> On Jul 25, 2018, at 2:01 PM, Brett Cannon > > wrote:
>>
>> 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.
> 
> It makes me think a bit of the US Supreme Court, where judges who might
> someday want to be on that court, learn to be very careful about hiding
> their true opinions (without directly lying of course) on a number of
> very controversial topics, knowing that coming out for/against them is
> likely to blow up their changes of ever progressing to that point.

You know, I'm sure that's already the case in the Python community, on
topics such as diversity policies, CoCs and the like.

Regards

Antoine.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] And Now for Something Completely Different

2018-07-25 Thread Alex Gaynor 
On Wed, Jul 25, 2018 at 7:24 PM Donald Stufft  wrote:

>
>
> On Jul 25, 2018, at 2:01 PM, Brett Cannon  wrote:
>
> 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.
>
>
> It makes me think a bit of the US Supreme Court, where judges who might
> someday want to be on that court, learn to be very careful about hiding
> their true opinions (without directly lying of course) on a number of very
> controversial topics, knowing that coming out for/against them is likely to
> blow up their changes of ever progressing to that point.
> ___
> python-committers mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

(I've been quite on this thread thus far, just soaking everything else up,
but this side note about SCOTUS made me want to share this potentially
relevant observation/nerdery.)

Recent trends in Supreme Court nominees increasingly have justices coming
from the DC Circuit [0]. The reason for this (IMO) is that the DC Circuit
deals very heavily in parts of the law that only lawyers care about --
primarily administrative law and suits against the federal government. They
see almost no cases dealing with social issues. As a result, nominees tend
to have records without cases that will generate significant controversy
amongst the public (while still being able to demonstrate their judicial
philosophy to folks who understand such things).

The analogy in the Python-verse might be inviting a new core developer for
their work on runtime internals, but then having the ability to sway stdlib
design once they become a core dev.

This type of system stands in contrast with the one the Rust community has,
where they have dedicated teams, which people are members of (some people
are members of many), and they define the scope of the team's
responsibility/authority. So you can be a member of the compilers team,
with no say over how the community team functions.

Hope everyone enjoyed my Supreme Court nerdery,
Alex

[0]: Chief Justice Roberts, Justice Ginsburg, Justice Thomas, Judge
Garland, and Judge Kavanaugh.

-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/