date:20180718


On 07/18/2018 09:40 PM, Carol Willing wrote:

I am in favor of a time limit. Yet, October 1 seems a bit too long for the 
initial governance decision (i.e. how to
decide how to decide). My perspective, based on transitions in non-profits and 
the corporate world, is that the longer
an organization let's it draw out then fear, uncertainty, and doubt creep in.

We have PEP 10 in place for a strawperson vote. It seems as good as anything to 
use to determine how to make a decision.
Perhaps set a 30 day deadline to submit decision process recommendations. Then 
take a strawperson poll on each and at
the core sprint create a time window for specific proposals on structure be 
submitted before October 1.

My concern if we leave how to decide until at least Oct 1 that the likelihood 
of completing this year is fairly low.


My understanding is that, between now and Oct 1, we'll all get our proposals together for both how to decide, and what 
to decide.  Then we have the first vote to decide how to decide, then maybe a week or two later we use that mechanism to 
decide on a governance model.


--
~Ethan~

___
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

2018-07-18 Thread Carol Willing

I am in favor of a time limit. Yet, October 1 seems a bit too long for the
initial governance decision (i.e. how to decide how to decide). My
perspective, based on transitions in non-profits and the corporate world,
is that the longer an organization let's it draw out then fear,
uncertainty, and doubt creep in.

We have PEP 10 in place for a strawperson vote. It seems as good as
anything to use to determine how to make a decision. Perhaps set a 30 day
deadline to submit decision process recommendations. Then take a
strawperson poll on each and at the core sprint create a time window for
specific proposals on structure be submitted before October 1.

My concern if we leave how to decide until at least Oct 1 that the
likelihood of completing this year is fairly low.

On Wed, Jul 18, 2018, 9:15 PM Mariatta Wijaya 
wrote:

> +1
>
>
> On Wed, Jul 18, 2018, 8:54 PM Ethan Furman  wrote:
>
>> On 07/18/2018 08:45 PM, Łukasz Langa wrote:>
>>  >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith  wrote:
>>  >>
>>  >> I propose: no governance decisions finalized before October
>>  >> 1, 2018.
>>  >
>>  > +1 but it's okay and expected that discussions here will continue in
>> the interim.
>>
>> Absolutely!  Without continuing discussion we'll have nothing to vote on
>> come October!  ;-)
>>
>> --
>> ~Ethan~
>>
>> ___
>> 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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

+1


On Wed, Jul 18, 2018, 8:54 PM Ethan Furman  wrote:

> On 07/18/2018 08:45 PM, Łukasz Langa wrote:>
>  >> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith  wrote:
>  >>
>  >> I propose: no governance decisions finalized before October
>  >> 1, 2018.
>  >
>  > +1 but it's okay and expected that discussions here will continue in
> the interim.
>
> Absolutely!  Without continuing discussion we'll have nothing to vote on
> come October!  ;-)
>
> --
> ~Ethan~
>
> ___
> 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


On 07/18/2018 08:45 PM, Łukasz Langa wrote:>
>> On Jul 18, 2018, at 9:36 PM, Nathaniel Smith  wrote:
>>
>> I propose: no governance decisions finalized before October
>> 1, 2018.
>
> +1 but it's okay and expected that discussions here will continue in the 
interim.

Absolutely!  Without continuing discussion we'll have nothing to vote on come 
October!  ;-)

--
~Ethan~

___
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

2018-07-18 Thread Alex Martelli via python-committers

FWIW, +1.

Alex

On Wed, Jul 18, 2018 at 7:36 PM Nathaniel Smith  wrote:

> [tl;dr: We need some ground rules, because uncertainty makes it hard
> to think straight. But if we get sucked into a complicated meta-debate
> about the ground rules then that defeats the purpose. My proposal for
> a Minimum Viable Ground Rule: let's all agree not to finalize any
> governance decisions before October 1.]
>
> We're in a constitutional crisis, and that's scary. There's no map and
> none of us know what to expect. It feels like anything could happen.
> You look at the mailing list and see people making big proposals -- is
> one of them going to suddenly be adopted? If I look away for a few
> days, will I come back and find out that something's been decided?
> What are we even talking about? Do I need to jump into that thread
> RIGHT NOW? It's scary.
>
> People don't do their best work when scared. When we're scared it's
> harder to listen and build up common ground with others -- but that's
> exactly what we'll need to do to get through this. And also, like...
> being scared sucks. I would prefer to be less scared.
>
> So: can we do anything to make this less scary?
>
> One thing that would help is if we had some ground-rules for how the
> decision itself will be made. Knowing what to expect makes things less
> scary. There's another thread going on right now trying to do that
> (subject "Proposal on how to vote"). But... if you look at that
> thread, it turns out deciding on how to vote is itself an important
> decision with lots of subtle issues, where we probably want to give
> people time to think, brainstorm, critique. Heck, in the end we might
> decide a vote isn't even the best approach. So I'm not saying we
> shouldn't be having that discussion, we definitely should, but... it's
> also giving me a new source of anxiety: that we'll all be so eager to
> get *some* certainty here that we'll end up trying to force a decision
> prematurely. Kind of a catch-22: the decision about how to make
> complex decisions is itself a complex decision, which is what we don't
> know how to do yet.
>
> Is there some way to avoid this loop? Can we come up with some ground
> rules simple enough that we can agree on them without a big debate?
> Well, there's one thing I am pretty sure of: this is a big decision,
> there's a lot to think about and talk about, and that we won't regret
> taking some time some time to do that. And besides, trying to force it
> to happen faster will make people more scared and dig in their heels.
>
> So here's my proposal for an initial, Minimum Viable Ground Rule: we
> should set a date and promise that no actual decisions will be
> finalized before that. Until then we are just talking and
> brainstorming and gradually converging on points of consensus. (And to
> be clear, the point of this is to give us breathing room, not set a
> deadline -- we shouldn't dawdle, but if we get there and it turns out
> we need more time, then that's OK.)
>
> What would be a good date? The core sprint is coming up Sept. 10-14,
> and this seems to be a likely topic of conversation there. And then
> after the sprint, those who aren't present will need time to catch up
> with any discussions that happened at the sprint. So to make things
> concrete, I propose: no governance decisions finalized before October
> 1, 2018.
>
> Probably this is what will end up happening anyway, but if we make it
> explicit in advance and tell everyone, then at least we'll all know
> that it's OK to stop refreshing our email constantly and redirect that
> energy in more useful directions.
>
> What do you all think?
>
> -n
>
> --
> 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/
>
___
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

2018-07-18 Thread Zachary Ware

+1

--
Zach
(On a phone)

On Wed, Jul 18, 2018, 21:54 Ethan Furman  wrote:

> On 07/18/2018 07:36 PM, Nathaniel Smith wrote:
>
> > [tl;dr: We need some ground rules, because uncertainty makes it hard
> > to think straight. But if we get sucked into a complicated meta-debate
> > about the ground rules then that defeats the purpose. My proposal for
> > a Minimum Viable Ground Rule: let's all agree not to finalize any
> > governance decisions before October 1.]
>
> +1
>
> --
> ~Ethan~
>
> ___
> 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

2018-07-18 Thread Robert Collins

So, I'm fine with this, but FWIW I'm also fine with anything we come
up with: I trust us, our intentions individually and in aggregate, and
I can't imagine a poor outcome.

-Rob

On 19 July 2018 at 14:36, Nathaniel Smith  wrote:
> [tl;dr: We need some ground rules, because uncertainty makes it hard
> to think straight. But if we get sucked into a complicated meta-debate
> about the ground rules then that defeats the purpose. My proposal for
> a Minimum Viable Ground Rule: let's all agree not to finalize any
> governance decisions before October 1.]
___
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] Language moratorium

[Barry]

> I agree that we’ll effectively have language moratorium until we have a
> new governance structure.


Unsure!  Governance is needed to resolve conflict.  When there's broad
agreement, "leaders" aren't really needed.  For example, there's been a bit
of talk on python-ideas about adding a new `intmath` module capturing some
frequently reinvented functions for which decent implementations are known
but non-obvious (e.g., for generating the primes).  Nobody could sanely
fight to death against something like that.  Even whining about it would
appear petty ;-)


But let me ask, what do you propose to do about PEP 572?  That’s already
> been accepted, but not yet implemented.  Would it be exempt from the
> moratorium or scoot in under the wire?


Unless "accepted" has a meaning with which I'm unfamiliar, "exempt" is the
obvious answer.  Changing to such an unfamiliar meaning would require the
very governance structure whose present existence is denied by the case
hypothesis ;-)
___
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] Language moratorium

On Wed, Jul 18, 2018, 09:32 Mariatta Wijaya, 
wrote:

> There is a de facto moratorium for the time being until a new governance
>> model is chosen. Let's not formalize anything beyond that.
>
>
> I agree.
>

Same here.

-Brett


> Mariatta
>
>
> On Wed, Jul 18, 2018 at 9:24 AM Łukasz Langa  wrote:
>
>> There is a de facto moratorium for the time being until a new governance
>> model is chosen. Let's not formalize anything beyond that.
>>
>> --
>> Best regards,
>> Łukasz Langa
>>
>> > On Jul 18, 2018, at 11:11 AM, Stefan Krah  wrote:
>> >
>> >
>> > Hi,
>> >
>> > if I remember correctly, we had a moratorium for language changes around
>> > versions 3.2-3.3.  I think during that time relatively few BDFL-level
>> > decisions were required.
>> >
>> > Perhaps we could have one again, say for 12 months so we can figure
>> things
>> > out. Other Python implementations may welcome the moratorium so they can
>> > catch up.
>> >
>> >
>> > During that time we could just informally listen very closely to Guido
>> if
>> > anything requires a decision and he happens to be around. But there may
>> be
>> > no decisions at all.
>> >
>> > And yes, I guess we can successfully attempt to be nice, especially to
>> him
>> > (thanks for this wonderful language!).
>> >
>> >
>> >
>> > Stefan Krah
>> >
>> >
>> >
>> > ___
>> > 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/
>
___
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 on how to vote (was: An alternative governance model)

On Wed, Jul 18, 2018, 18:09 Alex Martelli,  wrote:

> Hi Brett,
>
> On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon  wrote:
>
>> [can I just say how much I've missed having both you and Tim around,
>> Alex? ]
>
>
> Heh, good to hear!-)
>
> Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91)
>>
>
> Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce
> on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84
> (at least not in the US with our `Imperial` system; does it work any
> differently in Canada with Metric?-)...
>

Sorry, the 82 in my head was from when Lukasz proposed 90%. That's what I
get for replying to emails on the bus after a very stressful day at work.

-Brett


> Alex
>
>
___
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 on how to vote (was: An alternative governance model)

2018-07-18 Thread Alex Martelli via python-committers

Hi Brett,

On Wed, Jul 18, 2018 at 5:51 PM Brett Cannon  wrote:

> [can I just say how much I've missed having both you and Tim around, Alex?
> ]

Heh, good to hear!-)

Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91)
>

Uh, sorry, but -- even were you to become BDFL, you don't get to Pronounce
on arithmetic: 2/3 of 91 is 60 (plus a fraction), nowhere near "roughly" 84
(at least not in the US with our `Imperial` system; does it work any
differently in Canada with Metric?-)...

Alex
___
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 on how to vote (was: An alternative governance model)

