Re: [python-committers] Transfer of power

[Paul Moore]

On 12 July 2018 at 15:57, Guido van Rossum  wrote:
> But I'm basically giving myself a permanent vacation from being BDFL, and you 
> all will be on your own.

I just want to echo everyone else's sentiments and say thank you for
all the work you've done, and for the example you've set to all of us.
Like many others here, my life would have been quite different without
Python. Even though I've never met you in person, you've been a huge
influence for me.

Best wishes for the future.
Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Anthony Baxter]

As someone who's not been involved for some time now, but was release
manager for a three or four years (2.3.1 through to 2.5.1), trying to have
the release manager also be a decider of potentially controversial things
doesn't seem scalable.

Getting a release out is a heck of a lot of work, both the actually cutting
the alphas, betas, &c, and also triaging issues that comes up and chasing
people up for fixes.

I'm not sure what the proper governance structures should be, but they
absolutely shouldn't be dumping extra load onto the release manager.

On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann  wrote:

> Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:
> > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou 
> wrote:
> > >
> > >
> > > I'd like to point out that the N-virate idea doesn't handle a key
> issue:
> > > once you have a N-virate, how do you evolve its composition according
> to
> > > the implication and motivation of its members - but also to remarks or
> > > frustation by non-virate contributors (especially new contributors who
> > > will feel there's a perpetual category they're locked out of)?  Do you
> > > just wait for people to gently step down when required?
> >
> > One way would be to re-elect them every 5 or so years.  Essentially,
> > an N-virate is a dictator-like entity for a few years.
> >
> > Yury
>
> We've had good luck in the OpenStack community tying leadership to
> release cycles. It causes elections more often (our cycles are 6
> months long), but people tend to step up for several cycles in a
> row so that hasn't been a cause of excessive turnover. Having
> frequent opportunities for folks to step down gracefully when they
> need or want to also means no one feels like they are signing up
> for an indefinite time commitment.
>
> For a multi-person group, staggered elections where only a portion
> of the group is up for election at one time, also provides some
> consistency when there is turnover.
>
> 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/
>
___
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] Identify roles of the BDFL

[Victor Stinner]

Hi,

2018-07-12 19:12 GMT+02:00 Mariatta Wijaya :
> What is the role of the successor(s)? Do we assume "whatever Guido did", or
> is this an opportunity to come up with a new process?
>
> One useful resource is Vicky Brasseur's talk: Passing the Baton, Succession
> planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8
> The slides:
> https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf
>
> Some ideas from that talk:
> 1. identify critical roles (e.g. PEP decision making)
> 2. refactor large roles
> 3. mentor the new successor, shadow the previous leader
> 4. document all the things

I liked this talk! (I attended it at FOSDEM)

To be able to replace the BDFL, IMHO first we need to define what are
the roles of the BDFL. I also think that it's an opportunity to split
the big central BDFL role into sub-roles: delegate some roles to
multiple people.

Let me try to list roles of the BDFL:

* Take a decision/PEP. For a Python change (usually a PEP), when they
are two good solutions and we fail to find a consensus, the BDFL
chooses his favorite solution. Usually, when the BDFL pronounces,
everybody has to follow his choice.

* PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL
final decision only comes after weeks of discussions and when there is
already a kind of consensus (usually in favor of the PEP, otherwise
the PEP is abandonned earlier). For example, python-ideas list already
works well to reject ideas which should obviously be rejected for
whatever reason. Sometimes when the consensus is to reject the PEP,
the BDFL officially rejects it.

* Public Relations. The BDFL is our reference for the Public
Relations. We like to ask our BDFL what is his vision for the next 5
years, even if he usually say that he doesn't know and he is usually
not the one who propose new ideas :-)

* Community? In case of conflict between two developers, sometimes the
BDFL tries to solve the conflict. I'm not sure that it's an official
role of the BDFL :-)

* Community. (Here I will maybe speak for myself.) The BDFL is my
reference for the right level of humour and right level of tone (on
mailing lists and other medias). When the tone goes bad, sometimes the
BDFL speaks up to cool down the discussion.

* Language. The BDFL is our designer for the Python language. I would
like to generalize this definition to the general "taste" of Python:
the BDFL defines what is "pythonic" or not by blessing some coding
styles and blessing some new syntaxes. It's wider than just the pure
grammar of the language.

* Diversity. Last years, the BDFL was a strong player to enhance the
diversity of core developers and contributors by mentoring directly
Mariatta Wijaya, and suggesting regularly to mentor more people from
minorities whenever possible. He also likes to wear PyLadies t-shirt
and support DjangoGirls ;-)


Maybe it would also help if we list what the BDFL is not:

* The BDFL is no longer the technical reference to review
implementation changes. IMHO other people took this role somewhere
between Python 1.0 and Python 3.7. As it has been said in the other
thread, there are known experts in some areas of the Python which
requires specific skills. For example, Yury Selivanov is my reference
for asyncio. Well, that's a bad example, since Guido van Rossum ("as a
developer, not as the BDFL") is my second reference here :-)

* IMHO the BDFL is not the single one to decide to promote a
contributor as a core developer. It seems like our process using a
vote on python-committers works. I'm not sure that the process is
perfect, but at least, I don't see the BDFL here as the central key to
take a decision.


These list are likely incomplete, don't hesitate to complete them :-)


The question is now if a single people or a single small group of
people should get all these roles? Or if we can distribute these roles
to multiple people? Moreover, do all these tasks still need a BDFL?
For example, do we need a diversity BDFL?

IMHO the most critical roles of the BDFL is to design the language and
take decisions on PEPs.


To follow Vicky's talk, the second step is: "2. refactor large roles".

Should we split the role "take the final decision on PEPs" into
sub-roles for example? Do we need in advance to define BDFL-delegate
for some kinds of PEPs? Or the BDFL should define per-PEP, which ones
he doesn't want to handle and need a BDFL-delegate? In my experience,
the BDFL delegation was done naturally, was not the source of
conflict, and usually discussed directly with the BDFL.

--

By the way, I already started to work on "1. identify critical roles
(e.g. PEP decision making)" a few months ago, not directly for the
BDFL roles, but more generally on "maintenance tasks" and what are the
key responsibilities in Python:

http://pythondev.readthedocs.io/maintenance_tasks.html

Victor
___
python-committers mailing list
python

[python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Nathaniel Smith]

On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa  wrote:
> I'm +1 to an Informational PEP around the state of the art in project 
> governance.

I think this is a great idea. There's a lot of experience out there on
different governance models, but of course any given project only uses
one of them, so knowledge about what works and what doesn't is pretty
fragmented across the F/OSS community. And this is a really important
decision for us and our users, so we should do due diligence. For
example, we should think this through at least as carefully as we
thought through Github vs. Gitlab :-). A PEP is a good format to start
doing that.

I volunteer to co-author such a PEP. But I'm not up to doing it on my
own. So... who else wants to be a co-author? (I'm not going to
pressure anyone, but Brett, Mariatta, and Carol, please know that your
names were the first ones that jumped to my mind when thinking about
this :-).)

What I'm thinking:

- While this might eventually produce some recommendations, the
immediate goal would just be to collect together different options and
ideas and point out their trade-offs. I'm guessing most core devs
aren't interested in becoming experts on open-source governance, so
the goal here would be to help the broader community get up to speed
and have a more informed discussion [1].

