Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Brett Cannon]

On Fri, 20 Jul 2018 at 17:05 Victor Stinner  wrote:

> 2018-07-21 0:58 GMT+02:00 Mariatta Wijaya :
> > Oct 1: Deadline for people to come up with proposals of governance model,
> > candidates, and how to vote
> > Dec 1: Deadline to choose a governance model, (and if possible, we choose
> > the new leader(s) too)
>
> What happens between October and December? People have 2 months to
> vote for their preferred governance?



> Why is the vote open for 2
> months?


I think the plan would be  to discuss what goes on the ballot and figuring
out who will vote (based on our decision by Oct 1), and then voting would
be open for the month of November).


> Can't we vote in 2 weeks for example?
>

Because others have been worried that a short amount of time to vote for
such a serious thing, especially if people happen to not be available. Or
put another way, people want enough lead time to be sure they are available
to vote and know to look for a voter email if they happen to be travelling
for all of November (just like you don't want us to make you write up your
governance proposal in August ;) .


>
> I guess that "Deadline" means that we are allowed to agree on
> something earlier :-) In that case, I'm fine with that.
>

Maybe. As I said, some people have asked for a large lead time to know when
a vote will happen to make themselves available so I'm not sure how much we
may be able to bring it up. It's possible, but I don't think it's
guaranteed.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Victor Stinner]

2018-07-21 0:58 GMT+02:00 Mariatta Wijaya :
> Oct 1: Deadline for people to come up with proposals of governance model,
> candidates, and how to vote
> Dec 1: Deadline to choose a governance model, (and if possible, we choose
> the new leader(s) too)

What happens between October and December? People have 2 months to
vote for their preferred governance? Why is the vote open for 2
months? Can't we vote in 2 weeks for example?

I guess that "Deadline" means that we are allowed to agree on
something earlier :-) In that case, I'm fine with that.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Nathaniel Smith]

On Fri, Jul 20, 2018 at 3:50 PM, Brett Cannon  wrote:
>
>
> On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith  wrote:
>>
>> On Fri, Jul 20, 2018, 08:58 Brett Cannon  wrote:
>> > While I'm purposefully staying out of this thread as my name is
>> > currently so strongly associated with it and I don't want people thinking
>> > I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50%
>> > time at Microsoft if I asked for it (I already get a day/week plus email
>> > reading every day).
>>
>> Is that only if you were named BDFL, or do you think they might also
>> support that if you were named "Chief PEP Herder", or "Member of the
>> steering council",or similar?
>
> It isn't really title and more about workload/responsibility. So if the
> title changed to "Chief PEP herder" but it was still on my shoulders to have
> final say then I don't expect an issue as they would understand what that
> means to me and my time. If I'm one of three on a council then I might still
> get more time but I'm not as sure; it's definitely possible, but not as much
> of a sure thing. If the group was 10 then probably not because that means I
> am just one of about a quarter of all authors over the past year.

Right, my point was more that "workload" and "authority" are related
but not exactly the same :-). For example, if we ended up with a
governance model in which final PEP acceptance is based on consensus
or voting or something, then we wouldn't have a BDFL, but it still
might be *very* helpful to have people with dedicated time to help
shepherd PEPs through the process of building consensus, working out
exactly what the points of disagreement were that needed to be voted
on, mediating arguments that get out of hand, and so forth [1] --
that's what I was trying to handwave at with the "Chief PEP herder"
title.

> I think that's a constant discussion to have which never really ends. People 
> with more time to effectively contribute is always welcome. :)

Sure, but there is something special about this moment too :-). If we
think that funding positions like these would make a significant
difference to the viability of our community post-Guido, then now is a
time when we could go to companies and say "look, Python is going
through this critical transition, it needs this kind of funding to
survive and thrive, can you help?", and see how they respond.

I don't want to put you on the spot and I know you can't make promises
on behalf of MS, so maybe I shouldn't have asked. But generally – we
have some evidence that companies might be willing to fund someone to
be the BDFL. It'd be useful to know whether companies would also be
willing to fund crucial community work even if it didn't mean they got
to boast about having the BDFL on their payroll.

-n

[1] personally I suspect that python's survival is going to depend
much more on whether we have people doing this kind of work, than on
which specific formal governance structure we end up with

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
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

[Victor Stinner]

2018-07-20 18:32 GMT+02:00 Steven D'Aprano :
> What happens when two trusted experts disagree and the voters don't have
> the expertise to tell which one is correct?

In my proposal, if no consensus can be found, the vote fails to reach
the majority, the PEP is rejected.

Usually, people disagree on on specific aspect of a PEP, not on the
overall idea. This is where I propose to separate the decision in two
votes: one vote for the "overall PEP" and one vote to decide between
two variants (paint it blue or green?).


> The sort of participatory democracy Victor and you seem to be talking
> about doesn't scale beyond small communities where everyone knows
> everyone else. That's why such participatory democracy worked in ancient
> Greece, and continues to be used in (eg) Swiss canons, but beyond that
> communities have moved to a representative democratic model.

Hum, I'm not sure if it's revelant here, but in France, 44 855 000
people vote for the president every 5 years.

If you want numbers, it seems like PHP has around 32 voters on RFC. I
also expect a number around 30 for Python. I'm not talking about the
total number of core developers (who can vote), but the number of core
developers that I expect to vote on a single PEP. I expect that many
cores will abstain from voting because they consider that it's not
their interest area, they didn't have time to follow the discussion or
they are "away from keyboard".


> One factor that I don't think Victor has covered is that of what
> percentage of core devs would have to vote for the result to be
> accepted -- a quorum, or equivalent.

My worst example for a vote would be the PEP 446 example that I used
previously. In short, they were 3 people who cared: Charles-François
Natali, Guido van Rossum and me (the author).

First, I would suggest that the authors are not allowed to vote on
their own PEP. For the PEP 446, it means that there were only 2
voters.

I propose to require at least 3 voters on a PEP. For the 50%+1
majority case, it means 2 "+1" votes are enough to approve a PEP on a
total of 3 voters. On sensitive PEPs (the ones with 66%+1 majority), I
propose to require at least 5 voters. If there are not enough voters,
the vote is canceled and a new vote can be attempted later.

I don't think that we will reach this minimum often. If it occurs,
maybe we can extend the vote window and ask people to vote.


> When it comes to *representative democracy* I believe that the
> Australian model of mandatory voting (resulting in 90% turnouts or
> higher) has many advantages over other systems. But for a technical
> community like this, I don't know that mandatory voting is desirable.

Wait. I'm against mandatory voting.

First, it's common that people are away from their computer for good
reasons like holidays.

Second, I would strongly suggest core developers to abstain to vote if
they didn't read the PEP (at least) or if they consider that they
don't know enough to be able to have an opinion on a PEP.


> (Perhaps if we have an Abstain option as well as Yes or No.)

I propose to not account "vote: 0" and missing voters to account the majority.

Ballot example:

* Like (+1): 6
* Dislike (-1): 5
* Abstain: 1