[can I just say how much I've missed having both you and Tim around, Alex?
]

On Wed, Jul 18, 2018, 17:28 Alex Martelli via python-committers, <
python-committers@python.org> wrote:

> There are plenty of precedents for mandatory voting, but the enforcement
> mechanisms (if any) appear not to be applicable to our case. Note the "if
> any": several countries declare voting a citizen's duty (in their
> Constitution or otherwise) but don't actually enforce this duty in any way.
> For example, that's the case in the United States: if you apply for
> naturalization you will be quizzed on many things, including "what are the
> duties of a citizen", and one of the latter is "participate in the
> democratic process" which includes voting -- but if you don't, no
> enforcement action is taken against you. In contrast, if you get a jury
> summons (jury duty being another of those citizen duties) and repeatedly
> fail to show up, you may end up in jail -- now THAT is enforcement of the
> duty (and no Python community organism has, nor should have, such power of
> enforcement.
>

And that lack of enforcement power is what makes me worry about mandatory
participation to make a vote considered legitimate.


> In Italy, where voting is declared to be a duty in the Constitution, at
> the start of the Republic you'd get (until next election) a stamp of "non
> ha votato" ("did not vote") in your publicly accessible judiciary record
> (it would come up in any background search -- and, in a country where
> firing employees was notoriously hard, some opined that such a flaw might
> be grounds for dismissal if the employer so wished, although I've never
> heard of it happening). That was abolished 25 years ago, in part because it
> was randomly/capriciously enforced (many judicial districts were too
> otherwise-busy to go through voting records and apply/remove the stamp!-).
> So, now, Italy is in the vast camp of countries declaring voting a duty
> (Italy's constitution was not changed on this subject) but not enforcing
> the "duty" at all (indeed, failing to show up to vote is now often
> advocated by adversaries of referendums, which have a 50% minimum
> participation threshold to be valid and may well be easier to defeat by
> getting people to just not show up -- since many others won't anyway for
> other reasons -- than by getting them to vote against).
>
> Since I originally brought up a parallel between "which BDFL" voting, and
> a Papal conclave, I would be remiss to fail to mention that since 1274 the
> Cardinals are locked up "with a key" ("cum clave") until a Pope does get
> elected -- usually a good-enough incentive to vote (though once the
> citizens of the town where the conclave was held had to decide after a few
> failed votes to only send in bread and water -- and later, said citizens
> removed the roof of the palace where the Cardinals were locked up, hoping
> that rain may speed up the proceedings). Colorful, but, again, not really
> applicable in our case.
>
> What's left? The "public naming and shaming" Italy used until a quarter
> century ago might work -- just make a little site listing the committers
> who, while having a right to vote, haven't voted (yet). A VERY long voting
> period might also help -- amendments to the US Constitution originally had
> unlimited times for ratification (the 27th amendment, originally the 2nd
> one proposed in 1789, was ratified 202 years after proposal), though these
> days 7 years is a more customary time limit for ratification. Not sure if
> these are good ideas.
>
> Another possibility is to avoid having separate thresholds for
> participation and approval (US constitution amendments work that way --
> with the specifics being a threshold only for approval out of all States,
> not how many States have voted for or against). I.e, if we decide 2/3 is
> OK, a proposal might be approved if 2/3 of *eligible* voters have voted
> for it -- no matter how many of the remaining 1/3 have voted against, or
> not (yet?) voted at all (since, if 100% of eligible voters could be
> bothered to vote, once the proposal gets 2/3 of the votes in favor, it does
> not matter whether the remaining 1/3 vote against, abstain, or whatever).
> This is not mutually exclusive with other ideas (of which, out of what I've
> mentioned, the viable ones -- though not necessarily wise! -- would be
> "public naming" of non-voters, and VERY long voting periods).
>

That is a good point of clarification. If we did super-majority, is it of
all counted *votes* or all possible *voters*? We might be surprised by the
participation levels, or we might be disappointed. So we might have to go
on what we think is reasonable, try it, and if there's a threshold
requirement then be prepared to have to vote again (and again ...) until
the threshold is met (or we lower the threshold ).

Another bit of concrete numbers: to get 84 people (roughly 2/3 of 91) to
have made a commit you have look back 7 years of commit

Re: [python-committers] An alternative governance model

2018-07-18 Thread Alex Martelli via python-committers

On Wed, Jul 18, 2018 at 4:09 PM Fred Drake  wrote:

> > On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya 
> wrote:
> > Let's be clear that we're not yet at the stage where we can vote for
> anything, let alone how to vote.
>
> On Wed, Jul 18, 2018 at 6:03 PM Łukasz Langa  wrote:
> > I don't understand what you mean. Before we get to vote on a variant of
> PEP 2, we need to decide how we are supposed to perform that vote. This
> needs to be decided before we discuss councils, dictators, and so on
> because it's all moot if there is no accepted way to agree which governance
> model we want.
>
> Humans do so love to argue!
>

No we don't! (cfr http://www.montypython.net/scripts/argument.php)...


Alex
___
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 on how to vote (was: An alternative governance model)

2018-07-18 Thread Alex Martelli via python-committers

There are plenty of precedents for mandatory voting, but the enforcement
mechanisms (if any) appear not to be applicable to our case. Note the "if
any": several countries declare voting a citizen's duty (in their
Constitution or otherwise) but don't actually enforce this duty in any way.
For example, that's the case in the United States: if you apply for
naturalization you will be quizzed on many things, including "what are the
duties of a citizen", and one of the latter is "participate in the
democratic process" which includes voting -- but if you don't, no
enforcement action is taken against you. In contrast, if you get a jury
summons (jury duty being another of those citizen duties) and repeatedly
fail to show up, you may end up in jail -- now THAT is enforcement of the
duty (and no Python community organism has, nor should have, such power of
enforcement.

In Italy, where voting is declared to be a duty in the Constitution, at the
start of the Republic you'd get (until next election) a stamp of "non ha
votato" ("did not vote") in your publicly accessible judiciary record (it
would come up in any background search -- and, in a country where firing
employees was notoriously hard, some opined that such a flaw might be
grounds for dismissal if the employer so wished, although I've never heard
of it happening). That was abolished 25 years ago, in part because it was
randomly/capriciously enforced (many judicial districts were too
otherwise-busy to go through voting records and apply/remove the stamp!-).
So, now, Italy is in the vast camp of countries declaring voting a duty
(Italy's constitution was not changed on this subject) but not enforcing
the "duty" at all (indeed, failing to show up to vote is now often
advocated by adversaries of referendums, which have a 50% minimum
participation threshold to be valid and may well be easier to defeat by
getting people to just not show up -- since many others won't anyway for
other reasons -- than by getting them to vote against).

Since I originally brought up a parallel between "which BDFL" voting, and a
Papal conclave, I would be remiss to fail to mention that since 1274 the
Cardinals are locked up "with a key" ("cum clave") until a Pope does get
elected -- usually a good-enough incentive to vote (though once the
citizens of the town where the conclave was held had to decide after a few
failed votes to only send in bread and water -- and later, said citizens
removed the roof of the palace where the Cardinals were locked up, hoping
that rain may speed up the proceedings). Colorful, but, again, not really
applicable in our case.

What's left? The "public naming and shaming" Italy used until a quarter
century ago might work -- just make a little site listing the committers
who, while having a right to vote, haven't voted (yet). A VERY long voting
period might also help -- amendments to the US Constitution originally had
unlimited times for ratification (the 27th amendment, originally the 2nd
one proposed in 1789, was ratified 202 years after proposal), though these
days 7 years is a more customary time limit for ratification. Not sure if
these are good ideas.

Another possibility is to avoid having separate thresholds for
participation and approval (US constitution amendments work that way --
with the specifics being a threshold only for approval out of all States,
not how many States have voted for or against). I.e, if we decide 2/3 is
OK, a proposal might be approved if 2/3 of *eligible* voters have voted for
it -- no matter how many of the remaining 1/3 have voted against, or not
(yet?) voted at all (since, if 100% of eligible voters could be bothered to
vote, once the proposal gets 2/3 of the votes in favor, it does not matter
whether the remaining 1/3 vote against, abstain, or whatever). This is not
mutually exclusive with other ideas (of which, out of what I've mentioned,
the viable ones -- though not necessarily wise! -- would be "public naming"
of non-voters, and VERY long voting periods).

Lastly, I suspect two votes should be separated: (1) what model we adopt
(BDFL, ruling triumvirate, whatever); (2) the model having been chosen, WHO
is going to serve (as BDFL, as triumvirate member, and so on)...

Alex

On Wed, Jul 18, 2018 at 3:46 PM Donald Stufft  wrote:

>
>
> > On Jul 18, 2018, at 6:18 PM, Łukasz Langa  wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
> >>
> >> While I am totally fine with a super-majority of votes for something to
> be accepted, I don't think the minimum participation requirement will work.
> If people simply choose not to vote then they choose not to (we have no way
> to really compel people to vote).
> >
> > It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it
> happening often. There are countries where voting is mandatory.
>
> Given that we don’t have a lot of levers in our tool chest to compel
> voting, what would you

Re: [python-committers] An alternative governance model

2018-07-18 Thread Fred Drake

On Wed, Jul 18, 2018 at 7:16 PM Mariatta Wijaya 
wrote:

> Next available is PEP lucky number 13 
>

As an integer, it has no known problems.  What could possibly go wrong?
;-)  To bad safe, make sure it lands on a Friday.

  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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 on how to vote (was: An alternative governance model)

2018-07-18 Thread Doug Hellmann

Excerpts from Łukasz Langa's message of 2018-07-18 17:31:40 -0500:
> The PSF uses a good voting system where votes are secret. I see no reason not 
> to reuse this infra.
> 
> -- 
> Best regards,
> Łukasz Langa

This feels like a case where a consensus-based voting system may
be better than one that depends on amassing raw votes.

https://civs.cs.cornell.edu is a hosted version of Condorcet that
is reliable, easy to use, and allows for public review of the ballots
(without associating them with the person casting them).

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] Proposal on how to vote (was: An alternative governance model)

On Wed, 18 Jul 2018 at 15:46 Donald Stufft  wrote:

>
>
> > On Jul 18, 2018, at 6:18 PM, Łukasz Langa  wrote:
> >
> >
> >> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
> >>
> >> While I am totally fine with a super-majority of votes for something to
> be accepted, I don't think the minimum participation requirement will work.
> If people simply choose not to vote then they choose not to (we have no way
> to really compel people to vote).
> >
> > It could be easily added to the list of things expected from a core
> contributor. It's not like this is a laborious chore, neither is it
> happening often. There are countries where voting is mandatory.
>
> Given that we don’t have a lot of levers in our tool chest to compel
> voting, what would you propose we do if we get only a 35% participation
> rate? We can’t drag people to the polls, the most we can really do is
> either keep running elections and hope you hit whatever threshold you
> decide on, or you start removing people who can vote until you’ve removed
> enough people that the people who are participating now make up whatever
> your target participation rate is.
>
> The first choice there strikes me as unrealistic. Hope is not a strategy,
> and I fail to see why repeatedly offering the same vote multiple times is
> likely to increase the participation rate. In fact, I think it’s likely to
> decease it as people get tired of having to do it over again and just start
> giving up and viewing it as noise.
>
> The second choice seems… dishonest to me? You’re not really increasing the
> participation of the vote, you’re just juicing the numbers to make the
> participation rate higher. It’s selectively defining who is eligible to
> vote to make the numbers look better.
>
> Is there another option I’m missing to compel people to vote?
>
> >
> > Taking a step back, there are two reasons I stress the importance of
> (almost) everybody voicing their support:
> > - this makes the decision authoritative ("the committers have spoken”);
>
> I think this is largely a non-issue. In the US we do not have mandatory
> elections, and I don’t see very many people challenging the authority of
> said elections due to the large percentage of non-voters. The most I
> generally see if people scolding those who don’t vote.
>
> > - this ensures that we haven't omitted somebody due to poor timing ("I
> was on a sabbatical and couldn't vote”).
>
> Unless you require 100% voting participation, it doesn’t ensure this, it
> just makes it less likely. If you target 90%, then a full 10% of the people
> could have been excluded due to poor timing.
>
> I don’t think it’s possible to fully eliminate this risk, but I think the
> best possible way of handling it is to advertise the vote well in advance,
> and allow the vote itself to take place over a reasonable amount of time.
> The more advance notice, and the larger the window of time is to actually
> vote in, the less likely timing becomes an issue. Just to pluck some random
> times out of the air, if you advertise the voting for 3 months and allow
> voting to happen any time in a months time, that gives people a full 4
> months they will have to be completely unavailable to have no idea the
> voting is happening, and be unable to access a computer for a handful of
> minutes to actually do the vote at all in a month.
>

I think this is a reasonable way to deal with the situation.

We will also need to see how many proposals we have and how similar they
are, else we might have to talk about ranked ballot.
___
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 on how to vote (was: An alternative governance model)

2018-07-18 Thread Victor Stinner

2018-07-19 0:36 GMT+02:00 Antoine Pitrou :
> Let's say I'm being asked if X should be a « next BDFL » (or Council
> member, etc.) and I vote no publicly.  What is my position if X is
> elected?  How will my vote be interpreted?  Will I get discriminated
> against (even unconsciously) just because I didn't choose that person?

I see. I understood that we were more discussing the governance model
than voting for a specific BDFL: I'm not convinced yet that we need a
BDFL :-)

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

Next available is PEP lucky number 13 

Mariatta


On Wed, Jul 18, 2018 at 4:14 PM Barry Warsaw  wrote:

> On Jul 18, 2018, at 16:06, Fred Drake  wrote:
>
> > PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> > superseded, recycling the PEP number seems out of character with the
> > RFC process from which we derived the PEP process.  Let's be cautious
> > about recycling like that; integers are cheap.
>
> Dang, so it is.  :(
>
> I don’t want to recycle numbers, so we’ll likely end up taking the next
> available low ones.
>
> Cheers,
> -Barry
>
> ___
> 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

On Jul 18, 2018, at 16:06, Fred Drake  wrote:

> PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> superseded, recycling the PEP number seems out of character with the
> RFC process from which we derived the PEP process.  Let's be cautious
> about recycling like that; integers are cheap.

Dang, so it is.  :(

I don’t want to recycle numbers, so we’ll likely end up taking the next 
available low ones.

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] An alternative governance model

2018-07-18 Thread Donald Stufft


> On Jul 18, 2018, at 7:06 PM, Fred Drake  wrote:
> 
> PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> superseded, recycling the PEP number seems out of character with the
> RFC process from which we derived the PEP process.  Let's be cautious
> about recycling like that; integers are cheap.

Amusingly, I went through the low numbered PEPs as a result of this, and found 
https://www.python.org/dev/peps/pep-0010/ 
.___
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

2018-07-18 Thread Fred Drake

> On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya  
> wrote:
> Let's be clear that we're not yet at the stage where we can vote for 
> anything, let alone how to vote.

On Wed, Jul 18, 2018 at 6:03 PM Łukasz Langa  wrote:
> I don't understand what you mean. Before we get to vote on a variant of PEP 
> 2, we need to decide how we are supposed to perform that vote. This needs to 
> be decided before we discuss councils, dictators, and so on because it's all 
> moot if there is no accepted way to agree which governance model we want.

Humans do so love to argue!

Both the decision-making process and the candidate decisions are
reasonable to discuss; there's no intrinsic ordering constraint for
reasonable discussion.  We need to decide on the decision-making
mechanism before the decision can be made, but that's it.

PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
superseded, recycling the PEP number seems out of character with the
RFC process from which we derived the PEP process.  Let's be cautious
about recycling like that; integers are cheap.

  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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 on how to vote (was: An alternative governance model)

2018-07-18 Thread Donald Stufft

> On Jul 18, 2018, at 6:18 PM, Łukasz Langa  wrote:
> 
> 
>> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
>> 
>> While I am totally fine with a super-majority of votes for something to be 
>> accepted, I don't think the minimum participation requirement will work. If 
>> people simply choose not to vote then they choose not to (we have no way to 
>> really compel people to vote).
> 
> It could be easily added to the list of things expected from a core 
> contributor. It's not like this is a laborious chore, neither is it happening 
> often. There are countries where voting is mandatory.

Given that we don’t have a lot of levers in our tool chest to compel voting, 
what would you propose we do if we get only a 35% participation rate? We can’t 
drag people to the polls, the most we can really do is either keep running 
elections and hope you hit whatever threshold you decide on, or you start 
removing people who can vote until you’ve removed enough people that the people 
who are participating now make up whatever your target participation rate is.

The first choice there strikes me as unrealistic. Hope is not a strategy, and I 
fail to see why repeatedly offering the same vote multiple times is likely to 
increase the participation rate. In fact, I think it’s likely to decease it as 
people get tired of having to do it over again and just start giving up and 
viewing it as noise.

The second choice seems… dishonest to me? You’re not really increasing the 
participation of the vote, you’re just juicing the numbers to make the 
participation rate higher. It’s selectively defining who is eligible to vote to 
make the numbers look better.

Is there another option I’m missing to compel people to vote?

> 
> Taking a step back, there are two reasons I stress the importance of (almost) 
> everybody voicing their support:
> - this makes the decision authoritative ("the committers have spoken”);

I think this is largely a non-issue. In the US we do not have mandatory 
elections, and I don’t see very many people challenging the authority of said 
elections due to the large percentage of non-voters. The most I generally see 
if people scolding those who don’t vote.

> - this ensures that we haven't omitted somebody due to poor timing ("I was on 
> a sabbatical and couldn't vote”).

Unless you require 100% voting participation, it doesn’t ensure this, it just 
makes it less likely. If you target 90%, then a full 10% of the people could 
have been excluded due to poor timing. 

I don’t think it’s possible to fully eliminate this risk, but I think the best 
possible way of handling it is to advertise the vote well in advance, and allow 
the vote itself to take place over a reasonable amount of time. The more 
advance notice, and the larger the window of time is to actually vote in, the 
less likely timing becomes an issue. Just to pluck some random times out of the 
air, if you advertise the voting for 3 months and allow voting to happen any 
time in a months time, that gives people a full 4 months they will have to be 
completely unavailable to have no idea the voting is happening, and be unable 
to access a computer for a handful of minutes to actually do the vote at all in 
a month.

> 
> If you feel like this is unrealistic because most of our committers aren't 
> currently active, I hear you. But what I like even less is claiming that "we, 
> the core team" made a decision when, say, just 35% of us voted. In such case 
> it would be easier for those of us who disagree to claim the decision doesn't 
> really represent the views of the greater core 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 on how to vote (was: An alternative governance model)


Le 19/07/2018 à 00:36, Antoine Pitrou a écrit :
> 
> Le 19/07/2018 à 00:29, Victor Stinner a écrit :
>> I hate cabals. I prefer to keep everything open and transparent, as
>> this mailing list is public (even if only core developers are allowed
>> to post).
> 
> Even if posting is public, you won't know whether there is a cabal or
> not (unless you are part of the cabal -- I hope you aren't, are you? ;-)).

Sorry: s/posting/voting/
___
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 on how to vote (was: An alternative governance model)


Le 19/07/2018 à 00:29, Victor Stinner a écrit :
> I hate cabals. I prefer to keep everything open and transparent, as
> this mailing list is public (even if only core developers are allowed
> to post).

Even if posting is public, you won't know whether there is a cabal or
not (unless you are part of the cabal -- I hope you aren't, are you? ;-)).

> Which drawback do you see of making the votes public?

Let's say I'm being asked if X should be a « next BDFL » (or Council
member, etc.) and I vote no publicly.  What is my position if X is
elected?  How will my vote be interpreted?  Will I get discriminated
against (even unconsciously) just because I didn't choose that person?

There are all kinds of pressures (or self-censorship phenomena) that can
occur with public voting.

(votes by elected representatives, conversely, are public, because being
elected it's important for the electors to know what the representatives
truly stand for)

Regards

Antoine.


> 
> Victor
> 
> 2018-07-19 0:26 GMT+02:00 Antoine Pitrou :
>>
>> By the way, should the vote be public or secret?
>> For such an important (and sensitive) matter, perhaps it would be wise
>> for it to be secret.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>>>
 On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:

 While I am totally fine with a super-majority of votes for something to be 
 accepted, I don't think the minimum participation requirement will work. 
 If people simply choose not to vote then they choose not to (we have no 
 way to really compel people to vote).
>>>
>>> It could be easily added to the list of things expected from a core 
>>> contributor. It's not like this is a laborious chore, neither is it 
>>> happening often. There are countries where voting is mandatory.
>>>
>>> Taking a step back, there are two reasons I stress the importance of 
>>> (almost) everybody voicing their support:
>>> - this makes the decision authoritative ("the committers have spoken");
>>> - this ensures that we haven't omitted somebody due to poor timing ("I was 
>>> on a sabbatical and couldn't vote").
>>>
>>> If you feel like this is unrealistic because most of our committers aren't 
>>> currently active, I hear you. But what I like even less is claiming that 
>>> "we, the core team" made a decision when, say, just 35% of us voted. In 
>>> such case it would be easier for those of us who disagree to claim the 
>>> decision doesn't really represent the views of the greater core 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/
>>>
>> ___
>> 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 on how to vote (was: An alternative governance model)

2018-07-18 Thread Victor Stinner

I hate cabals. I prefer to keep everything open and transparent, as
this mailing list is public (even if only core developers are allowed
to post).

Which drawback do you see of making the votes public?

Victor

2018-07-19 0:26 GMT+02:00 Antoine Pitrou :
>
> By the way, should the vote be public or secret?
> For such an important (and sensitive) matter, perhaps it would be wise
> for it to be secret.
>
> Regards
>
> Antoine.
>
>
> Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>>
>>> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
>>>
>>> While I am totally fine with a super-majority of votes for something to be 
>>> accepted, I don't think the minimum participation requirement will work. If 
>>> people simply choose not to vote then they choose not to (we have no way to 
>>> really compel people to vote).
>>
>> It could be easily added to the list of things expected from a core 
>> contributor. It's not like this is a laborious chore, neither is it 
>> happening often. There are countries where voting is mandatory.
>>
>> Taking a step back, there are two reasons I stress the importance of 
>> (almost) everybody voicing their support:
>> - this makes the decision authoritative ("the committers have spoken");
>> - this ensures that we haven't omitted somebody due to poor timing ("I was 
>> on a sabbatical and couldn't vote").
>>
>> If you feel like this is unrealistic because most of our committers aren't 
>> currently active, I hear you. But what I like even less is claiming that 
>> "we, the core team" made a decision when, say, just 35% of us voted. In such 
>> case it would be easier for those of us who disagree to claim the decision 
>> doesn't really represent the views of the greater core 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/
>>
> ___
> 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 on how to vote (was: An alternative governance model)

The PSF uses a good voting system where votes are secret. I see no reason not 
to reuse this infra.

-- 
Best regards,
Łukasz Langa

> On Jul 18, 2018, at 5:26 PM, Antoine Pitrou  wrote:
> 
> 
> By the way, should the vote be public or secret?
> For such an important (and sensitive) matter, perhaps it would be wise
> for it to be secret.
> 
> Regards
> 
> Antoine.
> 
> 
>> Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
>> 
>>> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
>>> 
>>> While I am totally fine with a super-majority of votes for something to be 
>>> accepted, I don't think the minimum participation requirement will work. If 
>>> people simply choose not to vote then they choose not to (we have no way to 
>>> really compel people to vote).
>> 
>> It could be easily added to the list of things expected from a core 
>> contributor. It's not like this is a laborious chore, neither is it 
>> happening often. There are countries where voting is mandatory.
>> 
>> Taking a step back, there are two reasons I stress the importance of 
>> (almost) everybody voicing their support:
>> - this makes the decision authoritative ("the committers have spoken");
>> - this ensures that we haven't omitted somebody due to poor timing ("I was 
>> on a sabbatical and couldn't vote").
>> 
>> If you feel like this is unrealistic because most of our committers aren't 
>> currently active, I hear you. But what I like even less is claiming that 
>> "we, the core team" made a decision when, say, just 35% of us voted. In such 
>> case it would be easier for those of us who disagree to claim the decision 
>> doesn't really represent the views of the greater core 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/
>> 
> ___
> 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 on how to vote (was: An alternative governance model)


By the way, should the vote be public or secret?
For such an important (and sensitive) matter, perhaps it would be wise
for it to be secret.

Regards

Antoine.


Le 19/07/2018 à 00:18, Łukasz Langa a écrit :
> 
>> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
>>
>> While I am totally fine with a super-majority of votes for something to be 
>> accepted, I don't think the minimum participation requirement will work. If 
>> people simply choose not to vote then they choose not to (we have no way to 
>> really compel people to vote).
> 
> It could be easily added to the list of things expected from a core 
> contributor. It's not like this is a laborious chore, neither is it happening 
> often. There are countries where voting is mandatory.
> 
> Taking a step back, there are two reasons I stress the importance of (almost) 
> everybody voicing their support:
> - this makes the decision authoritative ("the committers have spoken");
> - this ensures that we haven't omitted somebody due to poor timing ("I was on 
> a sabbatical and couldn't vote").
> 
> If you feel like this is unrealistic because most of our committers aren't 
> currently active, I hear you. But what I like even less is claiming that "we, 
> the core team" made a decision when, say, just 35% of us voted. In such case 
> it would be easier for those of us who disagree to claim the decision doesn't 
> really represent the views of the greater core 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/
> 
___
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 on how to vote (was: An alternative governance model)

> On Jul 18, 2018, at 4:56 PM, Brett Cannon  wrote:
> 
> While I am totally fine with a super-majority of votes for something to be 
> accepted, I don't think the minimum participation requirement will work. If 
> people simply choose not to vote then they choose not to (we have no way to 
> really compel people to vote).

It could be easily added to the list of things expected from a core 
contributor. It's not like this is a laborious chore, neither is it happening 
often. There are countries where voting is mandatory.

Taking a step back, there are two reasons I stress the importance of (almost) 
everybody voicing their support:
- this makes the decision authoritative ("the committers have spoken");
- this ensures that we haven't omitted somebody due to poor timing ("I was on a 
sabbatical and couldn't vote").

If you feel like this is unrealistic because most of our committers aren't 
currently active, I hear you. But what I like even less is claiming that "we, 
the core team" made a decision when, say, just 35% of us voted. In such case it 
would be easier for those of us who disagree to claim the decision doesn't 
really represent the views of the greater core 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] An alternative governance model

> On Jul 18, 2018, at 4:14 PM, Mariatta Wijaya  
> wrote:
> 
> Let's be clear that we're not yet at the stage where we can vote for 
> anything, let alone how to vote.

I don't understand what you mean. Before we get to vote on a variant of PEP 2, 
we need to decide how we are supposed to perform that vote. This needs to be 
decided before we discuss councils, dictators, and so on because it's all moot 
if there is no accepted way to agree which governance model we want.

> Last week someone suggested doing research of other governance models. We 
> should still do that before we even start voting on anything.

Yes, agreed, absolutely! But these are two separate concerns. I'm interested in 
establishing how we decide which model fits us.

- Ł
___
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] Proposal on how to vote (was: An alternative governance model)

[starting a new thread]

On Wed, 18 Jul 2018 at 14:04 Łukasz Langa  wrote:

>
> > On Jul 18, 2018, at 1:23 PM, Alex Martelli  wrote:
> >
> > Since 1179 (and with a few very minor exceptions in the centuries right
> after then -- none since 1612), the Catholic Church requires a
> super-majority of 2/3 to elect a new Pope. I don't see how the choice of a
> BDFL is so much more important to the Python community, than the choice of
> a Pope is to the Catholic Church; thus, requiring 90% rather than "just"
> 2/3 seems unwarranted.
>
> This is a good point. Moreover, I'm sure Monty Python-wise it's only
> fitting for us to base our rules on a papal conclave.
>
> If we do, then it looks like 2/3 it is. However, historically cardinal
> participation rates were really high so I'd like to keep the 90%
> participation rule there.
>

To put hard numbers to this, there are 91 people with commit rights ATM and
171 potential people based on the bugs.python.org committers list. So that
means we will require anywhere from 82 to 154 people to vote. To me that
seems unreachable on either end of the scale.

While I am totally fine with a super-majority of votes for something to be
accepted, I don't think the minimum participation requirement will work. If
people simply choose not to vote then they choose not to (we have no way to
really compel people to vote).

-Brett


> I do find it a bit problematic that a papal conclave doesn't vote "yes/no"
> but rather just places names for a predefined position using predefined
> rules.
>
> > In fact, a 90% requirement gets dangerously close to a requirement for
> unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and
> thus end the session and nullify every decision made in the session.
>
> Oh, you know how to hit close to home! However, there's a big difference
> between one vote vetoing the ruling and ten (as there's 100+ GitHub
> committers now IIRC).
>
> But yeah, if the Vatican is fine with two thirds, it sounds like we could,
> too. By the way, if we're already studying Polish parliamentary rules, 2/3
> agreement is needed to make constitution changes.
>
> - Ł
> ___
> 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

2018-07-18 Thread Jack Jansen

Is it necessary to put exact percentages here?

I think a BDFL-replacement should have the support of a large majority of the 
community. I would expect anyone who would be considered as BDFL in the first 
place would voluntarily step down once this is no longer the case. I don’t 
think it is necessary to clearly define what “large majority” means, nor what 
“community” means.

If the Python community ever gets to the level infighting of Borgia popes 
versus de Medici popes I think things have deteriorated to a level that it 
won’t make much difference anyways.

I’m not 100% convinced I like Barry’s idea of a formal Council as the board of 
the community, but on the other hand I don’t have a good alternative (except 
for the anarchist village shouting match, but that has serious issues).

Jack

> On  18-Jul-2018, at 23:04 , Łukasz Langa  wrote:
> 
> 
>> On Jul 18, 2018, at 1:23 PM, Alex Martelli  wrote:
>> 
>> Since 1179 (and with a few very minor exceptions in the centuries right 
>> after then -- none since 1612), the Catholic Church requires a 
>> super-majority of 2/3 to elect a new Pope. I don't see how the choice of a 
>> BDFL is so much more important to the Python community, than the choice of a 
>> Pope is to the Catholic Church; thus, requiring 90% rather than "just" 2/3 
>> seems unwarranted.
> 
> This is a good point. Moreover, I'm sure Monty Python-wise it's only fitting 
> for us to base our rules on a papal conclave.
> 
> If we do, then it looks like 2/3 it is. However, historically cardinal 
> participation rates were really high so I'd like to keep the 90% 
> participation rule there.
> 
> I do find it a bit problematic that a papal conclave doesn't vote "yes/no" 
> but rather just places names for a predefined position using predefined rules.
> 
>> In fact, a 90% requirement gets dangerously close to a requirement for 
>> unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and 
>> thus end the session and nullify every decision made in the session.
> 
> Oh, you know how to hit close to home! However, there's a big difference 
> between one vote vetoing the ruling and ten (as there's 100+ GitHub 
> committers now IIRC).
> 
> But yeah, if the Vatican is fine with two thirds, it sounds like we could, 
> too. By the way, if we're already studying Polish parliamentary rules, 2/3 
> agreement is needed to make constitution changes.
> 
> - Ł
> ___
> 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/

--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman



___
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

Let's be clear that we're not yet at the stage where we can vote for
anything, let alone how to vote.

Barry made one proposal, that's all.

Last week someone suggested doing research of other governance models. We
should still do that before we even start voting on anything.

Mariatta


On Wed, Jul 18, 2018 at 2:04 PM Łukasz Langa  wrote:

>
> > On Jul 18, 2018, at 1:23 PM, Alex Martelli  wrote:
> >
> > Since 1179 (and with a few very minor exceptions in the centuries right
> after then -- none since 1612), the Catholic Church requires a
> super-majority of 2/3 to elect a new Pope. I don't see how the choice of a
> BDFL is so much more important to the Python community, than the choice of
> a Pope is to the Catholic Church; thus, requiring 90% rather than "just"
> 2/3 seems unwarranted.
>
> This is a good point. Moreover, I'm sure Monty Python-wise it's only
> fitting for us to base our rules on a papal conclave.
>
> If we do, then it looks like 2/3 it is. However, historically cardinal
> participation rates were really high so I'd like to keep the 90%
> participation rule there.
>
> I do find it a bit problematic that a papal conclave doesn't vote "yes/no"
> but rather just places names for a predefined position using predefined
> rules.
>
> > In fact, a 90% requirement gets dangerously close to a requirement for
> unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and
> thus end the session and nullify every decision made in the session.
>
> Oh, you know how to hit close to home! However, there's a big difference
> between one vote vetoing the ruling and ten (as there's 100+ GitHub
> committers now IIRC).
>
> But yeah, if the Vatican is fine with two thirds, it sounds like we could,
> too. By the way, if we're already studying Polish parliamentary rules, 2/3
> agreement is needed to make constitution changes.
>
> - Ł
> ___
> 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] Language moratorium

2018-07-18 Thread Stefan Krah

On Wed, Jul 18, 2018 at 11:47:22AM -0700, Barry Warsaw wrote:
> On Jul 18, 2018, at 09:11, Stefan Krah  wrote:
> 
> > if I remember correctly, we had a moratorium for language changes around
> > versions 3.2-3.3.  I think during that time relatively few BDFL-level
> > decisions were required.
> > 
> > Perhaps we could have one again, say for 12 months so we can figure things
> > out. Other Python implementations may welcome the moratorium so they can
> > catch up.
> 
> I agree that we’ll effectively have language moratorium until we have a new 
> governance structure.  But let me ask, what do you propose to do about PEP 
> 572?  That’s already been accepted, but not yet implemented.  Would it be 
> exempt from the moratorium or scoot in under the wire?

That is a tough question. :)  I meant a moratorium for new decisions and
subsequent changes, so I kind of assumed PEP 572 would go in.


