subject:"\[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] An alternative governance model

2018-07-18 Thread Łukasz Langa

> 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/

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

2018-07-18 Thread Mariatta Wijaya

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

2018-07-18 Thread Tim Peters

[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/

[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

2018-07-18 Thread Łukasz Langa

> 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

2018-07-18 Thread Tim Peters

[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

2018-07-18 Thread Tim Peters

[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

2018-07-18 Thread Łukasz Langa

> 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] 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/

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