If you account Abstain, 50%+1 majority means: (6+5+1)//2+1, at least 7
"like" votes are needed for the majority.

If you ignore Abstain, 50%+1 majority means: (6+5)//2+1, at least 6
"like" votes are needed for the majority.

IMHO 6 to win the vote makes more sense than 7. It becomes even more
obvious if you account all core developers who didn't vote, it would
look more like:

* Like (+1): 6
* Dislike (-1): 5
* Abstain: 60

:-)


> Personally, I'm not sure I'd even want to vote on every PEP that comes
> up. (...)

Me neither :-) As I wrote, I'm already ignoring some topics like
typing and packaging.


> Another issue we should consider: organised vote swapping. If votes are
> public, as Victor suggests, that would allow people to do deals: "I'll
> support your PEP for GOTO, if you support my PEP to deprecate tuples..."
> sort of thing. There's a reason why most ballots are secret.

I propose to make the vote public. I expect that some people who are
not sure about their vote will check who already voted (and what were
their vote) to help them to make a choice.

After talking with friends, I realized that I forgot to explain
something: my proposal doesn't change anything on the long discussion
which occurs *before* the vote. IMHO most tractions occurs during
these discussions, not during the vote. (I'm not sure of the word
"traction": I mean the pressure to pull most people on your side.)

By the way, I propose that the vote window will be "short": just 1 week.

Maybe we should announce the date of the vote 1 week before, to make
sure that people who care about the PEP will be available to vote.

Let me explain why I prefer a short window with a counter example. If
a vote remains open for 1 month, the discussion will likely continue
during the vote, and 

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Brett Cannon]

On Fri, 20 Jul 2018 at 16:25 Carol Willing  wrote:

> Thanks all. I am glad that Victor likes October 1. :-)
>
> So can we formalize the timeline proposed by Mariatta?
>

Fine by me. Everyone who cares to comment seems to agree that Oct 1 is good
and I think the Dec 1 deadline is very reasonable. We might need to
re-evaluate the Jan 1 date as we get closer, but I don't think we need to
worry about that right now.

-Brett


>
> On Fri, Jul 20, 2018, 5:58 PM Mariatta Wijaya 
> wrote:
>
>> As quick refresher, my proposed timeline is:
>>
>> Oct 1: Deadline for people to come up with proposals of governance model,
>> candidates, and how to vote
>> Dec 1: Deadline to choose a governance model, (and if possible, we choose
>> the new leader(s) too)
>> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec
>> 1.
>>
>> Mariatta
>>
> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Carol Willing]

Thanks all. I am glad that Victor likes October 1. :-)

So can we formalize the timeline proposed by Mariatta?

On Fri, Jul 20, 2018, 5:58 PM Mariatta Wijaya 
wrote:

> As quick refresher, my proposed timeline is:
>
> Oct 1: Deadline for people to come up with proposals of governance model,
> candidates, and how to vote
> Dec 1: Deadline to choose a governance model, (and if possible, we choose
> the new leader(s) too)
> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec
> 1.
>
> Mariatta
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Brett Cannon]

On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith  wrote:

> On Fri, Jul 20, 2018, 08:58 Brett Cannon  wrote:
> >
> >
> >
> > On Fri, Jul 20, 2018, 07:51 Nick Coghlan,  wrote:
> >>
> >> Guido was willing to do it for so long because Python was his
> >> creation, and he grew into the increasing demands of the BDFL role as
> >> time went by, but even he eventually reached the point of saying "I
> >> don't want to do this any more - the personal costs are outweighing
> >> the personal benefits". There's no way that a new individual in a
> >> comparable role to Guido's is going to have an easier time of it than
> >> Guido did, and a lot of good reasons to believe that they will find it
> >> significantly harder (not least of which is that Guido has been able
> >> to request 50% funded "BDFL-time" from his employers since he joined
> >> Google in 2005, and it's unlikely that a newcomer to the role would
> >> enjoy that benefit any time soon).
> >
> > While I'm purposefully staying out of this thread as my name is
> currently so strongly associated with it and I don't want people thinking
> I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50%
> time at Microsoft if I asked for it (I already get a day/week plus email
> reading every day).
>
> Is that only if you were named BDFL, or do you think they might also
> support that if you were named "Chief PEP Herder", or "Member of the
> steering council",or similar?
>

It isn't really title and more about workload/responsibility. So if the
title changed to "Chief PEP herder" but it was still on my shoulders to
have final say then I don't expect an issue as they would understand what
that means to me and my time. If I'm one of three on a council then I might
still get more time but I'm not as sure; it's definitely possible, but not
as much of a sure thing. If the group was 10 then probably not because that
means I am just one of about a quarter of all authors over the past year.


>
> AFAICT Guido spent a lot of time behind the scenes moving PEPs along
> and generally keeping things organized. I think we might get a lot of
> value out of having more people with time to focus on these things,
> and it's not really limited to the BDFL. The Django project seems to
> benefit a lot from their fellows program [1], and in the recent grant
> the PSF got for PyPI, everyone was *very* happy that we spent money on
> a project manager [2]. (And at the risk of falling into megalomania
> myself, I've also written about this recently [3].)
>
> So I don't have a specific proposal or anything, but maybe as part of
> this discussion we should be exploring ways to get more dedicated time on
> CPython, through company's donating time, or sponsoring people through
> the PSF, or whatever makes sense.
>

I think that's a constant discussion to have which never really ends.
People with more time to effectively contribute is always welcome. :)

-Brett


>
> -n
>
> [1]
> https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospective/
> [2] https://twitter.com/EWDurbin/status/968180960066928640
> [3]
> https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open-source-infrastructure/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Brett Cannon]

On Fri, 20 Jul 2018 at 15:23 Victor Stinner  wrote:

> 2018-07-20 22:42 GMT+02:00 Brett Cannon :
> > The leading proposal of a deadline to get governance model proposals in
> and
> > deciding on a voting procedure is October 1. Do you need more time than
> > that? And if so how much are you asking for?
>
> Carol wrote "Proposals due by Sept 9, 2018 AOE".


Yep, and most people disagreed. :) Mariatta's timeline seems to be what
people like.


> I'm fine with October 1.
>

Great!
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Nathaniel Smith]

On Fri, Jul 20, 2018, 08:58 Brett Cannon  wrote:
>
>
>
> On Fri, Jul 20, 2018, 07:51 Nick Coghlan,  wrote:
>>
>> Guido was willing to do it for so long because Python was his
>> creation, and he grew into the increasing demands of the BDFL role as
>> time went by, but even he eventually reached the point of saying "I
>> don't want to do this any more - the personal costs are outweighing
>> the personal benefits". There's no way that a new individual in a
>> comparable role to Guido's is going to have an easier time of it than
>> Guido did, and a lot of good reasons to believe that they will find it
>> significantly harder (not least of which is that Guido has been able
>> to request 50% funded "BDFL-time" from his employers since he joined
>> Google in 2005, and it's unlikely that a newcomer to the role would
>> enjoy that benefit any time soon).
>
> While I'm purposefully staying out of this thread as my name is currently so 
> strongly associated with it and I don't want people thinking I'm a 
> megalomaniac, I will say that I see no reason why I wouldn't get 50% time at 
> Microsoft if I asked for it (I already get a day/week plus email reading 
> every day).