- As per the general PEP philosophy, I think this is best done by
having some amount of general discussion on
python-dev/python-committers, plus a small group of coauthors (say 2-4
people) who take responsibility for filtering ideas and organizing
them in a coherent document.

- Places where we'll want to look for ideas:
  - The thread already happening on python-committers
  - Whatever books / articles / blog posts / etc. we can find (e.g. I
know Karl Fogel's Producing OSS book has some good discussion)
  - Other major projects in a similar position to CPython (e.g.,
node.js, Rust) -- what do they do, and what parts are they
happy/not-happy about?
  - Large Python projects (e.g. Django) -- likewise

If you have suggestions for particularly interesting projects or
excellent writing on the topic, then this thread would be a good place
to mention them.

-n

[1] The NumPy project has put a lot of energy into working through
governance issues over the last few years, and one thing that
definitely helped was coming up with some "assigned reading" ahead of
the main sprint where we talked about this. NumPy's problems are/were
pretty different from CPython's, but I'm imagining this PEP as filling
a similar role.

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

Re: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Antoine Pitrou]

Le 13/07/2018 à 13:31, Nathaniel Smith a écrit :
> 
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)

I don't know how much time I'll be able to devote to it, but feel free
to enlist me.

> If you have suggestions for particularly interesting projects or
> excellent writing on the topic, then this thread would be a good place
> to mention them.

Perhaps Apache httpd? (or some other major Apache project, since I
/think/ they share similar governance structures... I happen to work on
Apache Arrow, which is young and a bit on the small side compared to
Python, but can ask the project leaders for feedback)

Regards

Antoine.


> 
> What I'm thinking:
> 
> - While this might eventually produce some recommendations, the
> immediate goal would just be to collect together different options and
> ideas and point out their trade-offs. I'm guessing most core devs
> aren't interested in becoming experts on open-source governance, so
> the goal here would be to help the broader community get up to speed
> and have a more informed discussion [1].
> 
> - As per the general PEP philosophy, I think this is best done by
> having some amount of general discussion on
> python-dev/python-committers, plus a small group of coauthors (say 2-4
> people) who take responsibility for filtering ideas and organizing
> them in a coherent document.
> 
> - Places where we'll want to look for ideas:
>   - The thread already happening on python-committers
>   - Whatever books / articles / blog posts / etc. we can find (e.g. I
> know Karl Fogel's Producing OSS book has some good discussion)
>   - Other major projects in a similar position to CPython (e.g.,
> node.js, Rust) -- what do they do, and what parts are they
> happy/not-happy about?
>   - Large Python projects (e.g. Django) -- likewise
> 
> 
> -n
> 
> [1] The NumPy project has put a lot of energy into working through
> governance issues over the last few years, and one thing that
> definitely helped was coming up with some "assigned reading" ahead of
> the main sprint where we talked about this. NumPy's problems are/were
> pretty different from CPython's, but I'm imagining this PEP as filling
> a similar role.
> 
___
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] Transfer of power

[Doug Hellmann]

Oh, yeah, I guess I wasn’t clear there. I am not suggesting that release 
managers add this new responsibility. I’m suggesting that a release cycle 
length is an amount of time the community is used to dealing with, and 
therefore might make a good cadence for elections or whatever other rotation 
mechanism is selected for the new group.

Sorry for the confusion.

Doug

> On Jul 13, 2018, at 5:30 AM, Anthony Baxter  wrote:
> 
> As someone who's not been involved for some time now, but was release manager 
> for a three or four years (2.3.1 through to 2.5.1), trying to have the 
> release manager also be a decider of potentially controversial things doesn't 
> seem scalable. 
> 
> Getting a release out is a heck of a lot of work, both the actually cutting 
> the alphas, betas, &c, and also triaging issues that comes up and chasing 
> people up for fixes.
> 
> I'm not sure what the proper governance structures should be, but they 
> absolutely shouldn't be dumping extra load onto the release manager.
> 
> On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann  > wrote:
> Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:
> > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou  > > wrote:
> > >
> > >
> > > I'd like to point out that the N-virate idea doesn't handle a key issue:
> > > once you have a N-virate, how do you evolve its composition according to
> > > the implication and motivation of its members - but also to remarks or
> > > frustation by non-virate contributors (especially new contributors who
> > > will feel there's a perpetual category they're locked out of)?  Do you
> > > just wait for people to gently step down when required?
> > 
> > One way would be to re-elect them every 5 or so years.  Essentially,
> > an N-virate is a dictator-like entity for a few years.
> > 
> > Yury
> 
> We've had good luck in the OpenStack community tying leadership to
> release cycles. It causes elections more often (our cycles are 6
> months long), but people tend to step up for several cycles in a
> row so that hasn't been a cause of excessive turnover. Having
> frequent opportunities for folks to step down gracefully when they
> need or want to also means no one feels like they are signing up
> for an indefinite time commitment.
> 
> For a multi-person group, staggered elections where only a portion
> of the group is up for election at one time, also provides some
> consistency when there is turnover.
> 
> 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/ 
> 

___
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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Doug Hellmann]

Excerpts from Nathaniel Smith's message of 2018-07-13 04:31:00 -0700:
> On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa  wrote:
> > I'm +1 to an Informational PEP around the state of the art in project 
> > governance.
> 
> I think this is a great idea. There's a lot of experience out there on
> different governance models, but of course any given project only uses
> one of them, so knowledge about what works and what doesn't is pretty
> fragmented across the F/OSS community. And this is a really important
> decision for us and our users, so we should do due diligence. For
> example, we should think this through at least as carefully as we
> thought through Github vs. Gitlab :-). A PEP is a good format to start
> doing that.
> 
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)
> 
> What I'm thinking:
> 
> - While this might eventually produce some recommendations, the
> immediate goal would just be to collect together different options and
> ideas and point out their trade-offs. I'm guessing most core devs
> aren't interested in becoming experts on open-source governance, so
> the goal here would be to help the broader community get up to speed
> and have a more informed discussion [1].
> 
> - As per the general PEP philosophy, I think this is best done by
> having some amount of general discussion on
> python-dev/python-committers, plus a small group of coauthors (say 2-4
> people) who take responsibility for filtering ideas and organizing
> them in a coherent document.
> 
> - Places where we'll want to look for ideas:
>   - The thread already happening on python-committers
>   - Whatever books / articles / blog posts / etc. we can find (e.g. I
> know Karl Fogel's Producing OSS book has some good discussion)
>   - Other major projects in a similar position to CPython (e.g.,
> node.js, Rust) -- what do they do, and what parts are they
> happy/not-happy about?
>   - Large Python projects (e.g. Django) -- likewise
> 
> If you have suggestions for particularly interesting projects or
> excellent writing on the topic, then this thread would be a good place
> to mention them.

I would be happy to contribute based on the experiences we've had
with different leadership models in OpenStack.

Doug

> 
> -n
> 
> [1] The NumPy project has put a lot of energy into working through
> governance issues over the last few years, and one thing that
> definitely helped was coming up with some "assigned reading" ahead of
> the main sprint where we talked about this. NumPy's problems are/were
> pretty different from CPython's, but I'm imagining this PEP as filling
> a similar role.
> 
___
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] Identify roles of the BDFL

[Victor Stinner]