Stefan Krah




___
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

[Barry Warsaw, on the origin of BDFL]

> I’d put my money on Uncle Timmy coining that term,


Don't be insulting, Barry.  I have no patience - let alone love - for
frivolous wordplay.

It wasn't me, but Guido doesn't remember either.  Here's his best guess:

https://www.artima.com/weblogs/viewpost.jsp?thread=235725


Short course:  BDFL first appeared in a 1995 email sent by Ken Manheimer
summarizing a PSA meeting.  Guido was apparently named at that meeting as

*First Interim Benevolent Dicator* [sic]* for Life*

and

While I can't prove my title (with or without the First Interim prefix) was
> never used before, I'm pretty certain that it originated in this meeting.
> Given what I know of how their minds work, it was most likely invented by
> Ken Manheimer or Barry Warsaw, though it may well have been a joint
> invention by all present.


Some titles just _fit_.  Like Kim Jong Il's

Great Man, Who Is a Man of Deeds

and

 Dear Leader, who is a perfect incarnation of the appearance that a leader
should have


More inspiring ideas where those came from:

https://en.wikipedia.org/wiki/List_of_Kim_Jong-il%27s_titles
___
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] Language moratorium

2018-07-18 Thread Christian Heimes

On 2018-07-18 20:47, Barry Warsaw wrote:
> On Jul 18, 2018, at 09:11, Stefan Krah  wrote:
> 
>> if I remember correctly, we had a moratorium for language changes around
>> versions 3.2-3.3.  I think during that time relatively few BDFL-level
>> decisions were required.
>>
>> Perhaps we could have one again, say for 12 months so we can figure things
>> out. Other Python implementations may welcome the moratorium so they can
>> catch up.
> 
> I agree that we’ll effectively have language moratorium until we have a new 
> governance structure.  But let me ask, what do you propose to do about PEP 
> 572?  That’s already been accepted, but not yet implemented.  Would it be 
> exempt from the moratorium or scoot in under the wire?

It's the last will of our beloved dictator.

To quote my favorite Marvel villain: The first order of the new BDFL
cannot undo the last will of the previous BDFL.

Christian



signature.asc
Description: OpenPGP digital signature
___
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] Language moratorium

Le 18/07/2018 à 20:47, Barry Warsaw a écrit :
> On Jul 18, 2018, at 09:11, Stefan Krah  wrote:
> 
>> if I remember correctly, we had a moratorium for language changes around
>> versions 3.2-3.3.  I think during that time relatively few BDFL-level
>> decisions were required.
>>
>> Perhaps we could have one again, say for 12 months so we can figure things
>> out. Other Python implementations may welcome the moratorium so they can
>> catch up.
> 
> I agree that we’ll effectively have language moratorium until we have a new 
> governance structure.  But let me ask, what do you propose to do about PEP 
> 572?  That’s already been accepted, but not yet implemented.  Would it be 
> exempt from the moratorium or scoot in under the wire?

Since it's accepted, the implementation is just a matter of code review
and doesn't require (AFAICT) the intervention of an ultimate authority.
As much as I dislike PEP 572...

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] Language moratorium

On Jul 18, 2018, at 09:11, Stefan Krah  wrote:

> if I remember correctly, we had a moratorium for language changes around
> versions 3.2-3.3.  I think during that time relatively few BDFL-level
> decisions were required.
> 
> Perhaps we could have one again, say for 12 months so we can figure things
> out. Other Python implementations may welcome the moratorium so they can
> catch up.

I agree that we’ll effectively have language moratorium until we have a new 
governance structure.  But let me ask, what do you propose to do about PEP 572? 
 That’s already been accepted, but not yet implemented.  Would it be exempt 
from the moratorium or scoot in under the wire?

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/

[python-committers] An alternative governance model

Le 18/07/2018 à 19:51, Barry Warsaw a écrit :
> On Jul 18, 2018, at 01:43, Antoine Pitrou  wrote:
>>
>> Why do you think non-BDFL projects have a problem with """ambiguity as
>> to the authority of said decision"""?  What is your basis for that
>> assertion?
> 
> With more people empowered to make a binding decision as part of a Supreme 
> Council, there will be more uncertainty in the authority of the person 
> pronouncing. 

I don't really follow you.  If you have a collegial body (a Council),
it's the Council as a whole that has the authority to pronounce.  Not
any singular member of the Council (unless the Council functions as a
miniature monarchy, that is).  So the "person pronouncing" is the Council.

(Imagine a parliamentary regime: when a parliament decides on a law,
it's the parliament's authority that makes the law valid in the eyes of
every citizen.  It does not matter which representatives exactly voted
on a given piece of law.)

> Of one thing I have absolutely no doubt: no decision in Python will ever be 
> unanimous!  That kind of proves my point as to why a singular leader is 
> necessary. :)

That doesn't prove anything. A dictator is not needed to make up for
the lack of unanimity (fortunately! otherwise we would all live under
dictatorships...).

>> You're creating a huge problem here.  Whatever dictator you come up
>> with, not everyone will be ok with that choice.  What are they supposed
>> to do?  If one doesn't think X is legitimate as a dictator, how does one
>> keep contributing to the project?  In other words, you are threatening
>> to exclude people, perhaps seasoned contributors.
> 
> How is that any different with a Supreme Council rather than a singular 
> leader?  Whatever makeup of the Council we come up with, not everyone will be 
> okay with those choices.  What are they supposed to do?

Well, there is a large difference between a dictator-for-life and, for
example, a collegial body that gets renewed from time to time.  The
latter is probably easier to compromise with, even for those who
don't like its makeup.

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] An alternative governance model

On Jul 18, 2018, at 10:13, Eric Snow  wrote:

> Regardless of when it happens (if ever), what will happen
> in the future when we don't have anyone suitable?  One danger is that
> we will install someone un-suitable because "we've always had a BDFL".
> But what is that "danger"?  What impact could a rogue BDFL have?

I’m not concerned about that, and not just because I’m secretly wishing for a 
filibuster until I get to join Guido on the Isle of Former Pythonistas Who Know 
Prefer To Sip Margaritas In Peace and Quiet and No Internet.

Grooming suitable future leaders is critical to the relevance of Python for the 
next 30 years.  I’m confident that when the time comes, there will be obvious 
choices, just as there has been for Release Managers.  And if there really 
isn’t then future archeologists will point to this thread and say “maybe now we 
can experiment with a Supreme Council”.

> 1. what makes a good BDFL?
> 2. what do we do when we can't find a suitable candidate?
> 3. what negative impact can a BDFL have?
> 4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?

I’d like to add: how do we ensure that we will have many suitable candidates if 
and when the time comes to choose the N+1BDFL?

> However, I supposed I hadn't considered it before, but the BDFL has a
> much more significant role.  The Python community is in many ways a
> reflection of Guido and a result of his leadership (much more than
> technical leadership).  Consequently, a new BDFL must be someone who
> reflects where we want the community to be.

To me, that’s the “vision” question, but I think the BDFL doesn’t just reflect 
the communities wishes, because “the community” will never agree 100% on 
anything.  Which, FTR, I think is okay.  The BDFL uses their intuition, 
compassion, and experience to move Python forward according to their vision for 
what the language should be, deeply informed by —but not subservient to— the 
opinions of all its users and developers, because that’s essentially impossible.

> 2. what do we do when we can't find a suitable candidate?
> 
> This is worth figuring out.  It isn't something we've discussed much.
> I expect most folks feel like it will never be an issue.  I suppose
> they're right.  At the point there isn't a suitable candidate, we have
> larger problems to address. :)

Indeed.  I’d say that we should be proactive so that we never get into that 
position, by beginning to groom future NBDFLs now.

> 3. what negative impact can a BDFL have?
> 
> I was primarily thinking about a "rogue" BDFL, rather that about
> mistakes an otherwise good one might make.  The big question is what
> does it mean for the BDFL to go "rogue".  It definitely isn't "making
> a decision the people don't agree with" as Guido has done that plenty
> of times (to our benefit). :)  In my mind, the main bad that the BDFL
> can do is to hurt the community.  Their possible negative technical
> impact is small and highly recoverable.

That’s a good point, except that there is usually a window of practical 
recoverability.  For example, once Python 3.8 is released, PEP 572 will be very 
very difficult to undo.

> 4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?
> 
> People make mistakes.  We should expect the BDFL to make them too.  We
> should also expect them to care deeply about Python (as well as align
> relatively closely with the community).  We can deal with their
> mistakes. :)
> 
> However, if the BDFL turns out to be not as capable as we expected (no
> judgement, Brett) or appears to be purposefully hurting Python then
> we'd need to act.  On the one hand we'd need to deal with the BDFL
> directly, likely replacing them or more broadly restructuring.  On the
> other had we'd have to deal with the community consequences (the four
> listed in point #3).  The latter is the one with deeper consequences.
> TBH, the same is true of any structure we apply (e.g. council,
> majority rule).
> 
> I suppose the most we could plan for would be quickly removing a rogue
> BDFL (but without such a plan hanging over a good BDFL's head).  I'd
> consider Barry's proposal of advisers to be in the right direction.
> That said, as with #2 this is probably not something that will ever
> come up.

Thanks Eric, these are good points to consider.

> The "benevolent" part is critical though.  Without it none of the rest
> would work for us.  Perhaps I've misunderstood your point?  FWIW, the
> word "dictator" has a lot of negative connotation that does not match
> our usage in BDFL.  I don't mean to suggest that's the only concern
> here, but would it help to use a different name than BDFL?  IIRC, it's
> either a clever Monty Python reference or a tongue-in-cheek expression
> from Barry 20 years ago that stuck.

I’d put my money on Uncle Timmy coining that term, but maybe you’re on to 
something here.  Okay, let’s call our leader “Dinsdale”.  As in, who will be 
the Next Dinsdale?

> Fair enough.  I don't

Re: [python-committers] An alternative governance model

2018-07-18 Thread Alex Martelli via python-committers

Since 1179 (and with a few very minor exceptions in the centuries right
after then -- none since 1612), the Catholic Church requires a
super-majority of 2/3 to elect a new Pope. I don't see how the choice of a
BDFL is so much more important to the Python community, than the choice of
a Pope is to the Catholic Church; thus, requiring 90% rather than "just"
2/3 seems unwarranted.

In fact, a 90% requirement gets dangerously close to a requirement for
unanimity -- allowing any member of the Sejm to shout "Nie pozwalam!" and
thus end the session and nullify every decision made in the session. As
https://en.wikipedia.org/wiki/Liberum_veto puts it, "Many historians hold
that the liberum veto was a major cause of the deterioration of the
Commonwealth political system" all the way to the partitions of Poland.

Let's steer well clear of this: those who cannot remember the past, etc,
etc...

Alex

On Wed, Jul 18, 2018 at 11:07 AM Łukasz Langa  wrote:

>
> > On Jul 18, 2018, at 11:54 AM, Ethan Furman  wrote:
> >
> > Are you saying that we should use some method besides voting, or that a
> higher percentage of yea votes is required?  If the latter, I have no
> problem with 66% or 75%.
>
> The cleanest way would be for Guido to choose but he already said he wants
> to stay out of the process.
>
> With that in mind, one alternative is for the President of the PSF to
> choose ;-)
>
> ...so realistically the only alternative is a vote. Given the gravity of
> the situation (a decision on how future decisions are made; long-term
> consequences), I propose:
>
> 1. Define a committer as anybody with GitHub privileges. While not
> everybody on this mailing list decided to get GitHub credentials, they can
> do it at any point. At the same time, by defining the committer set as
> GitHub contributors, we solve the issue of inactive contributors. And this
> is important because...
>
> 2. Require 90% participation for the vote to be valid.
>
> 3. Require 90% votes in favor for the proposal to pass.
>
> If 2. or 3. fail, back to the drawing board. I'd lower those requirements
> only after a few consecutive votes fail.
>
> - Ł
> ___
> 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