Is that only if you were named BDFL, or do you think they might also
support that if you were named "Chief PEP Herder", or "Member of the
steering council",or similar?

AFAICT Guido spent a lot of time behind the scenes moving PEPs along
and generally keeping things organized. I think we might get a lot of
value out of having more people with time to focus on these things,
and it's not really limited to the BDFL. The Django project seems to
benefit a lot from their fellows program [1], and in the recent grant
the PSF got for PyPI, everyone was *very* happy that we spent money on
a project manager [2]. (And at the risk of falling into megalovania
myself, I've also written about this recently [3].)

So I don't have a specific proposal or anything, but maybe as part of
this discussion we should exploring ways to get more dedicated time on
CPython, through company's donating time, or sponsoring people through
the PSF, or whatever makes sense.

-n

[1] 
https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospective/
[2] https://twitter.com/EWDurbin/status/968180960066928640
[3] 
https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open-source-infrastructure/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Victor Stinner]

2018-07-20 22:42 GMT+02:00 Brett Cannon :
> The leading proposal of a deadline to get governance model proposals in and
> deciding on a voting procedure is October 1. Do you need more time than
> that? And if so how much are you asking for?

Carol wrote "Proposals due by Sept 9, 2018 AOE". I'm fine with October 1.

Victor
___
python-committers mailing list
python-committers@python.org
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

[Brett Cannon]

On Thu, 19 Jul 2018 at 16:47 Victor Stinner  wrote:

> or: Replace Dictatorship with Democracy.
> [SNIP]
>
>
> == What is the image send to the community and contributors? ==
>
> Last year, I mentored multiple contributors. What I learnt is that
> contributing to Python is much harder than what I expected.
>
> Most core developers are core for 5 years or longer (maybe 10 years
> for some of them?), and we (core developers) forgot how hard it is to
> contribute. When your name is known in a community: it's very easy to
> share your ideas, other people listen to you and respect your
> experience. It's much faster to get a pull request merged... sometimes
> simply because you merged your own PR :-)
>
> Becoming a core developer takes between 6 months and 2 years, it
> requires a lot of commitment, to have free time, etc. In short, it's
> *very hard* to recruit new core developers. It seems like many people
> forgot that.
>
> What is the image sent to contributors if we create a subgroup inside
> core developpers called "council"? What if we elect a new BDFL *for
> life*? Does it mean that even core developers judgment are no longer
> trusted, only the council decision matters? What about people outside
> in the insider group of cores... regular contributors? Will anyone
> still listen to them?
>
> I'm not saying that a new governance will lead to such issues. I'm
> only opening the question of the image sent to the community.
>

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.

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.


> [SNIP]
>
> Advantages.
>
> [SNIP]
>
> The decision becomes taken by "the community" (core developers in
> practice) rather than an individual. Negative comments should no
> longer target an individual but the collective decision. Being a
> public person is not easy, it seems like Guido resigns partially
> because of that pressure. I know that Brett Cannon also suffered of
> negativity of some haters of the Internet. I also had a depression
> recently caused partially by Python. Working on an open source and
> public project causes specific issues.
>

Steve pointed out in his reply about how this might increase load as people
will have to start trying to get people on side to vote the way they want.
In US politics this is done by someone called a *whip* who "whips up" votes
for a bill. With 91 (or more if people start to come back to use their
commit rights who have not added their GitHub usernames) of us getting
grandfathered into this, people will be somewhat political in getting votes
for or against PEPs they care about since only people post-Guido would be
made core devs knowing they now have a vote on PEPs and thus take that into
consideration when adding new members to the team.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Brett Cannon]

On Thu, 19 Jul 2018 at 14:59 Victor Stinner  wrote:

> Please extend the deadline: next week, I will be at EuroPython (I
> don't think that I will have time to sit down and come up with
> something), and I'm (more or less) in holiday the whole month of
> August.
>

The leading proposal of a deadline to get governance model proposals in and
deciding on a voting procedure is October 1. Do you need more time than
that? And if so how much are you asking for?

-Brett


>
> Victor
>
> 2018-07-19 21:43 GMT+02:00 Antoine Pitrou :
> >
> > Le 19/07/2018 à 21:35, Carol Willing a écrit :
> >>>
> > My biggest concern is that dragging this on into the new year will
> > result in more bikeshedding, more uncertainty, and less confidence in
> > the developer community decision making ability.
> 
>  That's a fair point.  But there's also an opposite concern that
>  discussions may be deterred or cut short by a too tight deadline.
> Even
>  simple and uncontentious PEPs take time to write, discuss and
> finalize.
> >>>
> >>> Maybe it would be better to focus on a first date for submitting
> >>> proposals and then wait to set the rest of the deadlines until after
> >>> we have a bit more of the discussion behind us. That will give us
> >>> a sense for how much consensus there is and how much more discussion
> >>> might be needed.
> >>
> >> This suggestion seems to balance well the different perspectives.
> >>
> >> Proposals due by Sept 9, 2018 AOE.
> >
> > I still think it's too short.  Imagine someone leaving in August.
> > Besides catching up with work, the beginning of a new school year (if
> > they have kids) and other things, they have only 9 days to contribute
> > usefully.
> >
> > This is not something we can mobilize for to try and compress the time
> > span as much possible.
> >
> > Regards
> >
> > Antoine.
> > ___
> > python-committers mailing list
> > python-committers@python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
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

[Donald Stufft]

> On Jul 19, 2018, at 7:47 PM, Victor Stinner  wrote:
> 
> It seems that the main question for a new governance is how to take a
> decision on PEPs (accept or reject them with some variants like
> Deferred). I read that core developers are unable to make a decision
> themselves (fail to reach a consensus) and that letting core
> developers decide would make Python "inconsistent" (as if only a
> single BDFL is able to keep Python consistent). I also read that the
> BDFL is required to make unpopular decisions to enhance Python.

I think the core difference behind all of the proposals, when you get down to
brass tacks, will be the vision for where the langauge goes. There are
independently good ideas that maybe should not be accepted, because they
compromise the vision for the worse, or ideas that seem poor on the tin but that
once they get added they mesh well with the overall language.

The further you scale up the number of people directly deciding the direction
of the language, the more likely you will find inconsistency. No two people have
the same design sense, and so if you ask two people you're likely to get at
least two answers.

Of course with many things, there are grey areas. If you have some sort of
council of N developers, with a small enough N you can arrive at a place where
the design sense for all of N are closely enough aligned that the inconsistency
produced by them are minor enough as to not be noticeable. However, the larger
you make that group, the more likely you are to introduce larger and larger
inconsitencies.

Now, that doesn't mean that focusing on consistency to the end of all other
things is the right choice. The laws of any democratic country tend to be
extremely inconsistent, due to that very reason, but most people would not argue
that we should revert democracy back to dictatorships in those countries.