2018-07-13 12:40 GMT+02:00 Victor Stinner :
> * Take a decision/PEP. For a Python change (usually a PEP), when they
> are two good solutions and we fail to find a consensus, the BDFL
> chooses his favorite solution. Usually, when the BDFL pronounces,
> everybody has to follow his choice.
>
> * PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL
> final decision only comes after weeks of discussions and when there is
> already a kind of consensus (usually in favor of the PEP, otherwise
> the PEP is abandonned earlier). For example, python-ideas list already
> works well to reject ideas which should obviously be rejected for
> whatever reason. Sometimes when the consensus is to reject the PEP,
> the BDFL officially rejects it.

Let me elaborate this part. One quality of the BDFL (Guido) is to take
unpopular decision when he knows that it is the right choice.

Some examples:

* PEP 572: assignment expressions.

* The PEP 446 "Make newly created file descriptors non-inheritable"
was supposed to break the world... Well, it occurred and almost nobody
noticed this Python 3.4 change... I like what Guido wrote on my PEP
with humor: "We are aware of the code breakage this is likely to
cause, and doing it anyway for the good of mankind." :-)

* Yury mentioned async/await keywords.

* Add your own example.

Well, maybe this "responsibility" goes against my idea of voting on
PEPs :-) ("popularity contest")

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] Identify roles of the BDFL

[Antoine Pitrou]

Le 13/07/2018 à 18:36, Victor Stinner a écrit :
> 
> Let me elaborate this part. One quality of the BDFL (Guido) is to take
> unpopular decision when he knows that it is the right choice.
> 
> Some examples:
> 
> * PEP 572: assignment expressions.
> 
> * The PEP 446 "Make newly created file descriptors non-inheritable"
> was supposed to break the world... Well, it occurred and almost nobody
> noticed this Python 3.4 change... I like what Guido wrote on my PEP
> with humor: "We are aware of the code breakage this is likely to
> cause, and doing it anyway for the good of mankind." :-)
> 
> * Yury mentioned async/await keywords.
> 
> * Add your own example.
> 
> Well, maybe this "responsibility" goes against my idea of voting on
> PEPs :-) ("popularity contest")

Of the three you mention, only PEP 572 would have been controversial
enough to fail a vote, IMO.

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] possible future PEP discussion format [was: Transfer of power]

[Ethan Furman]

On 07/12/2018 01:27 PM, Raymond Hettinger wrote:


For the bigger decisions (and there aren't many coming up), I have some

> suggestions on ways to improve the discussions so that the interested
> parties can have a more equal say in the outcome and so that the
> discussions can be more time efficient (it takes too much time to keep-up
> with long-running, active threads).


Essentially the idea would be have a wiki/faq editable by all the

> participants. It would include the key examples, arguments for and against,
> and rebuttals which can be collected into a current-state-of-the-conversation.
> This would be somewhat different than the current PEP process because
> currently PEP authors dominate the conversation and others can get drowned
> out too easily.  (This idea is modeled on the California Legislative Analyst
> Voters Guide which summarizes proposals and has statements and rebuttals from
> both proponents and opponents).

I really like this idea.  I stopped reading the PEP 572 threads once it was painfully obvious that almost all new 
replies were just saying the same things over and over and over...


--
~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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Brett Cannon]

On Fri, 13 Jul 2018 at 04:31 Nathaniel Smith  wrote:

> On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa  wrote:
> > I'm +1 to an Informational PEP around the state of the art in project
> governance.
>
> I think this is a great idea. There's a lot of experience out there on
> different governance models, but of course any given project only uses
> one of them, so knowledge about what works and what doesn't is pretty
> fragmented across the F/OSS community. And this is a really important
> decision for us and our users, so we should do due diligence. For
> example, we should think this through at least as carefully as we
> thought through Github vs. Gitlab :-). A PEP is a good format to start
> doing that.
>
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)
>

Thanks for thinking of me, but I actually already have a governance model
that I want to propose so I don't think I could be viewed as impartial when
gathering details on other approaches.



>
> What I'm thinking:
>
> - While this might eventually produce some recommendations, the
> immediate goal would just be to collect together different options and
> ideas and point out their trade-offs. I'm guessing most core devs
> aren't interested in becoming experts on open-source governance, so
> the goal here would be to help the broader community get up to speed
> and have a more informed discussion [1].
>
> - As per the general PEP philosophy, I think this is best done by
> having some amount of general discussion on
> python-dev/python-committers, plus a small group of coauthors (say 2-4
> people) who take responsibility for filtering ideas and organizing
> them in a coherent document.
>
> - Places where we'll want to look for ideas:
>   - The thread already happening on python-committers
>   - Whatever books / articles / blog posts / etc. we can find (e.g. I
> know Karl Fogel's Producing OSS book has some good discussion)
>   - Other major projects in a similar position to CPython (e.g.,
> node.js, Rust) -- what do they do, and what parts are they
> happy/not-happy about?
>   - Large Python projects (e.g. Django) -- likewise
>

So are you thinking an informational PEP that does a general survey of
other projects and how they handle things? If so then I think that would be
interesting to have even for other projects looking for this kind of
information.

My suspicion is when we all decide it's time to make a decision that we
will have a call for PEPs on governance models and then we will choose from
those. So in that situation I would view this initial PEP as information
gathering for those that want an idea of what preexisting approaches there
are before working towards a concrete proposal. That sounds about right?


>
> If you have suggestions for particularly interesting projects or
> excellent writing on the topic, then this thread would be a good place
> to mention them.
>

Someone privately suggested Kafka to me, but I think that's partially
because Kafka is apparently about to propose a release and the person
follows its development.

-Brett


>
> -n
>
> [1] The NumPy project has put a lot of energy into working through
> governance issues over the last few years, and one thing that
> definitely helped was coming up with some "assigned reading" ahead of
> the main sprint where we talked about this. NumPy's problems are/were
> pretty different from CPython's, but I'm imagining this PEP as filling
> a similar role.
>
> --
> 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/

[python-committers] possible future PEP discussion format [was: Transfer of power]

[Ethan Furman]

On 07/12/2018 01:27 PM, Raymond Hettinger wrote:

> For the bigger decisions (and there aren't many coming up), I have some
> suggestions on ways to improve the discussions so that the interested
> parties can have a more equal say in the outcome and so that the
> discussions can be more time efficient (it takes too much time to keep-up
> with long-running, active threads).
>
> Essentially the idea would be have a wiki/faq editable by all the
> participants. It would include the key examples, arguments for and against,
> and rebuttals which can be collected into a current-state-of-the-conversation.
> This would be somewhat different than the current PEP process because
> currently PEP authors dominate the conversation and others can get drowned
> out too easily.  (This idea is modeled on the California Legislative Analyst
> Voters Guide which summarizes proposals and has statements and rebuttals from
> both proponents and opponents).

I really like this idea.  I stopped reading the PEP 572 threads once it was painfully obvious that almost all new 
replies were just saying the same things over and over and over...


--
~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] Identify roles of the BDFL

[Brett Cannon]

On Fri, 13 Jul 2018 at 03:44 Victor Stinner  wrote:

> Hi,
>
> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya :
> > What is the role of the successor(s)? Do we assume "whatever Guido did",
> or
> > is this an opportunity to come up with a new process?
> >
> > One useful resource is Vicky Brasseur's talk: Passing the Baton,
> Succession
> > planning for your project https://www.youtube.com/watch?v=Jhkm2PA_Gf8
> > The slides:
> >
> https://ia800809.us.archive.org/2/items/pyconau2017-successionplanning/03-pyconau2017-successionplanning-with_notes.pdf
> >
> > Some ideas from that talk:
> > 1. identify critical roles (e.g. PEP decision making)
> > 2. refactor large roles
> > 3. mentor the new successor, shadow the previous leader
> > 4. document all the things
>
> I liked this talk! (I attended it at FOSDEM)
>
> To be able to replace the BDFL, IMHO first we need to define what are
> the roles of the BDFL. I also think that it's an opportunity to split
> the big central BDFL role into sub-roles: delegate some roles to
> multiple people.
>
> Let me try to list roles of the BDFL:
>
> * Take a decision/PEP. For a Python change (usually a PEP), when they
> are two good solutions and we fail to find a consensus, the BDFL
> chooses his favorite solution. Usually, when the BDFL pronounces,
> everybody has to follow his choice.
>
> * PEP. The BDFL takes the final decision on a PEP. Usually, the BDFL
> final decision only comes after weeks of discussions and when there is
> already a kind of consensus (usually in favor of the PEP, otherwise
> the PEP is abandonned earlier). For example, python-ideas list already
> works well to reject ideas which should obviously be rejected for
> whatever reason. Sometimes when the consensus is to reject the PEP,
> the BDFL officially rejects it.
>

I view the first and second points as basically the same. This is the role
of final arbiter of PEP acceptance.


>
> * Public Relations. The BDFL is our reference for the Public
> Relations. We like to ask our BDFL what is his vision for the next 5
> years, even if he usually say that he doesn't know and he is usually
> not the one who propose new ideas :-)
>
> * Community? In case of conflict between two developers, sometimes the
> BDFL tries to solve the conflict. I'm not sure that it's an official
> role of the BDFL :-)
>
> * Community. (Here I will maybe speak for myself.) The BDFL is my
> reference for the right level of humour and right level of tone (on
> mailing lists and other medias). When the tone goes bad, sometimes the
> BDFL speaks up to cool down the discussion.
>