> On Jul 18, 2018, at 11:54 AM, Ethan Furman  wrote:
> 
> Are you saying that we should use some method besides voting, or that a 
> higher percentage of yea votes is required?  If the latter, I have no problem 
> with 66% or 75%.

The cleanest way would be for Guido to choose but he already said he wants to 
stay out of the process.

With that in mind, one alternative is for the President of the PSF to choose ;-)

...so realistically the only alternative is a vote. Given the gravity of the 
situation (a decision on how future decisions are made; long-term 
consequences), I propose:

1. Define a committer as anybody with GitHub privileges. While not everybody on 
this mailing list decided to get GitHub credentials, they can do it at any 
point. At the same time, by defining the committer set as GitHub contributors, 
we solve the issue of inactive contributors. And this is important because...

2. Require 90% participation for the vote to be valid.

3. Require 90% votes in favor for the proposal to pass.

If 2. or 3. fail, back to the drawing board. I'd lower those requirements only 
after a few consecutive votes fail.

- Ł
___
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

On Jul 18, 2018, at 09:44, Steve Dower  wrote:

> Right now, I imagine Barry is testing the waters to see whether it's worth 
> his time writing this up as a proposed PEP 2. Other people seem to be 
> interested in also proposing alternative PEP 2s, and eventually we as a group 
> will have to select one of them, no doubt by majority vote. And while Barry's 
> long service to this group certainly adds weight to his opinion, it's also 
> likely that we can filibuster for long enough until he retires and then 
> ignore him completely :)

One can only hope! :)

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] An alternative governance model

On Jul 18, 2018, at 09:10, Antoine Pitrou  wrote:

> At this point we are not talking about a majority vote.  All I see is a
> rushed plebiscite on a single governance model and a single person.

Antoine, there’s nothing rushed about this.  I made a proposal, and there’s a 
healthy debate going on.  We don’t even know how the decisions will be made, or 
by whom yet.

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] An alternative governance model

On Jul 18, 2018, at 03:31, Ethan Furman  wrote:
> 
> I think this is the crux of the argument:  getting a group of people, even a 
> small one, to agree on a singular vision can be very difficult.

Yep.

>> I also think a council will be much more risk adverse than a singular BDFL, 
>> and that’s not necessarily a good thing.  While moratoriums and a more
> > conservative approach to change may be appropriate at times, I would prefer 
> > those to be deliberate decisions for a specific purpose, rather than
> > the unintended outcome of groupthink or lack of consensus.  A singular BDFL 
> > with support from the community will have more authority to make
> > decisions which probably will never be universally accepted, and much less 
> > prone to vapor lock due to lack of consensus or internal bickering.
> 
> Community support can be mercurial, and should not be relied upon as an 
> underpinning of our governance model.

No?  I think it’s critical.

Here’s a thought experiment: Pretend that PEP 572 were in front of the Supreme 
Council.  How do you think the discussions would go?  Would your opinion for or 
against be weighed with sufficient deliberation?  Would the PEP have undergone 
the rewrites it did in order to address the concerns early on?  Would you have 
confidence in the decision of the Council, whether it went your way or not?  If 
you lost the argument, how would you react?  How would any of that be different 
with a singular leader?  Would it matter to you if that leader was not Guido?

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] An alternative governance model

On Jul 18, 2018, at 03:04, Antoine Pitrou  wrote:
> 
> If we're talking about a dictator (this is Barry's proposal), we're not
> talking about someone that just makes language design decisions, as
> Victor pointed out.

I’m talking about a singular leader who has the responsibility and vision to 
direct Python for as long as they are able and want to.  Just as Guido left 
tons of decisions to others (including this one :), so will the next BDFL.  
Exactly what that mix of delegation will look like is, in my proposal, up to 
the NBDFL.

-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] An alternative governance model

On Jul 18, 2018, at 02:49, Ethan Furman  wrote:

>> (*) (I'm leaving the "benevolent" part out, since clearly it was only
>> tied to Guido's personality, not to any inherent statutory limitations)
> 
> I think that's a mistake.  Clearly, the "benevolent" part is a major criteria 
> for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is 
> not the only benevolent core-dev we have.

+1 - completely agree.  “Benevolence” is critical IMHO.

-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] An alternative governance model

On Jul 18, 2018, at 01:43, Antoine Pitrou  wrote:
> 
> Why do you think non-BDFL projects have a problem with """ambiguity as
> to the authority of said decision"""?  What is your basis for that
> assertion?

With more people empowered to make a binding decision as part of a Supreme 
Council, there will be more uncertainty in the authority of the person 
pronouncing.  Part of that will be because the pronouncement can come from any 
of the member of the Council, and part may come from more turnover in the 
Council membership.  I’m not at all concerned about *us* accepting that 
authoritative decision because we are are deeply invested in Python’s 
governance.  But I claim that the vast majority of Python users are not, so 
while they recognize Guido’s name as the (former) leader, I question whether 
they will be able to have the same certainty in the authority of a decision 
coming from 3 or 5 people who’s names they are not familiar with.  With a 
singular leader, it will be easier to communicate the authority of that leader.

So yeah, maybe it’s a PR problem, but it’s still important nonetheless.

> I'm worried that you seem to be descending into magical thought,
> believing for some reason that nothing else than monarchy could ever
> work for a software project.

We’re not talking about software project governance in general, we’re talking 
about Python specifically. And Python has had a strong singular leader with a 
clear vision for its entire nearly 30 year life.  Yes, I personally question 
whether a Supreme Council will work for Python.

> Since you're opening this can of worms, I'll say it:
> 
> - I'm -1 on a new dictator-for-life (*)

Let me be clear: “BDFL” is a convenient term with a well-known meaning.  In 
fact, I believe *we* coined that term that’s now often used in other open 
source projects.  But as Guido has eloquently demonstrated, the “For Life” part 
really means “For As Long As They Want To Do It”.  In other words, it’s just a 
title for the job.  In my proposal, it really means “For As Long As They Want 
To Do It And They Don’t Do Something Evil Enough To Get Impeached”.  I’m 
spelling that title with the initialism “BDFL” :)

> - I'm -1 on Brett Cannon as a new dictator-for-life

Of one thing I have absolutely no doubt: no decision in Python will ever be 
unanimous!  That kind of proves my point as to why a singular leader is 
necessary. :)

> You're creating a huge problem here.  Whatever dictator you come up
> with, not everyone will be ok with that choice.  What are they supposed
> to do?  If one doesn't think X is legitimate as a dictator, how does one
> keep contributing to the project?  In other words, you are threatening
> to exclude people, perhaps seasoned contributors.

How is that any different with a Supreme Council rather than a singular leader? 
 Whatever makeup of the Council we come up with, not everyone will be okay with 
those choices.  What are they supposed to do?

Ultimately you’re right.  There are zillions of reasons not to contribute to 
Python, so having no confidence in its leadership is just one more.  
Fortunately, only you get to decide whether your reasons not to contribute 
outweigh your reasons to contribute.  And further, it’s open source, so you are 
*always* welcome to fork.  Look at Devuan 
.

>> I’ve long said — somewhat in jest, since I never expected Guido to actually 
>> ever retire! — that Brett would be my choice for the next BDFL.  I think 
>> he’s the perfect candidate, and he’s already demonstrated qualities that I 
>> think make him a fantastic leader.
> 
> I bed to disagree, Barry.  Brett is a good contributor, that doesn't
> make him legitimate as a dictator.  Only Guido could be, and he has
> stepped down.
> 
> The amount of cheerleading here ("""smart, compassionate, passionate,
> respectful, young, tall, and has the right mix of technical excellence
> and social skills""") is embarrassing.  What if we don't subscribe to
> your views of Brett's qualities: do you expect us to publicly criticize
> Brett so as to justify our opposition?

Also fortunately, I don’t get to unilaterally decide this!  I get to propose a 
plan, make my arguments, try to persuade, and cast my one vote — hopefully, 
depending on the criteria.  Just like all of you. :)

(Maybe we don’t count anybody who has more hair on his chin now than his head 
when he first started using Python, in which case, I’m definitely forking what 
I’ll call UncleTimmython).

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] An alternative governance model

On Wed, Jul 18, 2018 at 10:44 AM Steve Dower  wrote:
> Your contributions to this part of the discussion are also very useful -
> we need to know what concerns people have, and often those concerns may
> not have occurred to those of us who approach it with a more idealistic
> idea of how everything will work out.

This is a critical point, especially as we are without a BDFL to rely
on for this discussion and decision. :)  We need all the viewpoints,
mutual respect, and patience.

-eric
___
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

On Wed, Jul 18, 2018 at 10:36 AM Łukasz Langa  wrote:
> A simple majority vote is wildly insufficient for this case. Python is a 
> large project with many contributors and alienating maybe tens of them is not 
> acceptable, especially if we are talking about a "for life" choice.

+1

-eric
___
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

On Wed, Jul 18, 2018 at 2:43 AM Antoine Pitrou  wrote:
> Le 18/07/2018 à 04:02, Barry Warsaw a écrit :
> > A singular BDFL provides clear leadership.  With a council of elders, it 
> > will be more difficult to communicate both to the Python community, and to 
> > the larger, more peripheral user base, that any particular individual has 
> > the authority to make decisions.  Regardless of size, there would 
> > ultimately be some one person communicating any council decision.  There 
> > will inevitably be ambiguity as to the authority of said decision.
>
> Why do you think non-BDFL projects have a problem with """ambiguity as
> to the authority of said decision"""?  What is your basis for that
> assertion?
>
> I'm worried that you seem to be descending into magical thought,
> believing for some reason that nothing else than monarchy could ever
> work for a software project.

tl;dr  We worry too much :)

While I do not feel quite the same way on your point, Antoine, I'm
glad you brought this up.  A blanket policy of monarchy would be a
serious problem at the point that a BDFL goes "rogue".  However, a
blanket opposition to monarchy leads to its own problems.  Relative to
the BDFL's power, context is significant here.

There is apparently a lot of support (mine included) for Barry's
proposal.  However, we might be blinded, now and in general, to the
possibility of a rogue BDFL by the availability of good candidates
(that "clearly" would not go rogue) in the present and struggle to
imagine a time that there isn't such a candidate or that we were wrong
about them.  In fact, IIUC some reputable core devs do not feel like
there's any such candidate now (no disrespect, Brett), based on what
they expect a BDFL to be.  We need to respect that and consider that
viewpoint.  Regardless of when it happens (if ever), what will happen
in the future when we don't have anyone suitable?  One danger is that
we will install someone un-suitable because "we've always had a BDFL".
But what is that "danger"?  What impact could a rogue BDFL have?