Democracy brings with it more power to the "masses" and helps protect against
a sole leader drastically going against the will of "the people" over an
extended period of time.

So realistically, the choice comes down to whether we value consistency more
(in which case, we'd want to favor solutions that have a small N) or more
directly empowering people with a democracy.

Of course, you could try to do something that combines the two of them. You
could elect a BDFL, but have PEPs go through a vote process first where they
need to get a simple majority, and at which point the BDFL could approve or
veto, and if they veto, then the voting body gets an additional chance to vote
and if they're able to get a larger majority (2/3?) then they can override the
BDFL's veto. That provides some protections from both a "design by committee"
effect (since the BDFL can veto) but also provides very popular proposals a
chance to pass even if the BDFL is against them.

The big loss of that compromise is that you again, give up some of the
consistency, since a large enough group of developers can still introduce an
inconsistent vision and you remove the ability for the BDFL to accept unpopular
but long term necessary PEPs (since they'd have to get a simple majority first).


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Steve Dower]

On 20Jul2018 0858, Brett Cannon wrote:
While I'm purposefully staying out of this thread as my name is 
currently so strongly associated with it and I don't want people 
thinking I'm a megalomaniac, I will say that I see no reason why I 
wouldn't get 50% time at Microsoft if I asked for it (I already get a 
day/week plus email reading every day).


I agree that this would likely happen. (Also that he's not a megalomaniac.)

I've been talking with our senior management about all this a bit over 
the last week, and the general mood is concern for Python's future if we 
spend an extended time without leadership. Microsoft's future these days 
certainly includes the Python ecosystem, and providing time for an 
employee to contribute freely in such a leadership role should be very 
easy to arrange.


And since most people are probably not aware of the "day job" breakdown 
we have, Brett does not spend his time working on Microsoft's policy 
directions on Python - that is largely me and some people who are not 
really known outside the company - so I wouldn't be concerned about 
Python being "forced into alignment" with anything except Visual Studio 
Code ;)


I also agreed to Barry's proposal under the expectation that I would 
still take a month off every year and one day a week like I do already. 
That plus a council of folks to help with the load makes me think I can 
handle the workload without having to sacrifice more personal time than 
I'm already comfortable doing now. I also think that we as a team and a 
community are a bit more aware of the issue of burnout thanks to Guido's 
retirement.


Plus Andrea said it was okay  (The cat was indifferent.)


"Approval of his/her household" is actually a really good criteria for 
taking on this kind of role :)


Cheers,
Steve
___
python-committers mailing list
python-committers@python.org
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

[Barry Warsaw]

On Jul 20, 2018, at 00:49, Antoine Pitrou  wrote:
> 
> I find the PEP-delegate to be a powerful concept.  Why wouldn't *every*
> PEP have a PEP-delegate?  This way we don't need a BDFL anymore.  We can
> discuss how to nominate PEP-delegates (Nick had an interesting proposal).

Because IMHO that would lead to a language designed by committee, with a less 
consistent vision.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
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

[Doug Hellmann]

Excerpts from Steven D'Aprano's message of 2018-07-21 02:32:02 +1000:
> On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote:
> > Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
> 
> [...]
> > > In contrast, I would imagine that people would continue to discuss
> > > PEPs in exactly the same way that they currently do, so the result
> > > would be that the votes are based more on partially-informed opinion
> > > and "gut feeling". Certainly some people will work harder to provide
> > > an informed vote, but I doubt that will be true in the majority of
> > > cases. Worst case, people will feel a responsibility to vote, but
> > > won't have any more time than they do right now so they'll vote with
> > > limited information simply because "it's expected of them" to vote.
> 
> [...]
> > In other communities that use this form of consensus approval for
> > design changes I have seen folks who do not have time or interest
> > to dig deeply into a proposed change learn to trust others who have
> > the time, interest, and expertise. The team comes out stronger as
> > a result of that built-up trust.
> 
> A few questions...
> 
> You say folks "learn to trust others", but what does that mean in 
> practice? The only interpretation I can think of is:
> 
> People vote for a feature, because Fred says he's in favour 
> of it and they trust him, or like him personally, or because
> he's more charismatic and persuasive than those against it.
> 
> What happens when two trusted experts disagree and the voters don't have 
> the expertise to tell which one is correct?

The same sort of thing that happens with PEPs. Either the proposal
itself is changed to support more compromise, or it is abandoned and the
status quo prevails.

> How large are these communities you are referring to?

OpenStack had 2000 contributors during 2017. Of those, I would
estimate that on the order of a few hundred are considered core
reviewers in some way and would have a formal vote in our specification
process, although the group reviewing any given specification would
be somewhat closer to the size of the python core developer team
size.

> The sort of participatory democracy Victor and you seem to be talking 
> about doesn't scale beyond small communities where everyone knows 
> everyone else. That's why such participatory democracy worked in ancient 
> Greece, and continues to be used in (eg) Swiss canons, but beyond that 
> communities have moved to a representative democratic model.

It is certainly harder to implement as the size of the group grows. I
don't think this group has hit the point where it is impossible to
sustain, though.

> Certainly the Python community as a whole is *significantly* bigger 
> than a village. What about the core developers? Now? In the future?

I'm not sure the entire Python community is really the relevant
size to consider. Another important aspect of open source governance
to keep in mind is that decisions need to be made by the folks doing
the work.  That's one reason the existing PEP delegate process works
so well today -- the person making that final decision is invested
in not just the decision but the overall area where the work is
happening. We already trust them to both know what they are doing
technically and guide the decision making process to consensus.

I find it interesting that the arguments in favor of a single BDFL
tend to assume that the person selected will be responsible and
informed enough to make good decisions, and the argument against a
more democratic approach seems to be that the community would not
be. Where in that latter assumption is the leadership of the person
we would be giving the BDFL title to? Why are they unable to
communicate, inform, and lead a democratically organized community
to achieve goals for the common good? And if they can't, why are
they qualified to be a dictator?

> One factor that I don't think Victor has covered is that of what 
> percentage of core devs would have to vote for the result to be 
> accepted -- a quorum, or equivalent.

Yes, this is a good point. I'm not sure a 1-size-fits-all approach
necessarily works, but some way of deciding how to know when consensus
is reached would be an important aspect of choosing a democratic
approach.

> Personally, I'm not sure I'd even want to vote on every PEP that comes 
> up. When I was first nominated to the PSF, I took the voting rights as 
> both a privilege and a duty and took them very seriously indeed. But as 
> time went on, I got somewhat disillusioned and burned out (for reasons 
> we need not go into). And that is only voting once or twice a year.
> 
> If I had to vote on a dozen or two dozen PEPs a year, most of which I 
> have little or no interest in, the annoyance factor would be 
> correspondingly greater. But if I don't vote, could that doom PEPs to 
> fail because they don't get a quorum?

One approach some of our teams take is to have a subset of the core

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

[Steve Dower]