While Guido played this role, I don't think that necessarily plays into
governance. I suspect, though, that if we choose some council structure
then those people will act as the public face of the team overall to help
project the tone we hope to set overall. IOW I don' think we can
appointment the head of humour (although if we do I'm nominating Tim ;) .


>
> * Language. The BDFL is our designer for the Python language. I would
> like to generalize this definition to the general "taste" of Python:
> the BDFL defines what is "pythonic" or not by blessing some coding
> styles and blessing some new syntaxes. It's wider than just the pure
> grammar of the language.
>

This is the other key part of the BDFL. I have always viewed Guido's BDFL
role on PEPs to be an initial yea/nay, and then either delegating with some
guiding words to a person who has domain expertise for a technical PEP or
to make a pronouncement for a design-related PEP that isn't technical (e.g.
function expressions).


>
> * Diversity. Last years, the BDFL was a strong player to enhance the
> diversity of core developers and contributors by mentoring directly
> Mariatta Wijaya, and suggesting regularly to mentor more people from
> minorities whenever possible. He also likes to wear PyLadies t-shirt
> and support DjangoGirls ;-)
>

I lump this into the community and PR bucket as I don't know if we need to
be worrying about appointing a head of diversity right now as that doesn't
tie into governance. If, once this is all over, we want to take our
diversity efforts to another level then a diversity SIG could be formed,
but I don't see this as a BDFL thing and more of a team thing that someone
choose to spearhead.

-Brett


>
> Maybe it would also help if we list what the BDFL is not:
>
> * The BDFL is no longer the technical reference to review
> implementation changes. IMHO other people took this role somewhere
> between Python 1.0 and Python 3.7. As it has been said in the other
> thread, there are known experts in some areas of the Python which
> requires specific skills. For example, Yury Selivanov is my reference
> for asyncio. Well, that's a bad example, since Guido van Rossum ("as a
> developer, not as the BDFL") is my second reference here :-)
>
> * IMHO the BDFL is not the single one to decide to promote a
> contributor as a core developer. It seems like our process using a
> vote on python-committe

Re: [python-committers] possible future PEP discussion format [was: Transfer of power]

[Ethan Furman]

On 07/13/2018 11:21 AM, Ethan Furman wrote:

[...]

Sorry, was trying to generate a new thread.  Please respond to that one instead.

--
~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] possible future PEP discussion format [was: Transfer of power]

[Neil Schemenauer]

On 2018-07-13, Ethan Furman wrote:
> I stopped reading the PEP 572 threads once it was painfully
> obvious that almost all new replies were just saying the same
> things over and over and over...

Perhaps this can be seen as a kind of economic problem.  What is the
cost of posting to a PEP discussion thread vs the cost of everyone
reading that post?  Or, what is the value of the comment vs what is
cost for everyone to read it?

With the current discussion method, the costs are often
disproportionate. You have hundreds of people reading the thread.
So that cost is pretty high.  Posting a half-baked comment is too
easy.  Starting a new thread with a new subject line is too easy.

One idea is to have a list dedicated to PEP discussions.  We could
establish a set of rules (cultural norms) for discussion on that
list.  E.g.

- do your background research before posting: read PEP in its
  entirety, read complete PEP discussion thread

- make high quality posts: ensure your points are truly bringing new
  ideas forth, present them clearly and succinctly

- lay down rules for subject lines of posts, when you can start a
  new thread.  Off topic discussion should go back to python-ideas.

python-ideas can remain a free-wheeling wild west.  Make the PEP
discussion list a formal discussion forum.  If people don't follow
the rules, warn them and ultimately ban them from the list.

Thinking about subject line rules, it would be helpful to organize
threads by PEP, by topic and sub-topic.  E.g.

PEP 572: R: informal educator feedback
PEP 572: S: comprehension scope
PEP 572: S: operator precedence of :=

Possible topic abbreviations:

R: Rationale
S: Syntax and semantics
E: Examples

Regards,

  Neil
___
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] Transfer of power

[Jack Jansen]

A wild idea:

How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, and 
actually the “3” isn’t important either) where unanimity is required for 
language changes (i.e. basically for accepting a PEP)?

A unanimity requirement will inevitably lead to more conservative decisions, 
but that may be a good thing...
--
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] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 15:11, Jack Jansen  wrote:
> 
> How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, 
> and actually the “3” isn’t important either) where unanimity is required for 
> language changes (i.e. basically for accepting a PEP)?

Possibly, but even if unanimity can’t be achieved, I feel strongly that any 
decision coming from the GUIDO/Cabal/Council should be give as a single party.  
E.g. if Alice and Bob +1 PEP 801 and Carol -1’s it, I don’t think any purpose 
is served by breaking that out into individual votes.  I would hope that the 
council members support each other and the body’s decision even if it doesn’t 
go an individual’s way.

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] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 02:30, Anthony Baxter  wrote:
> 
> As someone who's not been involved for some time now, but was release manager 
> for a three or four years (2.3.1 through to 2.5.1), trying to have the 
> release manager also be a decider of potentially controversial things doesn't 
> seem scalable.
> 
> I'm not sure what the proper governance structures should be, but they 
> absolutely shouldn't be dumping extra load onto the release manager.

My thinking is that the current RM can serve a useful role on the Council, but 
not in a voting capacity.  Some possible scenarios:

* A Council member wants to author a PEP.  They probably shouldn’t also get to 
vote on the PEP’s acceptance, so the RM can serve as a replacement vote for 
that one PEP.  (Maybe only for Standard Track PEPs).

* If a Council member is temporarily unavailable, the RM can serve in their 
place during that period.

* The RM can give valuable insight that may influence Council members votes.  
Maybe the PEP’s implementation is too difficult for the current release, and 
recommends deferral.