Before diving in to that, consider that change has a directly
proportional relationship with disruption.  Disruption to any
organization has a pretty high cost, so the effect should be carefully
considered before deciding to make changes (which is what we're doing,
hopefully).  In our case, figuring out how to proceed
post-Guido-as-BDFL, we should make sure there's a good reason to
change our "governance model".  [Really quick: python-dev is rather
ad-hoc as an org, so calling it a "governance model" is a bit
misleading.]  We've been operating (successfully) for decades with a
BDFL.  As others have indicated, Python greatly owes its success to
having a BDFL.  Assuming we find a suitable replacement (I think we
can), why otherwise disrupt things?  "this is our chance to change so
we should" is an extremely weak argument on its own (and a dangerous
one), as is "monarchs are always bad".  There needs to be a stronger
reason (one that applies concretely to us).  Otherwise, at the least
"status quo wins a stalemate" here.  Arguably the best course of
action would be to change as little as possible.

All that said, I strongly affirm that we should not dismiss concerns
and differing opinions.  We need to consider them and be respectful.
We must resist the temptation to say "let's be real, that isn't
something we need to worry about".  That's why I'm glad you said what
you did, Antoine.  It made me think about a few aspects of the status
quo that may be worth addressing sooner rather than later.  Along
those lines, I consider the following questions to be significant.
I'll address them a little, but not conclusively.

1. what makes a good BDFL?
2. what do we do when we can't find a suitable candidate?
3. what negative impact can a BDFL have?
4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?

In my mind the key question is #3 (see my comments below).

--

1. what makes a good BDFL?

This is already being discussed in other threads, e.g. about the
"roles" of the BDFL.  I'll add that the BDFL is someone we trust to
lead Python into the future, even when it's hard and even when we
strongly disagree with them.  As a core team we rely on the BDFL to
help us make hard technical decisions.

However, I supposed I hadn't considered it before, but the BDFL has a
much more significant role.  The Python community is in many ways a
reflection of Guido and a result of his leadership (much more than
technical leadership).  Consequently, a new BDFL must be someone who
reflects where we want the community to be.

2. what do we do when we can't find a suitable candidate?

This is worth figuring out.  It isn't something we've discussed much.
I expect most folks feel like it will never be an issue.  I suppose
they're right.  At the point there isn't a suitable candidate, we have
larger problems to address. :)

3. what negative impact can a BDFL have?

I was primarily thinking about a

Re: [python-committers] An alternative governance model

2018-07-18 Thread M.-A. Lemburg

I find this discussion really interesting from a social perspective.
Let's keep it going for a while without jumping to any conclusions.
It's too early to head down into one particular rabbit hole yet ;-)

There's no rush and if things crystallize only in a year's time,
that's perfectly fine.

(And even better: We have Tim back with us for all that time to
entertain us :-))

Cheers.


On 18.07.2018 18:55, Tim Peters wrote:
> [Antoine Pitrou]
> 
>> At this point we are not talking about a majority vote.  All I see is a
>> rushed plebiscite on a single governance model and a single person.
>>
> 
> I view this as the "freewheeling brainstorming" initial part of the
> process.  We've barely even mentioned who the plebes may be - is it just
> committers who have a say?  If so, is that by definition precisely the
> members of this mailing list, or some broader or narrower definition?  Or
> also some subset of the 5 classes of PSF membership?  Etc.  And regardless
> of how someone wants to answer that, who decides on who gets to "vote" to
> begin with?  Under what authority?
> 
> IOW, we're several universes away from reaching a credible resolution.
> 
> In the meantime, a "+1" or "-1" from me really just means "let's keep this
> idea on the table" or "let's drop this one", respectively.  Which carries
> no actual weight at all.
> 
> It's valuable to push back against ideas you don't like, and I'm glad you
> are!

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jul 18 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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

On Jul 17, 2018, at 22:55, Kushal Das  wrote:

> +1 to this idea including Brett as BDFL. Though I am wondering if
> anyone asked Brett about it?

I know my email was long, so easy to overlook, but I did ask Brett and he 
didn’t immediately say no.  :)

-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] An alternative governance model

[Senthil Kumaran ]

> ...

Personally, just as a nitpick, I'd like to reserve the term BDFL to Guido,
> and choose a different term to signify the ultimate authority of the new
> leader.
>

Finally - an important issue ;-)

I submit instead that Monty Python would _certainly_ have kept the BDFL
title.  The irony of having at least two living BDFLs is just too exquisite
to resist :-)

But we can learn from other dictatorships too.  For example, one of Kim Il
Sung's many titles was "President".  It was important for his son to get
fancy titles too when he took over, so he was also called "President".  And
it was Kim Il Sung's title that changed, to "Eternal President".  That gave
him even more prestige.

If there can be only one BDFL, then Guido's title should change to EBDFL.
On his resume he can explain that means "Emeritus BDFL", but we'll all know
it means "Eternal BDFL" :-)
___
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

2018-07-18 Thread Senthil Kumaran

On Wed, Jul 18, 2018 at 9:38 AM, Antoine Pitrou  wrote:
>
> Le 18/07/2018 à 18:36, Łukasz Langa a écrit :
> >
> >
> > A simple majority vote is wildly insufficient for this case. Python is a
> large project with many contributors and alienating maybe tens of them is
> not acceptable, especially if we are talking about a "for life" choice.
>
> Thanks for saying this better than I could :-)
>

I supported Barry's proposal. I can definitely understand   Łukasz's and
Antoine's stance here.  One of the important part of Barry's proposal was
removal of "for life" part.

Most of us are volunteers contributing to python. A leader with ultimate
say on language design, governance burden to steer the comittee is going to
be challenging and stressful for "anyone" in this model proposed by Barry.

Thank you,
Senthil
___
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

[Antoine Pitrou]

> At this point we are not talking about a majority vote.  All I see is a
> rushed plebiscite on a single governance model and a single person.
>

I view this as the "freewheeling brainstorming" initial part of the
process.  We've barely even mentioned who the plebes may be - is it just
committers who have a say?  If so, is that by definition precisely the
members of this mailing list, or some broader or narrower definition?  Or
also some subset of the 5 classes of PSF membership?  Etc.  And regardless
of how someone wants to answer that, who decides on who gets to "vote" to
begin with?  Under what authority?

IOW, we're several universes away from reaching a credible resolution.

In the meantime, a "+1" or "-1" from me really just means "let's keep this
idea on the table" or "let's drop this one", respectively.  Which carries
no actual weight at all.

It's valuable to push back against ideas you don't like, and I'm glad you
are!
___
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

On 07/18/2018 09:36 AM, Łukasz Langa wrote:

On Jul 18, 2018, at 10:58 AM, Ethan Furman wrote:

If we, by majority vote, pick a governance model (dictator, council, or

>> whatever), then that legitimizes it.  If we, by majority vote, pick the
>> new BDFL, then that legitimizes it.  Being unhappy with the choice does
>> not make the choice illegitimate.

A simple majority vote is wildly insufficient for this case. Python is a

> large project with many contributors and alienating maybe tens of them is
> not acceptable, especially if we are talking about a "for life" choice.

Are you saying that we should use some method besides voting, or that a higher percentage of yea votes is required?  If 
the latter, I have no problem with 66% or 75%.

--
~Ethan~
___
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

2018-07-18 Thread Steve Dower


On 18Jul2018 0910, Antoine Pitrou wrote:


Le 18/07/2018 à 17:58, Ethan Furman a écrit :


If we, by majority vote, pick a governance model (dictator, council, or 
whatever), then that legitimizes it.  If we, by
majority vote, pick the new BDFL, then that legitimizes it.  Being unhappy with 
the choice does not make the choice
illegitimate.


At this point we are not talking about a majority vote.  All I see is a
rushed plebiscite on a single governance model and a single person.


The "plebiscite" is really about the question "should we *consider* 
appointing someone as NBDFL" - Barry's very first line of his email reads:



I’d like to propose an alternative model, and with it a succession plan, that 
IMHO hasn’t gotten enough discussion.  It’s fairly radical in that it proposes 
to not actually change that much!


The only thing I see happening now is sounding out opinions on the 
model. No decision is being taken yet.


Right now, I imagine Barry is testing the waters to see whether it's 
worth his time writing this up as a proposed PEP 2. Other people seem to 
be interested in also proposing alternative PEP 2s, and eventually we as 
a group will have to select one of them, no doubt by majority vote. And 
while Barry's long service to this group certainly adds weight to his 
opinion, it's also likely that we can filibuster for long enough until 
he retires and then ignore him completely :)


Your contributions to this part of the discussion are also very useful - 
we need to know what concerns people have, and often those concerns may 
not have occurred to those of us who approach it with a more idealistic 
idea of how everything will work out.


Nobody has really disputed the idea of codifying our new model as PEP 2. 
Until we have an actual text of PEP 2, I see no reason for concern that 
we are rushing anything.


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] An alternative governance model


Le 18/07/2018 à 18:36, Łukasz Langa a écrit :
> 
>> On Jul 18, 2018, at 10:58 AM, Ethan Furman  wrote:
>>
>> If we, by majority vote, pick a governance model (dictator, council, or 
>> whatever), then that legitimizes it.  If we, by majority vote, pick the new 
>> BDFL, then that legitimizes it.  Being unhappy with the choice does not make 
>> the choice illegitimate.
> 
> A simple majority vote is wildly insufficient for this case. Python is a 
> large project with many contributors and alienating maybe tens of them is not 
> acceptable, especially if we are talking about a "for life" choice.

Thanks for saying this better than I could :-)

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] An alternative governance model

> On Jul 18, 2018, at 10:58 AM, Ethan Furman  wrote:
> 
> If we, by majority vote, pick a governance model (dictator, council, or 
> whatever), then that legitimizes it.  If we, by majority vote, pick the new 
> BDFL, then that legitimizes it.  Being unhappy with the choice does not make 
> the choice illegitimate.

A simple majority vote is wildly insufficient for this case. Python is a large 
project with many contributors and alienating maybe tens of them is not 
acceptable, especially if we are talking about a "for life" choice.

- Ł

___
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] Language moratorium

>
> There is a de facto moratorium for the time being until a new governance
> model is chosen. Let's not formalize anything beyond that.


I agree.

Mariatta


On Wed, Jul 18, 2018 at 9:24 AM Łukasz Langa  wrote:

> There is a de facto moratorium for the time being until a new governance
> model is chosen. Let's not formalize anything beyond that.
>
> --
> Best regards,
> Łukasz Langa
>
> > On Jul 18, 2018, at 11:11 AM, Stefan Krah  wrote:
> >
> >
> > Hi,
> >
> > if I remember correctly, we had a moratorium for language changes around
> > versions 3.2-3.3.  I think during that time relatively few BDFL-level
> > decisions were required.
> >
> > Perhaps we could have one again, say for 12 months so we can figure
> things
> > out. Other Python implementations may welcome the moratorium so they can
> > catch up.
> >
> >
> > During that time we could just informally listen very closely to Guido if
> > anything requires a decision and he happens to be around. But there may
> be
> > no decisions at all.
> >
> > And yes, I guess we can successfully attempt to be nice, especially to
> him
> > (thanks for this wonderful language!).
> >
> >
> >
> > Stefan Krah
> >
> >
> >
> > ___
> > 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] Language moratorium