Summary: appointing a BDFL or small council *does not* force them to do 
all the work themselves.


On 20Jul2018 0457, Victor Stinner wrote:

mailing list (I'm talking about "+1" emails), before a formal and well
defined PEP is written ;-)


Until your new process arrives, "+1" emails are not votes and have never 
been considered as such. They've always been an easy and impersonal way 
to provide the BDFL[-delegate] with the opinions of the experts within 
the team who have taken the time to review a proposal.


Judging the general feeling of an email list is impossible without such 
emails. Counting these without taking into account the person providing 
the vote is a terrible idea (for example, if the topic is itertools, my 
+1 in no way comes close to cancelling out Raymond's -1, and nor should it).




People are free to send emails, but at the end, a vote would occur on
a proper PEP, not on emails.


Substitute "vote" for "decision" (which may be decided by voting, but 
does not presuppose that voting is the only option) and I'm +1 on this. 
The final decision should always be made against the PEP, not the 
discussion.




[Ethan] My first issue with this model is, as discussed above, a lack of a
consistent vision.  A BDFL is not just there to say, "this PEP is accepted,"
but also to say, "change this one piece here, remove that piece there, add
this" -- definitely not something easily done by 100+ voters.


I agree that an author can be confused when two different core
developers ask to make two opposite changes. This is where an expert
can help the author to drive the discussion and help the author to
make choices.

To formalize a little bit more, I would identify 3 groups: PEP authors
(usually an individual), group who help authors to write the PEP and
drive the discussion, group who vote (all core devs) at the end.


Despite apparently being completely opposed to the other proposals, this 
part matches them nearly identically.


Everyone seems to be in support of a model where:
* anyone can propose a change (PEP author)
* trusted people should help sponsor/champion it (core committer 
bringing it to python-dev)

* trusted person/people should make a final determination

The only argument I see is entirely around how to choose that last 
group. The options:


* choose one person who always has to make that determination
* choose one person who chooses that group on a proposal-by-proposal basis
* choose a small group who always has to make that determination
* choose a small group who chooses that group on a proposal-by-proposal 
basis

* don't choose and force everyone to make that determination

Your proposal is the last one. My preference is the second or fourth. 
Some people seem to assume that unless we slow down now we will 
automatically end up with the first or third, but I don't see any basis 
for that assumption.


A BDFL or Council are free to delegate as much or as little as they 
want, and could conceivably reduce their workload to "once a week I will 
review emails starting with '[PEP xxx] Request for delegate' and provide 
a response".



I saw people writing "mandatory votes" in a different thread. I don't
see why anyone would be forced to vote on PEPs :-) (I'm not talking
here about this very specific case of deciding a new governance for
Python.)

I prefer to abstain me from commenting PEPs in some areas like typing
or distutils, since they are out of my interest area and I don't feel
that I would add anything useful. I love that other experts who have a
stronger background in these topics than me are able to provide good
feedback to drive the discussion.


"Abstain" is counted as a vote, just not in any direction. The point 
about mandatory voting is whether we need to wait for you to respond 
before considering a decision to have been reached. If we make that 
decision numerical, then sooner or later we will need to make 
exceptions. If we have appointed 1-to-n people to determine when a 
decision has been reached, the flexibility is built in to the process.



Hum. Let me try to explain my point differently. Currently, some
people don't read PEPs just because at the end, only the single BDFL
vote counts. What's the point of spending hours (if not days) on
reading a long PEP and the long discussion on mailing lists, if your
count doesn't count? Now imagine that all votes count. I expect that
people will spend more time on reading carefully each PEP and follow
more closely discussions since they will be de facto more involved in
the decision process.


If/when we choose a BDFL, it will need to be someone who is known for 
listening to all contributions and not excluding people for unfair or 
invalid reasons. It will also give them the power to declare how they 
want to hear contributions - they do not need to commit to reading and 
responding to every email! If you feel strongly against a proposal, you 
know who to go to in order to make that known.


By contrast, if everyone 

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