* If the Council also decides on the “PEP-worthiness” of an idea, the RM can 
weigh in based on their unique perspective on the release cycle.

* The RM can provide an independent oversight role on the Council, kind of like 
an ombudsman (or maybe that should be a separate role, although I suspect it 
will be rarely invoked in practice).

I would propose that the RM be involved with Council communications, but does 
not get a vote.

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] Transfer of power

[Larry Hastings]

On 07/13/2018 03:30 PM, Barry Warsaw wrote:

On Jul 13, 2018, at 15:11, Jack Jansen  wrote:

How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, and 
actually the “3” isn’t important either) where unanimity is required for 
language changes (i.e. basically for accepting a PEP)?

Possibly, but even if unanimity can’t be achieved, I feel strongly that any 
decision coming from the GUIDO/Cabal/Council should be give as a single party.  
E.g. if Alice and Bob +1 PEP 801 and Carol -1’s it, I don’t think any purpose 
is served by breaking that out into individual votes.  I would hope that the 
council members support each other and the body’s decision even if it doesn’t 
go an individual’s way.


I disagree.  My proposal for Python's Council Of Elders is partially 
based on the Supreme Court Of The United States.  For example, SCOTUS 
judges are appointed for life, and I think PCOE members should be too.


When SCOTUS renders a decision:

 * the deliberation is held in private, but then
 * the judges cast their votes,
 * the "winning" side writes up the official decision, called "the
   Court's opinion",
 * and any member may contribute their own individual opinion,
   concurring /or/ dissenting, and finally
 * all votes and opinions contributed to the decision are made public.

This seems like a sensible approach for the PCOE to me too.  I prefer 
more transparency in governance generally, and as a member of the 
community governed by this body I'd prefer more rather than less insight 
into the process and the thinking that went into the decision.  I don't 
think it's a requirement for the PCOE to present as a unified front or 
to work in secret for them to be supportive of each other and of the 
body's decision.


Sunlight, not darkness,


//arry/
___
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] Transfer of power

[Steve Dower]

On 13Jul2018 1600, Larry Hastings wrote:
I disagree.  My proposal for Python's Council Of Elders is partially 
based on the Supreme Court Of The United States.  For example, SCOTUS 
judges are appointed for life, and I think PCOE members should be too.


When SCOTUS renders a decision:

  * the deliberation is held in private, but then
  * the judges cast their votes,
  * the "winning" side writes up the official decision, called "the
Court's opinion",
  * and any member may contribute their own individual opinion,
concurring /or/ dissenting, and finally
  * all votes and opinions contributed to the decision are made public.

This seems like a sensible approach for the PCOE to me too.  I prefer 
more transparency in governance generally, and as a member of the 
community governed by this body I'd prefer more rather than less insight 
into the process and the thinking that went into the decision.  I don't 
think it's a requirement for the PCOE to present as a unified front or 
to work in secret for them to be supportive of each other and of the 
body's decision.


Sunlight, not darkness


I agree with Larry, at least until the point at which we see "the 
public" aggressively idolising or demonising those members of the 
Council with whom they agree/disagree. Then I'll change my mind :)


(For those who are unfamiliar with the phenomenon I'm referencing, wait 
for SCOTUS to decide _anything_ and then go look at American Twitter.)


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] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 03:40, Victor Stinner  wrote:

> Should we split the role "take the final decision on PEPs" into
> sub-roles for example? Do we need in advance to define BDFL-delegate
> for some kinds of PEPs? Or the BDFL should define per-PEP, which ones
> he doesn't want to handle and need a BDFL-delegate? In my experience,
> the BDFL delegation was done naturally, was not the source of
> conflict, and usually discussed directly with the BDFL.

I don’t think we need to be so formal about delegation.  As you say, it should 
generally happen naturally.

I actually think delegation will be more common, leaving mostly the 
language-level Standards Track PEPs for the BDFL (Benevolent Design Faction 
Lifers - okay, still playing with names :).

One tricky thing with delegation will be when a natural delegate is also the 
author of the PEP. For example, if Yury proposed some changes to async, he 
wouldn’t also be able to pronounce on it.  OTOH, Guido is of course still a 
developer and could be a delegate for such PEPs if he wants.  Just something to 
be aware of.

It’s possible that more decisions that have previously been informal will be 
best served by the PEP process.  For example, the pronouncement that 
dictionaries officially preserve insertion order would likely be handled as a 
succinct PEP.  One of the roles of the council would be to decide whether a 
change is PEP-worthy or not.  It’s possible that ideas that only show up on the 
tracker for example, need to be promoted into a PEP, and it would be up to the 
developer community to help identify those potential changes.

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] Identify roles of the BDFL

[Carol Willing]

> On Jul 13, 2018, at 11:39 AM, Brett Cannon  > wrote:
> 
> 
> 
> On Fri, 13 Jul 2018 at 03:44 Victor Stinner  > wrote:
> Hi,
> 
> 2018-07-12 19:12 GMT+02:00 Mariatta Wijaya  >:
> 
> 
> * Diversity. Last years, the BDFL was a strong player to enhance the
> diversity of core developers and contributors by mentoring directly
> Mariatta Wijaya, and suggesting regularly to mentor more people from
> minorities whenever possible. He also likes to wear PyLadies t-shirt
> and support DjangoGirls ;-)
> 
> I lump this into the community and PR bucket as I don't know if we need to be 
> worrying about appointing a head of diversity right now as that doesn't tie 
> into governance. If, once this is all over, we want to take our diversity 
> efforts to another level then a diversity SIG could be formed, but I don't 
> see this as a BDFL thing and more of a team thing that someone choose to 
> spearhead.
> 

Brett, 

I'm wondering if prematurely placing this in the community and PR bucket gives 
mentoring and inclusion among the core developer enviroment enough strategic 
importance. Knowing how gracious you are, I suspect that you personally are 
viewing it as such. Yet, I'm not sure that by removing this as a role that 
Guido has played is best for the language or the developer community.

If I look at the many important roles that Guido has played, I personally 
believe that he has been someone who encouraged many women (and I'm sure others 
as well) and most importantly provided a safe place to share ideas. If we 
reflect on Mariatta's PyCon talk and Summit talk, it's clear that we should not 
overlook this role as growth and improvements still need to happen here.

I believe that improving the overall communication and professionalism on 
mailing lists and PEPs is important to continuously improve the culture and 
discourse. While this may help improve inclusion (and is a step in the right 
direction), I would encourage everyone to reflect on Mariatta's talks and 
consider whether improvement will happen if members of 
GUIDO/elders/triumvirate/kittens of entropy and anarchy/pick your 
governance/etc. don't believe, embrace, and make this a priority  in stewarding 
the future of the Python language.

tldr; We don't need a head of diversity. What we need is leadership that 
embraces inclusion and will steward the vision for improvements.

Thanks,
Carol

___
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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Barry Warsaw]

On Jul 13, 2018, at 04:31, Nathaniel Smith  wrote:
> 
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)

Count me in.

Procedurally, I think an informational PEP numbered in sequence is a good place 
for the “design” of our governance.  Once we’ve settled on a plan, we would 
capture the operational procedures in a new process PEP (I propose PEP 2), 
which would be our working document moving forward.  I think it’s pretty much a 
certainty that whatever we come up with initially will undergo changes as time 
goes on and we gain experience.  PEP 2 would then be the living document for 
our language governance process.