There is a de facto moratorium for the time being until a new governance model 
is chosen. Let's not formalize anything beyond that.

-- 
Best regards,
Łukasz Langa

> On Jul 18, 2018, at 11:11 AM, Stefan Krah  wrote:
> 
> 
> Hi,
> 
> if I remember correctly, we had a moratorium for language changes around
> versions 3.2-3.3.  I think during that time relatively few BDFL-level
> decisions were required.
> 
> Perhaps we could have one again, say for 12 months so we can figure things
> out. Other Python implementations may welcome the moratorium so they can
> catch up.
> 
> 
> During that time we could just informally listen very closely to Guido if
> anything requires a decision and he happens to be around. But there may be
> no decisions at all.
> 
> And yes, I guess we can successfully attempt to be nice, especially to him
> (thanks for this wonderful language!).
> 
> 
> 
> Stefan Krah
> 
> 
> 
> ___
> 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


Le 18/07/2018 à 17:58, Ethan Furman a écrit :
> 
> If we, by majority vote, pick a governance model (dictator, council, or 
> whatever), then that legitimizes it.  If we, by 
> majority vote, pick the new BDFL, then that legitimizes it.  Being unhappy 
> with the choice does not make the choice 
> illegitimate.

At this point we are not talking about a majority vote.  All I see is a
rushed plebiscite on a single governance model and a single person.

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] Language moratorium

2018-07-18 Thread Stefan Krah



Hi,

if I remember correctly, we had a moratorium for language changes around
versions 3.2-3.3.  I think during that time relatively few BDFL-level
decisions were required.

Perhaps we could have one again, say for 12 months so we can figure things
out. Other Python implementations may welcome the moratorium so they can
catch up.


During that time we could just informally listen very closely to Guido if
anything requires a decision and he happens to be around. But there may be
no decisions at all.

And yes, I guess we can successfully attempt to be nice, especially to him
(thanks for this wonderful language!).



Stefan Krah



___
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

On 07/18/2018 03:04 AM, Antoine Pitrou wrote:

Hi Ethan,

Le 18/07/2018 à 11:49, Ethan Furman a écrit :

You're creating a huge problem here. Whatever dictator you come up
with, not everyone will be ok with that choice. What are they supposed
to do? If one doesn't think X is legitimate as a dictator, how does one
keep contributing to the project? In other words, you are threatening
to exclude people, perhaps seasoned contributors.

I find this an empty argument. What were they supposed to do when PEPs they
wanted were rejected, and PEPs they thought
foolish accepted?

I'm not sure what you mean? I may disagree with my governement's
decisions without wanting to overthrow the whole regime (or, conversely,
I may agree with some of a despot's decisions without finding him
legitimate to make those decisions). Disagreeing with a PEP has nothing
to do with this discussion, has it?

If we, by majority vote, pick a governance model (dictator, council, or whatever), then that legitimizes it. If we, by
majority vote, pick the new BDFL, then that legitimizes it. Being unhappy with the choice does not make the choice
illegitimate.

If we go with a committee are we threatening to exclude those who
think design-by-committee is not a legitamate method, or don't think

>> it's members are legitimate choices?

If we're talking about a dictator (this is Barry's proposal), we're not
talking about someone that just makes language design decisions,

I was asking about how objecting to the currently chosen dictator would be any different from objecting to the currently
chosen council members.

as Victor pointed out.

Where did he point this out? I don't see an email, although I might just be
missing it.

--
~Ethan~
___
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

On Tue, Jul 17, 2018 at 8:15 PM Eric V. Smith  wrote:
> On 7/17/2018 10:02 PM, Barry Warsaw wrote:
> > I’d like to propose an alternative model, and with it a succession plan, 
> > that IMHO hasn’t gotten enough discussion.  It’s fairly radical in that it 
> > proposes to not actually change that much!
> >
> > TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors 
> > that helps the BDFL in various capacities, with additional 
> > responsibilities.  I also have someone specific in mind for the NBDFL, but 
> > you’ll have to read on for the big reveal.
>
> I've come to this same conclusion. I think Brett would be a good choice,
> and I'd support him, but I think the more important part is that it be a
> single person.

+1

IMHO, if we can have someone we can trust then a BDFL is the best
option.  Brett definitely fits that criteria for me. (Plus Canadians
are "Benevolent" by definition, right?)  Barry's proposal to have the
council supporting (and guarding against) the BDFL gives the proposal
better stability in the face of the unknown future.

-eric
___
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


On 07/17/2018 07:02 PM, Barry Warsaw wrote:


TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors

> that helps the BDFL in various capacities, with additional responsibilities.

Having a singular BDFL certainly has its advantages, and from my interactions with Brett I certainly would have no 
qualms about supporting him in that role.


More in-line devil's advocate comments below.


A singular BDFL provides clear leadership.  With a council of elders, it will 
be more difficult to communicate both to the Python community,
> and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. 
Regardless of size, there
> would ultimately be some one person communicating any council decision.  There will inevitably be ambiguity as to the 
authority of said decision.
> How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can 
speak authoritatively on
> decisions for the language?  “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably 
authoritative than “Alice Jones, BDFL”.


If the council appointments are for life, it shouldn't take too long to figure 
out.


This also comes into play for shutting down discussions early.  With a 
committee, it’s possible that you’ll have some disagreement among the
> members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change 
fits into the overall
> direction for Python’s evolution.  Alice Jones may say “No, that’s not gonna happen” only to be overruled or 
undermined by Bob Smith’s “That’s

> a good idea”.

I suspect that will occasionally happen -- I don't know that it's a big enough issue to make the NBDFL model the obvious 
choice.



Taken together, these fall under the umbrella of having one voice for the 
decision making process.  It may be possible for consensus within the
> council to come across as a single voice, but I think it will generally be harder.  A council also opens the door for 
more back-channel lobbying

> of a sympathetic member.  Yes, such lobbying is possible with a BDFL, but at 
least there should be less contention.

I think this is the crux of the argument:  getting a group of people, even a small one, to agree on a singular vision 
can be very difficult.



I also think a council will be much more risk adverse than a singular BDFL, and 
that’s not necessarily a good thing.  While moratoriums and a more
> conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a 
specific purpose, rather than
> the unintended outcome of groupthink or lack of consensus.  A singular BDFL with support from the community will have 
more authority to make
> decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of 
consensus or internal bickering.


Community support can be mercurial, and should not be relied upon as an 
underpinning of our governance model.


Will a council be able to articular, express, communicate, adapt, and follow 
through on that vision?  Will a council be able to evaluate a proposed
> change as it supports or detracts from that vision?  Will a council be able to break out of a primarily maintenance 
position, to actually move the

> language and its primary implementation forward?  I’m not so sure.

I am sure that those questions will be difficult for a BDFL, a council, a 
membership majority, or whatever system we choose.


The formation of a formal Council is still a good idea!  I just think that it 
shouldn’t be the ultimate arbiter of decisions for Python.  So what

> would the Council do?


- It would serve as a check on the BDFL.  If Bob Smith were one day employed by 
Evil Corp. and started making decisions that were directly detrimental
> to Python, the council should be able to effectively impeach.  There should be checks and balances on this power, the 
BDFL shouldn’t continuously fear
> a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for 
when the BDFL is abusing their

> power.

In other words, a more complicated tyranny of the majority.


- The council would select the next BDFL if and when that time comes.  No one 
will serve forever, so a clear succession plan should be in place.
>  To avoid the tyranny of the majority, the council would serve similarly to a board of directors.  They’d search for 
candidates, match them against

> well defined criteria, conduct interviews, serve as the voice of the 
community, and eventually select the N+1BDFL.

Why should the council have that power?  If the core-devs are selecting the NBDFL now, I see no reason why we shouldn't 
in the future as well.



- The council would serve as trusted advisors to the NBDFL.  The BDFL won’t be 
out there all alone!  The council will provide advice when requested,

> and back up

Re: [python-committers] An alternative governance model


Hi Ethan,

Le 18/07/2018 à 11:49, Ethan Furman a écrit :
>>
>> You're creating a huge problem here.  Whatever dictator you come up
>> with, not everyone will be ok with that choice.  What are they supposed
>> to do?  If one doesn't think X is legitimate as a dictator, how does one
>> keep contributing to the project?  In other words, you are threatening
>> to exclude people, perhaps seasoned contributors.
> 
> I find this an empty argument.  What were they supposed to do when PEPs they 
> wanted were rejected, and PEPs they thought 
> foolish accepted?

I'm not sure what you mean?  I may disagree with my governement's
decisions without wanting to overthrow the whole regime (or, conversely,
I may agree with some of a despot's decisions without finding him
legitimate to make those decisions).  Disagreeing with a PEP has nothing
to do with this discussion, has it?

> If we go with a committee are we threatening to exclude those who
think design-by-committee is not a
> legitamate method, or don't think it's members are legitimate choices?

If we're talking about a dictator (this is Barry's proposal), we're not
talking about someone that just makes language design decisions, as
Victor pointed out.

Or if it is what we're talking about, the name is ill-chosen :-)

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] An alternative governance model

On 07/18/2018 01:43 AM, Antoine Pitrou wrote:

Le 18/07/2018 à 04:02, Barry Warsaw a écrit :

If you’ve read this far - thank you! Now for the big reveal. I think the

>> Next BDFL should be… (drum roll)…

Brett Cannon

Since you're opening this can of worms, I'll say it:

- I'm -1 on a new dictator-for-life (*)
- I'm -1 on Brett Cannon as a new dictator-for-life

I find this an empty argument. What were they supposed to do when PEPs they wanted were rejected, and PEPs they thought
foolish accepted? If we go with a committee are we threatening to exclude those who think design-by-committee is not a
legitamate method, or don't think it's members are legitimate choices?

No, we are not threatening anybody. The core-devs will make their choice, and those who don't like the result can leave
or go as they will.

(*) (I'm leaving the "benevolent" part out, since clearly it was only
tied to Guido's personality, not to any inherent statutory limitations)

I think that's a mistake. Clearly, the "benevolent" part is a major criteria for the dictator, triumvirate, CoE, or
whatever we come up with, and Guido is not the only benevolent core-dev we have.

I’ve long said — somewhat in jest, since I never expected Guido to actually

>> ever retire! — that Brett would be my choice for the next BDFL. I think he’s
>> the perfect candidate, and he’s already demonstrated qualities that I think
>> make him a fantastic leader.

I beg to disagree, Barry. Brett is a good contributor, that doesn't
make him legitimate as a dictator. Only Guido could be, and he has
stepped down.

I agree: being a good contributor does not ipso facto make for a good
benevolent dictator.

I disagree that only Guido could be a good BDFL. I do agree that good BDFLs
are rare.

The amount of cheerleading here ("""smart, compassionate, passionate,
respectful, young, tall, and has the right mix of technical excellence
and social skills""") is embarrassing. What if we don't subscribe to
your views of Brett's qualities: do you expect us to publicly criticize
Brett so as to justify our opposition?

I think one can oppose the NBDFL model without criticizing the proposed candidate. After all, if the model is rejected
it doesn't matter who the candidates were. If the model is accepted, then I think a simple "I disagree with your
assessment" would suffice, and you could nominate someone you felt was more qualified.

--
~Ethan~
___
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