[Steven D'Aprano]

On Fri, Jul 20, 2018 at 09:59:39AM +0200, Antoine Pitrou wrote:
> 
> Le 20/07/2018 à 01:47, Victor Stinner a écrit :
> > 
> > What is the image sent to contributors if we create a subgroup inside
> > core developpers called "council"? What if we elect a new BDFL *for
> > life*? Does it mean that even core developers judgment are no longer
> > trusted, only the council decision matters? What about people outside
> > in the insider group of cores... regular contributors? Will anyone
> > still listen to them?
> 
> That's a very good point, I think.  Creating intimidating structures may
> not help attract new contributors.  A BDFL is intimidating.  Depending
> on its name and powers, a council or collegial body can be intimidating
> too (I'd recommend against naming it "Council of Elders", which IMHO
> sends the wrong message).

Perhaps we could call it the Pythonic Inquisition, whose three weapons 
are experience, intelligence, the PEP process, and a fanatical 
dedication to backwards compatibility, and absolutely no braces.

*wink*

Please be explicit: what message do you think it sends which is the 
wrong message?

I think that the messages sent include:

- there is someone in charge;

- this is a meritocracy;

- you too could get into the council, someday;

- but you aren't in it yet;

- trust and responsibility comes in degrees;

- and must be earned, not just granted to random people on the
  Internet because they ask for core developer rights;

- the evolution of the language is driven by reasoned argument,
  not popularity contests.


We've had a BDFL for a quarter of a century, and Python has done pretty 
well, possibly by far the most popular programming language not driven 
by a corporate owner or patron (and more popular than many languages 
which do have corporate owners). Of course it is impossible to prove a 
negative, we cannot dismiss the possibility that Guido-as-BDFL has been 
"sending the wrong message" for two decades, scaring off contributors 
and acting as a drag on Python's success. But I doubt it, and I doubt 
that a new BDFL or Council or Triumvirate would do so either.



-- 
Steve
___
python-committers mailing list
python-committers@python.org
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

[Steven D'Aprano]

On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote:
> Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:

[...]
> > In contrast, I would imagine that people would continue to discuss
> > PEPs in exactly the same way that they currently do, so the result
> > would be that the votes are based more on partially-informed opinion
> > and "gut feeling". Certainly some people will work harder to provide
> > an informed vote, but I doubt that will be true in the majority of
> > cases. Worst case, people will feel a responsibility to vote, but
> > won't have any more time than they do right now so they'll vote with
> > limited information simply because "it's expected of them" to vote.

[...]
> In other communities that use this form of consensus approval for
> design changes I have seen folks who do not have time or interest
> to dig deeply into a proposed change learn to trust others who have
> the time, interest, and expertise. The team comes out stronger as
> a result of that built-up trust.

A few questions...

You say folks "learn to trust others", but what does that mean in 
practice? The only interpretation I can think of is:

People vote for a feature, because Fred says he's in favour 
of it and they trust him, or like him personally, or because
he's more charismatic and persuasive than those against it.

What happens when two trusted experts disagree and the voters don't have 
the expertise to tell which one is correct?

How large are these communities you are referring to?

The sort of participatory democracy Victor and you seem to be talking 
about doesn't scale beyond small communities where everyone knows 
everyone else. That's why such participatory democracy worked in ancient 
Greece, and continues to be used in (eg) Swiss canons, but beyond that 
communities have moved to a representative democratic model.

Certainly the Python community as a whole is *significantly* bigger 
than a village. What about the core developers? Now? In the future?

One factor that I don't think Victor has covered is that of what 
percentage of core devs would have to vote for the result to be 
accepted -- a quorum, or equivalent.

When it comes to *representative democracy* I believe that the 
Australian model of mandatory voting (resulting in 90% turnouts or 
higher) has many advantages over other systems. But for a technical 
community like this, I don't know that mandatory voting is desirable.

(Perhaps if we have an Abstain option as well as Yes or No.)

So how many non-Abstain votes are needed? Victor mentioned "50% + 1" 
votes, but does that assume 100% turnout? What if only a handful of 
people vote on some exceedingly obscure, technical question of no 
interest to the majority?

Personally, I'm not sure I'd even want to vote on every PEP that comes 
up. When I was first nominated to the PSF, I took the voting rights as 
both a privilege and a duty and took them very seriously indeed. But as 
time went on, I got somewhat disillusioned and burned out (for reasons 
we need not go into). And that is only voting once or twice a year.

If I had to vote on a dozen or two dozen PEPs a year, most of which I 
have little or no interest in, the annoyance factor would be 
correspondingly greater. But if I don't vote, could that doom PEPs to 
fail because they don't get a quorum?

Another issue we should consider: organised vote swapping. If votes are 
public, as Victor suggests, that would allow people to do deals: "I'll 
support your PEP for GOTO, if you support my PEP to deprecate tuples..." 
sort of thing. There's a reason why most ballots are secret.



-- 
Steve
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Brett Cannon]

On Fri, Jul 20, 2018, 07:51 Nick Coghlan,  wrote:

> On 18 July 2018 at 16:42, Chris Jerdonek  wrote:
> > I agree a name other than BDFL should be chosen, especially since (as
> > I understand it) Guido is still BDFL but just taking a permanent
> > vacation, and the name implies there should only be one.
> >
> > Also, if we're considering particular people, I think Nick should also
> > be considered.
>
> As much as I appreciate the vote of confidence, I'm actively working
> to reduce my open source commitments and responsibilities at the
> moment, not increase them. Burnout's a thing, y'all, especially when
> you have the attention span of a caffeinated squirrel and get involved
> in far more things than you could ever hope to see through to
> completion in a reasonable period of time :)
>
> And that's my primary concern with any proposals to put a comparable
> level of stress to that which Guido has been handling for years on to
> another volunteer's shoulders: I don't think it's an even remotely
> reasonable thing to request of a community volunteer.
>
> Guido was willing to do it for so long because Python was his
> creation, and he grew into the increasing demands of the BDFL role as
> time went by, but even he eventually reached the point of saying "I
> don't want to do this any more - the personal costs are outweighing
> the personal benefits". There's no way that a new individual in a
> comparable role to Guido's is going to have an easier time of it than
> Guido did, and a lot of good reasons to believe that they will find it
> significantly harder (not least of which is that Guido has been able
> to request 50% funded "BDFL-time" from his employers since he joined
> Google in 2005, and it's unlikely that a newcomer to the role would
> enjoy that benefit any time soon).
>

While I'm purposefully staying out of this thread as my name is currently
so strongly associated with it and I don't want people thinking I'm a
megalomaniac, I will say that I see no reason why I wouldn't get 50% time
at Microsoft if I asked for it (I already get a day/week plus email reading
every day).

I also agreed to Barry's proposal under the expectation that I would still
take a month off every year and one day a week like I do already. That plus
a council of folks to help with the load makes me think I can handle the
workload without having to sacrifice more personal time than I'm already
comfortable doing now. I also think that we as a team and a community are a
bit more aware of the issue of burnout thanks to Guido's retirement.

Plus Andrea said it was okay  (The cat was indifferent.)

-Brett


> In the 2 terms I spent on the PSF board, one of the things I aimed to
> help Ewa work towards was making being on the Board less of a recipe
> for burnout, and I've done what I could to help make working on the
> Python packaging ecosystem less of a burnout factory as well. Before
> my time on the Board, other folks had already started the process of
> having paid PSF staff take on more PyCon US management
> responsibilities to help reduce the burden on folks volunteering for
> PyCon US leadership roles.
>
> In that context, setting up a high profile volunteer leadership role
> that I'd expect to mainly let us burn out multiple people in
> succession really doesn't seem like a good response to a leading
> contributor deciding that it's time for them to step down :)
>
> So while I'm in favour of the minimal PEP 1 tweaks needed to keep the
> volunteer-per-PEP BDFL-Delegate model going for the less controversial
> proposals that don't touch core parts of the language, I *don't* think
> filing Guido's name off and writing Brett's (or anyone else's) name in
> is the right answer for the deeper community governance questions
> we're asking ourselves, and I think we'd be squandering a rare
> opportunity to explore the alternatives if we instead sought to
> preserve the status quo too directly.
>
> Yes, change is scary, and there's always a risk we'll find that we
> don't like the initial iteration of whatever we come up with, but
> that's just motivation to ensure that whatever system we come up with
> has mechanisms for change built into it (just as even the PSF's
> by-laws can be amended by a vote of the members).
>
> Personally, I think the contributor council approach is likely to
> prove to be a good way to go (since it distributes the burden of
> responsibility amongst mutiple volunteers and doesn't leave anyone
> feeling obliged to be "on" all the time), and it would then be up to
> the initial members of that council to come up with a way to
> appropriately rotate any spokesperson responsibilities that came up.
>
> I also think folks are placing too much weight on the notion of Guido
> as the primary spokesperson representing what the core contributors
> are thinking - if anyone were to be seen as occupying that role, I'd
> actually point to whoever takes the lead editor role for the What's
> New document in any given 

Re: [python-committers] An alternative governance model

[Nick Coghlan]

On 18 July 2018 at 16:42, Chris Jerdonek  wrote:
> I agree a name other than BDFL should be chosen, especially since (as
> I understand it) Guido is still BDFL but just taking a permanent
> vacation, and the name implies there should only be one.
>
> Also, if we're considering particular people, I think Nick should also
> be considered.

As much as I appreciate the vote of confidence, I'm actively working
to reduce my open source commitments and responsibilities at the
moment, not increase them. Burnout's a thing, y'all, especially when
you have the attention span of a caffeinated squirrel and get involved
in far more things than you could ever hope to see through to
completion in a reasonable period of time :)

And that's my primary concern with any proposals to put a comparable
level of stress to that which Guido has been handling for years on to
another volunteer's shoulders: I don't think it's an even remotely
reasonable thing to request of a community volunteer.