-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] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 17:11, Carol Willing  wrote:

> If I look at the many important roles that Guido has played, I personally 
> believe that he has been someone who encouraged many women (and I'm sure 
> others as well) and most importantly provided a safe place to share ideas. If 
> we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we 
> should not overlook this role as growth and improvements still need to happen 
> here.

Maybe we refactor this particular role of the BDFL?  It may be that given 
Guido’s passion for this topic, he would still want to be active.  If so, he 
would certainly still have the stature, respect, and voice to continue to 
promote this within the community.  Of course, we don’t know whether that’ll be 
the case or not.

It’s a good question though: should the Council primarily concern itself with 
technical details of language evolution, or take on more of the other roles 
that Guido traditional performed?  Or do you see more of an overlap there 
(other than through the person embodying that role)?

-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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Carol Willing]

> On Jul 13, 2018, at 5:15 PM, Barry Warsaw  wrote:
> 
> On Jul 13, 2018, at 04:31, Nathaniel Smith  wrote:
>> 
>> I volunteer to co-author such a PEP. But I'm not up to doing it on my
>> own. So... who else wants to be a co-author? (I'm not going to
>> pressure anyone, but Brett, Mariatta, and Carol, please know that your
>> names were the first ones that jumped to my mind when thinking about
>> this :-).)
> 
> Count me in.

Me too.

> 
> Procedurally, I think an informational PEP numbered in sequence is a good 
> place for the “design” of our governance.

I've been debating all day how to respond to this informational PEP re: 
governance. While I think it's great to cull good practices from other 
communities, I'm not sure that Python really fits into any existing governance 
that other projects use. IMHO Python is one of the healthiest 
language/community in the open source world. There's a reason that the saying 
"I came for the language and stayed for the community" exists.

There's also a reason the Zen of Python has been so popular for so long. It 
works.

While this may be an unconventional idea, I would love to look at governance 
through the lens of these 2 universally held beliefs as we begin to "design" 
our goverance (Thank you Barry for phrasing so well).

>  Once we’ve settled on a plan, we would capture the operational procedures in 
> a new process PEP (I propose PEP 2), which would be our working document 
> moving forward.  I think it’s pretty much a certainty that whatever we come 
> up with initially will undergo changes as time goes on and we gain 
> experience.  PEP 2 would then be the living document for our language 
> governance process.

Sounds great.


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

Re: [python-committers] Identify roles of the BDFL

[Carol Willing]

> 
> On Jul 13, 2018, at 5:25 PM, Barry Warsaw  wrote:
> 
> On Jul 13, 2018, at 17:11, Carol Willing  wrote:
> 
>> If I look at the many important roles that Guido has played, I personally 
>> believe that he has been someone who encouraged many women (and I'm sure 
>> others as well) and most importantly provided a safe place to share ideas. 
>> If we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we 
>> should not overlook this role as growth and improvements still need to 
>> happen here.
> 
> Maybe we refactor this particular role of the BDFL?  It may be that given 
> Guido’s passion for this topic, he would still want to be active.  If so, he 
> would certainly still have the stature, respect, and voice to continue to 
> promote this within the community.  Of course, we don’t know whether that’ll 
> be the case or not.

Make sense, and I have no object to refactoring. I sincerely hope that is the 
case, but mostly I want Guido to do whatever rocks his world.

> It’s a good question though: should the Council primarily concern itself with 
> technical details of language evolution, or take on more of the other roles 
> that Guido traditional performed?  Or do you see more of an overlap there 
> (other than through the person embodying that role)?

Our messages crossed from a different post so I'm going to repost it here:

> [Barry] Procedurally, I think an informational PEP numbered in sequence is a 
> good place for the “design” of our governance.

[Carol] I've been debating all day how to respond to this informational PEP re: 
governance. While I think it's great to cull good practices from other 
communities, I'm not sure that Python really fits into any existing governance 
that other projects use. IMHO Python is one of the healthiest 
language/community in the open source world. There's a reason that the saying 
"I came for the language and stayed for the community" exists.

There's also a reason the Zen of Python has been so popular for so long. It 
works.

While this may be an unconventional idea, I would love to look at governance 
through the lens of these 2 universally held beliefs as we begin to "design" 
our goverance (Thank you Barry for phrasing so well).

---

tldr; If what evolves embraces the Zen of Python and "I came for the language 
and stayed for the community", I am confident that the language will benefit 
technically. Encouraging people to work together even through disagreement and 
to respect that more than one solution is possible (it doesn't have to be one 
is great and the other stinks).


> 
> -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] Transfer of power

[Larry Hastings]

On 07/13/2018 04:20 PM, Steve Dower wrote:

On 13Jul2018 1600, Larry Hastings wrote:
I disagree.  My proposal for Python's Council Of Elders is partially 
based on the Supreme Court Of The United States.  For example, SCOTUS 
judges are appointed for life, and I think PCOE members should be too.


When SCOTUS renders a decision:

  * the deliberation is held in private, but then
  * the judges cast their votes,
  * the "winning" side writes up the official decision, called "the
    Court's opinion",
  * and any member may contribute their own individual opinion,
    concurring /or/ dissenting, and finally
  * all votes and opinions contributed to the decision are made public.


I agree with Larry, at least until the point at which we see "the 
public" aggressively idolising or demonising those members of the 
Council with whom they agree/disagree. Then I'll change my mind :)


Despite the smiley etc, this is a reasonable point.  But!  I think it's 
inevitable.  As the BDFL Guido received more than his fair share of 
idolatry and demonization (cf. the PEP 572 discussion). It's a natural 
consequence of having identifiable people in charge of a project as 
popular as Python.  Having the PCOE keep its votes / dissent private 
wouldn't eliminate the consequences of fame for its members--all I'd 
expect is that it'd be more evenly distributed.



//arry/
___
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] Transfer of power

[Tim Peters]

[Larry Hastings]
...

>
>- However, once appointed, Elders are appointed is "for life".  The
>only way to remove one would be for them to voluntarily step down--there
>would be no mechanism to remove one from office.  (Perhaps this is too
>strong--perhaps one could be removed by a unanimous vote from all other
>Elders?)  I want the Council to be immune to popular opinion, to be
>empowered to do what they think is right without fear of anything beyond
>negative public opinion.
>
> At the time the US"s founders drafted the Constitution, mean US life
expectancy was about 35 years   A Federal judge only had to maintain "good
behavior" to keep their job, but I imagine they expected most judges would
die within a decade or two regardless.

I really don't think they'd be happy with how the Supreme Court turned out
- political ideologues wielding near-absolute power for decades on end.

So:  term limits!  Say, 12 years.  If there are 3 Elders, replace one every
12/3 = 4 years.  At the start we can use the `secrets` module to pick which
Elders get the first 4, 8, and 12-year terms ;-)

Fresh blood is a good thing in all areas.


>- I'm not sure how we'd replace Elders.  Maybe they'd hold an
>internal-only election?  ("Jo has decided to step down, and we have elected
>Sam as Jo's replacement.")
>
> Obviously, an Elder would be nominated by the President and confirmed with
the advice and consent of the Senate ;-)

Or, short of that, by an approval vote of the Fellows (whatever it is we
call for-real PSF members these days).

And I'd propose to let the Fellows remove an Elder by a 2/3rd supermajority
vote (akin to the bar for impeachment of a US President).
___
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] Transfer of power

[Ethan Furman]

On 07/13/2018 06:54 PM, Tim Peters wrote:


Or, short of that, by an approval vote of the Fellows (whatever it is we call 
for-real PSF members these days).


Forgive my ignorance, but how does one become a PSF member?

--
~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] Transfer of power

[Nathaniel Smith]

On Fri, Jul 13, 2018 at 6:54 PM, Tim Peters  wrote:
> [Larry Hastings]
> ...
>>
>> However, once appointed, Elders are appointed is "for life".  The only way
>> to remove one would be for them to voluntarily step down--there would be no
>> mechanism to remove one from office.  (Perhaps this is too strong--perhaps
>> one could be removed by a unanimous vote from all other Elders?)  I want the
>> Council to be immune to popular opinion, to be empowered to do what they
>> think is right without fear of anything beyond negative public opinion.
>
> At the time the US"s founders drafted the Constitution, mean US life
> expectancy was about 35 years   A Federal judge only had to maintain "good
> behavior" to keep their job, but I imagine they expected most judges would
> die within a decade or two regardless.

That's not really true -- life expectancy *at birth* was ~35 years,
but mostly because so many people died as infants/children. If you
survived long enough to get nominated for a judgeship, then by that
point your life expectancy wasn't too different from what we're used
to today: 
https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html

But I think there are a lot of differences between a 21st-century
F/OSS project and an 18th-century federal government, so probably not
the most relevant model in any case. And of course it's always
tempting to start inventing neat rules and procedures, but IME those
details are actually the least important part of project governance
(compared to things like, having a healthy discussion culture, tools
for building consensus, etc. -- by the time you're voting on something
you've already failed). So debating the pros and cons of term limits
seems a bit premature to me right now :-).

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

Re: [python-committers] Transfer of power

[Tim Peters]

[Tim]

> > Or, short of that, by an approval vote of the Fellows (whatever it is we
> call for-real PSF members these days).
>


[Ethan Furman]

> Forgive my ignorance, but how does one become a PSF member?


That depends on which year you ask ;-)  The current rules are here:

https://www.python.org/psf/membership/

That also defines what I meant by "Fellows".
___
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] Transfer of power

[Larry Hastings]

On 07/13/2018 06:54 PM, Tim Peters wrote:
So:  term limits!  Say, 12 years.  If there are 3 Elders, replace one 
every 12/3 = 4 years.  At the start we can use the `secrets` module to 
pick which Elders get the first 4, 8, and 12-year terms ;-)


Fresh blood is a good thing in all areas.


Can I get you to clarify what you mean by "term limits"?  Do you solely 
mean "Elders would not be appointed for life, but rather would need to 
be re-elected every N years"?  Or do you additionally mean "No Elder can 
serve more than N terms in their lifetime?"  As an admittedly-feeble 
attempt at disambiguation, I'd call the former "limited terms" and the 
latter "term limits".  (I would welcome better terms ;-)


I'm most familiar with the term "term limits" from American politics, 
where it definitely means the latter: a person can only serve N times, 
and are simply ineligible to serve in that same role an N+1th time.  As 
an example, after FDR was elected President four times (!), the American 
Congress passed the 22nd Amendment which limits any particular person to 
no more than two terms as President.


Using my terminology above, at the moment I'm open-minded about whether 
or not the Council members should have "limited terms".  But I'm less 
upbeat about "term limits".  Personally I've always found this concept 
of "term limits" a bit silly--the electorate could simply decline to 
re-elect the incumbent.  The fact that Americans re-elect the incumbent 
so frequently, and /also/ vote for term limits, seems to distill down to 
the attitude "Throw the bums out!... except for /my/ guy, he's good."



//arry/
___
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] Transfer of power

[Tim Peters]

[Nathaniel Smith ]

> That's not really true -- life expectancy *at birth* was ~35 years,
> but mostly because so many people died as infants/children. If you
> survived long enough to get nominated for a judgeship, then by that
> point your life expectancy wasn't too different from what we're used
> to today:
> https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html


But that's just anecdotal, apparently cherry-picking the oldest people of
the time the author could find, and misleadingly saying "George Washington
was a young 67 [at death]", implying that was exceptionally young.  A
better account is here, which shows a bell-like curve for _all_ the
Founders' death ages, peaking in the 60s (Washington did not die
exceptionally young - except by _contemporary_ standards):

https://en.wikipedia.org/wiki/Founding_Fathers_of_the_United_States#Youth_and_longevity

I happily grant that the vast bulk of mean expectancy increase is due to
surviving early childhood, but it's not true either that life expectancy at
(say) age 30 hasn't also increased.

But I think there are a lot of differences between a 21st-century
> F/OSS project and an 18th-century federal government, so probably not
> the most relevant model in any case. And of course it's always
> tempting to start inventing neat rules and procedures, but IME those
> details are actually the least important part of project governance
> (compared to things like, having a healthy discussion culture, tools
> for building consensus, etc. -- by the time you're voting on something
> you've already failed). So debating the pros and cons of term limits
> seems a bit premature to me right now :-).
>

The subject "Transfer of power" is a pretty good clue that building tools
(etc) isn't the primary topic of this thread ;-)  We're looking to fill the
void left by an Absolute Dictator for Life stepping down.  It's important
to get that part right too, because "by the time you're voting on something
you're already failed" is a thing that will happen, and repeatedly.  Guido
has been the last, best resort in such cases.

The US Supreme Court is the closest thing to a dictatorial institution the
US has (lifetime appointments, answerable to nobody, and against which
there is no appeal), so it's a natural model to consider when replacing a
dictator.

Maybe people don't want a dictatorial court of last resort at all.  That
would be germane too.
___
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] Transfer of power

[Tim Peters]

[Tim]

> So:  term limits!  Say, 12 years.  If there are 3 Elders, replace one
> every 12/3 = 4 years.  At the start we can use the `secrets` module to pick
> which Elders get the first 4, 8, and 12-year terms ;-)
>
> Fresh blood is a good thing in all areas.
>
>

[Larry]

> Can I get you to clarify what you mean by "term limits"?  Do you solely
> mean "Elders would not be appointed for life, but rather would need to be
> re-elected every N years"?  Or do you additionally mean "No Elder can serve
> more than N terms in their lifetime?"  As an admittedly-feeble attempt at
> disambiguation, I'd call the former "limited terms" and the latter "term
> limits".  (I would welcome better terms ;-)
>

It would mean whatever we said it means ;-)  I had in mind that an Elder
would be limited to one 12-year term.  You do your dozen and you're out.
The only ways to get out are to serve your 12 years, quit. die, or get
impeached.  Then that's it - you can't be a Python Elder again.



> I'm most familiar with the term "term limits" from American politics,
> where it definitely means the latter: a person can only serve N times, and
> are simply ineligible to serve in that same role an N+1th time.  As an
> example, after FDR was elected President four times (!), the American
> Congress passed the 22nd Amendment which limits any particular person to no
> more than two terms as President.
>

In the context of hypothetical US Supreme Court term limits, legal thinking
has been in line with my meaning above, although (a single) 18-year term
has been most often discussed in that context:

https://en.wikipedia.org/wiki/Term_limits_in_the_United_States#Supreme_Court

However, the articles I read most recently talked about 12 years instead,
and I like that better for Python.  The Supremes get a salary, but Elders
don't.  12 years is a long commitment to do something "in spare time".