Guido was willing to do it for so long because Python was his
creation, and he grew into the increasing demands of the BDFL role as
time went by, but even he eventually reached the point of saying "I
don't want to do this any more - the personal costs are outweighing
the personal benefits". There's no way that a new individual in a
comparable role to Guido's is going to have an easier time of it than
Guido did, and a lot of good reasons to believe that they will find it
significantly harder (not least of which is that Guido has been able
to request 50% funded "BDFL-time" from his employers since he joined
Google in 2005, and it's unlikely that a newcomer to the role would
enjoy that benefit any time soon).

In the 2 terms I spent on the PSF board, one of the things I aimed to
help Ewa work towards was making being on the Board less of a recipe
for burnout, and I've done what I could to help make working on the
Python packaging ecosystem less of a burnout factory as well. Before
my time on the Board, other folks had already started the process of
having paid PSF staff take on more PyCon US management
responsibilities to help reduce the burden on folks volunteering for
PyCon US leadership roles.

In that context, setting up a high profile volunteer leadership role
that I'd expect to mainly let us burn out multiple people in
succession really doesn't seem like a good response to a leading
contributor deciding that it's time for them to step down :)

So while I'm in favour of the minimal PEP 1 tweaks needed to keep the
volunteer-per-PEP BDFL-Delegate model going for the less controversial
proposals that don't touch core parts of the language, I *don't* think
filing Guido's name off and writing Brett's (or anyone else's) name in
is the right answer for the deeper community governance questions
we're asking ourselves, and I think we'd be squandering a rare
opportunity to explore the alternatives if we instead sought to
preserve the status quo too directly.

Yes, change is scary, and there's always a risk we'll find that we
don't like the initial iteration of whatever we come up with, but
that's just motivation to ensure that whatever system we come up with
has mechanisms for change built into it (just as even the PSF's
by-laws can be amended by a vote of the members).

Personally, I think the contributor council approach is likely to
prove to be a good way to go (since it distributes the burden of
responsibility amongst mutiple volunteers and doesn't leave anyone
feeling obliged to be "on" all the time), and it would then be up to
the initial members of that council to come up with a way to
appropriately rotate any spokesperson responsibilities that came up.

I also think folks are placing too much weight on the notion of Guido
as the primary spokesperson representing what the core contributors
are thinking - if anyone were to be seen as occupying that role, I'd
actually point to whoever takes the lead editor role for the What's
New document in any given release, since most Pythonistas don't even
think about the core development process until they're looking at a
new release and asking themselves "Why on Earth did they add *that*?".
(It could actually be an interesting trial addition to the PEP process
to require that PEP authors include a draft What's New entry, as it
forces you to step back from the intricacies of language and
interpreter runtime design, and focus on the end user impact of a
proposed change)

Cheers,
Nick.

P.S. Since "What *do* you think is the upper limit on what's a
reasonable request to make of a community volunteer?" is a natural
follow-up question, I'm currently fairly comfortable with the scope of
things like PSF Board membership, PSF Working Group membership,
CPython release management, CPython module maintainership, and the
packaging BDFL-Delegate responsibilities I recently handed over to
Paul Moore (and I think that last one is borderline, and could stand
to follow in CPython's footsteps if we can settle on a 

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

[Doug Hellmann]

Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
> On 20 July 2018 at 12:57, Victor Stinner  wrote:
> > Hum. Let me try to explain my point differently. Currently, some
> > people don't read PEPs just because at the end, only the single BDFL
> > vote counts. What's the point of spending hours (if not days) on
> > reading a long PEP and the long discussion on mailing lists, if your
> > count doesn't count?
> 
> My suspicion is that *most* people who don't read PEPs don't do so
> because they don't have the time, not because they don't believe that
> their opinion will matter. In actual fact, the evidence from many
> threads is that people are more than happy to express their opinion
> even though they haven't read the PEP. So I doubt that giving people
> more power to affect the result will make little practical difference.
> 
> > Now imagine that all votes count. I expect that
> > people will spend more time on reading carefully each PEP and follow
> > more closely discussions since they will be de facto more involved in
> > the decision process.
> 
> In contrast, I would imagine that people would continue to discuss
> PEPs in exactly the same way that they currently do, so the result
> would be that the votes are based more on partially-informed opinion
> and "gut feeling". Certainly some people will work harder to provide
> an informed vote, but I doubt that will be true in the majority of
> cases. Worst case, people will feel a responsibility to vote, but
> won't have any more time than they do right now so they'll vote with
> limited information simply because "it's expected of them" to vote.
> 
> I suspect that the reality will be somewhere between these two extremes.
> 
> Paul

In other communities that use this form of consensus approval for
design changes I have seen folks who do not have time or interest
to dig deeply into a proposed change learn to trust others who have
the time, interest, and expertise. The team comes out stronger as
a result of that built-up trust.

Doug
___
python-committers mailing list
python-committers@python.org
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

[Doug Hellmann]

Excerpts from Antoine Pitrou's message of 2018-07-20 09:49:01 +0200:
> 
> Le 20/07/2018 à 02:51, Ethan Furman a écrit :
> > My first issue with this model is, as discussed above, a lack of a 
> > consistent vision.  A BDFL is not just there to say, 
> > "this PEP is accepted," but also to say, "change this one piece here, 
> > remove that piece there, add this" -- definitely 
> > not something easily done by 100+ voters.
> > 
> > My second issue is qualifications:  there are plenty of PEPs that I either 
> > have no interest in or whose field I have no 
> > experience with, and my voting on those PEPs would be nonsensical; when 
> > that happens to a BDFL s/he appoints a BDFOP.
> > 
> > My third issue is, quite simply, time.  Working on patches takes time; 
> > reviewing PRs takes time; and being a good voting 
> > citizen takes lots and lots of time -- and we're all volunteers.  Time is 
> > at a premium.
> 
> This is true.  But it's a problem for the BDFL even more.  Our ex-BDFL
> resigned because of pressure and exhaustion.  Why would another BDFL
> fare better?
> 
> Victor pointed out something I didn't know: that several prominent core
> devs (him, Brett Cannon) recently suffered from
> breakdown/burnout/depression.
> 
> I find the PEP-delegate to be a powerful concept.  Why wouldn't *every*
> PEP have a PEP-delegate?  This way we don't need a BDFL anymore.  We can
> discuss how to nominate PEP-delegates (Nick had an interesting proposal).

+1

Doug
___
python-committers mailing list
python-committers@python.org
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

[Paul Moore]

On 20 July 2018 at 12:57, Victor Stinner  wrote:
> Hum. Let me try to explain my point differently. Currently, some
> people don't read PEPs just because at the end, only the single BDFL
> vote counts. What's the point of spending hours (if not days) on
> reading a long PEP and the long discussion on mailing lists, if your
> count doesn't count?

My suspicion is that *most* people who don't read PEPs don't do so
because they don't have the time, not because they don't believe that
their opinion will matter. In actual fact, the evidence from many
threads is that people are more than happy to express their opinion
even though they haven't read the PEP. So I doubt that giving people
more power to affect the result will make little practical difference.

> Now imagine that all votes count. I expect that
> people will spend more time on reading carefully each PEP and follow
> more closely discussions since they will be de facto more involved in
> the decision process.

In contrast, I would imagine that people would continue to discuss
PEPs in exactly the same way that they currently do, so the result
would be that the votes are based more on partially-informed opinion
and "gut feeling". Certainly some people will work harder to provide
an informed vote, but I doubt that will be true in the majority of
cases. Worst case, people will feel a responsibility to vote, but
won't have any more time than they do right now so they'll vote with
limited information simply because "it's expected of them" to vote.

I suspect that the reality will be somewhere between these two extremes.

Paul
___
python-committers mailing list
python-committers@python.org
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

[Victor Stinner]

Hi Ethan,

Thanks for your feedback!

2018-07-20 2:51 GMT+02:00 Ethan Furman :
>> I see that many people are eager to replace the old governance based
>> on a single BDFL with a new governance with a new BD(FL) and/or a
>> council. My problem is that I don't see any clear definition of the
>> roles of these BD(FL) and/or council: what they are expected to do,
>> what they cannot do, etc.
>
> I imagine that will be made clear in that proposed PEP.

In that case,  I would prefer that people abstain from voting on this
mailing list (I'm talking about "+1" emails), before a formal and well
defined PEP is written ;-)


> This is, unfortunately, true -- with 100+ core-devs (give or take a few)
> that's basically 100+ different visions of Python, and on any particular
> issue the majority will be made up of different core-devs, therefore
> different visions will be approving/rejecting the PEPs, and internal
> consistency becomes impossible.
>
>> Can someone please explain me the rationale behind these fears? Do you
>> have examples? Maybe examples outside Python?
>
> Examples inside Python are good enough:
>
> - PEP 435 (Enum)  [accepted]
>   lots of minor decisions from BDFL about this or that choice,

Hum, first I would like to have better statistics on the number of
active core developers. On Stéphane Wirtel statistics on pull
requests, the number of active core developers was closer to 34...

Would you mind to elaborate? How would enum be inconsistent without
the BDFL work?

> and still there were about 1,000 emails over several threads

Honestly, I don't recall the discussion on the enum module. What do
you mean by this large number of emails?

People are free to send emails, but at the end, a vote would occur on
a proper PEP, not on emails.

Let me try to guess what you mean. Do you mean that a 50%+1 majority
would be impossible to reach because each core developer had a
different taste on how enum should look like?

What I saw in PHP RFC is that sometimes there are multiple votes on a
single RFC, to choose between alternatives (translation for Python:
replace RFC with PEP :-)). A recent example:

  https://wiki.php.net/rfc/array_key_first_last

The RFC proposed to add array_key_first/last()" and
array_value_first/last(). The array_value variant was controversial
and so has been voted separately. There was a corner value for values:
a value can really be null, whereas the RFC proposes to also return
null to signal an error. This case doesn't occur with keys, since
using null as a key is automatically replaced with an empty string:
it's possible to distinguish null as an error. They decided to approve
array_key_first()/last() but reject array_value_first()/last(), which
IMHO is a wise choice :-)