Using my terminology above, at the moment I'm open-minded about whether or
> not the Council members should have "limited terms".  But I'm less upbeat
> about "term limits".  Personally I've always found this concept of "term
> limits" a bit silly--the electorate could simply decline to re-elect the
> incumbent.  The fact that Americans re-elect the incumbent so frequently,
> and *also* vote for term limits, seems to distill down to the attitude
> "Throw the bums out!... except for *my* guy, he's good."
>

Of course a limit on the number of terms a Congress Critter can serve is
intended to force the _other_ side's bums out.  The passion for the
prospect of being able to do that clouds seeing that it will also throw
your side's bums out too ;-)

BTW, we both know that the US founders deliberately did _not_ want Federal
judges to be elected.  They had little use for democracy at the Federal
level.  But without a Prez and a Congress to "do the right thing" in the
peoples' best interest, I figured it's good enough to let PSF Fellows do
the voting (in the best interests of the PSF's much broader membership).
___
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] Transfer of power

[Nathaniel Smith]

On Fri, Jul 13, 2018 at 8:22 PM, Tim Peters  wrote:
> [Nathaniel Smith ]
>>
>> That's not really true -- life expectancy *at birth* was ~35 years,
>> but mostly because so many people died as infants/children. If you
>> survived long enough to get nominated for a judgeship, then by that
>> point your life expectancy wasn't too different from what we're used
>> to today:
>> https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html
>
> But that's just anecdotal, [...]

Yeah, it's an off-topic digression anyway so I was simplifying and
didn't spend much time looking for the perfect link. Looking a bit it
seems like in ~1790 a 20-year old white male in the US could expect to
live another ~45 years, and today that's up to ~55 years, and then the
numbers get closer together as the ages increase. Which is about what
I had in mind for "not too different".

>> But I think there are a lot of differences between a 21st-century
>> F/OSS project and an 18th-century federal government, so probably not
>> the most relevant model in any case. And of course it's always
>> tempting to start inventing neat rules and procedures, but IME those
>> details are actually the least important part of project governance
>> (compared to things like, having a healthy discussion culture, tools
>> for building consensus, etc. -- by the time you're voting on something
>> you've already failed). So debating the pros and cons of term limits
>> seems a bit premature to me right now :-).
>
>
> The subject "Transfer of power" is a pretty good clue that building tools
> (etc) isn't the primary topic of this thread ;-)  We're looking to fill the
> void left by an Absolute Dictator for Life stepping down.  It's important to
> get that part right too, because "by the time you're voting on something
> you're already failed" is a thing that will happen, and repeatedly.  Guido
> has been the last, best resort in such cases.

Well, sure, we can try to come up with something to slot into the
space Guido is leaving, while keeping everything else the same, that's
one option. But I doubt it's the best one. Guido is, quite literally,
irreplaceable.

> The US Supreme Court is the closest thing to a dictatorial institution the
> US has (lifetime appointments, answerable to nobody, and against which there
> is no appeal), so it's a natural model to consider when replacing a
> dictator.

Yeah, I get why it comes to mind for USians here, but there are also,
like... lots of actual open-source projects that have transitioned
from a BDFL model to something else, and they're probably even more
natural models ;-).

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

Re: [python-committers] Transfer of power

[Tim Peters]

[Nathaniel Smith]

> ...
> Well, sure, we can try to come up with something to slot into the
> space Guido is leaving, while keeping everything else the same, that's
> one option.


There are already differences between "a Guido" and what Larry suggested.


> But I doubt it's the best one.


Then please suggest something specific you think is better.


> Guido is, quite literally, irreplaceable.
>

Yet the roles he played are not self-evidently dispensable either.


> > The US Supreme Court is the closest thing to a dictatorial institution
> the
> > US has (lifetime appointments, answerable to nobody, and against which
> there
> > is no appeal), so it's a natural model to consider when replacing a
> > dictator.
>
> Yeah, I get why it comes to mind for USians here, but there are also,
> like... lots of actual open-source projects that have transitioned
> from a BDFL model to something else, and they're probably even more
> natural models ;-).


Then spell out what they did and how that worked for them?  I'm not
familiar with any such.  The closest match to Python's development process
I know of was Perl's, but Larry Wall is still (AFAIK) dictator-for-life in
Perl world.

On the face of it, sure, I'd rather look at a successful transition in an
open source software project than at the centuries-old experiment that
brought us American politics ;-)
___
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] Transfer of power

[Alex Martelli via python-committers]

>
>
> How about a triumvirate (or trium*ate if “vir” is seen as too male-centric,
>

The root "vir" in appropriate contexts (though clearly not in all, e.g in
`virile`) has long been divorced from its original "male" denotation. The
best example is probably in the word "virtus" (in English, "virtue") and
further derivatives (e.g "virtuoso", an Italian word which has also been
adopted in English), where nobody perceives a denotation of "maleness" any
more (even though a long time ago the word was coined to refer to "a male's
positive traits" such as courage and strength).

I contend that "triumvir" today has no more denotation of maleness than
"virtue" does -- e.g, Merriam-Webster defines it as "one of a commission or
ruling body of three" (appropriately gender-neutral) and I think they're
spot-on about this.


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] Transfer of power

[Gregory P. Smith]

On Thu, Jul 12, 2018 at 12:17 PM Brett Cannon  wrote:

> On Thu, 12 Jul 2018 at 11:53 Barry Warsaw  wrote:
>
>>
>> That said, I think a triumvirate would work (Guido’s Unworthy Inherited
>> Delegation Organization).
>
>
> Nice! "GUIDO decided ..." Totally going to mess with Guido's personal SEO,
> though. ;)
>

+1  Whatever we wind up with, the name has already been decided.  Lets keep
GUIDO as the name unless the ex-BDFL rejects it!  =)

I *assumed* someone else would've long suggested we act as an autonomous
collective organized as an anarcho-syndicalist commune in honor of
https://youtu.be/Yx_pDo9B0NY by now given the in person conversations where
the Holy Grail quoting of came up. :P  (in case it isn't obvious: *don't
take that seriously*)

In all seriousness, we already have a BDFL delegate system for PEPs that
makes sense.  At a minimum, how to choose the delegate, or early reject a
PEP so it doesn't need one, is the thing we'll decide within the next year.

I also liked some of Raymond H's suggestions around adjusting the PEP
section authorship and potentially final decision acceptance process. But
those types of changes are likely best kept separate from choosing how BDFL
delegates are agreed on. (ie: lets decide how we would even declare the
decision of such changes first)

-gps
___
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] Transfer of power

[Nick Coghlan]

On 13 July 2018 at 00:57, Guido van Rossum  wrote:
> Now that PEP 572 is done, I don't ever want to have to fight so hard for a
> PEP and find that so many people despise my decisions.
>
> I would like to remove myself entirely from the decision process. I'll still
> be there for a while as an ordinary core dev, and I'll still be available to
> mentor people -- possibly more available. But I'm basically giving myself a
> permanent vacation from being BDFL, and you all will be on your own.

Guido, thank you for the immense amount of time and energy you've
devoted to both designing and developing Python-the-language, and also
to building and supporting python-dev-the-collaborative-community.

I know I'd be a different person without the years of freely shared
experience, knowledge, and advice that I've benefited from by being
part of this group.

> I'll still be here, but I'm trying to let you all figure something out for
> yourselves. I'm tired, and need a very long break.

Take all the time you need - you've built a strong design community
here, and hopefully we can arrange things in away that allows you to
rediscover the fun parts of contributing without the burden of always
needing to be the ultimately responsible decision maker :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/