For enum, if you are talking about the two proposed alternatives "Not
having to specify values for enums" and "Using special names or forms
to auto-assign enum values", I guess that separated votes could be
used: one vote for the main idea "having an Enum type", and a vote on
the variants. The PEP author (and maybe an expert would him them to
drive the PEP) would decide which votes are worth it.


> - PEP 461 (%-formatting for bytes and byte arrays) [accepted]
>   IIRC there was lots of push-back on adding this to bytes and byte arrays

Sorry, I don't understand what is wrong with this PEP. If I recall
correctly, all core developers were in favor of adding back this
feature to Python 3, no?

I recall that I started to write a PEP 460, but Antoine wanted to
"modify" it. In fact, he basically rewrote it from scratch, so I asked
him to remove my name from it :-)

Then you wrote a competitor PEP. At the end, your PEP won.

I don't see how bytes % args is a good example of the need of a BDFL
to keep Python consistent. Would you mind to elaborate? Do you have
that having two PEPs in a competition goes against the principle of
voting?


> - PEP 463 (exception-catching expressions) [rejected]
>   lots of discussion here, not sure if it would have been accepted by
> majority vote

Hum, I don't recall well this discussion. If I recall correctly, the
consensus quickly agreed to reject the PEP. Most people already
disliked the PEP on python-ideas, no... I'm not sure of that. At
least, I disliked the PEP since its start :-)

What do you mean by "not sure if it would have been accepted by majority vote"??


> - PEP 572 (assignment expressions) [accepted]
>   'nough said

Joker! I will not comment that one. I don't have enough perspective on it yet.


> My first issue with this model is, as discussed above, a lack of a
> consistent vision.  A BDFL is not just there to say, "this PEP is accepted,"
> but also to say, "change this one piece here, remove that piece there, add
> this" -- definitely not something easily done by 100+ voters.

I agree that an author can be confused when two different core
developers ask to make two opposite changes. This is where an expert
can help the author to drive the discussion and help the author 

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

[Antoine Pitrou]

Le 20/07/2018 à 01:47, Victor Stinner a écrit :
> 
> What is the image sent to contributors if we create a subgroup inside
> core developpers called "council"? What if we elect a new BDFL *for
> life*? Does it mean that even core developers judgment are no longer
> trusted, only the council decision matters? What about people outside
> in the insider group of cores... regular contributors? Will anyone
> still listen to them?

That's a very good point, I think.  Creating intimidating structures may
not help attract new contributors.  A BDFL is intimidating.  Depending
on its name and powers, a council or collegial body can be intimidating
too (I'd recommend against naming it "Council of Elders", which IMHO
sends the wrong message).

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
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

[Antoine Pitrou]

Le 20/07/2018 à 02:51, Ethan Furman a écrit :
> My first issue with this model is, as discussed above, a lack of a consistent 
> vision.  A BDFL is not just there to say, 
> "this PEP is accepted," but also to say, "change this one piece here, remove 
> that piece there, add this" -- definitely 
> not something easily done by 100+ voters.
> 
> My second issue is qualifications:  there are plenty of PEPs that I either 
> have no interest in or whose field I have no 
> experience with, and my voting on those PEPs would be nonsensical; when that 
> happens to a BDFL s/he appoints a BDFOP.
> 
> My third issue is, quite simply, time.  Working on patches takes time; 
> reviewing PRs takes time; and being a good voting 
> citizen takes lots and lots of time -- and we're all volunteers.  Time is at 
> a premium.

This is true.  But it's a problem for the BDFL even more.  Our ex-BDFL
resigned because of pressure and exhaustion.  Why would another BDFL
fare better?

Victor pointed out something I didn't know: that several prominent core
devs (him, Brett Cannon) recently suffered from
breakdown/burnout/depression.

I find the PEP-delegate to be a powerful concept.  Why wouldn't *every*
PEP have a PEP-delegate?  This way we don't need a BDFL anymore.  We can
discuss how to nominate PEP-delegates (Nick had an interesting proposal).

Regards

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