From vstinner at redhat.com  Thu Nov  1 12:44:10 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 1 Nov 2018 17:44:10 +0100
Subject: [python-committers] PEP 8015: Organization of the Python
 community
In-Reply-To: <CA+3bQGGqD-6MH9GO-eymB5hmqcGU+cgPiBVgpMUXme+3EdVZng@mail.gmail.com>
References: <CA+3bQGGqD-6MH9GO-eymB5hmqcGU+cgPiBVgpMUXme+3EdVZng@mail.gmail.com>
Message-ID: <CA+3bQGEw-auFMSVChDnQWYCP1PxRm+hi=PEjReW+9JdhwuMwXg@mail.gmail.com>

Hi,

To take in account all discussions around my PEP 8015, I updated it:
it?s now the version 4. I added a Version History at the bottom of the
PEP to help reviewers. In short: votes are now announced in advance
(0, 1 or 3 weeks depending on the vote) and only open for 1 week
instead of 1 month, the ?Python (Core) Board? has been renamed to
?Python Steering Committee? to clarify its role.

https://www.python.org/dev/peps/pep-8015/

Discussion on Discourse:
https://discuss.python.org/t/pep-8015-organization-of-the-python-community/193

Version History
===============

History of this PEP:

* Version 4:

  * Adjust votes: open for 1 week instead of 1 month, and announced
    in advance.
  * Rename the "Python Core Board" to the "Python Steering Committee";
  * Clarify that this committee doesn't approve PEPs and that committee
    members cannot cumulate more than 2 mandates;
  * Add the "Type Hints" team to the annex.

* Version 3: Add "Special Case: Ban a core developer" and "How to update
  this PEP" sections.
* Version 2: Rename the "Python board" to the "Python Core Board",
  to avoid confusion with the PSF Board.
* Version 1: First version posted to python-committers and
  discuss.python.org.

Victor

From vstinner at redhat.com  Thu Nov  1 13:10:12 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 1 Nov 2018 18:10:12 +0100
Subject: [python-committers] PEP 8015: Organization of the Python
 community
In-Reply-To: <CAP1=2W5p23vbg+sMT2FcunNiVNnwdUVZ07G--JwmdYJAWtJ3+g@mail.gmail.com>
References: <CA+3bQGGqD-6MH9GO-eymB5hmqcGU+cgPiBVgpMUXme+3EdVZng@mail.gmail.com>
 <CAP1=2W5p23vbg+sMT2FcunNiVNnwdUVZ07G--JwmdYJAWtJ3+g@mail.gmail.com>
Message-ID: <CA+3bQGGimb2YtE4jKUeXu2ejGfwHWtVKggyc--nK1Puus8Km0w@mail.gmail.com>

Hi Brett,

I just updated my PEP to take in account your comments.

Le ven. 12 oct. 2018 ? 20:33, Brett Cannon <brett at python.org> a ?crit :
>> Team members are Python contributors and Python core developers. The
>> team is responsible to select who can join the team and how.
>
> How is this bootstrapped? Do I get to declare myself the "import team" and then I get to choose who joins after that?

I added the first paragraph and added "self-organized" in the second:

"""
When enough developers are interested by a specific topic, they can
create a new team. Usually, the main action is to ask the Python
postmaster to create a new "SIG" mailing list, but the team can choose
to use a different communication channel.

Team members are Python contributors and Python core developers. The
team is self-organized and is responsible to select who can join the
team and how.
"""

https://www.python.org/dev/peps/pep-8015/#python-teams

>> Board members must be Python core developers.  It is important that the
>> members of the board reflect the diversity of Python' users and
>> contributors. A small step to ensure that is to enforce that two members
>> cannot work for the same company (or subsidiaries of the same company).
>> In addition, to encourage more people to get involved, a core developer
>> can only be a board member twice (up to 6 years total).
>
> Is the two-term limit forever, or just consecutively?

I clarified the limit of 2 mandates:

"""
In addition, to encourage more people to get involved, a core developer
can only be a committee member twice in their whole life (up to 6 years
total), it can be two mandates in a row.
"""

https://www.python.org/dev/peps/pep-8015/#election-of-python-steering-committee-members

Does it look better to you? If not, would you mind to propose something?

Victor

From vstinner at redhat.com  Thu Nov  1 13:15:07 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 1 Nov 2018 18:15:07 +0100
Subject: [python-committers] PEP 8015: Organization of the Python
 community
In-Reply-To: <CAP1=2W5p23vbg+sMT2FcunNiVNnwdUVZ07G--JwmdYJAWtJ3+g@mail.gmail.com>
References: <CA+3bQGGqD-6MH9GO-eymB5hmqcGU+cgPiBVgpMUXme+3EdVZng@mail.gmail.com>
 <CAP1=2W5p23vbg+sMT2FcunNiVNnwdUVZ07G--JwmdYJAWtJ3+g@mail.gmail.com>
Message-ID: <CA+3bQGEx6NzfSdTBdX9Fb82Wm1_iUzzveEk-Y2_ss7f84u=ryw@mail.gmail.com>

Brett:
> Is this here to mean the expectation that the conduct WG will manage CoC issues for the core development team?

Core developers and Steering Committee members are at the same level
than any other Python contributor when they misbehave. I expect the
"autonomous" conduct workgroup to handle CoC issues from all Python
contributors.

I added a "Special Case: Ban a core developer" section which has a
direct relationship between the Code of Conduct and the core developer
status. Extract:

"As any other member of the Python community, the PSF Code of Conduct
Workgroup can ban a core developer for a limited amount of time. In
this case, the core developer immediately loses their core developer
status."

https://www.python.org/dev/peps/pep-8015/#special-case-ban-a-core-developer

It is also a consequence of this notice:

"Core developers are also expected to be exemplary when it comes to
the Code of Conduct."

https://www.python.org/dev/peps/pep-8015/#python-core-developers

Victor

From taleinat at gmail.com  Fri Nov  2 09:19:04 2018
From: taleinat at gmail.com (Tal Einat)
Date: Fri, 2 Nov 2018 15:19:04 +0200
Subject: [python-committers] Suggestion: A PSF grant for running a "Core Dev
 Mentorship Program"
Message-ID: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>

 *tl;dr:* I?d like to apply for a PSF grant to mentor several developers
towards becoming active contributors and hopefully core-devs.

1. What do you think? Any +1/-1 would be very helpful.
2. I'm looking for info on how successful mentoring has been in getting
more contributors. Any such info or references would be a great help!

-------------------------------------------------------------------------------

Recently there has been a recent "wave" of requests for mentoring on this
list. This was triggered by Victor Stinner?s post "Looking for people from
underrepresented groups to mentor"
<https://mail.python.org/mm3/archives/list/core-mentorship at python.org/message/Z33DZF7C4YXUD2SMHVHUZDN25I3FCNGP/>,
who later wrote that he received 20-30 requests for mentoring
<https://mail.python.org/mm3/archives/list/core-mentorship at python.org/message/W3IEAEQQBXTC663SFES52XLIMPKBAWJB/>
(!).

My understanding is that many of us would like to have more active
contributors and core developers. Additionally, many would like these to be
a more diverse group. Guido and Victor have lately taken up mentoring
several developers with the explicit intent of achieving these goals.

I would also like to work towards these goals. I have recently invested
more time on the core-mentorship mailing list and Zulip stream, as well as
doing my best to mentor two promising developers. However, my free time is
becoming increasingly limited again, and I am learning that effectively
mentoring a developer requires being able to spend a good amount of time
nearly daily on such mentoring.

My life circumstances are such that I would be able to commit to a
medium-term part-time paid project. Therefore, I?ve come up with an idea
for a concerted effort to mentor a group of developers for a significant
length of time, which I?ve called a ?Core Dev Mentorship Program?.

My current suggestion is to remotely mentor five developers for 10 weeks,
selecting the participants to be as diverse a group as possible among
appropriate applicants. I wrote a proposal and submitted it to the PSF.
They rightly asked that I first bring this before the core devs, so here I
am.

I can think of reasons to oppose such a project, with the foremost being
that most (all?) such mentorship has thus far been done on a volunteer
basis, and we wouldn?t want to negatively impact future volunteer
mentorship efforts. In my eyes this project would be a complementary
effort, and I propose it only because it appears that we are currently
unable to mentor as many as we would like, nor as many as would like to be
mentored.

I am purposefully not including the details of my proposal, as I would like
to first focus on whether the idea is supported in general.

Any and all comments, suggestions and criticism are most welcome.

-------------------------------------------------------------------------------


Note: I also posted this in the "commiters" category on
<https://discuss.python.org/t/suggestion-a-psf-grant-for-running-a-core-dev-mentorship-program/289>
discuss.python.org; see additional discussion there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181102/cb0d2352/attachment.html>

From antoine at python.org  Fri Nov  2 09:37:51 2018
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 2 Nov 2018 14:37:51 +0100
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
Message-ID: <fd130590-9570-819e-5c73-8c726fad24e6@python.org>


Le 02/11/2018 ? 14:19, Tal Einat a ?crit?:
> 
> I would also like to work towards these goals. I have recently invested
> more time on the core-mentorship mailing list and Zulip stream, as well
> as doing my best to mentor two promising developers. However, my free
> time is becoming increasingly limited again, and I am learning that
> effectively mentoring a developer requires being able to spend a good
> amount of time nearly daily on such mentoring.

I'd *really* like to know why that is the case.  Most existing core
developers didn't need "a good amount of time" to be spent "nearly
daily" on their mentoring to get them up to speed.  Instead they
progressed slowly on the contribution curve, with due feedback from
senior core developers, but without requiring extended attention.

Contributing to a large mature project like CPython requires dedication
and significant prior experience.  If someone needs a large amount of
hand-holding then that's a bad sign IMO.  There are much simpler and
more approachable projects out there if they'd like to learn
contributing to open source software.

I'd also like to know what the current outcomes of the "Core Mentorship"
program are.  How many core developers or seasoned contributors did we
get from it?  The core-mentorship mailing-list has been existing since
2011, so we should have ample experience by now.

Regards

Antoine.

From antoine at python.org  Fri Nov  2 09:55:46 2018
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 2 Nov 2018 14:55:46 +0100
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
Message-ID: <88552487-9498-fa52-3ff5-cdb9fdc85355@python.org>


As a side note, I'm not against the general principle of funding some
mentorship or other contribution-related activity.  I'm just unsure that
this would be money well spent.

Regards

Antoine.


Le 02/11/2018 ? 14:37, Antoine Pitrou a ?crit?:
> 
> Le 02/11/2018 ? 14:19, Tal Einat a ?crit?:
>>
>> I would also like to work towards these goals. I have recently invested
>> more time on the core-mentorship mailing list and Zulip stream, as well
>> as doing my best to mentor two promising developers. However, my free
>> time is becoming increasingly limited again, and I am learning that
>> effectively mentoring a developer requires being able to spend a good
>> amount of time nearly daily on such mentoring.
> 
> I'd *really* like to know why that is the case.  Most existing core
> developers didn't need "a good amount of time" to be spent "nearly
> daily" on their mentoring to get them up to speed.  Instead they
> progressed slowly on the contribution curve, with due feedback from
> senior core developers, but without requiring extended attention.
> 
> Contributing to a large mature project like CPython requires dedication
> and significant prior experience.  If someone needs a large amount of
> hand-holding then that's a bad sign IMO.  There are much simpler and
> more approachable projects out there if they'd like to learn
> contributing to open source software.
> 
> I'd also like to know what the current outcomes of the "Core Mentorship"
> program are.  How many core developers or seasoned contributors did we
> get from it?  The core-mentorship mailing-list has been existing since
> 2011, so we should have ample experience by now.
> 
> Regards
> 
> Antoine.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From taleinat at gmail.com  Fri Nov  2 10:02:43 2018
From: taleinat at gmail.com (Tal Einat)
Date: Fri, 2 Nov 2018 16:02:43 +0200
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
Message-ID: <CALWZvp6FvCRcAeSc7uWW2qifOhKBJT1r0u_Q_VMxEgT87oYvsg@mail.gmail.com>

Hi Antoine,



On Fri, Nov 2, 2018 at 3:38 PM Antoine Pitrou <antoine at python.org> wrote:

>
> Le 02/11/2018 ? 14:19, Tal Einat a ?crit :
> >
> > I would also like to work towards these goals. I have recently invested
> > more time on the core-mentorship mailing list and Zulip stream, as well
> > as doing my best to mentor two promising developers. However, my free
> > time is becoming increasingly limited again, and I am learning that
> > effectively mentoring a developer requires being able to spend a good
> > amount of time nearly daily on such mentoring.
>
> I'd *really* like to know why that is the case.


I've recently been mentoring two experienced developers: Gus Goulart and
Jonathan Gossage. Initially, when their momentum was highest, every day at
least one of them had non-trivial questions to ask and/or PRs ready for
review. I attempted to be highly responsive to allow them to progress
unhindered, and found myself spending at least 30 minutes on this nearly
every day. I now spend less time on this simply because their momentum is
reduced, partially because at one point I was not able to keep up with
their progress.


> Most existing core
> developers didn't need "a good amount of time" to be spent "nearly
> daily" on their mentoring to get them up to speed.  Instead they
> progressed slowly on the contribution curve, with due feedback from
> senior core developers, but without requiring extended attention.
>

True, but this process is not suitable for many, and it does not seem to
currently be yielding as many regular contributors and core developers as
we'd like.

My personal experience is that it took me over a decade between beginning
to contribute to Python to becoming an active core dev. I believe that that
could have taken just a few months if I had had a mentor.


> Contributing to a large mature project like CPython requires dedication
> and significant prior experience.  If someone needs a large amount of
> hand-holding then that's a bad sign IMO.  There are much simpler and
> more approachable projects out there if they'd like to learn
> contributing to open source software.
>

There appear to be many experienced developers interested in becoming
contributors (and possibly core devs down the road). The two I'm now
mentoring are such; they don't require "hand-holding" in the sense of more
junior developers. No other core dev seemed to be available for mentoring
them when they first asked for mentoring.


> I'd also like to know what the current outcomes of the "Core Mentorship"
> program are.  How many core developers or seasoned contributors did we
> get from it?  The core-mentorship mailing-list has been existing since
> 2011, so we should have ample experience by now.
>

I'm looking for this info too!

- Tal Einat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181102/f2400f7a/attachment.html>

From vstinner at redhat.com  Fri Nov  2 12:30:36 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 2 Nov 2018 17:30:36 +0100
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
Message-ID: <CA+3bQGG8856ZhtFd4b4CfJ6mJbmUC-8vWTCGf7_HzpGEXekqqg@mail.gmail.com>

Le 02/11/2018 ? 14:19, Tal Einat a ?crit :
> > I am learning that
> > effectively mentoring a developer requires being able to spend a good
> > amount of time nearly daily on such mentoring.

It really depends on the availability and skills of the mentoree. I
have mentorees who are very busy and sometimes don't ask anything for
2 weeks. Others are making good progress and ask me for help multiple
times per week. I wouldn't say daily, since neither mentorees nor me
are available everyday.

I also know that I should try to answer as soon as possible to my
mentorees, since they are usually blocked and unable to find the
solution by themselves.

Le ven. 2 nov. 2018 ? 14:38, Antoine Pitrou <antoine at python.org> a ?crit :
> I'd *really* like to know why that is the case.  Most existing core
> developers didn't need "a good amount of time" to be spent "nearly
> daily" on their mentoring to get them up to speed.  Instead they
> progressed slowly on the contribution curve, with due feedback from
> senior core developers, but without requiring extended attention.

Such profiles are the least common, and we already promoted all of them :-)

The trend on mentoring means that we need more core developers and
that we have to help to prevent people moving to a more responsive
project.

IMO saying that mentoring is not needed indirectly means that we have
enough available core developers to handle the 6000 open issues, the
900 pull requests, maintain the continuous integration (Travis CI,
AppVeyor, VSTS, buildbots), fix regressions, etc.

> Contributing to a large mature project like CPython requires dedication
> and significant prior experience.  If someone needs a large amount of
> hand-holding then that's a bad sign IMO.

We have documentations like the devguide, but to me it's now obvious
that it's not enough. I don't see it as a bad sign. Python is a very
mature project which has very high quality standard and a very strong
constraint of backward compatibility. Python is different from other
projects. IMHO breaking the backward compatibility in Django seems to
be easiler than in Python.

> There are much simpler and
> more approachable projects out there if they'd like to learn
> contributing to open source software.

Exactly. This is why we fail to convert volunteer contributors to core
developers. They fly away because pull requests are not reviewed,
whereas other projects are faster than us to review PRs, give better
feedback and has less strict on quality/backward compat.

Victor

From vstinner at redhat.com  Fri Nov  2 12:33:45 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 2 Nov 2018 17:33:45 +0100
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <88552487-9498-fa52-3ff5-cdb9fdc85355@python.org>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
 <88552487-9498-fa52-3ff5-cdb9fdc85355@python.org>
Message-ID: <CA+3bQGHoGEUiyxiJ9uah7VoCDxWaB295dy7-zYbvzbt+4t_Ssw@mail.gmail.com>

Le ven. 2 nov. 2018 ? 14:55, Antoine Pitrou <antoine at python.org> a ?crit :
> As a side note, I'm not against the general principle of funding some
> mentorship or other contribution-related activity.  I'm just unsure that
> this would be money well spent.

This is a good question. We already a lot of core developers, but
almost none is paid to contribute.

Mentoring is an investment in the long term. Is it better to pay
someone to review and merge PRs?

Reviewing PRs is also a way to help and train contributors. It's not
very different from mentoring, depending on your definition of
mentoring :-)

Victor

From brett at python.org  Fri Nov  2 18:20:43 2018
From: brett at python.org (Brett Cannon)
Date: Fri, 2 Nov 2018 15:20:43 -0700
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
Message-ID: <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>

FYI I just updated PEP 8001 with the result of the poll which very clearly
favoured the Condorcet method for winner selection.

On Tue, 30 Oct 2018 at 12:52, Tim Peters <tim.peters at gmail.com> wrote:

> There's a poll about the voting method to use to decide on the winning
> governance PEP.  We'd like to see more people weigh in:
>
>     https://discuss.python.org/t/python-governance-electoral-system/290/26
>
> PEP 8001 specifies that IRV will be used.  There's pushback against
> that.  Since a poll is a form of approval voting, there's also
> pushback against using a poll to vote on the voting method.  But we
> really don't have the time to pursue infinite regress to its end ;-)
>
> I'm not in charge of anything, so take this for what it's worth:  pick
> the option(s) that are closest to what you can live with, but add a
> comment to the poll if there's some aspect of what you vote for that
> you really can't abide (e.g., at least one person said they would vote
> for Approval, _except_ that they object to getting the PSF Board
> involved in case there's a tie).  The high-order bit of this poll is
> about the basic approaches people can live with, not details of how
> problem cases are handled.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181102/93f478cc/attachment.html>

From steve at pearwood.info  Fri Nov  2 18:49:25 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 3 Nov 2018 09:49:25 +1100
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
Message-ID: <20181102224925.GM3817@ando.pearwood.info>

On Fri, Nov 02, 2018 at 03:20:43PM -0700, Brett Cannon wrote:

> FYI I just updated PEP 8001 with the result of the poll which very clearly
> favoured the Condorcet method for winner selection.

That was quick. It would have been nice if there had been some sort of 
obvious announcement of the time frame available for voting before 
voting closed :-( Did I miss it?

How many people voted? Out of what (approximate) pool of potential 
voters?



-- 
Steve

From vstinner at redhat.com  Fri Nov  2 18:57:02 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 2 Nov 2018 23:57:02 +0100
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <20181102224925.GM3817@ando.pearwood.info>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <20181102224925.GM3817@ando.pearwood.info>
Message-ID: <CA+3bQGFSTUUDadXMzD0a1784Pr3Z_5M7hT3XfUK6OY9cO4JK9Q@mail.gmail.com>

Le ven. 2 nov. 2018 ? 23:49, Steven D'Aprano <steve at pearwood.info> a ?crit :
> How many people voted? Out of what (approximate) pool of potential
> voters?

25 voters on 65 core developers who have an account on discuss.python.org.

25 can be seen at:
https://discuss.python.org/t/python-governance-electoral-system/290/26

65 comes from:
https://discuss.python.org/groups/committers

Note: I didn't vote (not interested to vote on the voting method).

Victor

From steve at pearwood.info  Fri Nov  2 19:07:33 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 3 Nov 2018 10:07:33 +1100
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CA+3bQGFSTUUDadXMzD0a1784Pr3Z_5M7hT3XfUK6OY9cO4JK9Q@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <20181102224925.GM3817@ando.pearwood.info>
 <CA+3bQGFSTUUDadXMzD0a1784Pr3Z_5M7hT3XfUK6OY9cO4JK9Q@mail.gmail.com>
Message-ID: <20181102230732.GO3817@ando.pearwood.info>

On Fri, Nov 02, 2018 at 11:57:02PM +0100, Victor Stinner wrote:
> Le ven. 2 nov. 2018 ? 23:49, Steven D'Aprano <steve at pearwood.info> a ?crit :
> > How many people voted? Out of what (approximate) pool of potential
> > voters?
> 
> 25 voters on 65 core developers who have an account on discuss.python.org.

Thanks!


-- 
Steve

From chris.jerdonek at gmail.com  Fri Nov  2 19:30:57 2018
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 2 Nov 2018 16:30:57 -0700
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
Message-ID: <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>

It would have been nice to know beforehand if the results of the poll
were going to change the PEP. I didn't participate because I didn't
feel like the poll had a fair process like the PEP's themselves.

--Chris

On Fri, Nov 2, 2018 at 3:21 PM Brett Cannon <brett at python.org> wrote:
>
> FYI I just updated PEP 8001 with the result of the poll which very clearly favoured the Condorcet method for winner selection.
>
> On Tue, 30 Oct 2018 at 12:52, Tim Peters <tim.peters at gmail.com> wrote:
>>
>> There's a poll about the voting method to use to decide on the winning
>> governance PEP.  We'd like to see more people weigh in:
>>
>>     https://discuss.python.org/t/python-governance-electoral-system/290/26
>>
>> PEP 8001 specifies that IRV will be used.  There's pushback against
>> that.  Since a poll is a form of approval voting, there's also
>> pushback against using a poll to vote on the voting method.  But we
>> really don't have the time to pursue infinite regress to its end ;-)
>>
>> I'm not in charge of anything, so take this for what it's worth:  pick
>> the option(s) that are closest to what you can live with, but add a
>> comment to the poll if there's some aspect of what you vote for that
>> you really can't abide (e.g., at least one person said they would vote
>> for Approval, _except_ that they object to getting the PSF Board
>> involved in case there's a tie).  The high-order bit of this poll is
>> about the basic approaches people can live with, not details of how
>> problem cases are handled.
>> _______________________________________________
>> python-committers mailing list
>> python-committers at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From tim.peters at gmail.com  Fri Nov  2 20:09:35 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 2 Nov 2018 19:09:35 -0500
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
Message-ID: <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>

[Chris Jerdonek <chris.jerdonek at gmail.com>]
> It would have been nice to know beforehand if the results of the poll
> were going to change the PEP.

Don't look at me ;-)  Like I said, "I'm not in charge of anything",
and I had no input in changing PEP 8001 beyond contributing to the
message thread, same as everyone else.  I viewed the poll as being
informational, to get a sense of how people felt about the issues.
Apparently someone actually in charge of the PEP thought consensus was
"clear enough", presumably in part because of the poll results, but
also presumably because of the quite extensive following discussion
(of which the poll results can fairly be said to be representative).

> I didn't participate because I didn't feel like the poll had a fair
> process like the PEP's themselves.

Which you've already said in the discuss.python.org thread.  So,
mentally, when I viewed the poll, I added one vote to IRV for you.  I
don't know whether Brett did too, but IRV was trailing too much for it
to make a material difference.

As above, I expect it was really the discussion that drove the
decision, of which the poll results were but a summary.  But October
is over, so Brett can speak for himself now ;-)

From chris.jerdonek at gmail.com  Fri Nov  2 20:22:34 2018
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Fri, 2 Nov 2018 17:22:34 -0700
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
 <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>
Message-ID: <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>

On Fri, Nov 2, 2018 at 5:09 PM Tim Peters <tim.peters at gmail.com> wrote:
>
> [Chris Jerdonek <chris.jerdonek at gmail.com>]
> > It would have been nice to know beforehand if the results of the poll
> > were going to change the PEP.
>
> Don't look at me ;-)  Like I said, "I'm not in charge of anything",
> and I had no input in changing PEP 8001 beyond contributing to the
> message thread, same as everyone else.

My reply was to Brett and not to you. If I had known the poll was
going to be binding, I could have made an effort to participate in the
discussion and try to sway people. As it was, the discussion was
started and dominated by people who were against IRV. They are the
most motivated to change things, and they're also the ones most
motivated to participate in the poll. I couldn't afford to participate
in such a discussion otherwise, as I said in the discussion. There are
already 98 messages -- many of which are lengthy -- not to mention
messages in other threads. It would take a lot of time and emotional
energy to engage in such a discussion.

--Chris



> I viewed the poll as being
> informational, to get a sense of how people felt about the issues.
> Apparently someone actually in charge of the PEP thought consensus was
> "clear enough", presumably in part because of the poll results, but
> also presumably because of the quite extensive following discussion
> (of which the poll results can fairly be said to be representative).
>
> > I didn't participate because I didn't feel like the poll had a fair
> > process like the PEP's themselves.
>
> Which you've already said in the discuss.python.org thread.  So,
> mentally, when I viewed the poll, I added one vote to IRV for you.  I
> don't know whether Brett did too, but IRV was trailing too much for it
> to make a material difference.
>
> As above, I expect it was really the discussion that drove the
> decision, of which the poll results were but a summary.  But October
> is over, so Brett can speak for himself now ;-)

From donald at stufft.io  Fri Nov  2 21:04:39 2018
From: donald at stufft.io (Donald Stufft)
Date: Fri, 2 Nov 2018 21:04:39 -0400
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
 <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>
 <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>
Message-ID: <38DC9B84-D80F-49A8-A069-FA636FD3B48D@stufft.io>



> On Nov 2, 2018, at 8:22 PM, Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
> 
> On Fri, Nov 2, 2018 at 5:09 PM Tim Peters <tim.peters at gmail.com> wrote:
>> 
>> [Chris Jerdonek <chris.jerdonek at gmail.com>]
>>> It would have been nice to know beforehand if the results of the poll
>>> were going to change the PEP.
>> 
>> Don't look at me ;-)  Like I said, "I'm not in charge of anything",
>> and I had no input in changing PEP 8001 beyond contributing to the
>> message thread, same as everyone else.
> 
> My reply was to Brett and not to you. If I had known the poll was
> going to be binding, I could have made an effort to participate in the
> discussion and try to sway people. As it was, the discussion was
> started and dominated by people who were against IRV. They are the
> most motivated to change things, and they're also the ones most
> motivated to participate in the poll. I couldn't afford to participate
> in such a discussion otherwise, as I said in the discussion. There are
> already 98 messages -- many of which are lengthy -- not to mention
> messages in other threads. It would take a lot of time and emotional
> energy to engage in such a discussion.
> 
> --Chris
> 


I don?t believe the poll *was* binding, certainly I suspect that if the results of the poll had been say, tied instead of a blowout that even if Condorcet had barely won out, that the PEP would not have changed (other than to update that while there were other methods, discussion around them compared to IRV was inconclusive). Rather I think that the poll and the entire discussion was weighed, both of which provide different signals (discussion tends to overweight people who are more passionate, whereas the poll takes very little effort to participate in, but tends to overweight people who don?t really care).

Honestly, I?m not sure what you thought the point of the discussion was if not to advocate that the PEP itself should change and thus a possible outcome of that was that the PEP would change. Why else would that discussion exist? I can sympathize with being unable to participate due to time constraints, but we also have to weigh in realities like we?re never going to be able to structure such a discussion such that 100% of people are able and willing to participate in it, the best you can do is try to structure it to give everyone as much chance as possible.

The selection of a voting mechanism ended up going through these layers:

1. In person discussion at an event in the West Coast USA.
2. Online discussion largely in discourse, but slightly on python-committers as well.
3. An online poll on discourse, with notification to python-committers.

Of those, (1) selected IRV and while I was not there, I get the send that there wasn?t a strong preference for IRV in that meeting, rather it was better than plurality and something the attendees were familiar with. (2) seemed to me (and I may be biased) to heavily weight towards a ?Anything but Plurality or IRV? direction, and (3) ultimately confirmed that.

While not everyone might not have gotten to have their voice heard, the discussion and the poll was accessible to any committer who could participate via online (which I suspect is most of them) with the barest amount of investment being to vote in the poll and otherwise ignore the discussion.

I would also point out that while the poll itself was run via the Approval voting method [1], looking at the numbers it?s not hard to come to the conclusion that it?s hard to suggest that the *method* used by the poll gives us invalid results. For instance, if we had instead run the poll using IRV instead of Approval *and* we assume that every single person who approved of IRV would have ranked it first (and anyone who didn?t approve of IRV at all would have ranked it last)? then IRV still would have lost even if the poll was run via IRV. 

Unfortunately, It?s hard to know exactly how the voting mechanism would have affected the other results because while IRV was ?disapproved? by a significant margin, the other ones were not.

However, since the poll was run using Approval, it?s hard for someone advocating for the Approval method to say that the results are invalid due to the method used, since it was their desired method that chose a method other than Approval.

I suspect folks who prefer Condorcet are not going to complain too much about the poll using Approval, since it fair and away preferred Condorcet (21 of the 25 voters were OK with Condorcet) although it?s *possible* that the 20 people who were Condorcet voters would not have ranked it first, but that it was everyone?s second choice. Though if their first choice was Approval, see above!

Really, 3-2-1 is the only one that it feels to me like could really argue about the tally method of the poll. The poll wasn?t run with their preferred method (like anyone who preferred Approval), they didn?t win, their loss wasn?t so great that they would have, for sure, lost under their own method [2], and if everyone who approved of them had picked them as their first choice, that?s roughly half of the people taking the poll. Fortunately I can say as one of the people who approved of 3-2-1, it would *not* have been my first choice, which pushes it from 12 to 13, to 11 to 14 which makes it more unlikely that 3-2-1 would have won in any other method as well.

Fortunately, the margins of the poll are such that the outcome is unlikely to have changed by having run the poll under a different method.

[1] Largely because that?s what discourse polls supported, plus getting into a discussion about choosing the method we use to choose the method that we use to choose the method that we use to choose the method that we use to choose the PEP is an unsolvable, infinite problem.
[2] We might be able to compute this by assuming approval = +1, disapproval = -1 and then running the simulation, but that?s more effort than I feel like putting in.


From tim.peters at gmail.com  Fri Nov  2 21:18:05 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 2 Nov 2018 20:18:05 -0500
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
 <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>
 <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>
Message-ID: <CAExdVNmFehxiQWpVuCBYVN2-9-=CTSnktgEEsaRqFSsY0pgJ-w@mail.gmail.com>

[Chris Jerdonek <chris.jerdonek at gmail.com>]
> My reply was to Brett and not to you.

So it was!  I missed that - I just noticed that the vast bulk of the
text I was replying to was a quote of my message here about the poll.
I should have checked.


> If I had known the poll was going to be binding,

As before, I had - and have - no reason to believe the poll was
binding.  It did, however, fairly reflect the sentiments expressed in
the long thread of which it was a part - except for not recording your
opinion, but because you didn't vote.


> I could have made an effort to participate in the
> discussion and try to sway people. As it was, the discussion was
> started and dominated by people who were against IRV. They are the
> most motivated to change things, and they're also the ones most
> motivated to participate in the poll. I couldn't afford to participate
> in such a discussion otherwise, as I said in the discussion. There are
> already 98 messages -- many of which are lengthy -- not to mention
> messages in other threads. It would take a lot of time and emotional
> energy to engage in such a discussion.

Decisions are often driven by people who do give the time and
emotional energy to discussing the issues at length.  It's not like
there was universal agreement in the thread - there was lots of give &
take.  IRV "lost" because _nobody_ spoke for it.  About 40% of the
core developers who have an account on discuss.python.org did vote in
the poll, so it's not like it was just a tiny percentage of developers
who made their opinion known.  And we know some didn't vote because
they couldn't care less how the vote is run (e.g., Guido appears to be
in that category).

I'd be concerned it there were evidence that there _might_ be
widespread support for the PEP as it was originally written - but I
just don't see any.  Now that Brett announced the change, you're - so
far - the only one objecting to the change.

I'm not a fan of Condorcet methods myself (but because of their
conceptual complexity - their results are fine), but even I'm not
complaining ;-)

From tim.peters at gmail.com  Fri Nov  2 21:34:25 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 2 Nov 2018 20:34:25 -0500
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <38DC9B84-D80F-49A8-A069-FA636FD3B48D@stufft.io>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
 <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>
 <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>
 <38DC9B84-D80F-49A8-A069-FA636FD3B48D@stufft.io>
Message-ID: <CAExdVNmC8ett2xEooRvYQyyHSFG0MinotyraG=ZKSDsSpuS7QA@mail.gmail.com>

[Donald Stufft <donald at stufft.io>]
> ...
> Really, 3-2-1 is the only one that it feels to me like could really argue about
> the tally method of the poll.

Since I suggested 3-2-1 to begin with, let me assure you that Approval
for the poll was fine with me.  Heck, I didn't even once object that
the pool creator thought so little of 3-2-1 that he didn't even name
it correctly ;-)  (I _assume_ the "1-2-3" in the poll was intended to
be "3-2-1").

> ...
> Fortunately I can say as one of the people who approved of 3-2-1, it would *not*
> have been my first choice,

Nor mine!  STAR would have been my first choice, but it didn't even
appear in the poll (3-2-1 is just too new to trust yet).  As is, "pure
Condorcet" was my first choice, which happened to be the winner, so I
can hardly complain.

From steve.dower at python.org  Fri Nov  2 22:26:24 2018
From: steve.dower at python.org (Steve Dower)
Date: Fri, 2 Nov 2018 19:26:24 -0700
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <CA+3bQGHoGEUiyxiJ9uah7VoCDxWaB295dy7-zYbvzbt+4t_Ssw@mail.gmail.com>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
 <88552487-9498-fa52-3ff5-cdb9fdc85355@python.org>
 <CA+3bQGHoGEUiyxiJ9uah7VoCDxWaB295dy7-zYbvzbt+4t_Ssw@mail.gmail.com>
Message-ID: <f3cb5121-bb82-7d27-eeab-e8a411ae988f@python.org>

On 02Nov2018 0933, Victor Stinner wrote:
> Mentoring is an investment in the long term. Is it better to pay
> someone to review and merge PRs?
> 
> Reviewing PRs is also a way to help and train contributors. It's not
> very different from mentoring, depending on your definition of
> mentoring :-)

The problem here is that most of the reviews require either specialised 
knowledge of the area being changed (essentially the ability to predict 
the flow-on impact of any change), or a strong decision that the change 
is good. This severely limits the people who can approve most PRs.

Every time I start going through the list of PRs, I find that I'm 
obviously not the right person to approve the change, or that I should 
not be unilaterally approving the change (without discussing it on 
python-dev). Which means that you can't pay me to review most PRs, 
because I simply can't do it :) So who do we get to review them?

Without a stated direction/vision for CPython, it's very hard for any 
individual developer to make unilateral decisions on many PRs. And since 
there are many major areas, each with their own "team" or "expert", we 
really need those maintainers to be reviewing PRs in their areas, and 
also feeling empowered and supported to make leadership-like decisions 
for their areas.

Mentoring is certainly the solution to the latter, provided the current 
experts are mentoring new experts in their area, and landing a 
governance model that helps us decide what sorts of other changes are 
good for Python solves the former. Simply paying "someone" doesn't help.

Cheers,
Steve

From vstinner at redhat.com  Fri Nov  2 22:37:02 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 3 Nov 2018 03:37:02 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
Message-ID: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>

Hi,

According to the PEP 8001: "The vote will happen in a 2-week-long
window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's
now in less than two weeks.

I see that the PEP 8001 is still being updated (voting method). Should
we still expect new changes before the vote starts? Can we set a
deadline, like November 15 (Anywhere-on-Earth)?

Nathaniel Smith and Donald Stuff have a draft PEP 8016 which is still
at the "ideas" stage:
https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/28

What is the deadline to submit new governance PEP and to update
governance PEPs? November 15 (Anywhere-on-Earth)?

For the PEP 8001, who is going to organize the vote? It seems like
there isn't much to do. The bare minimum is just to create the private
repository. Or is it already created?

Another task would be to send notices about the vote on all
communication channels used by core developers? Announce 1 week before
it starts, when it starts, and maybe also remainder 3 days and 1 day
before it ends?

Does someone plan to have holiday during the vote and will not be able to vote?

Which tool can be used to compute the vote result? Parse the text
files in the Git repository and implement the Condorcet method.

Victor

From tim.peters at gmail.com  Fri Nov  2 23:24:36 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 2 Nov 2018 22:24:36 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
Message-ID: <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>

[Victor Stinner <vstinner at redhat.com>,
 asking lots of good questions]
> ...
> I see that the PEP 8001 is still being updated (voting method). Should
> we still expect new changes before the vote starts?

I don't detect any groundswell of opposition anymore now that the
voting method changed.

Nevertheless, I probably won't vote - I object to public ballots on
principle.  That's been raised by others, so I won't repeat the
arguments, and I appear to be very much in a minority here.

> Can we set a deadline, like November 15 (Anywhere-on-Earth)?

Good idea!

> ...
> Which tool can be used to compute the vote result? Parse the text
> files in the Git repository and implement the Condorcet method.

"Pure Condorcet" is close to trivial to tally:  there is a Condorcet
winner, or there isn't.  I wouldn't even bother to write code to
figure it out.  For example, write a simple script to convert each
ballot to a single line for the following web page, paste the ballots
into the text box, and click the "Calculate all winners" button:

    https://www.cse.wustl.edu/~legrand/rbvote/calc.html

The result page will tell you whether or not a Condorcet winner
exists.  As a bonus, it will also tell you who the winner would be
under 15 different ranked-ballot scoring methods.  Which may be handy
to know in the unlikely case there isn't a Condorcet winner.  For
example, if "Schulze" and "Hare" (which was called "IRV" in the
previous PEP iteration) both pick the same winner then, I bet most
people would say "ah, good enough".

From ericsnowcurrently at gmail.com  Fri Nov  2 23:40:11 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 2 Nov 2018 21:40:11 -0600
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
Message-ID: <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>

On Fri, Nov 2, 2018, 21:24 Tim Peters <tim.peters at gmail.com wrote:

> Nevertheless, I probably won't vote - I object to public ballots on
> principle.  That's been raised by others, so I won't repeat the
> arguments, and I appear to be very much in a minority here.
>

Would it help if we only published who voted, and kept their votes
private?  Publishing the actual votes probably doesn't make a big
difference here, relative to the broader Python/tech community.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181102/a51f0c99/attachment-0001.html>

From vstinner at redhat.com  Fri Nov  2 23:40:46 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 3 Nov 2018 04:40:46 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
Message-ID: <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>

> > I see that the PEP 8001 is still being updated (voting method). Should
> > we still expect new changes before the vote starts?
>
> I don't detect any groundswell of opposition anymore now that the
> voting method changed.

I'm unhappy with the "[] Further discussion" choice. We have a
governance crisis. Many people would like to see it resolved as soon
as possible, I don't see the ability to vote for "[] Further
discussion" as a way to resolve this crisis.

There are 6 proposed governance PEPs (maybe 7? ;-)). I don't expect
that everybody will agree on everything in a PEP, but everybody should
be at least able to order them to vote, no? If no, well, maybe don't
vote?


Le sam. 3 nov. 2018 ? 04:24, Tim Peters <tim.peters at gmail.com> a ?crit :
> Nevertheless, I probably won't vote - I object to public ballots on
> principle.

I'm not surprised that someone doesn't like one part of the PEP 8001.
But well, we need to move on and take a decision...


> "Pure Condorcet" is close to trivial to tally:  there is a Condorcet
> winner, or there isn't.  I wouldn't even bother to write code to
> figure it out.  For example, write a simple script to convert each
> ballot to a single line for the following web page, paste the ballots
> into the text box, and click the "Calculate all winners" button:
>
>     https://www.cse.wustl.edu/~legrand/rbvote/calc.html

Yes, I'm asking for such script. I didn't say that it would be overcomplicated.

The PEP 8001 is not trivial, it expects a specific format:

**DO NOT LEAVE ANY BRACKETS BLANK!**
**DO NOT REPEAT A RANKING/NUMBER!**

Maybe it would help to have a script to validate my own vote? (Also
ensure that all choices are present?)

> The result page will tell you whether or not a Condorcet winner
> exists.  As a bonus, it will also tell you who the winner would be
> under 15 different ranked-ballot scoring methods.  Which may be handy
> to know in the unlikely case there isn't a Condorcet winner.  For
> example, if "Schulze" and "Hare" (which was called "IRV" in the
> previous PEP iteration) both pick the same winner then, I bet most
> people would say "ah, good enough".

Hum, it seems like you are unhappy with the chosen voting method.
Again, we have to move on and take a decision. We cannot discuss
voting methods forever, and there is no perfect voting methods. Only
tradeoffs. I looked at the length of the discussion, and I understood
that everybody had the opportunity to express their opinion, and the
discussion gone deeply in voting methods, as Carol, I was impressed by
the level of the discussion :-)

Victor

From vstinner at redhat.com  Fri Nov  2 23:44:22 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 3 Nov 2018 04:44:22 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
Message-ID: <CA+3bQGGNCUMCf5f-tDcqTei4Zv9xNgOiOS=yOz2SnNt6GHEkFg@mail.gmail.com>

Le sam. 3 nov. 2018 ? 04:40, Eric Snow <ericsnowcurrently at gmail.com> a ?crit :
> Would it help if we only published who voted, and kept their votes private?  Publishing the actual votes probably doesn't make a big difference here, relative to the broader Python/tech community.

The PEP has a whole section explaining the rationale:
https://www.python.org/dev/peps/pep-8001/#why-should-the-vote-be-public

This PEP has 9 authors and has been discussed in length.

Maybe we should stop to change the vote method? :-) (As I wrote, the
last limit for me to changes the PEP 8001 is Nov. 15, the day before
voting on governance PEPs starts.)

Victor

From ericsnowcurrently at gmail.com  Sat Nov  3 00:02:23 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 2 Nov 2018 22:02:23 -0600
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGGNCUMCf5f-tDcqTei4Zv9xNgOiOS=yOz2SnNt6GHEkFg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
 <CA+3bQGGNCUMCf5f-tDcqTei4Zv9xNgOiOS=yOz2SnNt6GHEkFg@mail.gmail.com>
Message-ID: <CALFfu7D=QVGwuBPwws2YVvKyZdf6OOwtKVaJtpUdv7UfoQX+fg@mail.gmail.com>

On Fri, Nov 2, 2018, 21:44 Victor Stinner <vstinner at redhat.com wrote:

> Le sam. 3 nov. 2018 ? 04:40, Eric Snow <ericsnowcurrently at gmail.com> a
> ?crit :
> > Would it help if we only published who voted, and kept their votes
> private?  Publishing the actual votes probably doesn't make a big
> difference here, relative to the broader Python/tech community.
>
> The PEP has a whole section explaining the rationale:
> https://www.python.org/dev/peps/pep-8001/#why-should-the-vote-be-public
>
> This PEP has 9 authors and has been discussed in length.
>

Right.  I'm one of the authors. :)  When we discussed this point it was for
the sake of communicating validity to the community.  However, I'm not
convinced that publishing more than the list of voters is needed for that.
If that's something that would make Tim more comfortable with voting then I
suggest we consider it.

-eric

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181102/31965fd1/attachment.html>

From tim.peters at gmail.com  Sat Nov  3 00:06:57 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 2 Nov 2018 23:06:57 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
Message-ID: <CAExdVNnJm52DDDgCaaEDEDo=poS04Xhh8X2mJPM6fra4a5RX2g@mail.gmail.com>

[Victor Stinner <vstinner at redhat.com>]
> I'm unhappy with the "[] Further discussion" choice. We have a
> governance crisis. Many people would like to see it resolved as soon
> as possible, I don't see the ability to vote for "[] Further
> discussion" as a way to resolve this crisis.

Nobody else does either.  This was added for political reasons:  it's
_expected_ that virtually everyone will rank "Further discussion"
last, so we can "prove" to the world that we really do want it to end
ASAP.  "See?  We voted, and 'further discussion' came in dead last!"


> There are 6 proposed governance PEPs (maybe 7? ;-)). I don't expect
> that everybody will agree on everything in a PEP, but everybody should
> be at least able to order them to vote, no? If no, well, maybe don't
> vote?

I'm missing context for this.  Has someone complained about that?  I
_would_ ;-) , but why bother.  Having to strictly rank forces people
to fabricate distinctions they may not actually believe.  A voting
protocol that forces dishonesty isn't attractive.  Note that Condorcet
methods don't generally require this; for example, Schulze is happy if
you rate any number of choices "all the same to me".  If you in fact
have no preference among (say) 3 of the PEPs, why must you be forced
to say that you strictly most like just one of them - and strictly
most dislike another?

"The reason" appears to be that the more of that people do, the more
likely there won't be a Condorcet winner.

> ...
> I'm not surprised that someone doesn't like one part of the PEP 8001.
> But well, we need to move on and take a decision...

Sure!

>> "Pure Condorcet" is close to trivial to tally:  there is a Condorcet
>> winner, or there isn't.  I wouldn't even bother to write code to
>> figure it out.  For example, write a simple script to convert each
>> ballot to a single line for the following web page, paste the ballots
>> into the text box, and click the "Calculate all winners" button:
>>
>>     https://www.cse.wustl.edu/~legrand/rbvote/calc.html

> Yes, I'm asking for such script. I didn't say that it would be overcomplicated.

Well, that professor already wrote one.  Give me the task of tallying
the ballots. and I'd do just what I said above :-)

> The PEP 8001 is not trivial, it expects a specific format:
>
> **DO NOT LEAVE ANY BRACKETS BLANK!**
> **DO NOT REPEAT A RANKING/NUMBER!**
>
> Maybe it would help to have a script to validate my own vote? (Also
> ensure that all choices are present?)

Someone will have to do that, but it's a different issue than I was
answering above:  your original "Which tool can be used to compute the
vote result?".

> ...
> Hum, it seems like you are unhappy with the chosen voting method.

Not at all!  If we had used a ranked ballot in the poll, "Pure
Condorcet" would have been my #1 choice.  For this election.

> Again, we have to move on and take a decision.

Yup.  In the poll, I voted "approve" for everything, but retracted my
vote for IRV after it was pointed out that _other_ PEPs pointed back
at 8001 to define the voting method _they_ used too.  I was willing to
endure IRV for a PEP 8001 one-shot vote, but not for eternity.

I could live with any of the other methods forever, but if we had a
PEP on voting methods in general, _then_ I'd push for hybrid
score-runoff methods, like STAR and 3-2-1.  They're much easier to
understand, and do better in large-scale voting simulations, than the
others.

> We cannot discuss voting methods forever, and there is no perfect voting
> methods. Only tradeoffs.

Which I know ;-)  But some nevertheless do better than others under
very widely varying assumptions.  That's why, e.g., absolutely nobody
is in favor of plurality.  "But nothing is perfect" isn't actually a
reason for accepting something that's awful in ordinary conditions ;-)

The best of the Condorcet methods are in fact very good.

> I looked at the length of the discussion, and I understood
> that everybody had the opportunity to express their opinion, and the
> discussion gone deeply in voting methods, as Carol, I was impressed by
> the level of the discussion :-)

From tim.peters at gmail.com  Sat Nov  3 00:20:02 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 2 Nov 2018 23:20:02 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
Message-ID: <CAExdVN=SJfdn-K1hH8NV8_UdszmK6fB19VAdJ8DJTwDkhD2chA@mail.gmail.com>

[Tim]
>> Nevertheless, I probably won't vote - I object to public ballots on
>> principle.  That's been raised by others, so I won't repeat the
>> arguments, and I appear to be very much in a minority here.

[Eric Snow <ericsnowcurrently at gmail.com>]
> Would it help if we only published who voted, and kept their votes
> private?  Publishing the actual votes probably doesn't make a
> big difference here, relative to the broader Python/tech community.

That would probably be enough to convince me to vote, but I don't want
to hold things up either.  If I'm the only one, why bother?  It's not
like my vote will change the result ;-)

BTW, the years I was on the PSF Board, I always wanted everyone to
know how we voted on everything.  But I was elected to that position,
so was voting as a representative of those who elected me.

But nobody has any more business knowing how I vote on a PEP than,
say, how I vote for the local mayor.  That's between me and my
conscience.  Your vote is between you and yours, and I want actively
_not_ to be able to see how others voted.

Although I'm all in favor of making the PEP ballots public, if
stripped of personally identifying info.

From donald at stufft.io  Sat Nov  3 00:38:59 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 00:38:59 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVN=SJfdn-K1hH8NV8_UdszmK6fB19VAdJ8DJTwDkhD2chA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
 <CAExdVN=SJfdn-K1hH8NV8_UdszmK6fB19VAdJ8DJTwDkhD2chA@mail.gmail.com>
Message-ID: <D4406751-8043-4B1E-AB5A-FEC0A88757D5@stufft.io>



> On Nov 3, 2018, at 12:20 AM, Tim Peters <tim.peters at gmail.com> wrote:
> 
> [Tim]
>>> Nevertheless, I probably won't vote - I object to public ballots on
>>> principle.  That's been raised by others, so I won't repeat the
>>> arguments, and I appear to be very much in a minority here.
> 
> [Eric Snow <ericsnowcurrently at gmail.com>]
>> Would it help if we only published who voted, and kept their votes
>> private?  Publishing the actual votes probably doesn't make a
>> big difference here, relative to the broader Python/tech community.
> 
> That would probably be enough to convince me to vote, but I don't want
> to hold things up either.  If I'm the only one, why bother?  It's not
> like my vote will change the result ;-)
> 
> BTW, the years I was on the PSF Board, I always wanted everyone to
> know how we voted on everything.  But I was elected to that position,
> so was voting as a representative of those who elected me.
> 
> But nobody has any more business knowing how I vote on a PEP than,
> say, how I vote for the local mayor.  That's between me and my
> conscience.  Your vote is between you and yours, and I want actively
> _not_ to be able to see how others voted.
> 
> Although I'm all in favor of making the PEP ballots public, if
> stripped of personally identifying info.
> _______________________________________________


FWIW I tend to agree with Tim on public vs private ballots, although unlike him I don?t feel strongly enough to abstain from voting on this one particular vote.

On a practical matter, keeping the ballots secret will rely on either having a trusted person to tally the election results or using some software that will do it for us. There is https://civs.cs.cornell.edu <https://civs.cs.cornell.edu/> which we could use that does offer private ballots and offers making the ballots (with or without a name attached to them) public. It doesn?t support ?pure? Condorcet but it should be easy enough to take the public but anonymous ballots and compute to determine if there was a condorcet winner or if one of the methods had to break a cycle, and if there wasn?t a condorcet winner, just re-run the election. Beyond that, I?m not sure what other options there are for anonymous ranked voting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/6d08407e/attachment.html>

From donald at stufft.io  Sat Nov  3 00:41:18 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 00:41:18 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <D4406751-8043-4B1E-AB5A-FEC0A88757D5@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CALFfu7CoDggjj9S-4mDe7XRt=N68hVw0eFvwkNdKFU7E7zm4ng@mail.gmail.com>
 <CAExdVN=SJfdn-K1hH8NV8_UdszmK6fB19VAdJ8DJTwDkhD2chA@mail.gmail.com>
 <D4406751-8043-4B1E-AB5A-FEC0A88757D5@stufft.io>
Message-ID: <13D88E4F-32F2-429A-AE9F-320BA5827F3E@stufft.io>



> On Nov 3, 2018, at 12:38 AM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
> 
>> On Nov 3, 2018, at 12:20 AM, Tim Peters <tim.peters at gmail.com <mailto:tim.peters at gmail.com>> wrote:
>> 
>> [Tim]
>>>> Nevertheless, I probably won't vote - I object to public ballots on
>>>> principle.  That's been raised by others, so I won't repeat the
>>>> arguments, and I appear to be very much in a minority here.
>> 
>> [Eric Snow <ericsnowcurrently at gmail.com <mailto:ericsnowcurrently at gmail.com>>]
>>> Would it help if we only published who voted, and kept their votes
>>> private?  Publishing the actual votes probably doesn't make a
>>> big difference here, relative to the broader Python/tech community.
>> 
>> That would probably be enough to convince me to vote, but I don't want
>> to hold things up either.  If I'm the only one, why bother?  It's not
>> like my vote will change the result ;-)
>> 
>> BTW, the years I was on the PSF Board, I always wanted everyone to
>> know how we voted on everything.  But I was elected to that position,
>> so was voting as a representative of those who elected me.
>> 
>> But nobody has any more business knowing how I vote on a PEP than,
>> say, how I vote for the local mayor.  That's between me and my
>> conscience.  Your vote is between you and yours, and I want actively
>> _not_ to be able to see how others voted.
>> 
>> Although I'm all in favor of making the PEP ballots public, if
>> stripped of personally identifying info.
>> _______________________________________________
> 
> 
> FWIW I tend to agree with Tim on public vs private ballots, although unlike him I don?t feel strongly enough to abstain from voting on this one particular vote.
> 
> On a practical matter, keeping the ballots secret will rely on either having a trusted person to tally the election results or using some software that will do it for us. There is https://civs.cs.cornell.edu <https://civs.cs.cornell.edu/> which we could use that does offer private ballots and offers making the ballots (with or without a name attached to them) public. It doesn?t support ?pure? Condorcet but it should be easy enough to take the public but anonymous ballots and compute to determine if there was a condorcet winner or if one of the methods had to break a cycle, and if there wasn?t a condorcet winner, just re-run the election. Beyond that, I?m not sure what other options there are for anonymous ranked voting.

Oh, unfortunately this also doesn?t allow publishing *Who* voted without attaching them to a ballot, it?s either public, attached to the ballot, or private (if you?re not publishing the names, the system doesn?t even keep them, it just generates unique voter IDs for each).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/90c70d00/attachment-0001.html>

From njs at pobox.com  Sat Nov  3 00:45:25 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 2 Nov 2018 21:45:25 -0700
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
Message-ID: <CAPJVwBn1txdb68V-AnCSWpW64fVsJbmb93KV83e4cBGq4z-2KA@mail.gmail.com>

On Fri, Nov 2, 2018 at 8:40 PM, Victor Stinner <vstinner at redhat.com> wrote:
> The PEP 8001 is not trivial, it expects a specific format:
>
> **DO NOT LEAVE ANY BRACKETS BLANK!**
> **DO NOT REPEAT A RANKING/NUMBER!**
>
> Maybe it would help to have a script to validate my own vote? (Also
> ensure that all choices are present?)

I'm not sure what the motivation for those restrictions is. I guess
with IRV there isn't an obvious way to handle a repeated number, but
with Condorcet it's no problem. And both methods are fine with leaving
some options blank (it's equivalent to ranking the blank options as
tied for dead last).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From tim.peters at gmail.com  Sat Nov  3 01:44:18 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 00:44:18 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAPJVwBn1txdb68V-AnCSWpW64fVsJbmb93KV83e4cBGq4z-2KA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
 <CAPJVwBn1txdb68V-AnCSWpW64fVsJbmb93KV83e4cBGq4z-2KA@mail.gmail.com>
Message-ID: <CAExdVNmD4E5e1kWaqb_p=OdHUGc1r4qvk5K_p7BytjkX5_2hsA@mail.gmail.com>

[Victor Stinner <vstinner at redhat.com>]
>> The PEP 8001 is not trivial, it expects a specific format:
>>
>> **DO NOT LEAVE ANY BRACKETS BLANK!**
>> **DO NOT REPEAT A RANKING/NUMBER!**

[Nathaniel Smith <njs at pobox.com>]
> I'm not sure what the motivation for those restrictions is. I guess
> with IRV there isn't an obvious way to handle a repeated number,

FWIW, I've never seen any IRV variant that allowed duplicate rankings.
And I don't see how it could:  at each round it's counting only the
number of _first_ ranked candidates among those who remain, and if a
voter had ties for their first place candidates that voter would be
helping multiple candidates survive the round.  "Not fair."


> but with Condorcet it's no problem. And both methods are fine
> with leaving some options blank (it's equivalent to ranking the
> blank options as tied for dead last).

But leaving some candidates unrated is common in IRV schemes.  When
the last of a given ballot's rated candidates is eliminated, that
ballot is thrown out and the election continues as if it had never
existed (in particular, it no longer counts for the "majority" needed
to win the next round).

PEP 8001 says:

"""
A vote which omits candidates in the ranking is invalid. This is
because such votes are incompatible with the desired properties listed
above, namely:

Making voters consider alternatives, as well as
Doing everything possible to reach a conclusion in a single election.
"""

The first point is dubious.  While it may be hard to prove, what will
happen in reality is that some voters will simply make up rankings for
PEPs they never even read.  This is so common in forced-ranking
systems that it has a name:

    https://en.wikipedia.org/wiki/Donkey_vote

There may be some merit to the second point, and especially if
donkey-voting is common:  the more people mindlessly give a rank equal
to a candidate's distance from the top, the less likely cycles are to
form (assuming all ballots list the PEPs in the same order - which
they really shouldn't, but probably will ;-) ).

In any case, without IRV there's scant reason to require that all
ranks be distinct, and I think dropping that requirement would be a
serious improvement, both for making it easier to construct a valid
ballot, and especially to allow voters more possibility to express
their true preferences (including "these two, three, ... are equally
fine by me").

What may be hard to get across then is that, e.g., the ballot rankings

    1 1 1 6 6 6
and
    5 5 5 6 6 6

have exactly the same effect:  "I like the first three better than the
last three - maybe a little, maybe a lot, you just can't tell from
what I'm allowed to express."

From antoine at python.org  Sat Nov  3 05:39:08 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 10:39:08 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
Message-ID: <a14181f2-3e7d-07de-780a-6cc7e3035527@python.org>


Le 03/11/2018 ? 04:40, Victor Stinner a ?crit?:
>>> I see that the PEP 8001 is still being updated (voting method). Should
>>> we still expect new changes before the vote starts?
>>
>> I don't detect any groundswell of opposition anymore now that the
>> voting method changed.
> 
> I'm unhappy with the "[] Further discussion" choice. We have a
> governance crisis. Many people would like to see it resolved as soon
> as possible, I don't see the ability to vote for "[] Further
> discussion" as a way to resolve this crisis.

Why are you worried?  If many people would like to see the "crisis" (I
would call it a void) resolved early, then probably "Further discussion"
won't win.  So how is its presence a problem?

Regards

Antoine.

From p.f.moore at gmail.com  Sat Nov  3 06:55:14 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 3 Nov 2018 10:55:14 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
Message-ID: <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>

On Sat, 3 Nov 2018 at 02:37, Victor Stinner <vstinner at redhat.com> wrote:
>
> According to the PEP 8001: "The vote will happen in a 2-week-long
> window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's
> now in less than two weeks.
>
> I see that the PEP 8001 is still being updated (voting method). Should
> we still expect new changes before the vote starts? Can we set a
> deadline, like November 15 (Anywhere-on-Earth)?
>
> Nathaniel Smith and Donald Stuff have a draft PEP 8016 which is still
> at the "ideas" stage:
> https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/28
>
> What is the deadline to submit new governance PEP and to update
> governance PEPs? November 15 (Anywhere-on-Earth)?

Following on from this, where and when is the discussion on PEPs
happening? I guess maybe discord, but I haven't seen much (I only "pop
in" occasionally and skim for new threads). Specifically, I'm looking
for threads that *compare* proposals - and all I'm seeing is threads
on individual proposals, ironing out details and technicalities -
which is important, sure, but not relevant to me in terms of knowing
how proposals compare, and what "public opinion" is favouring.

The reason I'm interested in public discussions is that I don't have a
particularly strong opinion on the governance model we choose per se,
so I'm mostly happy to abstain on a "I trust the rest of the core devs
to come up with a sensible decision" basis. **However**, in order to
validate that trust, a key part for me is following the discussions,
and getting a sense of the overall views of the group. But in this
(particularly crucial) instance, I have utterly no sense of what
proposals are the front runners, which are considered to have open
questions, etc. Up until now, I'd taken that to be because the
proposals weren't final, and discussions hadn't really started. But
now that the vote is getting close, I'm getting more and more
concerned - with no sense of the possible direction of the vote, how
can I trust that the decision will be one I can be comfortable with -
and how do I influence the direction except by participating in the
discussions I've been unable to locate?

Currently, I feel like my only option is to abstain and hope - I don't
have the time (or knowledge) to review, understand and assess the
proposals well enough to make an informed vote, but I have no way of
assessing the "expert opinions" of those who do, to allow me to make a
broad judgement. Frankly, I feel pretty disenfranchised by the process
at the moment.

Paul

From ethan at stoneleaf.us  Sat Nov  3 10:22:21 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 3 Nov 2018 07:22:21 -0700
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
Message-ID: <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>

On 11/03/2018 03:55 AM, Paul Moore wrote:

> Frankly, I feel pretty disenfranchised by the process
> at the moment.

+1

--
~Ethan~

From stefan at bytereef.org  Sat Nov  3 11:19:57 2018
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 3 Nov 2018 16:19:57 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
Message-ID: <20181103151956.GA6050@bytereef.org>

On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote:
> On 11/03/2018 03:55 AM, Paul Moore wrote:
> 
> >Frankly, I feel pretty disenfranchised by the process
> >at the moment.
> 
> +1

I wouldn't go as far as disenfranchised, but just this thread made it clear
to me that taking in information is at least 10x faster if presented on a
mailing list.

Discourse feels like eating soup with a fork, especially now that the
volume is higher.


Stefan Krah




From antoine at python.org  Sat Nov  3 11:22:30 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 16:22:30 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <20181103151956.GA6050@bytereef.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
Message-ID: <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>


Le 03/11/2018 ? 16:19, Stefan Krah a ?crit?:
> On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote:
>> On 11/03/2018 03:55 AM, Paul Moore wrote:
>>
>>> Frankly, I feel pretty disenfranchised by the process
>>> at the moment.
>>
>> +1
> 
> I wouldn't go as far as disenfranchised, but just this thread made it clear
> to me that taking in information is at least 10x faster if presented on a
> mailing list.
> 
> Discourse feels like eating soup with a fork, especially now that the
> volume is higher.

Indeed.  As soon as a discussion is starting to become branchy,
Discourse just ruins readability compared to a normal threaded
discussion system.  The electoral system discussion is an example of that:
https://discuss.python.org/t/python-governance-electoral-system/290

Regards

Antoine.

From taleinat at gmail.com  Sat Nov  3 13:06:09 2018
From: taleinat at gmail.com (Tal Einat)
Date: Sat, 3 Nov 2018 19:06:09 +0200
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <f3cb5121-bb82-7d27-eeab-e8a411ae988f@python.org>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
 <88552487-9498-fa52-3ff5-cdb9fdc85355@python.org>
 <CA+3bQGHoGEUiyxiJ9uah7VoCDxWaB295dy7-zYbvzbt+4t_Ssw@mail.gmail.com>
 <f3cb5121-bb82-7d27-eeab-e8a411ae988f@python.org>
Message-ID: <CALWZvp69zgyRae9fyza6FS7rg0gephqLmHNk4g+NCmwoDkV0NQ@mail.gmail.com>

I'll try to address some of the points brought up here without trying to
"sell" this too much.

To reiterate: I'm suggesting the "Mentorship Program" only because of an
apparent lack of regular contributors, many devs who would like to be
mentored, and a low availability of core devs for mentoring.


On Fri, Nov 2, 2018 at 6:34 PM Victor Stinner wrote:

Mentoring is an investment in the long term. Is it better to pay
> someone to review and merge PRs?
>

This would basically be paying someone to do just one part of a core dev's
work, and IMO that's a bad idea in general. I also specifically think it
would far less effective in the long-term than mentoring, but that's hard
to qualify.


> Reviewing PRs is also a way to help and train contributors. It's not
> very different from mentoring, depending on your definition of
> mentoring :-)


It's *very* different from my method of mentoring. I do many additional
things, among them:

* first and foremost, those mentored having a long-term plan and partner
* settings expectations and providing encouragement
* helping choose appropriate tasks
* answering little "silly" questions that many feel uncomfortable to raise
in public forums
* explaining lots of small details about process, tools, priorities and
more; for example, what kind of changes are backported and how far back
* maintaining momentum over a significant period of time

Reviewing PRs is one significant piece of my mentoring, but IMO not the
most important one.


On Sat, Nov 3, 2018 at 4:26 AM Steve Dower wrote:

The problem here is that most of the reviews require either specialised
> knowledge of the area being changed (essentially the ability to predict
> the flow-on impact of any change), or a strong decision that the change
> is good. This severely limits the people who can approve most PRs.
>
> Every time I start going through the list of PRs, I find that I'm
> obviously not the right person to approve the change, or that I should
> not be unilaterally approving the change (without discussing it on
> python-dev). Which means that you can't pay me to review most PRs,
> because I simply can't do it :) So who do we get to review them?
>
> Without a stated direction/vision for CPython, it's very hard for any
> individual developer to make unilateral decisions on many PRs. And since
> there are many major areas, each with their own "team" or "expert", we
> really need those maintainers to be reviewing PRs in their areas, and
> also feeling empowered and supported to make leadership-like decisions
> for their areas.
>

>From my experience, these domain experts are often forced to spend much
more time on each PR due to the writers having little experience or
guidance developing *this* codebase. Having the new contributors submit
higher quality PRs, and having those first reviewed by a non-expert core
dev or an experienced contributor, would benefit everyone IMO. For example,
it is not a good use of our experts' time to repeatedly deal with minor
deficiencies: code style, wording, minor design issues, missing NEWS
entries etc.

I've experienced this recently with PRs submitted for itertools. I had to
revise my first PR several times to conform to Raymond's (justified!)
requirements, which required him to spend a lot of time on the reviews, so
the whole process to took a very long time. Later, someone else made a PR
for another of Raymond's modules; I reviewed the PR and after several
iterations is was ready for Raymond's final review, which was short and
simple.


> Mentoring is certainly the solution to the latter, provided the current
> experts are mentoring new experts in their area, and landing a
> governance model that helps us decide what sorts of other changes are
> good for Python solves the former. Simply paying "someone" doesn't help.
>

My mentoring would aim to bring experienced developers to the point where
they can consistently create high-quality PRs, requiring mostly high-level
decisions from the experts. They could also effectively help to move
forward many issues and PRs which are not yet at the point where they
really need an expert's attention. And perhaps most importantly, they would
be at the point where they could begin to gain expertise in specific parts
of the codebase and eventually become "domain experts" themselves.

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/a3ecdcd0/attachment.html>

From donald at stufft.io  Sat Nov  3 13:24:46 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 13:24:46 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
Message-ID: <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>



> On Nov 3, 2018, at 11:22 AM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
> Le 03/11/2018 ? 16:19, Stefan Krah a ?crit :
>> On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote:
>>> On 11/03/2018 03:55 AM, Paul Moore wrote:
>>> 
>>>> Frankly, I feel pretty disenfranchised by the process
>>>> at the moment.
>>> 
>>> +1
>> 
>> I wouldn't go as far as disenfranchised, but just this thread made it clear
>> to me that taking in information is at least 10x faster if presented on a
>> mailing list.
>> 
>> Discourse feels like eating soup with a fork, especially now that the
>> volume is higher.
> 
> Indeed.  As soon as a discussion is starting to become branchy,
> Discourse just ruins readability compared to a normal threaded
> discussion system.  The electoral system discussion is an example of that:
> https://discuss.python.org/t/python-governance-electoral-system/290
> 

Huh, I found the experience exactly the opposite. I was just remarking last night how glad I was that the discussion happened in discourse instead of on the mailing list, because of how poorly I felt the discussion would have gone on a mailing list. The ability to trivially multi quote alone was a drastic improvement, much less the ability to control, on a topic by topic basis, what level of notification I wanted for that topic.


From donald at stufft.io  Sat Nov  3 13:26:16 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 13:26:16 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
Message-ID: <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>



> On Nov 3, 2018, at 1:24 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
> 
>> On Nov 3, 2018, at 11:22 AM, Antoine Pitrou <antoine at python.org> wrote:
>> 
>> 
>> Le 03/11/2018 ? 16:19, Stefan Krah a ?crit :
>>> On Sat, Nov 03, 2018 at 07:22:21AM -0700, Ethan Furman wrote:
>>>> On 11/03/2018 03:55 AM, Paul Moore wrote:
>>>> 
>>>>> Frankly, I feel pretty disenfranchised by the process
>>>>> at the moment.
>>>> 
>>>> +1
>>> 
>>> I wouldn't go as far as disenfranchised, but just this thread made it clear
>>> to me that taking in information is at least 10x faster if presented on a
>>> mailing list.
>>> 
>>> Discourse feels like eating soup with a fork, especially now that the
>>> volume is higher.
>> 
>> Indeed.  As soon as a discussion is starting to become branchy,
>> Discourse just ruins readability compared to a normal threaded
>> discussion system.  The electoral system discussion is an example of that:
>> https://discuss.python.org/t/python-governance-electoral-system/290
>> 
> 
> Huh, I found the experience exactly the opposite. I was just remarking last night how glad I was that the discussion happened in discourse instead of on the mailing list, because of how poorly I felt the discussion would have gone on a mailing list. The ability to trivially multi quote alone was a drastic improvement, much less the ability to control, on a topic by topic basis, what level of notification I wanted for that topic.
> 


Perhaps the difference is in that every mail client I?ve ever used presents mailing list threads (or any thread) as a singular flat stream anyways? To be honest, I find the threaded views on like hyper kitty or piper mail to be abysmal anyways :|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/9008dd42/attachment-0001.html>

From antoine at python.org  Sat Nov  3 13:42:04 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 18:42:04 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
Message-ID: <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>


Le 03/11/2018 ? 18:26, Donald Stufft a ?crit?:
>>>
>>> Indeed. ?As soon as a discussion is starting to become branchy,
>>> Discourse just ruins readability compared to a normal threaded
>>> discussion system. ?The electoral system discussion is an example of
>>> that:
>>> https://discuss.python.org/t/python-governance-electoral-system/290
>>>
>>
>> Huh, I found the experience exactly the opposite. I was just remarking
>> last night how glad I was that the discussion happened in discourse
>> instead of on the mailing list, because of how poorly I felt the
>> discussion would have gone on a mailing list. The ability to trivially
>> multi quote alone was a drastic improvement, much less the ability to
>> control, on a topic by topic basis, what level of notification I
>> wanted for that topic.

The fact that you were an active participant all along in that
discussion might paint the thing in brighter colours for you.  But I
think anyone *discovering* the discussion in its current state will have
trouble making heads or tails of which subtopics were spawned, and
whether/how they resolved.

> Perhaps the difference is in that every mail client I?ve ever used
> presents mailing list threads (or any thread) as a singular flat stream
> anyways?

Er, really?  Generally they give you an option to turn on or off
threaded display.  And that in itself is a huge advantage: you can
change the setting at will, depending on your preference.  Often you can
even do so on a per-folder or per-account basis (at least with
Thunderbird you do).

Discourse doesn't allow anything of that.  It doesn't even *record*
anything about the topical discussion flow, so it's not like a
third-party tool or plugin could fix the problem, since the information
is lost.  You're basically forced to accept the flat discussion view,
which is completely unworkable to review a long and branchy discussion.

> To be honest, I find the threaded views on like hyper kitty or
> piper mail to be abysmal anyways :|

Hyper kitty doesn't *have* a threaded view AFAICT (or if it does, the
CSS does its best to hide the threading :-)).  And that's why many
people like me largely prefer the pipermail format, even though there
are genuine technical arguments against pipermail.

Regards

Antoine.

From donald at stufft.io  Sat Nov  3 13:46:46 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 13:46:46 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
Message-ID: <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>



> On Nov 3, 2018, at 1:42 PM, Antoine Pitrou <antoine at python.org> wrote:
> 
>> Perhaps the difference is in that every mail client I?ve ever used
>> presents mailing list threads (or any thread) as a singular flat stream
>> anyways?
> 
> Er, really?  Generally they give you an option to turn on or off
> threaded display.  And that in itself is a huge advantage: you can
> change the setting at will, depending on your preference.  Often you can
> even do so on a per-folder or per-account basis (at least with
> Thunderbird you do).


GMail?s webmail and Mail.app are really the only two mail clients I?ve used in the past decade or so to be honest. I think I used thunderbird for a few weeks when I was a teenager but I honestly don?t even remember anything about it (and I barely got any email back then so I think I just used the default).

TBH I find threaded views nonsensical in every medium I?ve ever seen them in, even things like Reddit or the such feel really poor to me. Either the threading is so in your face that the same points end up getting repeated at different sub threads, or the threading is so minimal that people are replying to things cross sub-thread and treating it like a ?flat? discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/30e934a4/attachment.html>

From antoine at python.org  Sat Nov  3 13:57:21 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 18:57:21 +0100
Subject: [python-committers] [OT] email clients
In-Reply-To: <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
Message-ID: <33900d64-fa59-fe76-f283-9115d96385f5@python.org>


Le 03/11/2018 ? 18:46, Donald Stufft a ?crit?:
> 
>> On Nov 3, 2018, at 1:42 PM, Antoine Pitrou <antoine at python.org
>> <mailto:antoine at python.org>> wrote:
>>
>>> Perhaps the difference is in that every mail client I?ve ever used
>>> presents mailing list threads (or any thread) as a singular flat stream
>>> anyways?
>>
>> Er, really? ?Generally they give you an option to turn on or off
>> threaded display. ?And that in itself is a huge advantage: you can
>> change the setting at will, depending on your preference. ?Often you can
>> even do so on a per-folder or per-account basis (at least with
>> Thunderbird you do).
> 
> GMail?s webmail and Mail.app are really the only two mail clients I?ve
> used in the past decade or so to be honest.

I don't know anything about Mail.app, but as far as GMail I find it
quite hostile UI-wise.  Like many Google UIs, I might add (don't get me
started on Google Groups :-/).

I find it interesting that you are so disturbed by threaded discussion
views, while for some other people it's the reverse.  That advocates for
a system that allows both kinds of presentation, and Discourse isn't that.

As a side note, a similar debate was held about filesystem hierarchies
in the 2000s.  Some UI designers felt that tree-shaped hierarchies were
too complicated for most people, and started talking about replacing
them with elaborate task-driven views.  At the end, some of the
underlying technologies were kept (such as indexing and fast
content-based search), but filesystem hierarchies are still the primary
way of organizing user data on desktop / laptop computer systems.

Regards

Antoine.

From steve.dower at python.org  Sat Nov  3 13:58:52 2018
From: steve.dower at python.org (Steve Dower)
Date: Sat, 3 Nov 2018 10:58:52 -0700
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <CALWZvp69zgyRae9fyza6FS7rg0gephqLmHNk4g+NCmwoDkV0NQ@mail.gmail.com>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
 <88552487-9498-fa52-3ff5-cdb9fdc85355@python.org>
 <CA+3bQGHoGEUiyxiJ9uah7VoCDxWaB295dy7-zYbvzbt+4t_Ssw@mail.gmail.com>
 <f3cb5121-bb82-7d27-eeab-e8a411ae988f@python.org>
 <CALWZvp69zgyRae9fyza6FS7rg0gephqLmHNk4g+NCmwoDkV0NQ@mail.gmail.com>
Message-ID: <bc376c17-80ca-1ebc-4635-57292bb1bca1@python.org>

On 03Nov2018 1006, Tal Einat wrote:
> My mentoring would aim to bring experienced developers to the point 
> where they can consistently create high-quality PRs, requiring mostly 
> high-level decisions from the experts.

This is a great point, and I'm supportive of having "general reviewers" 
who can get PRs to a point where they're ready for domain-specific 
reviews. Hopefully that would also responses like "this seems big enough 
to file and discuss on an issue before submitting a PR, so hold off on 
the code for a bit".

Given this seems to be your goal, I'm supportive of your proposal and 
program. Best of luck!

Cheers,
Steve

From barry at python.org  Sat Nov  3 14:06:12 2018
From: barry at python.org (Barry Warsaw)
Date: Sat, 3 Nov 2018 11:06:12 -0700
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
Message-ID: <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>

On Nov 2, 2018, at 20:24, Tim Peters <tim.peters at gmail.com> wrote:

> Nevertheless, I probably won't vote - I object to public ballots on
> principle.  That's been raised by others, so I won't repeat the
> arguments, and I appear to be very much in a minority here.

I also prefer private ballots on principle, but I?ll still vote if they are public.  I don?t completely buy into the rationale in PEP 8001 on why they must be public.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/e36c9d02/attachment.sig>

From antoine at python.org  Sat Nov  3 14:07:36 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 19:07:36 +0100
Subject: [python-committers] Suggestion: A PSF grant for running a "Core
 Dev Mentorship Program"
In-Reply-To: <CA+3bQGG8856ZhtFd4b4CfJ6mJbmUC-8vWTCGf7_HzpGEXekqqg@mail.gmail.com>
References: <CALWZvp7DzgUCJDjTMWfYQsT+AR10LeyFgg8eRcqNqoO-vM5zPQ@mail.gmail.com>
 <fd130590-9570-819e-5c73-8c726fad24e6@python.org>
 <CA+3bQGG8856ZhtFd4b4CfJ6mJbmUC-8vWTCGf7_HzpGEXekqqg@mail.gmail.com>
Message-ID: <eec60cd9-90f0-9950-aa5b-6bdd0954b71e@python.org>


Le 02/11/2018 ? 17:30, Victor Stinner a ?crit?:
> 
>> There are much simpler and
>> more approachable projects out there if they'd like to learn
>> contributing to open source software.
> 
> Exactly. This is why we fail to convert volunteer contributors to core
> developers. They fly away because pull requests are not reviewed,
> whereas other projects are faster than us to review PRs, give better
> feedback and has less strict on quality/backward compat.

To be honest, often when PRs are reviewed the PR author never comes back
to address the points raised.  At least, that seems to have been my
experience several times recently.  Perhaps people expect their
contributions to be reviewed in a very short timeframe and they lose
patience afterwards?  That sounds like a plausible explanation.

It's also the case that CPython bugs are more and more obscure, and
probably less rewarding to fix because of that.  Take for example this fix:
https://github.com/python/cpython/pull/10305

It's nice that someone bothered to fix this issue.  But the underlying
concern is also completely fringy :-)  Usually you don't want to send
several gigabytes of data at once on a multiprocessing connection,
because that's obviously more inefficient than finding a way not to
duplicate the data.  So the fix is good for correctness (and it should
also be a very simple fix, even with the compatibility hack added in),
but not very relevant if you care a little bit about optimizing your system.

To have more interesting issues to work on for new contributors, we
should start adding new standard library modules (and/or new major core
features) again!

Regards

Antoine.

From stefan at bytereef.org  Sat Nov  3 14:22:19 2018
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 3 Nov 2018 19:22:19 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
Message-ID: <20181103182219.GA2952@bytereef.org>

On Sat, Nov 03, 2018 at 11:06:12AM -0700, Barry Warsaw wrote:
> On Nov 2, 2018, at 20:24, Tim Peters <tim.peters at gmail.com> wrote:
> 
> > Nevertheless, I probably won't vote - I object to public ballots on
> > principle.  That's been raised by others, so I won't repeat the
> > arguments, and I appear to be very much in a minority here.
> 
> I also prefer private ballots on principle, but I?ll still vote if they are public.  I don?t completely buy into the rationale in PEP 8001 on why they must be public.

Same here. I don't think it's that much of a minority (and I'm concerned that
Tim may not vote because of this).


Stefan Krah





From tim.peters at gmail.com  Sat Nov  3 14:41:30 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 13:41:30 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
Message-ID: <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>

[Antoine Pitrou <antoine at python.org>]
> ...
> Discourse doesn't allow anything of that.  It doesn't even *record*
> anything about the topical discussion flow, so it's not like a
> third-party tool or plugin could fix the problem, since the information
> is lost.

If there's been a direct reply to the message you're currently looking
at, there's an "N replies" button at the left end of the status line
at the bottom of the message.  You can click that to get the direct
replies expanded right then and there, but offset to the right.  The
UI only caters to one level of this, though.  If there is no "N
replies" button, you're looking at a leaf node.

Similarly, if you're looking at a message with a quote from a previous
message, there's an up-arrow icon to jump directly to the quoted
message.  Better, there's also an "expand" icon to show the _entirety_
of the quoted message inline.  I've grown to really like that, because
I sometimes wonder whether important context was snipped away.

So parent -> direct_child links _are_ recorded, but the UI seems to
directly support only expanding the first-level children of a message
in the flat ordered-by-time view.  If you, e.g., want to see
grandchildren too, it seems you need to go to a child in the flat view
and click _its_ "N replies" button.

> You're basically forced to accept the flat discussion view, which is completely
> unworkable to review a long and branchy discussion.

There are two more fundamental problems with long and branchy
discussions:  they're long, and they're branchy ;-)  Active
participants have their own mental map of how the discussion is going.
People browsing are going to get tied in knots no matter how it's
displayed.  Although, ya, I'd also like ways to make it more tree-like
than it is.  Sometimes.  For a discussion I'm actively involved in,
it's usually more convenient to see a flat view ordered by timestamp.

From donald at stufft.io  Sat Nov  3 14:45:01 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 14:45:01 -0400
Subject: [python-committers] [OT] email clients
In-Reply-To: <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
Message-ID: <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>



> On Nov 3, 2018, at 1:57 PM, Antoine Pitrou <antoine at python.org> wrote:
> 
> I find it interesting that you are so disturbed by threaded discussion
> views, while for some other people it's the reverse.  That advocates for
> a system that allows both kinds of presentation, and Discourse isn't that.

I would agree *if* that was the only axis that the two tools differed on. (Un)fortunately there is a laundry list of improvements over the traditional mailing list this is available in modern mechanisms for facilitating discussion that mailing lists lack. Even something as simple as being able to decide on a topic by topic basis whether you want to receive emails on that topic. Unfortunately it?s hard to impossible to retrofit these items onto email, because email has a lowest common denominator problem where you can?t meaningfully improve it, because you can?t break support with the huge deployment base of every mail client ever.

If there were a system that offered even most of the benefits, but allowed someone switching between tree view and flat view, I?d be all for it. However all of the modern systems I?m aware of only allow one or the other.

To be honest, I?m not even sure how you?d represent some of these things in a threaded view. For instance within discourse I can multi quote different posts to tie multiple lines of discussion together. How would you present that in a threaded view? A merge? I?m not aware of any threaded system that actually allows it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/156337bd/attachment-0001.html>

From antoine at python.org  Sat Nov  3 14:47:46 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 19:47:46 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
Message-ID: <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>


Le 03/11/2018 ? 19:41, Tim Peters a ?crit?:
> 
>> You're basically forced to accept the flat discussion view, which is completely
>> unworkable to review a long and branchy discussion.
> 
> There are two more fundamental problems with long and branchy
> discussions:  they're long, and they're branchy ;-)

But they are also unavoidable in any realistic setting.  The idea of
Discourse seems to discourage such discussions entirely.  But that only
works when the problems are simple and well-defined enough.

Regards

Antoine.

From antoine at python.org  Sat Nov  3 14:49:13 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 19:49:13 +0100
Subject: [python-committers] [OT] email clients
In-Reply-To: <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
Message-ID: <b93e0e71-1be8-c9ea-959f-4671fa80d4f1@python.org>


Le 03/11/2018 ? 19:45, Donald Stufft a ?crit?:
> 
> To be honest, I?m not even sure how you?d represent some of these things
> in a threaded view. For instance within discourse I can multi quote
> different posts to tie multiple lines of discussion together. How would
> you present that in a threaded view? A merge? I?m not aware of any
> threaded system that actually allows it.

I would give up on multiple quoting entirely.  I'm not sure it
represents a worthwhile improvement.

Regards

Antoine.

From ethan at stoneleaf.us  Sat Nov  3 15:04:37 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 3 Nov 2018 12:04:37 -0700
Subject: [python-committers] [OT] email clients
In-Reply-To: <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
Message-ID: <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>

On 11/03/2018 11:45 AM, Donald Stufft wrote:

> I would agree *if* that was the only axis that the two tools differed 
> on.

It's enough for me.  My participation on Discourse is going to be so low 
you might think I went emeritus. :/

> (Un)fortunately there is a laundry list of improvements over the 
> traditional mailing list

Which are all irrelevant if we don't use the tool itself.  It's like my 
wife wanting to reduce my sodium intake by buying reduced-sodium peanut 
butter -- it worked!  I don't eat that peanut butter.  ;)

--
~Ethan~

From tim.peters at gmail.com  Sat Nov  3 15:07:18 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 14:07:18 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
Message-ID: <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>

[Antoine]
>>> You're basically forced to accept the flat discussion view, which is completely
>>> unworkable to review a long and branchy discussion.

[Tim]
>> There are two more fundamental problems with long and branchy
>> discussions:  they're long, and they're branchy ;-)

[Antoine]
> But they are also unavoidable in any realistic setting.  The idea of
> Discourse seems to discourage such discussions entirely.  But that only
> works when the problems are simple and well-defined enough.

If your idea of what "works" is the typical long-and-branchy
contentious thread on Python-Ideas, we have incompatible views of what
"works" means ;-)  I don't care if something like that is displayed in
a 30-dimensional graph structure cross-linked by date, author,
reply-to, keywords, and semantic relevance, there's simply no clear
sense _to_ be made of such stuff.

The "Python Governance Electoral System" thread is as long and branchy
as a discussion has gotten there, but is more :"civilized" and
on-topic than most mailing list threads of similar complexity I've
seen in recent years.  It worked better than I expected it would -
although I was an active participant.

Making it very easy to multi-quote, with live clickable links to both
view and jump to the original messages, is really very nice.  _Lots_
of things are nicer than mailing lists.  And other things aren't.   So
it goes.

From donald at stufft.io  Sat Nov  3 15:09:50 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 15:09:50 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
Message-ID: <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>



> On Nov 3, 2018, at 2:06 PM, Barry Warsaw <barry at python.org> wrote:
> 
> I also prefer private ballots on principle, but I?ll still vote if they are public.  I don?t completely buy into the rationale in PEP 8001 on why they must be public.


So to avoid just complaining without an actionable suggestion, here?s a suggestion:

Use https://civs.cs.cornell.edu with the following settings (x in the ones turned on):

[x] Private
[ ] Make this a test poll: read all votes from a file.
[ ] Do not release results to all voters.
[x] Enable detailed ballot reporting.
[ ] In detailed ballot report, also reveal the identity of the voter with each ballot.
[ ] Allow voters to write in new choices.
[ ] Present choices on voting page in exactly the given order.
[ ] Allow voters to select ?no opinion? for some choices.
[ ] Enforce proportional representation


This best represents the current behavior, while moving us to use a secret ballot. Voting in this system looks like an email like https://s.caremad.io/9i63IkqBppKMudh/ <https://s.caremad.io/9i63IkqBppKMudh/> which includes in it a link to vote. Going to that link gives you a page like https://s.caremad.io/TDQWB0wv4FDx3I9/ <https://s.caremad.io/TDQWB0wv4FDx3I9/>. Which has some Ui affordances for dragging/dropping to re-order or to allow you to use a drop down to select your winner.  Once you submit your vote, you?re given a page like https://s.caremad.io/HszGnDfDJQ725YX/ <https://s.caremad.io/HszGnDfDJQ725YX/>. Once the election is over, the results are available and look like https://s.caremad.io/4Wcy5InXoLjV7MU/ <https://s.caremad.io/4Wcy5InXoLjV7MU/> (after you click a button to see more results).

This has the following properties:

- People?s identities are kept secret.
  - This assume that the people running that online system are discarding the votes like they claim to be. I don?t think they?re likely to be lying and it?s a popular online service so they?re unlikely to do anything about it.
- The actual ballots are public, and available to be viewed and even downloaded in CSV format.
- The results are computed, although none of the options are for ?pure? condorcet, we can use the CSV format to compute it how we like to verify that there was a pure condorcet winner.
- As a downside, the list of people who voted are *not* made public (it considers not participating at all to be something that deserves secret as well).
- As an upside, it will randomize the order ballots are in by default, and there is science/evidence to suggest that when ballots are in the same order for everyone, that items closer to the top of the ballot are more likely to win. Randomizing ballot order helps with this.
- It doesn?t require you to make a total ranking of all the options (it allows you to rank some items equal). This is fine with Condorcet (it just means a cycle is more likely). 
- A single person has to act as the election administrator, which basically only gives the power to start/stop the election and to add voters (you can?t add the same email address twice, doing so just re-sends the email to that person).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/7bdacf82/attachment-0001.html>

From antoine at python.org  Sat Nov  3 15:15:05 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 20:15:05 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
 <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
Message-ID: <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>


Le 03/11/2018 ? 20:07, Tim Peters a ?crit?:
> [Antoine]
>>>> You're basically forced to accept the flat discussion view, which is completely
>>>> unworkable to review a long and branchy discussion.
> 
> [Tim]
>>> There are two more fundamental problems with long and branchy
>>> discussions:  they're long, and they're branchy ;-)
> 
> [Antoine]
>> But they are also unavoidable in any realistic setting.  The idea of
>> Discourse seems to discourage such discussions entirely.  But that only
>> works when the problems are simple and well-defined enough.
> 
> If your idea of what "works" is the typical long-and-branchy
> contentious thread on Python-Ideas, we have incompatible views of what
> "works" means ;-)

That's a complete strawman.  python-ideas is a failure, and it would be
as much of a failure with a non-threaded discussion system.

> The "Python Governance Electoral System" thread is as long and branchy
> as a discussion has gotten there, but is more :"civilized" and
> on-topic than most mailing list threads of similar complexity I've
> seen in recent years.

Yes, but why?  Because everyone really wants the governance discussions
to succeed (and to succeed as soon as possible), so they make an extra
effort to avoid derailing them.  Such self-discipline doesn't prevail
for the more usual python-dev discussions (let alone python-ideas which
is its own universe).  People are human beings, they get carried away,
and I'm sure they will on Discourse too (unless they entirely refrain
from posting because they can't stand the discussion system, that is).

Regards

Antoine.

From donald at stufft.io  Sat Nov  3 15:15:47 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 15:15:47 -0400
Subject: [python-committers] [OT] email clients
In-Reply-To: <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
 <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
Message-ID: <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>



> On Nov 3, 2018, at 3:04 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> 
> On 11/03/2018 11:45 AM, Donald Stufft wrote:
> 
>> I would agree *if* that was the only axis that the two tools differed on.
> 
> It's enough for me.  My participation on Discourse is going to be so low you might think I went emeritus. :/
> 
>> (Un)fortunately there is a laundry list of improvements over the traditional mailing list
> 
> Which are all irrelevant if we don't use the tool itself.  It's like my wife wanting to reduce my sodium intake by buying reduced-sodium peanut butter -- it worked!  I don't eat that peanut butter.  ;)
> 


I?m the other way. I basically don?t participate in python-dev or python-ideas anymore because of the issues mailing lists have. At best I occasionally peek at them, but I even do that so rarely any more because even when I find something I want to participate in, knowing how painful participation is going to be is enough to make me decide not to typically.

There?s also a bit of a confirmation bias here of course. The people who would have otherwise contributed to discussion but decided not to because the UI afforded provided by mailing lists are bad enough for them personally to not make it worth it, are unlikely going to be here discussion their preferences. So we?re a self selected group who are at least willing to tolerate mailing lists to some degree, but there?s a reasonable chance that we?re excluding otherwise valuable contributors who simply don?t want to deal with mailing lists.

I would posit that pretty much any choice we make here, including *not* making a choice is going to exclude some subset of population? even the population of people currently ?here?. Thus the big question is which options are going to lose the fewest people and (ideally) contribute the least to burn out. I know for me personally, the python mailing lists are a non trivial amount of the source of burn out for me, and the only way I?ve managed to stay active in the community at all is by ignoring as many of our communities mailing lists as possible.


From antoine at python.org  Sat Nov  3 15:17:02 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 20:17:02 +0100
Subject: [python-committers] [OT] email clients
In-Reply-To: <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
 <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
 <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>
Message-ID: <2ec8e709-5a33-6b3c-f449-bc189ba247c0@python.org>


Le 03/11/2018 ? 20:15, Donald Stufft a ?crit?:
> 
> I?m the other way. I basically don?t participate in python-dev or python-ideas anymore because of the issues mailing lists have.

Just a question: which tool do you use to participate in distutils-sig
discussions, then?

Regards

Antoine.

From donald at stufft.io  Sat Nov  3 15:19:24 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 15:19:24 -0400
Subject: [python-committers] [OT] email clients
In-Reply-To: <2ec8e709-5a33-6b3c-f449-bc189ba247c0@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
 <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
 <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>
 <2ec8e709-5a33-6b3c-f449-bc189ba247c0@python.org>
Message-ID: <98C22966-8A15-481D-BAF5-A38DE35B013F@stufft.io>



> On Nov 3, 2018, at 3:17 PM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
> Le 03/11/2018 ? 20:15, Donald Stufft a ?crit :
>> 
>> I?m the other way. I basically don?t participate in python-dev or python-ideas anymore because of the issues mailing lists have.
> 
> Just a question: which tool do you use to participate in distutils-sig
> discussions, then?
> 

It?s the only mailing list (well besides this one, but this one only because it?s low traffic enough normally I didn?t filter it out into a folder to ignore) I still actively participate in. Even there I?ve been consciously pushing more of my own traffic to GitHub, or avoiding doing things that would require discussion on distutils-sig instead working on things that I could discuss entirely on GitHub.

My experience with the Governance discussion lead me to post https://mail.python.org/mm3/archives/list/distutils-sig at python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/ <https://mail.python.org/mm3/archives/list/distutils-sig at python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/> last night, so I?m pulling myself generally out of distutils-sig as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/184a7e7e/attachment-0001.html>

From donald at stufft.io  Sat Nov  3 15:27:29 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 15:27:29 -0400
Subject: [python-committers] [OT] email clients
In-Reply-To: <98C22966-8A15-481D-BAF5-A38DE35B013F@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
 <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
 <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>
 <2ec8e709-5a33-6b3c-f449-bc189ba247c0@python.org>
 <98C22966-8A15-481D-BAF5-A38DE35B013F@stufft.io>
Message-ID: <14F14800-C3D3-4B3D-B84A-E4AB82C025D1@stufft.io>



> On Nov 3, 2018, at 3:19 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
> 
>> On Nov 3, 2018, at 3:17 PM, Antoine Pitrou <antoine at python.org <mailto:antoine at python.org>> wrote:
>> 
>> 
>> Le 03/11/2018 ? 20:15, Donald Stufft a ?crit :
>>> 
>>> I?m the other way. I basically don?t participate in python-dev or python-ideas anymore because of the issues mailing lists have.
>> 
>> Just a question: which tool do you use to participate in distutils-sig
>> discussions, then?
>> 
> 
> It?s the only mailing list (well besides this one, but this one only because it?s low traffic enough normally I didn?t filter it out into a folder to ignore) I still actively participate in. Even there I?ve been consciously pushing more of my own traffic to GitHub, or avoiding doing things that would require discussion on distutils-sig instead working on things that I could discuss entirely on GitHub.
> 
> My experience with the Governance discussion lead me to post https://mail.python.org/mm3/archives/list/distutils-sig at python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/ <https://mail.python.org/mm3/archives/list/distutils-sig at python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/> last night, so I?m pulling myself generally out of distutils-sig as well.
> 


Oh yea, and I forgot to mention that I?ve been trying to advocate for pulling the packaging tools out of the PEP process and into our own process, ideally based on GitHub or Discourse or anything with modern UI affordances. That?s not entirely due to the pain of mailing lists, but that?s part of it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/c0eb3083/attachment.html>

From donald at stufft.io  Sat Nov  3 15:32:46 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 15:32:46 -0400
Subject: [python-committers] [OT] email clients
In-Reply-To: <14F14800-C3D3-4B3D-B84A-E4AB82C025D1@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
 <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
 <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>
 <2ec8e709-5a33-6b3c-f449-bc189ba247c0@python.org>
 <98C22966-8A15-481D-BAF5-A38DE35B013F@stufft.io>
 <14F14800-C3D3-4B3D-B84A-E4AB82C025D1@stufft.io>
Message-ID: <075AEC9B-BC2C-4261-BD43-DB705B222D3F@stufft.io>



> On Nov 3, 2018, at 3:27 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
> 
>> On Nov 3, 2018, at 3:19 PM, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
>> 
>> 
>> 
>>> On Nov 3, 2018, at 3:17 PM, Antoine Pitrou <antoine at python.org <mailto:antoine at python.org>> wrote:
>>> 
>>> 
>>> Le 03/11/2018 ? 20:15, Donald Stufft a ?crit :
>>>> 
>>>> I?m the other way. I basically don?t participate in python-dev or python-ideas anymore because of the issues mailing lists have.
>>> 
>>> Just a question: which tool do you use to participate in distutils-sig
>>> discussions, then?
>>> 
>> 
>> It?s the only mailing list (well besides this one, but this one only because it?s low traffic enough normally I didn?t filter it out into a folder to ignore) I still actively participate in. Even there I?ve been consciously pushing more of my own traffic to GitHub, or avoiding doing things that would require discussion on distutils-sig instead working on things that I could discuss entirely on GitHub.
>> 
>> My experience with the Governance discussion lead me to post https://mail.python.org/mm3/archives/list/distutils-sig at python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/ <https://mail.python.org/mm3/archives/list/distutils-sig at python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/> last night, so I?m pulling myself generally out of distutils-sig as well.
>> 
> 
> 
> Oh yea, and I forgot to mention that I?ve been trying to advocate for pulling the packaging tools out of the PEP process and into our own process, ideally based on GitHub or Discourse or anything with modern UI affordances. That?s not entirely due to the pain of mailing lists, but that?s part of it.
> 
> 

One last bit! 

I don?t mean to suggest that my participation is make or break for these lists. If I was the only one who felt this way, then I think it would be fair to say that I?m in the minority and while we want to encourage everyone, we can?t please everyone. I was merely trying to express that the choice isn?t move from mailing list to discourse and maybe exclude some people, or stay on mailing lists and exclude nobody. Either choice is going to be excluding some people.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/5e3c1663/attachment.html>

From tim.peters at gmail.com  Sat Nov  3 15:34:53 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 14:34:53 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
 <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
 <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>
Message-ID: <CAExdVNn5Ns+KsFiE_fAU4oU97FSbnBsJL7aetCh+rqACM6NK=A@mail.gmail.com>

[Antoine Pitrou <antoine at python.org>]
> ...
> That's a complete strawman.  python-ideas is a failure, and it would be
> as much of a failure with a non-threaded discussion system.
> ...
> Yes, but why?  Because everyone really wants the governance discussions
> to succeed (and to succeed as soon as possible), so they make an extra
> effort to avoid derailing them.  Such self-discipline doesn't prevail
> for the more usual python-dev discussions (let alone python-ideas which
> is its own universe).  People are human beings, they get carried away,
> and I'm sure they will on Discourse too (unless they entirely refrain
> from posting because they can't stand the discussion system, that is).

This may be a clear demonstration of one way Discourse "works better":
 the "conversation" we're having here is really of little value to
anyone, including to us.  But because replies instantly show up in our
inboxes, we're seemingly compelled to keep it going.

I don't have "mailing list mode" turned on for discuss.python.org, so
there's been nothing nagging me to "reply or die" there.  If I don't
reply to something in my inbox almost at once, it will almost
certainly scroll off the list of messages I can see on the first Gmail
page within a day.  Discourse has been more like a reasoned discussion
than a hasty IRC chat room.  Which, sure, may change.

In any case, I'm done with _this_ discussion now - have the last word,
if you like :-)

From ethan at stoneleaf.us  Sat Nov  3 15:38:22 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 3 Nov 2018 12:38:22 -0700
Subject: [python-committers] [OT] email clients
In-Reply-To: <075AEC9B-BC2C-4261-BD43-DB705B222D3F@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <46B96BAE-6DFF-4D94-B826-6703B5B23A71@stufft.io>
 <33900d64-fa59-fe76-f283-9115d96385f5@python.org>
 <C1BE3907-5E48-45BE-85CD-1BF26801AA6D@stufft.io>
 <458bde21-1bf7-9d28-d574-1504371f38ab@stoneleaf.us>
 <0C8EBECD-965A-441D-B6D2-493516AAE72B@stufft.io>
 <2ec8e709-5a33-6b3c-f449-bc189ba247c0@python.org>
 <98C22966-8A15-481D-BAF5-A38DE35B013F@stufft.io>
 <14F14800-C3D3-4B3D-B84A-E4AB82C025D1@stufft.io>
 <075AEC9B-BC2C-4261-BD43-DB705B222D3F@stufft.io>
Message-ID: <a03b1d1a-f167-d21e-5af7-a0e939a45a4e@stoneleaf.us>

On 11/03/2018 12:32 PM, Donald Stufft wrote:

> I don?t mean to suggest that my participation is make or break for these 
> lists. If I was the only one who felt this way, then I think it would be 
> fair to say that I?m in the minority and while we want to encourage 
> everyone, we can?t please everyone. I was merely trying to express that 
> the choice isn?t move from mailing list to discourse and maybe exclude 
> some people, or stay on mailing lists and exclude nobody. Either choice 
> is going to be excluding some people.

Sounds like python-dev should take a break from Python and create the 
ideal communication software so all of us can contribute with as few 
headaches as possible.

--
~Ethan~

From antoine at python.org  Sat Nov  3 15:56:18 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 20:56:18 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNn5Ns+KsFiE_fAU4oU97FSbnBsJL7aetCh+rqACM6NK=A@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
 <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
 <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>
 <CAExdVNn5Ns+KsFiE_fAU4oU97FSbnBsJL7aetCh+rqACM6NK=A@mail.gmail.com>
Message-ID: <201e5132-a00e-0077-d8d8-0d7224e8f2b7@python.org>


Le 03/11/2018 ? 20:34, Tim Peters a ?crit?:
> 
> This may be a clear demonstration of one way Discourse "works better":
>  the "conversation" we're having here is really of little value to
> anyone, including to us.

How does Discourse "work better", exactly?  The long-winded discussion
on variants of voting systems (with close to 100 messages) isn't exactly
*important* except for voting system nerds.  The subthread you started
about the "3-2-1" system was of close to no value, since you admitted
yourself that that system is too young and immature to be chosen, and
you were only "planting a seed" (and probably enjoying yourself a bit in
the process).  Yet it seems Discourse didn't discourage you from doing
so.  Why?

Well, because people making tangents on topics they like to talk about
is irrelevant to the discussion system used (and your own behaviour
proves it).  The only way you can prevent tangents is by preventing
discussion altogether.

*However*, an important feature of a discussion system is to help
skipping tangents you're not interested about.  A threaded discussion
system makes it very easy to ignore a subthread.  Not so much where the
various subthreads are intermingled in a flat chronologic view.

Regards

Antoine.

From donald at stufft.io  Sat Nov  3 16:45:07 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 16:45:07 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
Message-ID: <68F2E1CC-767B-461E-AA97-64272946AD41@stufft.io>



> On Nov 3, 2018, at 3:09 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
> 
>> On Nov 3, 2018, at 2:06 PM, Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
>> 
>> I also prefer private ballots on principle, but I?ll still vote if they are public.  I don?t completely buy into the rationale in PEP 8001 on why they must be public.
> 
> 
> So to avoid just complaining without an actionable suggestion, here?s a suggestion:
> 
> Use https://civs.cs.cornell.edu <https://civs.cs.cornell.edu/> with the following settings (x in the ones turned on):
> 
> [x] Private
> [ ] Make this a test poll: read all votes from a file.
> [ ] Do not release results to all voters.
> [x] Enable detailed ballot reporting.
> [ ] In detailed ballot report, also reveal the identity of the voter with each ballot.
> [ ] Allow voters to write in new choices.
> [ ] Present choices on voting page in exactly the given order.
> [ ] Allow voters to select ?no opinion? for some choices.
> [ ] Enforce proportional representation
> 
> 
> This best represents the current behavior, while moving us to use a secret ballot. Voting in this system looks like an email like https://s.caremad.io/9i63IkqBppKMudh/ <https://s.caremad.io/9i63IkqBppKMudh/> which includes in it a link to vote. Going to that link gives you a page like https://s.caremad.io/TDQWB0wv4FDx3I9/ <https://s.caremad.io/TDQWB0wv4FDx3I9/>. Which has some Ui affordances for dragging/dropping to re-order or to allow you to use a drop down to select your winner.  Once you submit your vote, you?re given a page like https://s.caremad.io/HszGnDfDJQ725YX/ <https://s.caremad.io/HszGnDfDJQ725YX/>. Once the election is over, the results are available and look like https://s.caremad.io/4Wcy5InXoLjV7MU/ <https://s.caremad.io/4Wcy5InXoLjV7MU/> (after you click a button to see more results).
> 
> This has the following properties:
> 
> - People?s identities are kept secret.
>   - This assume that the people running that online system are discarding the votes like they claim to be. I don?t think they?re likely to be lying and it?s a popular online service so they?re unlikely to do anything about it.
> - The actual ballots are public, and available to be viewed and even downloaded in CSV format.
> - The results are computed, although none of the options are for ?pure? condorcet, we can use the CSV format to compute it how we like to verify that there was a pure condorcet winner.
> - As a downside, the list of people who voted are *not* made public (it considers not participating at all to be something that deserves secret as well).
> - As an upside, it will randomize the order ballots are in by default, and there is science/evidence to suggest that when ballots are in the same order for everyone, that items closer to the top of the ballot are more likely to win. Randomizing ballot order helps with this.
> - It doesn?t require you to make a total ranking of all the options (it allows you to rank some items equal). This is fine with Condorcet (it just means a cycle is more likely). 
> - A single person has to act as the election administrator, which basically only gives the power to start/stop the election and to add voters (you can?t add the same email address twice, doing so just re-sends the email to that person).



One thing we need if we do go this route, is a single person to act as the election supervisor. Their powers are limited basically they configure the election, adding a description, the choices, etc and then they have the power to start the election, add voters via email addresses, and then end the election. All of these are manual action items, but the system automatically generates result emails and voter emails and such.

So if we go this route, we?d have to pick that person. I poked Ernest Durbin to see if he?d be willing to do that. I figure we?d make a good candidate for election supervisor (again, if we go that route) since he?s a PSF employee, he?s well known enough in the community and generally trusted (he has root on all the boxes pretty much, so he can do a lot of damage if he wanted) and he?s not a core developer, so he?s about as close to a trusted, but neutral party as we?re likely to find. He said he?d absolutely be willing to handle that if we want.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/9cb6b988/attachment.html>

From donald at stufft.io  Sat Nov  3 17:27:18 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 17:27:18 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <68F2E1CC-767B-461E-AA97-64272946AD41@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
 <68F2E1CC-767B-461E-AA97-64272946AD41@stufft.io>
Message-ID: <BA7F02EF-22DD-4861-A944-D5AC166250D6@stufft.io>



> On Nov 3, 2018, at 4:45 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
> 
> 
> One thing we need if we do go this route, is a single person to act as the election supervisor. Their powers are limited basically they configure the election, adding a description, the choices, etc and then they have the power to start the election, add voters via email addresses, and then end the election. All of these are manual action items, but the system automatically generates result emails and voter emails and such.
> 
> So if we go this route, we?d have to pick that person. I poked Ernest Durbin to see if he?d be willing to do that. I figure we?d make a good candidate for election supervisor (again, if we go that route) since he?s a PSF employee, he?s well known enough in the community and generally trusted (he has root on all the boxes pretty much, so he can do a lot of damage if he wanted) and he?s not a core developer, so he?s about as close to a trusted, but neutral party as we?re likely to find. He said he?d absolutely be willing to handle that if we want.
> 



Here is a PR that implements this https://github.com/python/peps/pull/830 <https://github.com/python/peps/pull/830>. Not going to merge it myself, just figured I?d offer it as an alternative option.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/fc98ccbe/attachment-0001.html>

From tim.peters at gmail.com  Sat Nov  3 17:30:33 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 16:30:33 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <201e5132-a00e-0077-d8d8-0d7224e8f2b7@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
 <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
 <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>
 <CAExdVNn5Ns+KsFiE_fAU4oU97FSbnBsJL7aetCh+rqACM6NK=A@mail.gmail.com>
 <201e5132-a00e-0077-d8d8-0d7224e8f2b7@python.org>
Message-ID: <CAExdVNnRbObE3de1SBQVR17kK3M35E3WD5TL_LmotaJ8wtJ2QQ@mail.gmail.com>

[Antoine]
> How does Discourse "work better", exactly?

Several examples have already been given.  You're determined to hate
it, and that's fine.


> The long-winded discussion> on variants of voting systems (with
> close to 100 messages) isn't exactly *important* except for voting
> system nerds.

Yet that discussion was spun off from a _different_ thread, so that's
close to 100 messages that don't show up _at all_ on the thread from
which it was spun off.  Better than a threaded view, if you were
looking at the original thread, that's close to 100 messages you'd
never know even existed.

As to its "importance", the title of the thread you're complaining
about ("Python Governance Electoral System")  made it clear it was
_about_ the election system.  If you don't care about the election
system, why read it at all?  You can't seriously complain that a
thread is full of messages it was intended to be about.


> The subthread you started about the "3-2-1" system was of close to no value,

I disagree.  It may well have been of negative value to _you_, but it
served its intended purpose, and 3-2-1 was approved by close to half
the poll voters despite that it wasn't intended to be a serious
contender at this time.  It got _some_ people to think - "does an
attractive method really need a background in graph theory to even
start to grasp?  display bizarre behavior in simple cases?".  Well,
no.  Which was news to some.

In any case, that subthread consisted of a grand total of 4 brief
messages, including my original post.  That 3-2-1 continued to be
mentioned in _distinct_ subtrees shows the seed I planted sprouted.
Good!

> since you admitted yourself that that system is too young and immature
> to be chosen, and you were only "planting a seed" (and probably enjoying
> yourself a bit in the process).

Yup!

> Yet it seems Discourse didn't discourage you from doing so.  Why?

Because, to me, it was a valuable message thoroughly on topic.


> Well, because people making tangents on topics they like to talk about
> is irrelevant to the discussion system used (and your own behaviour
> proves it).

As above, I disagree.  Knocking people loose from a presumption that a
good voting system "has to be" complex or inscrutable was supremely
relevant to the thread's purpose.  As is, I believe it helped lead to
the final decision:  "pure Condorcet", which is soooooo simple that
it's not even "a scoring method".  It's just a form of ballot, with an
agreement that if there's no utterly inarguable winner (a "Condorcet
winner"), we'll try something else until there is.

> The only way you can prevent tangents is by preventing discussion
> altogether.

Sure.  But in this case, I don't agree that "the tangent" you
identified was a tangent, and Discourse _did_ prevent other tangents
from spinning out of control.  For example, when we got to talking
about the possibility of ties, there was pretty quick consensus that
if we wanted to keep on with that, an entirely _different_ message
thread should be started for it.   Much as there was consensus earlier
that the election system messages should be spun off to their own
entirely different thread.  Which happened - but still leaves you
complaining about it ;-)

> *However*, an important feature of a discussion system is to help
> skipping tangents you're not interested about.  A threaded discussion
> system makes it very easy to ignore a subthread.  Not so much where the
> various subthreads are intermingled in a flat chronologic view.

So we'll apparently continue to disagree here.  To my eyes, there were
close to no off-topic tangents in the thread under discussion, and the
people actually participating in the thread were in broad agreement
that some other _related_ topics should be spun off to a different
top-level thread if people wanted to pursue them.

It worked fine.

From antoine at python.org  Sat Nov  3 18:11:07 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 3 Nov 2018 23:11:07 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNnRbObE3de1SBQVR17kK3M35E3WD5TL_LmotaJ8wtJ2QQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
 <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
 <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>
 <CAExdVNn5Ns+KsFiE_fAU4oU97FSbnBsJL7aetCh+rqACM6NK=A@mail.gmail.com>
 <201e5132-a00e-0077-d8d8-0d7224e8f2b7@python.org>
 <CAExdVNnRbObE3de1SBQVR17kK3M35E3WD5TL_LmotaJ8wtJ2QQ@mail.gmail.com>
Message-ID: <4e0edd71-2658-ee98-9b24-79166b50520c@python.org>


Le 03/11/2018 ? 22:30, Tim Peters a ?crit?:
> [Antoine]
>> How does Discourse "work better", exactly?
> 
> Several examples have already been given.  You're determined to hate
> it, and that's fine.

That's an idiotic statement and an unwarranted personal attack.  If
that's all you're taking from this discussion then we might just end it
here (especially as you previously mentioned you would stop posting, a
promise which apparently you weren't able to keep).

From tim.peters at gmail.com  Sat Nov  3 18:31:55 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 17:31:55 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <4e0edd71-2658-ee98-9b24-79166b50520c@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <833F3652-40F1-466B-AD60-A0842EC06147@stufft.io>
 <4d56e1e9-51c3-afae-1ca5-0bc30adc1677@python.org>
 <CAExdVNmos4JZOAx3+Ptden3V5Jr_XQZ_W+5AKYmtWwDPnJ+HSg@mail.gmail.com>
 <f4b47a24-2bdd-0857-3eb2-a54071e62e36@python.org>
 <CAExdVNmV53+59KhhseN8gXZO_XzsXPbgfZO1NZAS=pOyP8k_uw@mail.gmail.com>
 <cf353624-a52a-a34b-038e-28ec5596d3f3@python.org>
 <CAExdVNn5Ns+KsFiE_fAU4oU97FSbnBsJL7aetCh+rqACM6NK=A@mail.gmail.com>
 <201e5132-a00e-0077-d8d8-0d7224e8f2b7@python.org>
 <CAExdVNnRbObE3de1SBQVR17kK3M35E3WD5TL_LmotaJ8wtJ2QQ@mail.gmail.com>
 <4e0edd71-2658-ee98-9b24-79166b50520c@python.org>
Message-ID: <CAExdVNmhaijAhJHfeK0r47gNqg0f-MOn9isPhE8=7rPscvRu2Q@mail.gmail.com>

 [Antoine]
>>> How does Discourse "work better", exactly?

[Tim]
>> Several examples have already been given.  You're determined to hate
>> it, and that's fine.

[Antoine]
> That's an idiotic statement and an unwarranted personal attack.

It wasn't intended that way, but I can certainly see how it comes off
that way.  My apologies!

> If that's all you're taking from this discussion

Well, you cut off 99% of what I wrote, which sincerely attempted to
give reasons backed up by examples.  So:

> then we might just end it here

Yup!

> (especially as you previously mentioned you would stop posting, a
> promise which apparently you weren't able to keep).

I offered to let you have the last word.  But you took the opportunity
to ask at least two questions.  That left me with a dilemma:  leave
your questions unanswered and risk leaving the impression that I
thought you weren't worth engaging with at all - or try to answer them
and leave myself open to a charge of hypocrisy?  I made my choice:
I'd rather people believe I'm a hypocrite than that I believe you're
not worth talking with.

Which I don't regret.  I do regret characterizing your record of
having nothing  positive to say about Discourse as that "you're
determined to hate it".  That was rhetorical excess, neither necessary
nor helpful, despite that it wasn't intended to be taken literally.

From steve at pearwood.info  Sat Nov  3 18:55:18 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 4 Nov 2018 09:55:18 +1100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
Message-ID: <20181103225518.GR3817@ando.pearwood.info>

On Sat, Nov 03, 2018 at 01:24:46PM -0400, Donald Stufft wrote:

> Huh, I found the experience exactly the opposite. I was just remarking 
> last night how glad I was that the discussion happened in discourse 
> instead of on the mailing list, because of how poorly I felt the 
> discussion would have gone on a mailing list. The ability to trivially 
> multi quote alone was a drastic improvement,

I don't know what "multi quote" means, unless it means quoting multiple 
people's text in your reply. (Which I can do in email by copying and 
pasting.)

Can you link to an example of this useful multi quoting please?



-- 
Steve

From tim.peters at gmail.com  Sat Nov  3 20:01:15 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 19:01:15 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <20181103225518.GR3817@ando.pearwood.info>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <f706c1c5-9a31-aa76-1045-e4b9d4cf2a98@stoneleaf.us>
 <20181103151956.GA6050@bytereef.org>
 <59d6663a-8078-82bd-cdef-969bb3de6c91@python.org>
 <75927BB5-6808-428F-917A-CE61014EE971@stufft.io>
 <20181103225518.GR3817@ando.pearwood.info>
Message-ID: <CAExdVNktMYNkdpJyWnxMchtZH02CA718JFwDFLaJgueGA8t9Zg@mail.gmail.com>

[Steven D'Aprano <steve at pearwood.info>]
> I don't know what "multi quote" means, unless it means quoting multiple
> people's text in your reply. (Which I can do in email by copying and
> pasting.)
>
> Can you link to an example of this useful multi quoting please?

Sure - here's a message in which I included bits of three other peoples' posts:

    https://discuss.python.org/t/python-governance-electoral-system/290/30

This is "better" than email copy-paste in several ways:

- It's very easy to do.  Just select the other message's text you want
to quote, and a "Quote" control pops up.  Click that and the selected
text is properly formatted in your reply, automagically attributed to
the original author, and automagically linked back to the original
post.

- In your completed message, two controls appear on every chunk of
quoted text.  Clicking one jumps directly to the message you quoted.
Clicking the other expands the full text of the quoted message inline,
with the part you quoted color-highlighted.

That last is my favorite.  It's great to see whether important context
was snipped.  And, once you're used to it, I expect you _will_ snip
"important context", because it's so easy for the message reader to
just click to see the full original context - if they want to.

So, in the example I linked to, the quotes I included were very brief.
In email I would have quoted much more, because it's so hard (at least
in Gmail) to _find_ the original messages again.

The "multi" is a nice thing, but all of the above applies too when
just quoting from a single source.

In the context of the message thread you were replying to  (which I'm
not quoting here at all, because it's such a PITA to find the original
bits in Gmail), the "theoretical point" was that multi-quoting doesn't
play well with a threaded view:  your reply is "a child" of _every_
message you included pieces of.  The "message tree" is no longer a
tree.  Which I really don't care about ;-)

From steve at pearwood.info  Sat Nov  3 20:21:16 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 4 Nov 2018 11:21:16 +1100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
Message-ID: <20181104002115.GS3817@ando.pearwood.info>

On Sat, Nov 03, 2018 at 10:55:14AM +0000, Paul Moore wrote:
[...]
> Currently, I feel like my only option is to abstain and hope - I don't
> have the time (or knowledge) to review, understand and assess the
> proposals well enough to make an informed vote, but I have no way of
> assessing the "expert opinions" of those who do, to allow me to make a
> broad judgement. Frankly, I feel pretty disenfranchised by the process
> at the moment.

I think that there are legitimate criticisms of the way this transition 
and the discussion has been handled. (Such as the fragmentation of 
discussion and the difficulty in discovering where the pieces are.)

But let's be fair to those who have put in the effort to make this work 
so far. "Disenfranchisement" is not even close to a fair criticism.

Nobody has said you can't vote. Nobody is stripping you of your commit
bit, or your status as core dev. Nobody is going to tell you that you
can't vote because your name is similar to a convicted felon three
states away, or force you to stand in line for 16 hours at the one
polling booth for twenty miles on election day, and then turn you away
because you have the wrong kind of ID. Nobody is passing laws to strip
you of your ability to vote because of entirely spurious fears of "voter
fraud". (The actual fraud being legimate voters being disenfranchised
because they're poor or the wrong colour.)

With respect Paul, if we aren't willing to make even a minimal effort 
to make an informed vote, that's not disenfranchisement, that's just 
"can't be bothered".

"Can't be bothered" is a perfectly legitimate choice here -- I'm still 
considering it for myself. But I don't see how your current 
position is justified: as I read your post, your complaint is that you 
don't want to actually vote yourself, you don't have the time or 
inclination to study the proposals and make an informed choice, but 
you're disturbed that you don't know whether or not other people are 
likely to make the choice you would make if you did make an informed 
choice, which you aren't planning on doing.

"I know nothing about the issues, but I want to be sure everyone else 
will vote they way I would vote if I did."

I don't see how this is even possible. With respect, I think the answer 
to that is, well duh, if you don't vote or take part in the discussion, 
don't be surprised if people don't vote they way you want them to :-)

In any case, as I said, I think there are legitimate criticisms to be 
made. E.g. I think the decision to move the discussion to Discourse in 
the middle of the governance crisis was overly optimistic, the timing 
was not well thought-out, and making that decision behind closed doors 
and then announcing it as a fait acompli was certainly not living up to 
the ideals of openess, consideration and community-engagement that we 
claim to follow:

https://discuss.python.org/t/python-committers-is-dead-long-live-discuss-python-org/30

https://mail.python.org/pipermail/python-committers/2018-September/006187.html

But what's done is done, and we can't say we weren't informed or 
asked to open an account on Discourse.

But none of these criticisms are so serious as to bring the whole 
exercise into doubt. If we want to vote, we can. If we want to make 
an *informed* vote, we can read the PEPs:

https://www.python.org/dev/peps/pep-8000/

and we can start a discussion here or on Discourse.

Or if we want to just trust the rest of the community to do the right 
thing, that's a legitimate position too.

You've done the right thing asking about the discussion, and I'm sad 
that nobody has answered your question:

> how can I trust that the decision will be one I can be comfortable 
> with - and how do I influence the direction except by participating in 
> the discussions I've been unable to locate?

That's a reasonable question. I wish I had a better answer, but I too
have found it exceedingly hard to locate discussions. I know there has 
been some here, and some on Discourse (which I find hard to navigate, 
perhaps because of unfamiliarity).

Anywhere else? Zulip? I can't even find that, let alone tell if 
there are archived discussions.

The PEPs are on Github, has there been discussion there?

https://github.com/python/peps/blob/master/pep-8000.rst


-- 
Steve

From donald at stufft.io  Sat Nov  3 20:41:33 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 20:41:33 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <20181104002115.GS3817@ando.pearwood.info>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
Message-ID: <1692C7C7-1229-4D57-9C8A-79F576B36A01@stufft.io>


> On Nov 3, 2018, at 8:21 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> 
>> how can I trust that the decision will be one I can be comfortable 
>> with - and how do I influence the direction except by participating in 
>> the discussions I've been unable to locate?
> 
> That's a reasonable question. I wish I had a better answer, but I too
> have found it exceedingly hard to locate discussions. I know there has 
> been some here, and some on Discourse (which I find hard to navigate, 
> perhaps because of unfamiliarity).

As far as I am aware there is a topic per PEP on discourse that has had discussion mostly related to the specific PEP. I?m not aware of any general ?weighing the options? topic on any discussion forum.  I think so far it?s mostly just been people asking for refinements or changes to a specific PEP to make it more clear and/or more tolerable to that person. 

I think maybe the idea of voting itself has stifled some of the back and forth between options though I could be wrong about that. I?m not sure that I would personally find much benefit in a general thread on the various options. I think understand them well enough and I have my opinions on the suitability of each. I don?t feel like there?s much more to be said that would benefit me. If you (or anyone) feels like a general thread would be useful? then I would encourage you to start one and see what sort of discussion happens.

From donald at stufft.io  Sat Nov  3 21:20:41 2018
From: donald at stufft.io (Donald Stufft)
Date: Sat, 3 Nov 2018 21:20:41 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <1692C7C7-1229-4D57-9C8A-79F576B36A01@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <1692C7C7-1229-4D57-9C8A-79F576B36A01@stufft.io>
Message-ID: <33EE200E-7B1E-4482-99C0-2AE989410E8F@stufft.io>



> On Nov 3, 2018, at 8:41 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> As far as I am aware there is a topic per PEP on discourse that has had discussion mostly related to the specific PEP. I?m not aware of any general ?weighing the options? topic on any discussion forum.  I think so far it?s mostly just been people asking for refinements or changes to a specific PEP to make it more clear and/or more tolerable to that person. 
> 


Incase unfamiliarity with discourse is causing an issue in people finding the topics, and that?s what folks are stumbling with, here are links to each of the PEP specific topics:

- PEP 8010 - The Singular Leader - https://discuss.python.org/t/pep-8010-the-singular-leader/188 <https://discuss.python.org/t/pep-8010-the-singular-leader/188>
- PEP 8011 - Leadership by a Trio of Pythonistas - https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199 <https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199>
- PEP 8012 - The Community Model - https://discuss.python.org/t/pep-8012-the-community-model/156 <https://discuss.python.org/t/pep-8012-the-community-model/156>
- PEP 8013 - The External Council Model - https://discuss.python.org/t/pep-8013-the-external-council-governance-model/181 <https://discuss.python.org/t/pep-8013-the-external-council-governance-model/181>
- PEP 8014 - The Commons Model - https://discuss.python.org/t/pep-8014-the-commons-model/173 <https://discuss.python.org/t/pep-8014-the-commons-model/173>
- PEP 8015 - ?Organization of the Python Community? - https://discuss.python.org/t/pep-8015-organization-of-the-python-community/193 <https://discuss.python.org/t/pep-8015-organization-of-the-python-community/193>
 
There is also a draft PEP, PEP 8016 - ?The boringest possible steering committee model? - which is more of a proto-PEP at the moment, but discussion about it can be located at https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333 <https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333>.

Each thread seems to have somewhere between 30-50 total posts, so all in there?s maybe ~300 posts to read across all of them (and many of those posts are pretty short). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/c6d4a6db/attachment.html>

From tim.peters at gmail.com  Sat Nov  3 23:56:53 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sat, 3 Nov 2018 22:56:53 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
Message-ID: <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>

[Donald Stufft <donald at stufft.io>]
> So to avoid just complaining without an actionable suggestion, here?s a suggestion:
>
> Use https://civs.cs.cornell.edu with the following settings (x in the ones turned on):

Presumably someone is "running" this election, but I don't know who.
Do we believe they're paying attention to this list?  Or are they
focused on the Discourse site now?:  I'd hate to see this possibility
get lost:


> [x] Private
> [ ] Make this a test poll: read all votes from a file.
> [ ] Do not release results to all voters.
> [x] Enable detailed ballot reporting.
> [ ] In detailed ballot report, also reveal the identity of the voter with each ballot.
> [ ] Allow voters to write in new choices.
> [ ] Present choices on voting page in exactly the given order.
> [ ] Allow voters to select ?no opinion? for some choices.
> [ ] Enforce proportional representation

> ...
> This has the following properties:
>
> - People?s identities are kept secret.

Just noting they say they even destroy the email addresses the
supervisor gives to them, after sending them their voting URL email.

> ...
> - The results are computed, although none of the options are for ?pure? condorcet,
> we can use the CSV format to compute it how we like to verify that there was a
> pure condorcet winner.

The test poll you constructed didn't have a Condorcet winner.  Looking
at other public polls on that site, I noticed that when there _was_ a
Condorcet winner, the results page said

    (Condorcet winner: wins contests with all other choices)

next to the winning candidate.  Given that the results page also gives
a color-coded matrix of pairwise preference counts, verifying this is
trivial by eyeball (the winning candidate is in the top row, and is a
Condorcet winner if and only if all the cells in the top row are
colored green (excluding the extreme northwest cell, which is always
blank) - which means the top-row candidate outright won against every
other candidate - which is what "pure Condorcet winner" means).

> - As a downside, the list of people who voted are *not* made public (it
> considers not participating at all to be something that deserves secret
> as well).

Indeed, it appears that even the election supervisor has no way to
find out who did and didn't vote.  Although, from the Security page:

"""
The election supervisor can determine whether a voter has voted only
with the permission of the voter and only after the election has
ended.
"""

> - As an upside, it will randomize the order ballots are in by default, and
> there is science/evidence to suggest that when ballots are in the same
> order for everyone, that items closer to the top of the ballot are more
> likely to win. Randomizing ballot order helps with this.

Very good!  Don't know what PSF Board elections do now.  When David
Mertz was the election admin, he was enduring hideous schemes trying
to run multiple elections "invisibly" under the covers, each showing
the candidates in a different order.  That's really something that
_should_ be built in to the base system, not bolted on top with Rube
Goldberg schemes.

> - It doesn?t require you to make a total ranking of all the options (it allows you to
> rank some items equal). This is fine with Condorcet (it just means a cycle is
> more likely).

We can worry about that when it doesn't happen anyway ;-)

> - A single person has to act as the election administrator, which basically only
> gives the power to start/stop the election and to add voters (you can?t add
> the same email address twice, doing so just re-sends the email to that person).

So the admin _could_, e.g., add a hundred sock puppet email addresses,
and effectively give them self a hundred votes.  We couldn't tell,
other than noting that the total vote count seemed too high.

Which I don't really care about.  The CIVS service is good enough for
me - and likely far better than anything people who just can't believe
running an election can present any real difficulties will come up
with off the top of their heads ;-)

From donald at stufft.io  Sun Nov  4 01:52:57 2018
From: donald at stufft.io (Donald Stufft)
Date: Sun, 4 Nov 2018 01:52:57 -0400
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
 <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>
Message-ID: <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>



> On Nov 3, 2018, at 11:56 PM, Tim Peters <tim.peters at gmail.com> wrote:
> 
> [Donald Stufft <donald at stufft.io>]
>> So to avoid just complaining without an actionable suggestion, here?s a suggestion:
>> 
>> Use https://civs.cs.cornell.edu with the following settings (x in the ones turned on):
> 
> Presumably someone is "running" this election, but I don't know who.
> Do we believe they're paying attention to this list?  Or are they
> focused on the Discourse site now?:  I'd hate to see this possibility
> get lost:

I?ll mirror this over to discourse in a bit, or maybe tomorrow.

> 
>> ...
>> - The results are computed, although none of the options are for ?pure? condorcet,
>> we can use the CSV format to compute it how we like to verify that there was a
>> pure condorcet winner.
> 
> The test poll you constructed didn't have a Condorcet winner.  Looking
> at other public polls on that site, I noticed that when there _was_ a
> Condorcet winner, the results page said
> 
>    (Condorcet winner: wins contests with all other choices)
> 
> next to the winning candidate.  Given that the results page also gives
> a color-coded matrix of pairwise preference counts, verifying this is
> trivial by eyeball (the winning candidate is in the top row, and is a
> Condorcet winner if and only if all the cells in the top row are
> colored green (excluding the extreme northwest cell, which is always
> blank) - which means the top-row candidate outright won against every
> other candidate - which is what "pure Condorcet winner" means).

You?re right. I simulated an election without a Condorcet winner, but where the voting mechanisms would otherwise select a winner (just using the example from the Schulze Wikipedia page), it says "(Not defeated in any contest vs. another choice)?, instead. An example can be found at: https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_4191dbfb94efecb6&algorithm=beatpath <https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_4191dbfb94efecb6&algorithm=beatpath>.

Just for kicks I added enough ballots so that there would be a Condorcet winner, and I verified that the above is true, and an example can be found at https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_31f80ce0986ce98c&algorithm=beatpath <https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_31f80ce0986ce98c&algorithm=beatpath>.

So that means if we go with it, we can let CIVS tally for us and we?ll just look for a Condorcet winner instead of another kind of winner. Of course since all of the anonymized ballots are public, people are free to compute it themselves as well.

> 
>> - As a downside, the list of people who voted are *not* made public (it
>> considers not participating at all to be something that deserves secret
>> as well).
> 
> Indeed, it appears that even the election supervisor has no way to
> find out who did and didn't vote.  Although, from the Security page:
> 
> """
> The election supervisor can determine whether a voter has voted only
> with the permission of the voter and only after the election has
> ended.
> ?""

Maybe they mean that if you contact them they can look that information up? I?m looking and I don?t see any UI that lets me do that, so either it?s not implemented, it was removed, I?m missing it, or it requires contacting them.

> 
> 
>> - It doesn?t require you to make a total ranking of all the options (it allows you to
>> rank some items equal). This is fine with Condorcet (it just means a cycle is
>> more likely).
> 
> We can worry about that when it doesn't happen anyway ;-)

It can also optionally let people pick no opinion, though I?m not sure of the utility of that. It basically means, as I understand it, that in any pairwise contest that includes a option you had no opinion on, your ballot would just not be included. The FAQ on this says:


What does ?no opinion? mean? It means you are providing no information about how this choice ranks with respect to the other choices. For example, if you give one choice the rank 1, and give all other choices the rank ?no opinion?, your ballot becomes useless because it doesn't express any preferences. Voters often pick ?no opinion? when what they mean is that they don't like the choice or that they don't have any information about it. In these situations, it is often better to give the choice a low rank rather than to select ?no opinion?. A good reason for a voter to give a choice the rank ?no opinion? is because the voter isn't supposed to express an opinion about that choice.

It sounds to me like no opinion is a bit of a footgun here, so I think it makes sense not to allow it (probably the case of where you don?t have an opinion, you?re better off just ranking it last like the FAQ suggests).


> 
>> - A single person has to act as the election administrator, which basically only
>> gives the power to start/stop the election and to add voters (you can?t add
>> the same email address twice, doing so just re-sends the email to that person).
> 
> So the admin _could_, e.g., add a hundred sock puppet email addresses,
> and effectively give them self a hundred votes.  We couldn't tell,
> other than noting that the total vote count seemed too high.
> 
> Which I don't really care about.  The CIVS service is good enough for
> me - and likely far better than anything people who just can't believe
> running an election can present any real difficulties will come up
> with off the top of their heads ;-)


Yea. And my suggestion of Ernest is that well, an evil Ernest can already fuck shit up for the Python community way beyond trying to change how we make decisions about PEPs and such (and he?s not a core dev, so he doesn?t have a horse in this race). Although I don?t really care who runs it, I think anyone here is going to be honest about it.

I can say as a supervisor you also can?t see how people have voted at all until after the voting ends. You can only see how many people voted. This makes it harder to meaningfully influence the election because you won?t be able to make targeted, strategic puppet votes without either doing it blindly or flooding the votes to a degree that it would be obvious.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181104/16d969cb/attachment.html>

From donald at stufft.io  Sun Nov  4 02:05:52 2018
From: donald at stufft.io (Donald Stufft)
Date: Sun, 4 Nov 2018 02:05:52 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
 <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>
 <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>
Message-ID: <FA267B1C-E026-41CE-BB38-6FDC80DD18F7@stufft.io>



> On Nov 4, 2018, at 1:52 AM, Donald Stufft <donald at stufft.io> wrote:
> 
>> 
>> On Nov 3, 2018, at 11:56 PM, Tim Peters <tim.peters at gmail.com <mailto:tim.peters at gmail.com>> wrote:
>> 
>> [Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>>]
>>> So to avoid just complaining without an actionable suggestion, here?s a suggestion:
>>> 
>>> Use https://civs.cs.cornell.edu <https://civs.cs.cornell.edu/> with the following settings (x in the ones turned on):
>> 
>> Presumably someone is "running" this election, but I don't know who.
>> Do we believe they're paying attention to this list?  Or are they
>> focused on the Discourse site now?:  I'd hate to see this possibility
>> get lost:
> 
> I?ll mirror this over to discourse in a bit, or maybe tomorrow.


https://discuss.python.org/t/pep-8001-public-or-private-ballots/374
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181104/adb5dbf6/attachment-0001.html>

From tim.peters at gmail.com  Sun Nov  4 02:24:17 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 4 Nov 2018 01:24:17 -0600
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
 <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>
 <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>
Message-ID: <CAExdVNmHq6QHYg1dBnV1KCxCF4157=DiyGr=ohsTaY+xWOX7bw@mail.gmail.com>

[Tim]
>> ... when there _was_ a Condorcet winner, the results page said
>>
>>   (Condorcet winner: wins contests with all other choices)
>>
>> next to the winning candidate.  Given that the results page also gives
>> a color-coded matrix of pairwise preference counts, verifying this is
>> trivial by eyeball ... if and only if all the cells in the top row are
>> colored green ...

[Donald]
> You?re right. I simulated an election without a Condorcet winner, but
> where the voting mechanisms would otherwise select a winner (just
> using the example from the Schulze Wikipedia page), it says
> "(Not defeated in any contest vs. another choice)?, instead.

Errrrrrrr ... I wonder why?!  I had seen that in one of the public
polls, but in that case the winner's row was all green except for a
single yellow square. which meant the winner _tied_ with another in a
one-on-one contest.  So "not defeated" was correct.  But here:

> An example can be found at:
> https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_4191dbfb94efecb6&algorithm=beatpath.

there's a red square in the winner's (top) row:  the winner (E)
_lost_, 24 to 21, to #3 (C).  It's just not true that E wasn't
defeated in any one-on-one contest.

Oh well.  Best to ignore the words and look at the colors instead :-)


> Just for kicks I added enough ballots so that there would be a Condorcet
> winner, and I verified that the above is true, and an example can be found at
> https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_31f80ce0986ce98c&algorithm=beatpath.

Yup - and top row all green.


> So that means if we go with it, we can let CIVS tally for us and we?ll just
> look for a Condorcet winner instead of another kind of winner.

Yes, it will tell us instantly (when the election ends) whether
there's a Condorcet winner, and regardless of which method's radio
button happens to be selected.

> Of course since all of the anonymized ballots are public, people are free to
> compute it themselves as well.

And I bet someone will.  I'm too old ;-)

>> ...
>> """
>> The election supervisor can determine whether a voter has voted only
>> with the permission of the voter and only after the election has
>> ended.
>> ?""

> Maybe they mean that if you contact them they can look that information
> up? I?m looking and I don?t see any UI that lets me do that, so either
> it?s not implemented, it was removed, I?m missing it, or it requires
> contacting them.

Can't help, beyond noting that the election supervisor sure doesn't
appear to have any mechanical way to prove a voter gives permission -
and since their side threw away voters' email addresses, they have no
way to contact voters to ask either.

They do save crypto hashes of email addresses, so perhaps if you asked
them, they could give you a magic string you could in turn give to a
voter who in turn could send that string back to them from the same
email address they used to vote.  Or something ;-)

> ...
> It can also optionally let people pick no opinion, though I?m not sure of the utility
> of that. It basically means, as I understand it, that in any pairwise contest that
> includes a option you had no opinion on, your ballot would just not be included.

In effect, I bet that's all there is to it.  If there are C
candidates, all these methods start by building a CxC matrix M such
that M[i, j] counts the number of ballots that ranked candidate i
higher than candidate j.

If a full set of distinct rankings is required, then for every ballot,
exactly one of M[i, j] and M[j,i] will be incremented for every i != j
pair.

If i != j are ranked the same on some ballot, then neither M[i, j] nor
M[j, i] will be incremented for that ballot.

If i is missing on some ballot, then M[i, j] and M[j, i] will be left
alone for all j for that ballot.

> The FAQ on this says:
>
>
> What does ?no opinion? mean? It means you are providing no information about
> how this choice ranks with respect to the other choices. For example, if you give
> one choice the rank 1, and give all other choices the rank ?no opinion?, your
> ballot becomes useless because it doesn't express any preferences.
> Voters often pick ?no opinion? when what they mean is that they don't like the choice

In that case they should rank it near the bottom instead.

> or that they don't have any information about it.

Which is surely what it's _intended_ to be used for!  "No opinion", in
which case the ballot doesn't pretend the missing choice is either
better or worse than any other choice.  You're leaving its fate
entirely to people who _do_ have an opinion then.

> In these situations, it is often better to give the choice a low rank rather than
> to select ?no opinion?. A good reason for a voter to give a choice the rank
> ?no opinion? is because the voter isn't supposed to express an opinion
> about that choice.

Heh - who runs a vote where voters aren't "supposed" to express their
opinions?  Or is this site hosted in the DPRK? ;-)


> It sounds to me like no opinion is a bit of a footgun here, so I think it makes
> sense not to allow it (probably the case of where you don?t have an opinion,
> you?re better off just ranking it last like the FAQ suggests).

I'd disallow it, but because it's likely to be misunderstood.  The
_usual_ treatment of missing rankings in a Condorcet scheme is that
they're shorthand for saying "least favored".  For example, in a
17-person primary, you just rank your 3 favorites, and it's understood
that the other 14 are all tied for last place in your eyes.

That's _very_ different from treating them as "no opinion".  In the
primary, you're recording 3 losses for each of the missing 14, and you
wholly _intend_ to give them those losses.

> ...
> Yea. And my suggestion of Ernest is that well, an evil Ernest can already fuck
> shit up for the Python community way beyond trying to change how we make
> decisions about PEPs and such (and he?s not a core dev, so he doesn?t have
> a horse in this race). Although I don?t really care who runs it, I think anyone
> here is going to be honest about it.
>
> I can say as a supervisor you also can?t see how people have voted at all until
> after the voting ends. You can only see how many people voted. This makes it
> harder to meaningfully influence the election because you won?t be able to
> make targeted, strategic puppet votes without either doing it blindly or flooding
> the votes to a degree that it would be obvious.

No problem here with any of that.  Potential dishonesty in PythonLand
is far less a problem than that we fail to get anything done fretting
about proving how nothing could possibly be manipulated.  In fact, we
could almost certainly trust any one of the competing PEP's authors to
tally the votes, destroy the ballots, and just tell us who won :--)

From guido at python.org  Sun Nov  4 03:35:19 2018
From: guido at python.org (Guido van Rossum)
Date: Sun, 4 Nov 2018 01:35:19 -0700
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAExdVNmHq6QHYg1dBnV1KCxCF4157=DiyGr=ohsTaY+xWOX7bw@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
 <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>
 <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>
 <CAExdVNmHq6QHYg1dBnV1KCxCF4157=DiyGr=ohsTaY+xWOX7bw@mail.gmail.com>
Message-ID: <CAP7+vJK+srW5jyU9w1c47ruGKU66vfG5=aJPEBFN9k-BW5maSQ@mail.gmail.com>

Is it safe for people not interested in voting systems to ignore the rest
of this thread? I hope that if there's an update on the voting period or
specifics on how to vote (or what the choices are) these will be posted to
a new thread. I want to mute this one.

On Sun, Nov 4, 2018 at 12:24 AM Tim Peters <tim.peters at gmail.com> wrote:

> [Tim]
> >> ... when there _was_ a Condorcet winner, the results page said
> >>
> >>   (Condorcet winner: wins contests with all other choices)
> >>
> >> next to the winning candidate.  Given that the results page also gives
> >> a color-coded matrix of pairwise preference counts, verifying this is
> >> trivial by eyeball ... if and only if all the cells in the top row are
> >> colored green ...
>
> [Donald]
> > You?re right. I simulated an election without a Condorcet winner, but
> > where the voting mechanisms would otherwise select a winner (just
> > using the example from the Schulze Wikipedia page), it says
> > "(Not defeated in any contest vs. another choice)?, instead.
>
> Errrrrrrr ... I wonder why?!  I had seen that in one of the public
> polls, but in that case the winner's row was all green except for a
> single yellow square. which meant the winner _tied_ with another in a
> one-on-one contest.  So "not defeated" was correct.  But here:
>
> > An example can be found at:
> >
> https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_4191dbfb94efecb6&algorithm=beatpath
> .
>
> there's a red square in the winner's (top) row:  the winner (E)
> _lost_, 24 to 21, to #3 (C).  It's just not true that E wasn't
> defeated in any one-on-one contest.
>
> Oh well.  Best to ignore the words and look at the colors instead :-)
>
>
> > Just for kicks I added enough ballots so that there would be a Condorcet
> > winner, and I verified that the above is true, and an example can be
> found at
> >
> https://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_31f80ce0986ce98c&algorithm=beatpath
> .
>
> Yup - and top row all green.
>
>
> > So that means if we go with it, we can let CIVS tally for us and we?ll
> just
> > look for a Condorcet winner instead of another kind of winner.
>
> Yes, it will tell us instantly (when the election ends) whether
> there's a Condorcet winner, and regardless of which method's radio
> button happens to be selected.
>
> > Of course since all of the anonymized ballots are public, people are
> free to
> > compute it themselves as well.
>
> And I bet someone will.  I'm too old ;-)
>
> >> ...
> >> """
> >> The election supervisor can determine whether a voter has voted only
> >> with the permission of the voter and only after the election has
> >> ended.
> >> ?""
>
> > Maybe they mean that if you contact them they can look that information
> > up? I?m looking and I don?t see any UI that lets me do that, so either
> > it?s not implemented, it was removed, I?m missing it, or it requires
> > contacting them.
>
> Can't help, beyond noting that the election supervisor sure doesn't
> appear to have any mechanical way to prove a voter gives permission -
> and since their side threw away voters' email addresses, they have no
> way to contact voters to ask either.
>
> They do save crypto hashes of email addresses, so perhaps if you asked
> them, they could give you a magic string you could in turn give to a
> voter who in turn could send that string back to them from the same
> email address they used to vote.  Or something ;-)
>
> > ...
> > It can also optionally let people pick no opinion, though I?m not sure
> of the utility
> > of that. It basically means, as I understand it, that in any pairwise
> contest that
> > includes a option you had no opinion on, your ballot would just not be
> included.
>
> In effect, I bet that's all there is to it.  If there are C
> candidates, all these methods start by building a CxC matrix M such
> that M[i, j] counts the number of ballots that ranked candidate i
> higher than candidate j.
>
> If a full set of distinct rankings is required, then for every ballot,
> exactly one of M[i, j] and M[j,i] will be incremented for every i != j
> pair.
>
> If i != j are ranked the same on some ballot, then neither M[i, j] nor
> M[j, i] will be incremented for that ballot.
>
> If i is missing on some ballot, then M[i, j] and M[j, i] will be left
> alone for all j for that ballot.
>
> > The FAQ on this says:
> >
> >
> > What does ?no opinion? mean? It means you are providing no information
> about
> > how this choice ranks with respect to the other choices. For example, if
> you give
> > one choice the rank 1, and give all other choices the rank ?no opinion?,
> your
> > ballot becomes useless because it doesn't express any preferences.
> > Voters often pick ?no opinion? when what they mean is that they don't
> like the choice
>
> In that case they should rank it near the bottom instead.
>
> > or that they don't have any information about it.
>
> Which is surely what it's _intended_ to be used for!  "No opinion", in
> which case the ballot doesn't pretend the missing choice is either
> better or worse than any other choice.  You're leaving its fate
> entirely to people who _do_ have an opinion then.
>
> > In these situations, it is often better to give the choice a low rank
> rather than
> > to select ?no opinion?. A good reason for a voter to give a choice the
> rank
> > ?no opinion? is because the voter isn't supposed to express an opinion
> > about that choice.
>
> Heh - who runs a vote where voters aren't "supposed" to express their
> opinions?  Or is this site hosted in the DPRK? ;-)
>
>
> > It sounds to me like no opinion is a bit of a footgun here, so I think
> it makes
> > sense not to allow it (probably the case of where you don?t have an
> opinion,
> > you?re better off just ranking it last like the FAQ suggests).
>
> I'd disallow it, but because it's likely to be misunderstood.  The
> _usual_ treatment of missing rankings in a Condorcet scheme is that
> they're shorthand for saying "least favored".  For example, in a
> 17-person primary, you just rank your 3 favorites, and it's understood
> that the other 14 are all tied for last place in your eyes.
>
> That's _very_ different from treating them as "no opinion".  In the
> primary, you're recording 3 losses for each of the missing 14, and you
> wholly _intend_ to give them those losses.
>
> > ...
> > Yea. And my suggestion of Ernest is that well, an evil Ernest can
> already fuck
> > shit up for the Python community way beyond trying to change how we make
> > decisions about PEPs and such (and he?s not a core dev, so he doesn?t
> have
> > a horse in this race). Although I don?t really care who runs it, I think
> anyone
> > here is going to be honest about it.
> >
> > I can say as a supervisor you also can?t see how people have voted at
> all until
> > after the voting ends. You can only see how many people voted. This
> makes it
> > harder to meaningfully influence the election because you won?t be able
> to
> > make targeted, strategic puppet votes without either doing it blindly or
> flooding
> > the votes to a degree that it would be obvious.
>
> No problem here with any of that.  Potential dishonesty in PythonLand
> is far less a problem than that we fail to get anything done fretting
> about proving how nothing could possibly be manipulated.  In fact, we
> could almost certainly trust any one of the competing PEP's authors to
> tally the votes, destroy the ballots, and just tell us who won :--)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181104/db27cecc/attachment-0001.html>

From p.f.moore at gmail.com  Sun Nov  4 06:38:53 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 4 Nov 2018 11:38:53 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <20181104002115.GS3817@ando.pearwood.info>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
Message-ID: <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>

On Sun, 4 Nov 2018 at 00:21, Steven D'Aprano <steve at pearwood.info> wrote:
> But let's be fair to those who have put in the effort to make this work
> so far. "Disenfranchisement" is not even close to a fair criticism.

Frankly, I'm tired of being picked up on specifics of the wording I
used. I felt that "disenfranchised" described how I feel pretty well.
If you're saying that my understanding of the word is inaccurate, then
fine, I'm happy you know better than me. But I explained my problem in
more detail as well as stating the summary version - I can't find
context or discussions, I don't have the time to become an expert in
all the details[1] but conversely I can't find out what those who
*have* investigated the details think, etc etc.

It's an important decision, and one I care about, but not one that
will massively affect my daily routine, so I want to be involved, but
I don't have the means to do so to a level that matches its direct
impact on me.

If "disenfranchised" isn't the right word for that, then fine, pick
your own word and assume I used it. Or assume I just gave the longer
explanation and didn't bother trying to offer a one word summary of
how I feel.

I've explained my concern, I'm not going to debate whether my
vocabulary is sufficient to summarise my intent accurately any
further.
Paul

[1]  My problem! But a common situation in any voting process - do you
expect to understand all the details of international policy before
voting in an election?

From antoine at python.org  Sun Nov  4 06:43:30 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 4 Nov 2018 12:43:30 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
Message-ID: <76135f90-2cce-92d1-9ce9-1e2b1475bbd9@python.org>


Le 04/11/2018 ? 12:38, Paul Moore a ?crit?:
> On Sun, 4 Nov 2018 at 00:21, Steven D'Aprano <steve at pearwood.info> wrote:
>> But let's be fair to those who have put in the effort to make this work
>> so far. "Disenfranchisement" is not even close to a fair criticism.
> 
> Frankly, I'm tired of being picked up on specifics of the wording I
> used. I felt that "disenfranchised" described how I feel pretty well.
> If you're saying that my understanding of the word is inaccurate, then
> fine, I'm happy you know better than me. But I explained my problem in
> more detail as well as stating the summary version - I can't find
> context or discussions, I don't have the time to become an expert in
> all the details[1] but conversely I can't find out what those who
> *have* investigated the details think, etc etc.

I don't think anyone here is an expert on the details.  The discussion
we're having is probably unusual for most or all people here.

That people like me may spend more time reading the PEPs doesn't
actually make them more competent on the broader topic of governance
systems.  So feel free to judge the PEPs by yourself and don't be afraid
of casting such judgement.  You're as competent as anyone else.  Ideally
we would have started this discussion a lot of time in advance, and
without any deadline looming over us, but the events decided otherwise.

Regards

Antoine.

From steve.dower at python.org  Sun Nov  4 10:24:55 2018
From: steve.dower at python.org (Steve Dower)
Date: Sun, 4 Nov 2018 07:24:55 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
Message-ID: <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>

On 04Nov2018 0338, Paul Moore wrote:
> I felt that "disenfranchised" described how I feel pretty well.
> If you're saying that my understanding of the word is inaccurate, then
> fine, I'm happy you know better than me. But I explained my problem in
> more detail as well as stating the summary version - I can't find
> context or discussions, I don't have the time to become an expert in
> all the details[1] but conversely I can't find out what those who
> *have* investigated the details think, etc etc.
> 
> It's an important decision, and one I care about, but not one that
> will massively affect my daily routine, so I want to be involved, but
> I don't have the means to do so to a level that matches its direct
> impact on me.

I don't know about anyone else, but I was planning to post my own 
preferences publicly during the election, a kind of "if you trust my 
judgement, feel free to vote like I did".

Hopefully other people will do the same. I think most of us have worked 
well enough with at least some other people in the group over the years 
to have *someone* who we trust to decide on this for us. At the very 
least, it gives people a starting point, even if they end up voting 
differently themselves.

For example, right now, I'm leaning towards 8013, 8010, 8016, 8011, 
8012, 8015, 8014. But since some are still in flux (particularly 8016), 
that could change. And my core rationale is basically how likely we are 
to be able to fill the roles created by the model.

Obviously I could be lying about my preferences, though I can't think of 
any reason for me to want to do that or what I could gain out of it. The 
gain I see by sharing them is to at least offer people a kind of proxy 
vote. (I'm also sure I don't have the influence to make a huge 
difference by doing this. While we'd all love it if he did, I'm pretty 
sure Guido will not publish his preferences :) )

Cheers,
Steve

From tim.peters at gmail.com  Sun Nov  4 11:46:52 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 4 Nov 2018 10:46:52 -0600
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAP7+vJK+srW5jyU9w1c47ruGKU66vfG5=aJPEBFN9k-BW5maSQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <C4355AF4-B4F3-4CE8-90CC-F094D8E6FE7F@python.org>
 <5707F928-436E-4568-9570-3DCA7D20914E@stufft.io>
 <CAExdVNk4TRb-KM9hVVQhVBCmJyLvdJf_RiqCM3e+O1_i_SC-+Q@mail.gmail.com>
 <81890BC1-A4C6-414D-8FE6-830FE76DECAB@stufft.io>
 <CAExdVNmHq6QHYg1dBnV1KCxCF4157=DiyGr=ohsTaY+xWOX7bw@mail.gmail.com>
 <CAP7+vJK+srW5jyU9w1c47ruGKU66vfG5=aJPEBFN9k-BW5maSQ@mail.gmail.com>
Message-ID: <CAExdVNmFdR_+QFcQnriW71ED84o5MPLJQk=xaRnaWbsQTZRwcA@mail.gmail.com>

[Guido]
> Is it safe for people not interested in voting systems to
> ignore the rest of this thread?

Have you used mailing lists before? ;-)  The topics in this particular
thread have, e.g., ranged from voting systems (the specific message
you're replying to), through whether and why Discourse does or doesn't
suck, to concerns about how it's possible for someone with a life to
make informed choices among the governance PEPs themselves.

So far as the voting system alone goes, "probably safe".  Donald
already moved that specific part to Discourse.  His announcement of
that here crossed in the mail with the message you're replying to.  So
scant point to muting this thread on _that_ count.  The three messages
newer than yours in this thread didn't even mention the voting system.

> I hope that if there's an update on the voting period or specifics on
> how to vote (or what the choices are) these will be posted to a new
> thread.

See?  Another topic that's not about voting systems.  I hope so too,
but can't answer because I'm not in charge of anything here (and
neither is Donald).  But I _expect_  that if info people absolutely
need to know changes, whoever makes that decision will announce it
both here and on Discourse in visible ways.

From p.f.moore at gmail.com  Sun Nov  4 13:53:03 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 4 Nov 2018 18:53:03 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
Message-ID: <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>

On Sun, 4 Nov 2018 at 15:25, Steve Dower <steve.dower at python.org> wrote:
> For example, right now, I'm leaning towards 8013, 8010, 8016, 8011,
> 8012, 8015, 8014. But since some are still in flux (particularly 8016),
> that could change. And my core rationale is basically how likely we are
> to be able to fill the roles created by the model.

As one example of my confusion here,
https://www.python.org/dev/peps/pep-8016/ is currently a 404. So where
are you seeing something you can express a preference on? Presumably
you're looking at the raw data in github?

I have limited time, and I feel like we were promised a deadline after
which we could review what was being proposed, and discuss the
proposals in a public forum. After that, there would be a vote. But at
this point in time, I'm confused about:

1. When the proposals will be finalised and published.
2. Where the discussion(s) will be taking place.

PEP 8001 says that the vote will take place in the 2 weeks between 16
Nov and 30 Nov. PEP 8000 states that the following proposals exist:

PEP 8010 - The BDFL Governance Model
PEP 8011 - Python Governance Model Lead by Trio of Pythonistas
PEP 8012 - The Community Governance Model
PEP 8013 - The External Governance Model
PEP 8014 - The Commons Governance Model
PEP 8015 - Organization of the Python community

but claims that 8010 and 8012 are placeholders - looking at the PEPs
themselves, this seems to be untrue.

I'd like to spend some time reviewing the proposals and understanding
the options we're being asked to vote on, but I do *not* want to waste
time reviewing proposals that are still in flux. How do I know when I
can do that? And where do I go to see what *other* people are saying
about the relative merits of the proposals? The topics on Discourse
seem to be limited to one proposal at a time - so I'm assuming they
are thrashing out details (that I don't really care about - I don't
have enough of a "high level" feel yet to want to get into that level
of detail).

I guess I am assuming here that a topic titled "PEP 8013: The External
Council Governance Model" is just about PEP 8013, and doesn't include
digressions and off-topic subthreads (such as "this is why I prefer
PEP xxx over PEP 8013"). I suppose I'm basing that on the fact that
the Discourse users are making a point that one of the advantages of
Discourse is that threads don't ramble like mailing lists do. In
reality, I'm suspicious - it seems to me that human nature is such
that discussions *do* digress, and go off topic. But again it's about
time - if Discourse is just as much a bunch of wide ranging
discussions as the mailing list is, I don't have time to follow all of
Discourse as well as all of the lists I follow, and I don't have the
time to learn how to manage and prioritise on Discourse (or at least,
whatever time I do have that I could use for that, I'd rather use to
better understand the governance proposals, as those are more
important!) In the end, I accept that "I don't have enough time to do
a good job" is something I have to accept and decide whether I abstain
from the vote, or skim and vote as best I can based on that. That's
something I can't expect help in deciding - but a little more clarity
on what's happening with the process would make it a lot easier for me
to make that decision myself.

Anyhow, this is probably a bit off-topic again. I don't know whether
anyone thinks I'm offering anything new here - I feel like I'm
explaining my concerns from another perspective, but maybe all that's
coming across is me going on about the same things over and over. If
so, I apologise. I'll do my best to assume that I've said my piece
now, and if nothing gets better then I'm just going to have to deal
with it, as my views have been heard and that's all I can expect.

Paul

From njs at pobox.com  Mon Nov  5 04:48:33 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 5 Nov 2018 01:48:33 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
Message-ID: <CAPJVwBmR-kjE-HTu1VauxB-V1ZU57Ozau5bPxqDZHL2O7BFHnw@mail.gmail.com>

On Sun, Nov 4, 2018 at 10:53 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> As one example of my confusion here,
> https://www.python.org/dev/peps/pep-8016/ is currently a 404.

Sorry about that ? there's a thread here with background:
    https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333

And the PR to add it is here:
    https://github.com/python/peps/pull/827

So it should be available on python.org soon.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From brett at python.org  Mon Nov  5 13:42:26 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 5 Nov 2018 10:42:26 -0800
Subject: [python-committers] If you care about the voting method, please
 vote ; -)
In-Reply-To: <38DC9B84-D80F-49A8-A069-FA636FD3B48D@stufft.io>
References: <CAExdVNnyCK6RzKxjquxiwiSwqc7ZsP1MdhAgPvULiFwsddnQvg@mail.gmail.com>
 <CAP1=2W4Dh-fpb5Ptpx=OhER02Ma+bmmkF8RaQL=pOui=c91-3A@mail.gmail.com>
 <CAOTb1wf+OPLGisajEp2eLKXBbbLADOHvO_t-DNYYuZaQZt-rQg@mail.gmail.com>
 <CAExdVNm9uuTkKQFn5Th-QE38=ZoiMY3WpBjxggRvDw_ieFFDhQ@mail.gmail.com>
 <CAOTb1wd=P4YU11as+g9WWaQ_YB6cBnJSSZ0FkfTW1ghSGDVAPw@mail.gmail.com>
 <38DC9B84-D80F-49A8-A069-FA636FD3B48D@stufft.io>
Message-ID: <CAP1=2W7NeTKGji2TYB=aQ=F-8WsU3zbaQ3Fo-ZBKnUCcHZMerA@mail.gmail.com>

Everyone who has spoken up on my behalf is right: I personally never viewed
the poll as binding. When I first suggested doing the poll my schedule
outline included a day to discuss the results as never considered it
something that was an objective thing to follow (I think we ended up with
about two days in the end as no one else volunteered to update the PEP
faster than me getting to it on Friday). Had it been close I would never
have suggested changing the PEP to help keep this discussion to a minimum
(which is why I personally pushed back any changes to the PEP to begin
with).

But as Donald points out below, the results were very clearly in
Condorcet's favour no matter how you wanted to measure things, whether it
was by the poll or "reading the room" based on how people seemed to be
reacting to the IRV selection to begin with. Since finding a voting system
that everyone is happy with appears impossible we had to choose something,
and with a clear preference from those that participating in the process I
decided to update the PEP -- with a prior announcement on that thread that
I was going to in order to provide people time to object -- to represent
what seemed like the closest thing we came to consensus to.

On Fri, 2 Nov 2018 at 18:04, Donald Stufft <donald at stufft.io> wrote:

>
>
> > On Nov 2, 2018, at 8:22 PM, Chris Jerdonek <chris.jerdonek at gmail.com>
> wrote:
> >
> > On Fri, Nov 2, 2018 at 5:09 PM Tim Peters <tim.peters at gmail.com> wrote:
> >>
> >> [Chris Jerdonek <chris.jerdonek at gmail.com>]
> >>> It would have been nice to know beforehand if the results of the poll
> >>> were going to change the PEP.
> >>
> >> Don't look at me ;-)  Like I said, "I'm not in charge of anything",
> >> and I had no input in changing PEP 8001 beyond contributing to the
> >> message thread, same as everyone else.
> >
> > My reply was to Brett and not to you. If I had known the poll was
> > going to be binding, I could have made an effort to participate in the
> > discussion and try to sway people. As it was, the discussion was
> > started and dominated by people who were against IRV. They are the
> > most motivated to change things, and they're also the ones most
> > motivated to participate in the poll. I couldn't afford to participate
> > in such a discussion otherwise, as I said in the discussion. There are
> > already 98 messages -- many of which are lengthy -- not to mention
> > messages in other threads. It would take a lot of time and emotional
> > energy to engage in such a discussion.
> >
> > --Chris
> >
>
>
> I don?t believe the poll *was* binding, certainly I suspect that if the
> results of the poll had been say, tied instead of a blowout that even if
> Condorcet had barely won out, that the PEP would not have changed (other
> than to update that while there were other methods, discussion around them
> compared to IRV was inconclusive). Rather I think that the poll and the
> entire discussion was weighed, both of which provide different signals
> (discussion tends to overweight people who are more passionate, whereas the
> poll takes very little effort to participate in, but tends to overweight
> people who don?t really care).
>
> Honestly, I?m not sure what you thought the point of the discussion was if
> not to advocate that the PEP itself should change and thus a possible
> outcome of that was that the PEP would change. Why else would that
> discussion exist? I can sympathize with being unable to participate due to
> time constraints, but we also have to weigh in realities like we?re never
> going to be able to structure such a discussion such that 100% of people
> are able and willing to participate in it, the best you can do is try to
> structure it to give everyone as much chance as possible.
>
> The selection of a voting mechanism ended up going through these layers:
>
> 1. In person discussion at an event in the West Coast USA.
> 2. Online discussion largely in discourse, but slightly on
> python-committers as well.
> 3. An online poll on discourse, with notification to python-committers.
>
> Of those, (1) selected IRV and while I was not there, I get the send that
> there wasn?t a strong preference for IRV in that meeting, rather it was
> better than plurality and something the attendees were familiar with. (2)
> seemed to me (and I may be biased) to heavily weight towards a ?Anything
> but Plurality or IRV? direction, and (3) ultimately confirmed that.
>
> While not everyone might not have gotten to have their voice heard, the
> discussion and the poll was accessible to any committer who could
> participate via online (which I suspect is most of them) with the barest
> amount of investment being to vote in the poll and otherwise ignore the
> discussion.
>
> I would also point out that while the poll itself was run via the Approval
> voting method [1], looking at the numbers it?s not hard to come to the
> conclusion that it?s hard to suggest that the *method* used by the poll
> gives us invalid results. For instance, if we had instead run the poll
> using IRV instead of Approval *and* we assume that every single person who
> approved of IRV would have ranked it first (and anyone who didn?t approve
> of IRV at all would have ranked it last)? then IRV still would have lost
> even if the poll was run via IRV.
>
> Unfortunately, It?s hard to know exactly how the voting mechanism would
> have affected the other results because while IRV was ?disapproved? by a
> significant margin, the other ones were not.
>
> However, since the poll was run using Approval, it?s hard for someone
> advocating for the Approval method to say that the results are invalid due
> to the method used, since it was their desired method that chose a method
> other than Approval.
>
> I suspect folks who prefer Condorcet are not going to complain too much
> about the poll using Approval, since it fair and away preferred Condorcet
> (21 of the 25 voters were OK with Condorcet) although it?s *possible* that
> the 20 people who were Condorcet voters would not have ranked it first, but
> that it was everyone?s second choice. Though if their first choice was
> Approval, see above!
>
> Really, 3-2-1 is the only one that it feels to me like could really argue
> about the tally method of the poll. The poll wasn?t run with their
> preferred method (like anyone who preferred Approval), they didn?t win,
> their loss wasn?t so great that they would have, for sure, lost under their
> own method [2], and if everyone who approved of them had picked them as
> their first choice, that?s roughly half of the people taking the poll.
> Fortunately I can say as one of the people who approved of 3-2-1, it would
> *not* have been my first choice, which pushes it from 12 to 13, to 11 to 14
> which makes it more unlikely that 3-2-1 would have won in any other method
> as well.
>
> Fortunately, the margins of the poll are such that the outcome is unlikely
> to have changed by having run the poll under a different method.
>
> [1] Largely because that?s what discourse polls supported, plus getting
> into a discussion about choosing the method we use to choose the method
> that we use to choose the method that we use to choose the method that we
> use to choose the PEP is an unsolvable, infinite problem.
> [2] We might be able to compute this by assuming approval = +1,
> disapproval = -1 and then running the simulation, but that?s more effort
> than I feel like putting in.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/e9532b09/attachment.html>

From brett at python.org  Mon Nov  5 14:10:49 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 5 Nov 2018 11:10:49 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
Message-ID: <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>

On Sun, 4 Nov 2018 at 10:53, Paul Moore <p.f.moore at gmail.com> wrote:

> On Sun, 4 Nov 2018 at 15:25, Steve Dower <steve.dower at python.org> wrote:
> > For example, right now, I'm leaning towards 8013, 8010, 8016, 8011,
> > 8012, 8015, 8014. But since some are still in flux (particularly 8016),
> > that could change. And my core rationale is basically how likely we are
> > to be able to fill the roles created by the model.
>
> As one example of my confusion here,
> https://www.python.org/dev/peps/pep-8016/ is currently a 404. So where
> are you seeing something you can express a preference on? Presumably
> you're looking at the raw data in github?
>
> I have limited time, and I feel like we were promised a deadline after
> which we could review what was being proposed, and discuss the
> proposals in a public forum. After that, there would be a vote. But at
> this point in time, I'm confused about:
>
> 1. When the proposals will be finalised and published.
>

We were hoping by now already, but unfortunately the voting discussion has
gone on longer than I think anyone planned for.


> 2. Where the discussion(s) will be taking place.
>

Discourse and here.


>
> PEP 8001 says that the vote will take place in the 2 weeks between 16
> Nov and 30 Nov. PEP 8000 states that the following proposals exist:
>
> PEP 8010 - The BDFL Governance Model
> PEP 8011 - Python Governance Model Lead by Trio of Pythonistas
> PEP 8012 - The Community Governance Model
> PEP 8013 - The External Governance Model
> PEP 8014 - The Commons Governance Model
> PEP 8015 - Organization of the Python community
>
> but claims that 8010 and 8012 are placeholders - looking at the PEPs
> themselves, this seems to be untrue.
>

It's outdated. I think Barry just hasn't thought of updating it yet since
it's just an index into the 801X PEPs which you can view in the PEP index
directly without any special background info (I know I personally forgot
that PEP 8000 even listed the various PEPs).


>
> I'd like to spend some time reviewing the proposals and understanding
> the options we're being asked to vote on, but I do *not* want to waste
> time reviewing proposals that are still in flux. How do I know when I
> can do that?


I think the original point to this thread was to figure that out. My
assumption is that if we don't change dates then all 801X PEPs will
forcibly go into "final" status and not be updated short of spelling
mistakes or clarifications that were simply overlooked -- i.e. no semantic
changes -- on November 15.


> And where do I go to see what *other* people are saying
> about the relative merits of the proposals? The topics on Discourse
> seem to be limited to one proposal at a time - so I'm assuming they
> are thrashing out details (that I don't really care about - I don't
> have enough of a "high level" feel yet to want to get into that level
> of detail).
>

Correct. No grand discussion has occurred as all the discussion has been
around getting the various PEPs to a final state that the proposers were
happy with.


>
> I guess I am assuming here that a topic titled "PEP 8013: The External
> Council Governance Model" is just about PEP 8013, and doesn't include
> digressions and off-topic subthreads (such as "this is why I prefer
> PEP xxx over PEP 8013"). I suppose I'm basing that on the fact that
> the Discourse users are making a point that one of the advantages of
> Discourse is that threads don't ramble like mailing lists do. In
> reality, I'm suspicious - it seems to me that human nature is such
> that discussions *do* digress, and go off topic. But again it's about
> time - if Discourse is just as much a bunch of wide ranging
> discussions as the mailing list is, I don't have time to follow all of
> Discourse as well as all of the lists I follow, and I don't have the
> time to learn how to manage and prioritise on Discourse (or at least,
> whatever time I do have that I could use for that, I'd rather use to
> better understand the governance proposals, as those are more
> important!) In the end, I accept that "I don't have enough time to do
> a good job" is something I have to accept and decide whether I abstain
> from the vote, or skim and vote as best I can based on that. That's
> something I can't expect help in deciding - but a little more clarity
> on what's happening with the process would make it a lot easier for me
> to make that decision myself.
>

So far people have been good about keeping Discourse on-topic. There is
also the benefit of being able to forcibly split a thread when it starts to
go off-topic (versus what happened here when the thread went off-topic and
the only way to stop that is to start a new email thread and hope people
pick up on the fact that it split off).


>
> Anyhow, this is probably a bit off-topic again.


Yes, but that's a drawback to mailing lists in my opinion and it's hard to
avoid. :)

-Brett


> I don't know whether
> anyone thinks I'm offering anything new here - I feel like I'm
> explaining my concerns from another perspective, but maybe all that's
> coming across is me going on about the same things over and over. If
> so, I apologise. I'll do my best to assume that I've said my piece
> now, and if nothing gets better then I'm just going to have to deal
> with it, as my views have been heard and that's all I can expect.
>
> Paul
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/4ca57b44/attachment-0001.html>

From barry at python.org  Mon Nov  5 14:17:49 2018
From: barry at python.org (Barry Warsaw)
Date: Mon, 5 Nov 2018 11:17:49 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
Message-ID: <29F74581-E1F1-449C-B3DA-403CFDB430B6@python.org>

On Nov 5, 2018, at 11:10, Brett Cannon <brett at python.org> wrote:

> It's outdated. I think Barry just hasn't thought of updating it yet since it's just an index into the 801X PEPs which you can view in the PEP index directly without any special background info (I know I personally forgot that PEP 8000 even listed the various PEPs).

I just updated the PEP 8010 description in PEP 8000.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/94945c40/attachment.sig>

From p.f.moore at gmail.com  Mon Nov  5 14:22:38 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 5 Nov 2018 19:22:38 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
Message-ID: <CACac1F_gvQQxFf4_kL8v7xmhTL12DCBb3uzQWy=6rzoTw4Dcrg@mail.gmail.com>

On Mon, 5 Nov 2018 at 19:11, Brett Cannon <brett at python.org> wrote:

>> Anyhow, this is probably a bit off-topic again.
>
> Yes, but that's a drawback to mailing lists in my opinion and it's hard to avoid. :)

I did consider what I would have done on Discourse, and came to the
conclusion that I would have done exactly the same - I've no idea how
Discourse would help with a "here's some things I thought of that I
felt needed saying while reading this thread" post. Obviously I could
move the reply to a new topic, but I could just as easily have changed
the subject in the mailing list. So without meaning to ignore your
smiley, I don't think it's really a fault with mailing lists, just
with how people discuss things ;-)

Paul

From p.f.moore at gmail.com  Mon Nov  5 14:29:44 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 5 Nov 2018 19:29:44 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
Message-ID: <CACac1F-AWfhm-qXKS1ATXBOE-ZB8BVzoGxBwNe=oPCG0RrSthA@mail.gmail.com>

On Mon, 5 Nov 2018 at 19:11, Brett Cannon <brett at python.org> wrote:
>> I'd like to spend some time reviewing the proposals and understanding
>> the options we're being asked to vote on, but I do *not* want to waste
>> time reviewing proposals that are still in flux. How do I know when I
>> can do that?
>
> I think the original point to this thread was to figure that out. My assumption is that if we don't change dates then all 801X PEPs will forcibly go into "final" status and not be updated short of spelling mistakes or clarifications that were simply overlooked -- i.e. no semantic changes -- on November 15.

Hmm, so voting opens immediately after the PEPs are finalised? No
discussion/debate period before that? Maybe I misunderstood, I'd
assumed that this would be more similar to an election process, with a
period of canvassing support and/or debating the strengths and
weaknesses of the proposals, leading up to a vote.

OK. I can't say I *like* that, but if that's what's happening then
that probably explains some of my confusion.
Paul

From brett at python.org  Mon Nov  5 14:32:36 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 5 Nov 2018 11:32:36 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F_gvQQxFf4_kL8v7xmhTL12DCBb3uzQWy=6rzoTw4Dcrg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
 <CACac1F_gvQQxFf4_kL8v7xmhTL12DCBb3uzQWy=6rzoTw4Dcrg@mail.gmail.com>
Message-ID: <CAP1=2W6fER0zaCwdXJ+6BeZW=VgC0rxRUtMGgj19rdxHAhEzoA@mail.gmail.com>

On Mon, 5 Nov 2018 at 11:22, Paul Moore <p.f.moore at gmail.com> wrote:

> On Mon, 5 Nov 2018 at 19:11, Brett Cannon <brett at python.org> wrote:
>
> >> Anyhow, this is probably a bit off-topic again.
> >
> > Yes, but that's a drawback to mailing lists in my opinion and it's hard
> to avoid. :)
>
> I did consider what I would have done on Discourse, and came to the
> conclusion that I would have done exactly the same - I've no idea how
> Discourse would help with a "here's some things I thought of that I
> felt needed saying while reading this thread" post. Obviously I could
> move the reply to a new topic, but I could just as easily have changed
> the subject in the mailing list. So without meaning to ignore your
> smiley, I don't think it's really a fault with mailing lists, just
> with how people discuss things ;-)
>

In Discourse an admin could have selected every post related to "Discourse
versus Mailing Lists" and then created a new topic. Here, I can't do that,
and people who choose to keep replying to this thread on this topic (like I
am now :) will be accidentally, directly working against keeping the
conversation on-topic. So my comment was more general to this overall
thread than you specifically, Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/573d68fe/attachment.html>

From donald at stufft.io  Mon Nov  5 14:34:12 2018
From: donald at stufft.io (Donald Stufft)
Date: Mon, 5 Nov 2018 14:34:12 -0500
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F-AWfhm-qXKS1ATXBOE-ZB8BVzoGxBwNe=oPCG0RrSthA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
 <CACac1F-AWfhm-qXKS1ATXBOE-ZB8BVzoGxBwNe=oPCG0RrSthA@mail.gmail.com>
Message-ID: <4B72078B-BD74-49CD-B82E-EB44C7B341D8@stufft.io>



> On Nov 5, 2018, at 2:29 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> Hmm, so voting opens immediately after the PEPs are finalised? No
> discussion/debate period before that? Maybe I misunderstood, I'd
> assumed that this would be more similar to an election process, with a
> period of canvassing support and/or debating the strengths and
> weaknesses of the proposals, leading up to a vote.


I don?t think there is anything stopping people from doing that right now (and honestly, right now seems like the *right* time to do that if it?s going to happen, so that the proposals can evolve based on any discussion that comes out of that). Waiting until the proposals are set in stone seems like a less useful implementation of that idea.

I suspect the reason that people aren?t doing that, is just nobody has started that discussion for one reason or another.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/2596c7f3/attachment-0001.html>

From brett at python.org  Mon Nov  5 14:37:22 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 5 Nov 2018 11:37:22 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F-AWfhm-qXKS1ATXBOE-ZB8BVzoGxBwNe=oPCG0RrSthA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
 <CACac1F-AWfhm-qXKS1ATXBOE-ZB8BVzoGxBwNe=oPCG0RrSthA@mail.gmail.com>
Message-ID: <CAP1=2W7M0Ez1e3=3VF+9C4fn6mC7+9RSQpsny=UxQ5Bt3b8Ufw@mail.gmail.com>

On Mon, 5 Nov 2018 at 11:29, Paul Moore <p.f.moore at gmail.com> wrote:

> On Mon, 5 Nov 2018 at 19:11, Brett Cannon <brett at python.org> wrote:
> >> I'd like to spend some time reviewing the proposals and understanding
> >> the options we're being asked to vote on, but I do *not* want to waste
> >> time reviewing proposals that are still in flux. How do I know when I
> >> can do that?
> >
> > I think the original point to this thread was to figure that out. My
> assumption is that if we don't change dates then all 801X PEPs will
> forcibly go into "final" status and not be updated short of spelling
> mistakes or clarifications that were simply overlooked -- i.e. no semantic
> changes -- on November 15.
>
> Hmm, so voting opens immediately after the PEPs are finalised? No
> discussion/debate period before that?


You get 2 weeks of that since the vote is open that long (as currently
planned). I'm not sure if the UK has this, but think of it like voting by
mail. People are still discussing stuff while you can mail in your vote, so
if you aren't ready to cast your vote until the last day then you can wait
while those of us who are ready Day 1 can vote early.


> Maybe I misunderstood, I'd
> assumed that this would be more similar to an election process, with a
> period of canvassing support and/or debating the strengths and
> weaknesses of the proposals, leading up to a vote.
>

But there's also no election _day_ like you might be used to, but instead
an election _pair of weeks_. Do you really want to have threads like this
for more than two weeks anyway? ;)


>
> OK. I can't say I *like* that, but if that's what's happening then
> that probably explains some of my confusion.
>

Hopefully the above explanation assuages your worries, otherwise I don't
understand your worries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/9314d86a/attachment.html>

From tim.peters at gmail.com  Mon Nov  5 14:48:54 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 5 Nov 2018 13:48:54 -0600
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F_gvQQxFf4_kL8v7xmhTL12DCBb3uzQWy=6rzoTw4Dcrg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
 <CACac1F_gvQQxFf4_kL8v7xmhTL12DCBb3uzQWy=6rzoTw4Dcrg@mail.gmail.com>
Message-ID: <CAExdVNkHhYVPE=2x8vuNf+bXnGF3Hj77hub+ZtZgr08GBmyakQ@mail.gmail.com>

[Paul Moore <p.f.moore at gmail.com>]
> I did consider what I would have done on Discourse, and came to the
> conclusion that I would have done exactly the same - I've no idea how
> Discourse would help with a "here's some things I thought of that I
> felt needed saying while reading this thread" post.

It wouldn't, and nobody would really care.  It's when a technically
off-topic sub-thread _grows_ that it becomes "a problem".  Sometimes
you just can't gauge interest in whether it will without making a
start.  If people pile on, the very lack of a fully-threaded view in
Discourse is what _drives_ people to split it off to a new "category"
of its own   Which is a better outcome for everyone!  If you do care
about the new category, it has its own space wholly dedicated to it.
If you don't care, don't follow it, and you'll never even know that
it's still going on.

> Obviously I could move the reply to a new topic, but I could just as
> easily have changed the subject in the mailing list.

But people don't.  If this sub-thread keeps going on, someone
eventually _will_ change the Subject line, and then you need "clever"
software to show you that it's still the same sub-thread, and it keeps
getting sent to everyone on the "python-committers" list whether they
want it or not.

> So without meaning to ignore your smiley, I don't think it's really a fault with
> mailing lists, just with how people discuss things ;-)

In the absence of trying it for yourself, you could, e.g., look for
what the people who designed the system had in mind.  The lack of a
fully threaded view in Discourse was 100% intentional, not due to,
e.g., laziness, or lack of time or skill.

Here's a start:

    https://blog.codinghorror.com/web-discussions-flat-by-design/

I'm not necessarily endorsing those views, but I did take the time to
try to find out _why_ they did what they did.  It wasn't capricious.
There are things I do and don't like about Discourse, but _which_
things are still changing for me over time ;-)

From p.f.moore at gmail.com  Mon Nov  5 16:28:41 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 5 Nov 2018 21:28:41 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <4B72078B-BD74-49CD-B82E-EB44C7B341D8@stufft.io>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CACac1F8ZYnPLQO1Gtvn+W+b7znHJ7cYZYO3ha8pwa_LzkDx-sA@mail.gmail.com>
 <20181104002115.GS3817@ando.pearwood.info>
 <CACac1F9NfXGxNjuL2a0zS+3iBh4wqC06SZYfLUe6_2b64=dW6w@mail.gmail.com>
 <f28be41d-167b-922d-1977-ff4ee20f1cc0@python.org>
 <CACac1F_X9Wbg3Nfh-Xyv9WGRiyMqvF-YdNaDEXH3yi4vhmXvLA@mail.gmail.com>
 <CAP1=2W7m5aWfSaxnDd15CS0t=c2fqcVfJ=3HhWxMZygQMMeKmg@mail.gmail.com>
 <CACac1F-AWfhm-qXKS1ATXBOE-ZB8BVzoGxBwNe=oPCG0RrSthA@mail.gmail.com>
 <4B72078B-BD74-49CD-B82E-EB44C7B341D8@stufft.io>
Message-ID: <CACac1F8GhbgXFSU2_773hzMOhwScJ3ygJagzey+GRKc1PH5Eeg@mail.gmail.com>

I'm going to quote multiple people here and respond to various
comments at once. It's way harder doing so than it would have been in
Discourse, so I'm sort of proving that for myself (but having said
that, I was already aware of, and fine with, the idea that Discourse
does stuff like this better - it's simply that I don't have the time
right now to learn a new bit of software and adapt my workflow to its
approach).

On Mon, 5 Nov 2018 at 19:34, Donald Stufft <donald at stufft.io> wrote:
> I don?t think there is anything stopping people from doing that right now (and honestly, right now seems like the *right* time to do that if it?s going to happen, so that the proposals can evolve based on any discussion that comes out of that). Waiting until the proposals are set in stone seems like a less useful implementation of that idea.

Well, in my case I specifically don't want to end up commenting on
things that have changed and my understanding is out of date. That's a
common problem with PEP discussions, and one that I don't feel would
be helpful here. But agreed, if you see it as "wait until things are
set in stone", it sounds worse. Seeing it as "waiting until things are
stable" sounds more reasonable (at least to me) while still meaning
essentially the same ;-)

> I suspect the reason that people aren?t doing that, is just nobody has started that discussion for one reason or another.

I suspect that what those reasons are would be interesting. I wonder
how high "because I didn't think the proposal was finished yet" would
come? It's what's stopping me (although I tend to comment on threads
started by others more than starting my own, so I'm not a good
example),

On Mon, 5 Nov 2018 at 19:37, Brett Cannon <brett at python.org> wrote:
> Hopefully the above explanation assuages your worries, otherwise I don't understand your worries.

To an extent, yes. My main worry is that there won't *be* the sort of
discussion I'm hoping for. I like to have a sense of what the broad
consensus is on a proposal before making my own final decision, and at
the moment there's no discussion that I've seen that gives me that
sort of sense. If that remains the case over the 2 week voting period,
it'll be a little late by that point. And it's not obvious to me how I
could *start* such a discussion - "so how are people going to vote?"
isn't a particularly subtle opening. This tends to be "solved" (in
some sense) in political debates by the various parties trying to
persuade people to vote for them. That's not happening here, and I
think I'm just finding that unnerving (because the whole process has a
feel of a political debate to me).

Anyhow, I guess it's just me expecting something from the process that
it's not. And that's for me to deal with.

On Mon, 5 Nov 2018 at 19:49, Tim Peters <tim.peters at gmail.com> wrote:
> In the absence of trying it for yourself, you could, e.g., look for
> what the people who designed the system had in mind.  The lack of a
> fully threaded view in Discourse was 100% intentional, not due to,
> e.g., laziness, or lack of time or skill.
>
> Here's a start:
>
>     https://blog.codinghorror.com/web-discussions-flat-by-design/
>
> I'm not necessarily endorsing those views, but I did take the time to
> try to find out _why_ they did what they did.  It wasn't capricious.
> There are things I do and don't like about Discourse, but _which_
> things are still changing for me over time ;-)

Thanks, Tim. That link is definitely something I'll read up on. My
impression has always been that every part of Discourse's design was
carefully thought through, but I hadn't seen any specifics before. As
I say above, though, it's not that I don't intend to try Discourse
(and indeed, I know there are many things I expect to like about it) -
it's simply that I don't have time right now. I'm twitchy about that
fact because I *want* to follow the discussions on the governance
issues, but I haven't worked out an effective way to do so with the
time I have available right now.

(No need for replies to any of the above. I appreciate all of the
comments and anything I'm still concerned about is something I'll have
to work out for myself).

Paul

From vstinner at redhat.com  Mon Nov  5 17:08:42 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 5 Nov 2018 23:08:42 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <a14181f2-3e7d-07de-780a-6cc7e3035527@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
 <a14181f2-3e7d-07de-780a-6cc7e3035527@python.org>
Message-ID: <CA+3bQGEAwPqnXM4raoZKE0cyO9mHEWV=rJsoPm28Ti+eKn4kzQ@mail.gmail.com>

Le sam. 3 nov. 2018 ? 10:39, Antoine Pitrou <antoine at python.org> a ?crit :
> > I'm unhappy with the "[] Further discussion" choice. We have a
> > governance crisis. Many people would like to see it resolved as soon
> > as possible, I don't see the ability to vote for "[] Further
> > discussion" as a way to resolve this crisis.
>
> Why are you worried?  If many people would like to see the "crisis" (I
> would call it a void) resolved early, then probably "Further discussion"
> won't win.  So how is its presence a problem?

PEPs cannot be approved since July. It seems like we will not be able
to approve PEPs before January, even if a governance PEP is approved
and a new council/committee/whatever is elected.

There was a discussion abouge BDFL-delegate for Jeroen Demeyer's PEP
580 which has been somehow blocked (sorry, I didn't follow closely the
discussion, so I'm not sure of the outcome).

I would prefer the situation to be unblocked as soon as possible to
unblock Python 3.8. Otherwise, Python 3.8 will be the release of the
governance crisis with no large new features.

I know that at least two core developers have pending PEPs that they
didn't publish because there is nobody to approve PEPs.

Victor

From donald at stufft.io  Mon Nov  5 17:17:14 2018
From: donald at stufft.io (Donald Stufft)
Date: Mon, 5 Nov 2018 17:17:14 -0500
Subject: [python-committers] IMPORTANT: Missing Email Addresses for
 Governance Election Voter Roll
Message-ID: <A626D824-0C02-44EF-9A6C-B1873666FAEC@stufft.io>

We need a list of core developers email addresses to send ballot emails to. Since PEP 8001 states that we?re using inclusion in the ``python-core`` team on GitHub as the list of ?registered voters?, I wrote up a quick script that compiled a list of GitHub usernames in that team *today* and any public email address on their GitHub profile if there is one.

That is located at https://github.com/python/voters <https://github.com/python/voters> (specifically the 2018-11-16-governance-election.csv file), which is a private repository.

Please everyone take a moment to find your GitHub username in that file (it?s in alphabetical order) and ensure that the email address there is a good email for you to send your ballot to. If it?s wrong or missing, update the CSV file (there is a .voters.csv file that will taken into effect for any future voter rolls we may generate from this script).

If you?re not a member of the python-core team on Github and you want to participate in the vote, please ask to be added to that team, then add yourself to the 2018-11-16-governance-election.csv file.

We particularly need the following people (GitHub usernames) to go fill in their email addresses, as we do not currently have an email address for them, and without an email address, we cannot send you a ballot.

- [ ] @abalkin
- [ ] @akuchling
- [ ] @aleaxit
- [ ] @amauryfa
- [ ] @applio
- [ ] @avassalotti
- [ ] @brettcannon
- [ ] @doerwalter
- [ ] @doko42
- [ ] @eliben
- [ ] @ericsnowcurrently
- [ ] @ericvsmith
- [ ] @ezio-melotti
- [ ] @facundobatista
- [ ] @ilevkivskyi
- [ ] @jcea
- [ ] @jeremyhylton
- [ ] @larryhastings
- [ ] @lisroach
- [ ] @malemburg
- [ ] @Mariatta
- [ ] @markshannon
- [ ] @methane
- [ ] @mhammond
- [ ] @nascheme
- [ ] @ncoghlan
- [ ] @ned-deily
- [ ] @pfmoore
- [ ] @pitrou
- [ ] @pjenvey
- [ ] @rbtcollins
- [ ] @rhettinger
- [ ] @sandrotosi
- [ ] @serhiy-storchaka
- [ ] @sjoerdmullender
- [ ] @skrah
- [ ] @stevendaprano
- [ ] @taleinat
- [ ] @vadmium
- [ ] @willingc

This list of people is also available on Github at https://github.com/python/voters/issues/1 <https://github.com/python/voters/issues/1> (primarily so people would get a GitHub notification as well).

Thanks!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181105/36a5be00/attachment.html>

From antoine at python.org  Mon Nov  5 17:18:40 2018
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 5 Nov 2018 23:18:40 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEAwPqnXM4raoZKE0cyO9mHEWV=rJsoPm28Ti+eKn4kzQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CAExdVNkhbLp_15GfeVXXYk8WdT8TUMob3u_+EZfbqnL_TwSomQ@mail.gmail.com>
 <CA+3bQGEV9isidYsZiKOpMLpAcWYvC7M+T_tWp0Mv02ZXBODAAg@mail.gmail.com>
 <a14181f2-3e7d-07de-780a-6cc7e3035527@python.org>
 <CA+3bQGEAwPqnXM4raoZKE0cyO9mHEWV=rJsoPm28Ti+eKn4kzQ@mail.gmail.com>
Message-ID: <111ef0f1-50da-0ba0-049f-ccbf5d8d2251@python.org>


Le 05/11/2018 ? 23:08, Victor Stinner a ?crit?:
> Le sam. 3 nov. 2018 ? 10:39, Antoine Pitrou <antoine at python.org> a ?crit :
>>> I'm unhappy with the "[] Further discussion" choice. We have a
>>> governance crisis. Many people would like to see it resolved as soon
>>> as possible, I don't see the ability to vote for "[] Further
>>> discussion" as a way to resolve this crisis.
>>
>> Why are you worried?  If many people would like to see the "crisis" (I
>> would call it a void) resolved early, then probably "Further discussion"
>> won't win.  So how is its presence a problem?
> 
> PEPs cannot be approved since July.

Let me repeat the question: if "Further discussion" has no chance of
winning, why are you bothered by its presence?

Regards

Antoine.

From vstinner at redhat.com  Mon Nov  5 20:27:49 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 6 Nov 2018 02:27:49 +0100
Subject: [python-committers] Comparison of the 7 governance PEPs
Message-ID: <CA+3bQGFbw9PX5bkYf68kxvDyfCOVk57q7Dk9L6ziDU3R-ZfmtA@mail.gmail.com>

Hi Paul,

Le sam. 3 nov. 2018 ? 11:55, Paul Moore <p.f.moore at gmail.com> a ?crit :
> Currently, I feel like my only option is to abstain and hope - I don't
> have the time (or knowledge) to review, understand and assess the
> proposals well enough to make an informed vote, but I have no way of
> assessing the "expert opinions" of those who do, to allow me to make a
> broad judgement. Frankly, I feel pretty disenfranchised by the process
> at the moment.

I wrote a comparison and summary of the 7 governance PEPs for you :-)

https://discuss.python.org/t/comparison-of-the-7-governance-peps/392

WARNING: It is not always easy to extract the information and
summarize it, so it?s likely that I made mistakes.

Two weeks ago (October 24), Jake Edge wrote "Picking a governance
model for Python" on LWN: https://lwn.net/Articles/769178/ I didn't
publish the link earlier, since previously you required to have a LWN
account to read it (I do!).

Victor

From ncoghlan at gmail.com  Tue Nov  6 05:14:36 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 6 Nov 2018 20:14:36 +1000
Subject: [python-committers] IMPORTANT: Missing Email Addresses for
 Governance Election Voter Roll
In-Reply-To: <A626D824-0C02-44EF-9A6C-B1873666FAEC@stufft.io>
References: <A626D824-0C02-44EF-9A6C-B1873666FAEC@stufft.io>
Message-ID: <CADiSq7c_2-k4sVbyrsHbyMaq0bNWccaU0Fx_soidYeaH6xt9NA@mail.gmail.com>

On Tue, 6 Nov 2018 at 08:17, Donald Stufft <donald at stufft.io> wrote:
>
> We need a list of core developers email addresses to send ballot emails to. Since PEP 8001 states that we?re using inclusion in the ``python-core`` team on GitHub as the list of ?registered voters?, I wrote up a quick script that compiled a list of GitHub usernames in that team *today* and any public email address on their GitHub profile if there is one.
>
> That is located at https://github.com/python/voters (specifically the 2018-11-16-governance-election.csv file), which is a private repository.
>
> Please everyone take a moment to find your GitHub username in that file (it?s in alphabetical order) and ensure that the email address there is a good email for you to send your ballot to. If it?s wrong or missing, update the CSV file (there is a .voters.csv file that will taken into effect for any future voter rolls we may generate from this script).
>
> If you?re not a member of the python-core team on Github and you want to participate in the vote, please ask to be added to that team, then add yourself to the 2018-11-16-governance-election.csv file.
>
> We particularly need the following people (GitHub usernames) to go fill in their email addresses, as we do not currently have an email address for them, and without an email address, we cannot send you a ballot.

You should have email addresses for us, they're just in
bugs.python.org (which is necessarily linked on GitHub usernames, as
otherwise the CLA check wouldn't pass).

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From donald at stufft.io  Tue Nov  6 07:24:31 2018
From: donald at stufft.io (Donald Stufft)
Date: Tue, 6 Nov 2018 07:24:31 -0500
Subject: [python-committers] IMPORTANT: Missing Email Addresses for
 Governance Election Voter Roll
In-Reply-To: <CADiSq7c_2-k4sVbyrsHbyMaq0bNWccaU0Fx_soidYeaH6xt9NA@mail.gmail.com>
References: <A626D824-0C02-44EF-9A6C-B1873666FAEC@stufft.io>
 <CADiSq7c_2-k4sVbyrsHbyMaq0bNWccaU0Fx_soidYeaH6xt9NA@mail.gmail.com>
Message-ID: <0740F7DF-8C0D-41A9-88F6-B3125C09DC30@stufft.io>



> On Nov 6, 2018, at 5:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On Tue, 6 Nov 2018 at 08:17, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
>> 
>> We need a list of core developers email addresses to send ballot emails to. Since PEP 8001 states that we?re using inclusion in the ``python-core`` team on GitHub as the list of ?registered voters?, I wrote up a quick script that compiled a list of GitHub usernames in that team *today* and any public email address on their GitHub profile if there is one.
>> 
>> That is located at https://github.com/python/voters (specifically the 2018-11-16-governance-election.csv file), which is a private repository.
>> 
>> Please everyone take a moment to find your GitHub username in that file (it?s in alphabetical order) and ensure that the email address there is a good email for you to send your ballot to. If it?s wrong or missing, update the CSV file (there is a .voters.csv file that will taken into effect for any future voter rolls we may generate from this script).
>> 
>> If you?re not a member of the python-core team on Github and you want to participate in the vote, please ask to be added to that team, then add yourself to the 2018-11-16-governance-election.csv file.
>> 
>> We particularly need the following people (GitHub usernames) to go fill in their email addresses, as we do not currently have an email address for them, and without an email address, we cannot send you a ballot.
> 
> You should have email addresses for us, they're just in
> bugs.python.org <http://bugs.python.org/> (which is necessarily linked on GitHub usernames, as
> otherwise the CLA check wouldn't pass).
> 

If roundup has an API, feel free to submit a PR to generate-voter-roll.py in that same repository to have it pull from bugs.p.o as well. I already knew GitHub?s API so it was easy to spend 15 minutes tossing something together that would work. Clicking on the ?tracker documentation? link doesn?t mention an API at all.

If there?s no API, well there was 40 names, even if I spent 5 minutes each doing it manually, that?s still like 3+ hours of clicking through bugs.p.o trying to converge the two lists, and I don?t have 3+ hours to burn at the moment, so I figured it was easier to ask each of those 40 people to spend 5  minutes individually.

Sorry if you don?t feel that?s sufficient. I?m short on time leading up to Re:invent and trying to do the best I can with what time I can steal from elsewhere.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181106/7063dc97/attachment-0001.html>

From vstinner at redhat.com  Tue Nov  6 08:19:37 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 6 Nov 2018 14:19:37 +0100
Subject: [python-committers] IMPORTANT: Missing Email Addresses for
 Governance Election Voter Roll
In-Reply-To: <0740F7DF-8C0D-41A9-88F6-B3125C09DC30@stufft.io>
References: <A626D824-0C02-44EF-9A6C-B1873666FAEC@stufft.io>
 <CADiSq7c_2-k4sVbyrsHbyMaq0bNWccaU0Fx_soidYeaH6xt9NA@mail.gmail.com>
 <0740F7DF-8C0D-41A9-88F6-B3125C09DC30@stufft.io>
Message-ID: <CA+3bQGFXZsZRwnoWF6A=8R=8mj3-9W5obcuvhGs9jgfypJAfiA@mail.gmail.com>

I'm not sure about Roundup. In the web UI, the email address is
partially hidden for me. I'm not a Roundup Admin.

Le mar. 6 nov. 2018 ? 13:24, Donald Stufft <donald at stufft.io> a ?crit :
> If roundup has an API, feel free to submit a PR to generate-voter-roll.py in that same repository to have it pull from bugs.p.o as well. I already knew GitHub?s API so it was easy to spend 15 minutes tossing something together that would work. Clicking on the ?tracker documentation? link doesn?t mention an API at all.

I wrote a few lines to access to XML-RPC API of Roundup to generate
this list of vulnerabilities:
https://github.com/vstinner/python-security/blob/ad333b301fbc5ef3a954ed7c67affc48241a7a8f/render_doc.py#L393-L411

You probably want the server.display('user%s' % msg['author'],
'username', 'realname') part. I didn't check if I can use it to access
the email address.

FYI the result is this website:
http://python-security.readthedocs.io/vulnerabilities.html

Victor

From lukasz at langa.pl  Tue Nov 13 12:00:01 2018
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Tue, 13 Nov 2018 18:00:01 +0100
Subject: [python-committers] How do you find Discourse so far?
Message-ID: <2FEFEDB9-55BE-4190-8523-7EDB79F846D9@langa.pl>

Here's a poll:
https://discuss.python.org/t/how-do-you-find-discourse-so-far/429 <https://discuss.python.org/t/how-do-you-find-discourse-so-far/429>

- ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181113/b4e75463/attachment.html>

From mariatta at python.org  Wed Nov 14 17:12:00 2018
From: mariatta at python.org (Mariatta Wijaya)
Date: Wed, 14 Nov 2018 14:12:00 -0800
Subject: [python-committers] IMPORTANT: Missing Email Addresses for
 Governance Election Voter Roll
In-Reply-To: <CA+3bQGFXZsZRwnoWF6A=8R=8mj3-9W5obcuvhGs9jgfypJAfiA@mail.gmail.com>
References: <A626D824-0C02-44EF-9A6C-B1873666FAEC@stufft.io>
 <CADiSq7c_2-k4sVbyrsHbyMaq0bNWccaU0Fx_soidYeaH6xt9NA@mail.gmail.com>
 <0740F7DF-8C0D-41A9-88F6-B3125C09DC30@stufft.io>
 <CA+3bQGFXZsZRwnoWF6A=8R=8mj3-9W5obcuvhGs9jgfypJAfiA@mail.gmail.com>
Message-ID: <CAGbohnYiXK4aH+MiWssEnk8uL6TwC_ziv5TYi3w1fZE110GSCw@mail.gmail.com>

Bump. Some emails still missing, and we need them if you intend to vote in
the upcoming CPython general election: Nov 16, 2018.

Please provide your email address ASAP and before Nov 16, 2018.

See this issue for more details.
https://github.com/python/voters/issues/1


?

On Tue, Nov 6, 2018 at 5:19 AM Victor Stinner <vstinner at redhat.com> wrote:

> I'm not sure about Roundup. In the web UI, the email address is
> partially hidden for me. I'm not a Roundup Admin.
>
> Le mar. 6 nov. 2018 ? 13:24, Donald Stufft <donald at stufft.io> a ?crit :
> > If roundup has an API, feel free to submit a PR to
> generate-voter-roll.py in that same repository to have it pull from
> bugs.p.o as well. I already knew GitHub?s API so it was easy to spend 15
> minutes tossing something together that would work. Clicking on the
> ?tracker documentation? link doesn?t mention an API at all.
>
> I wrote a few lines to access to XML-RPC API of Roundup to generate
> this list of vulnerabilities:
>
> https://github.com/vstinner/python-security/blob/ad333b301fbc5ef3a954ed7c67affc48241a7a8f/render_doc.py#L393-L411
>
> You probably want the server.display('user%s' % msg['author'],
> 'username', 'realname') part. I didn't check if I can use it to access
> the email address.
>
> FYI the result is this website:
> http://python-security.readthedocs.io/vulnerabilities.html
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181114/941e557a/attachment.html>

From vstinner at redhat.com  Thu Nov 15 06:59:25 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 15 Nov 2018 12:59:25 +0100
Subject: [python-committers] PEP 8015: Organization of the Python
 community
In-Reply-To: <CA+3bQGGqD-6MH9GO-eymB5hmqcGU+cgPiBVgpMUXme+3EdVZng@mail.gmail.com>
References: <CA+3bQGGqD-6MH9GO-eymB5hmqcGU+cgPiBVgpMUXme+3EdVZng@mail.gmail.com>
Message-ID: <CA+3bQGG5KcTO_zdYf7D2S_U0q0CL4GH5BqOy6LDXr2EHSxaakg@mail.gmail.com>

Hi,

Since October 8, we had many productive discussions on governance PEPs
and I made multiple changes to my PEP 8015. See the "Version History"
at the end. The latest (I hope the *last*) change is that the Steering
Committee is now made of 5 people instead of 3, there are no term
limits (instead of a limit of 2 mandates: 6 years in total), and a
committee member can now be a PEP delegate. Full text below.

HTML version:
https://www.python.org/dev/peps/pep-8015/


PEP: 8015
Title: Organization of the Python community
Author: Victor Stinner
Status: Active
Type: Informational
Content-Type: text/x-rst
Created: 2018-10-04

Abstract
========

This PEP formalizes the current organization of the Python community and
proposes 3 main changes:

* Formalize the existing concept of "Python teams";
* Give more autonomy to Python teams;
* Replace the BDFL (Guido van Rossum) with a new "Python Steering
  Committee" of 5 members which has limited roles: basically decide how
  decisions are taken, but don't take decisions.

PEPs are approved by a PEP delegate or by a vote (reserved to core
developers, need ``>= 2/3`` majority).


Rationale
=========

This PEP describes the organization of the whole Python development
community, from Python users to the Python Steering Committee.
Describing all groups and all roles in the same document helps to make
the organization more consistent.

The number of governance changes is minimized to get a smooth transition
from the old BDFL organization to the new Steering Committee
organization.

One key design of the organization is to avoid decision bottlenecks.
Discussions and decisions are distributed into Python teams where
experts in each topic can be found. The expectation is smoother
discussions on PEPs: fewer people with better knowledge of the topic.

Previously, most decisions have been taken by the Benevolent
Dictator For Life (BDFL), Guido van Rossum. The growing popularity of
Python increased the pressure on a single person. The proposed
organization distributes decisions and responsibilities to reduce the
pressure and avoid wearing any individual down.

To keep most of the decision power within the hands of the community,
the Python Steering Committee has very limited roles. The idea is to
reduce the risk
that a group of people or companies "takes over" the Python project
through just a couple individuals. The project must remain autonomous
and open to everybody.

The most sensitives PEPs are decided by democracy: a vote reserved to
core developers, see the `PEP process`_ section below for the voting
method.


Common Guidelines
=================

* The Python community is open to everyone.
* Members must respect the `Python Community Code of Conduct
  <https://www.python.org/psf/codeofconduct/>`_ which ensures that
  discussions remain constructive and that everybody feels welcomed.
* Python is and will remain an autonomous project.
* People with decisions power should reflect the diversity of its users
  and contributors.


Community Organization
======================

Right now, there are different group of people involved in the Python
project. The more involved you are, the more decisions power you get. It
is important that the people acceding to the deepest group are the most
trusted ones.

This PEP formalizes the following groups:

* Python Users
* Python Contributors
* Python Teams Members
* Python Core Developers
* Python Steering Committee Members
* PSF Code of Conduct Workgroup


Python Users
============

This is the largest group: anyone who uses Python.


Python Contributors
===================

Once a Python user sends an email to a Python mailing list, comments on
the Python bug tracker, proposes or reviews a Python change, they become
a Python contributor.


Python Teams
============

Python became too big to work as an unique team anymore, people
naturally have grouped themselves as teams to work more closely on
specific topics, sometimes called "Special Interest Group" (SIG).

When enough developers are interested by a specific topic, they can
create a new team. Usually, the main action is to ask the Python
postmaster to create a new "SIG" mailing list, but the team can choose
to use a different communication channel.

Team members are Python contributors and Python core developers. The
team is self-organized and is responsible to select who can join the
team and how.

Team members can get the bug triage permission on the team bug tracker
component. The more involved in a team you are, the more decisions power
and responsibilities you get.

A team might become allowed to decide on their own PEPs, but only the
Python Steering Committee can allow that (and it has the power to revoke
it as well). Such a case is exceptional, currently a single team has
such permission: the Packaging Team.

See `Annex: Examples of Python Teams`_.


Python Core Developers
======================

One restricted definition of a core developer is the ability to merge a
change (anywhere in the code) and have the bug triage permission
(on all bug tracker components).

Core developers are developers who are proven to have the required skills to
decide if a change can be approved or must be rejected, but also (and
this is more important) what changes should not be made. Python has a
long history, big constraints on backward compatibility, high quality
standards (ex: changes require new tests). For these reasons, becoming
a core can take several months or longer.

Becoming a core developer means more responsibilities. For example, if a
developer merges a change, they become responsible for regressions and
for the maintenance of that modified code.

Core developers are expected to be exemplary when it comes to the Code
of Conduct. They are encouraged to mentor contributors.

Promote a contributor as core developer
---------------------------------------

Once an existing core developer considers that a contributor is ready to
join the core group, to become a core developer, that core developer
asks the contributor if they would like to become a core developer. If
the contributor is interested in such new responsibilities, a vote is
organized.

The vote is reserved to core developers, is public, and is open for 1
week.  Usually the core developer who proposes the promotion has to
describe the work and skills of the candidate in the description of the
vote. A contributor is only promoted if two thirds (``>= 2/3``) of
votes approve ("+1") the promotion. Only "+1" and "-1" votes are
accounted; other votes (ex: null, "-0", "+0.5") are ignored.

If the candidate is promoted, usually they get a mentor for 1 month to
help them to handle new responsibilities.

If the candidate is not promoted, a new vote can be organized later,
when the candidate gets the missing skills, for example 6 months later.


Python Steering Committee
=========================

The Python Steering Committee is made of the most trusted core
developers since it has the most decision power. The roles of this group
are strictly limited to ensure that Python keeps its autonomy and
remains open.

The Python Steering Committee is composed of 5 members. They are elected
for 3 years and 1/3 is replaced every year (first year: 1, second year:
2, third year: 2). This way, a member will stay for one full Python
release and the committee composition will be updated frequently. A
committee member can be a candidate for the seat they are leaving.
There are no term limits.

Committee members must be Python core developers. It is important that
the members of the committee reflect the diversity of Python' users and
contributors. A small step to ensure that is to enforce that only 2
members (strictly less than 50% of the 5 members) can work for the same
employer (same company or subsidiaries of the same company).

The size of 5 members has been chosen for the members diversity and to
ensure that the committee can continue to work even if a member becomes
unavailable for an unknown duration.

Python Steering Committee Roles
-------------------------------

Python Steering Committee roles:

* Decide how a PEP is approved (or rejected or deferred).
* Grant or revoke permissions to a Python team. For example, allow
  a team to give the bug triage permission (on the team component) to a
  contributor.

To decide how a PEP is approved (or rejected or deferred), there are two
options:

* The committee elects a PEP delegate (previously known as "BDFL-delegate"):
  a core developer who will take the final decision for the specific
  PEP. The committee select the PEP delegate who can be proposed by the
  Python team where the PEP is discussed.
* The committee can organize a vote on on the PEP, see `PEP process`_
  for the vote organization. The committee decides when the vote is
  organized. A vote is preferred for changes affecting all Python users,
  like language changes.

The committee keeps the "vision" and consistency of Python. It also makes
sure that important features reach completion. Their ability to pick PEP
delegates is meant to help them to achieve that goal.

Election of Python Steering Committee Members
---------------------------------------------

The vote is organized by the Steering Committee. It is announced 3 weeks
in advance: candidates have to apply during this period. The vote is
reserved to core developers and is open for 1 week. To avoid
self-censorship, the vote uses secret ballots: avoid the risk of
hostility from someone who may get more power (if they get elected).

The vote uses the `Schulze/Beatpath/CSSD variant
<https://en.wikipedia.org/wiki/Schulze_method>`_ of the `Condorcet
method <https://en.wikipedia.org/wiki/Condorcet_method>`_ using an
online service like `Condorcet Internet Voting Service (CIVS)
<https://civs.cs.cornell.edu/>`_. This voting method reduces the risk of
tie. It also produces a ranking of all candidates, needed for the
creation of the committee.

In case of tie, a new vote is organized immediately between candidates
involved in the tie using the same voting method and also during 1 week.
If the second vote leads to a tie again, the current Steering Committee
is responsible to select the elected member(s).

If a committee member steps down, a new vote is organized to replace
them.

If the situation of a committee member changes in a way that no longer
satisfies the committee constraint (ex: they move to the same company as
two other committee members), they have to resign. If the employer of a
member is acquired by the employer of two other members, the member with
the mandate ending earlier has to resign once the acquisition completes.

Election Creating the Python Steering Committee Members
-------------------------------------------------------

To bootstrap the process, 5 members are elected at the committee
creation. The vote follows the same rules than regular committee votes,
except that the election needs 5 members, and the vote is organized by
the PSF Board.

In a council election, if 3 of the top 5 vote-getters work for the
same employer, then whichever of them ranked lowest is disqualified
and the 6th-ranking candidate moves up into 5th place; this is
repeated until a valid council is formed.

In case of tie, a second vote is organized immediately between
candidates involved in the tie and following candidates to fill the
remaining seats. The vote follows the same rules as the regular
committee vote. If the second vote still result in a tie, the PSF Board
is responsible to elect members and decide their position in the vote
result.

The order in the vote result must be unique for elected members: #1 and
#2 are elected for 3 years, #2 and #3 for 2 years, and #5 for 1 year.

Example of vote result with a tie:

* A
* B
* C
* D
* E, F
* G
* ...

The first 4 candidates (A, B, C and D) are elected immediately. If E
works for the same employer than two other elected member, F is also
elected. Otherwise, a second vote is organized for the 5th seat between
E and F.

Special Case: Steering Committee Members And PEPs
-------------------------------------------------

A committee member can be a PEP delegate.

A committee member can propose a PEP, but cannot be the PEP delegate of
their own PEP.

When the committee decides that a PEP must be voted, committee members
can vote as they are also core developers, but they don't have more
power than other core developer.


PSF Code of Conduct Workgroup
=============================

Charter
-------

The workgroup's purpose is to foster a diverse and inclusive Python
community by enforcing the PSF code of conduct, along with providing
guidance and recommendations to the Python community on codes of
conduct, that supports the PSF mission of ?ongoing development of
Python-related technology and educational resources?.

We work toward this common goal in three ways:

* Review, revise, and advise on policies relating to the PSF code of
  conducts and other communities that the PSF supports. This includes
  any #python chat community & python.org email list under PSF
  jurisdiction.
* Create a standard set of codes of conduct and supporting documents for
  multiple channels of interaction such as, but not limited to,
  conferences, mailing lists, slack/IRC, code repositories, and more.
* Develop training materials and other processes to support Python
  community organizers in implementing and enforcing the code of
  conduct.

The organization of this workgroup is defined by the
`ConductWG Charter <https://wiki.python.org/psf/ConductWG/Charter>`_.

Special Case: Ban a core developer
----------------------------------

As any other member of the Python community, the PSF Code of Conduct
Workgroup can ban a core developer for a limited amount of time. In this
case, the core developer immediately loses their core developer status.
Core developers are expected to be exemplary when it comes to the Code
of Conduct.

In general, a ban is only the last resort action when all other options
have been exhausted.

At the end of the ban, the developer is allowed to contribute again as a
regular contributor.

If the developer changes their behavior, another core developer can
organize a new vote to propose the developer for promotion to core
developer. The vote follows the same process than for any other Python
contributor.


PEP process
===========

There are 2 main roles on PEPs:

* PEP Authors
* PEP Delegate

PEP Authors do their best to write high quality PEP.

The PEP delegate is responsible to help the authors to enhance their PEP
and is the one taking the final decision (accept, reject or defer the
PEP). They can also help to guide the discussion.

If no decision is taken, the authors can propose again the PEP later
(ex: one year later), if possible with new data to motivate the change. A
PEP Delegate can also choose to mark a PEP as "Deferred" to not reject
the PEP and encourage to reopen the discussion later.

PEPs specific to a Python team are discussed on the team mailing list.
PEPs impacting all Python developers (like language changes) must be
discussed on the python-dev mailing list.

Vote on a PEP
-------------

When the Python Steering Committee decides that a PEP needs a wider
approval, a vote is organized.

The vote is reserved to core developers, is public, is announced 1 week
in advance, and is open for 1 week. The PEP can still be updated during
the 1 week notice, but must not be modified during the vote. Such vote
happens on
the mailing list where the PEP has been discussed. The committee decides
when the vote is organized. The PEP must have been discussed for a
reasonable amount of time before it is put to vote.

A PEP is only approved if two thirds (``>= 2/3``) of votes approve
("+1") the PEP.  Only "+1" and "-1" votes are accounted; other votes
(ex: null, "-0", "+0.5") are ignored.

A PEP can only be approved or rejected by a vote, not be deferred.


Lack of Decision
================

If a discussion fails to reach a consensus, if the Python Steering
Committee fail to choose a PEP delegate, or if a PEP delegate fails to
take a decision, the obvious risk is that Python fails to evolve.

That's fine. Sometimes, doing nothing is the wisest choice.


Change this PEP
===============

The first version of this PEP has been written after Guido van Rossum
decided to resign from his role of BDFL in July 2018. Before this PEP,
the roles of Python community members have never been formalized. It is
difficult to design a perfect organization at the first attempt. This
PEP can be updated in the future to adjust the organization, specify how
to handle corner cases and fix mistakes.

Any change to this PEP must be validated by a vote. The vote is
announced 3 weeks in advance, is reserved to core developers, happens in
public on the python-committers mailing list, and is open for 1 week.
The proposed PEP change can still be updated during the 3 weeks notice,
but must not be modified during the vote.

The change is only approved if four fifths (``>= 4/5``) of votes approve
("+1") the change. Only "+1" and "-1" votes are accounted; other votes
(ex: null, "-0", "+0.5") are ignored.


Annex: Summary on votes
=======================

======================  =======  ======  =======
=================================
Vote                    Notice   Open    Ballot   Method
======================  =======  ======  =======
=================================
Promote contributor     none     1 week  public   ``>= 2/3`` majority
PEP                     1 week   1 week  public   ``>= 2/3`` majority
Change this PEP         3 weeks  1 week  public   ``>= 4/5`` majority
Steering Committee      3 weeks  1 week  private  Condorcet
(Schulze/Beatpath/CSSD)
======================  =======  ======  =======
=================================

All these votes are reserved to core developers.


Annex: Examples of Python Teams
===============================

Below are examples of some Python teams (the list will not be kept up to
date in this PEP).

Packaging Team
--------------

The packaging team runs its own PEP category and can approve (or reject)
their own PEPs.

* Website: `packaging.python.org <https://packaging.python.org/>`_
* Mailing list: `distutils-sig
  <https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/>`_
* Bug tracker component: ``Distutils``
* Example of members: Paul Moore, Nick Coghlan, Donald Stuff
* Stdlib module: ``distutils``
* Current PEP delegate: Paul Moore

IDLE Team
---------

IDLE is a special case in the Python standard library: it's a whole
application, not just a module. For this reason, it has been decided
that the code will be the same in all Python stable branches (whereas
the stdlib diverges in newer stable branches).

* Bug tracker component: ``IDLE``
* Example of members: Terry Reedy, Cheryl Sabella, Serhiy Storchaka
* Stdlib module: ``idlelib``

Mentorship Team
---------------

Becoming a core developer is long and slow process. Mentorship is an
efficient way to train contributors as future core developers and build
a trust relationship.

* Websites:

  * https://www.python.org/dev/core-mentorship/
  * https://devguide.python.org/

* Repository: https://github.com/python/devguide
* Mailing list: `core-mentorship
  <https://www.python.org/dev/core-mentorship/>`_ (private archives)
* Example of members: Guido van Rossum, Carol Willing, Victor Stinner

Note: The group is not responsible to promote core developers.

Documentation Team
------------------

* Mailing list: `doc-sig
  <https://mail.python.org/mailman/listinfo/doc-sig>`_
* Bug tracker component: ``Documentation``
* GitHub tag: ``type-doc``
* Example of members: Julien Palard, INADA Naoki, Raymond Hettinger.

The team also manages documentation translations.

See also the Mentorship team which maintains the "Devguide".

Security Team
-------------

* Website: https://www.python.org/news/security/
* Mailing lists:

  * ``security at python.org`` (to report vulnerabilities)
  * `security-sig
    <https://mail.python.org/mm3/mailman3/lists/security-sig.python.org/>`_
    (public list)

* Stdlib modules: ``hashlib``, ``secrets`` and ``ssl``
* Example of members: Christian Heimes, Benjamin Peterson

The ``security at python.org`` mailing list is invite-only: only members of
the "Python Security Response Team" (PSRT) can read emails and reply;
whereas security-sig is public.

Note: This team rarely proposed PEPs.

Performance Team
----------------

* Website: https://speed.python.org/
* Mailing list: `speed
  <https://mail.python.org/mm3/mailman3/lists/speed.python.org/>`_
* Repositories:

  * https://github.com/python/performance
  * https://github.com/tobami/codespeed

* Bug tracker type: ``Performance``
* GitHub label: ``type-performance``
* Stdlib module: ``cProfile``, ``profile``, ``pstats`` and ``timeit``
* Example of members: Victor Stinner, INADA Naoki, Serhiy Storchaka

Usually PEPs involving performance impact everybody and so are discussed
on the python-dev mailing list, rather than the speed mailing list.

Asynchronous Programming Team
-----------------------------

* Website: https://docs.python.org/dev/library/asyncio.html
* Mailing list: `async-sig
  <https://mail.python.org/mailman/listinfo/async-sig>`_
* Bug tracker component: ``asyncio``
* GitHub label: ``expert-asyncio``
* Stdlib modules: ``asyncio`` and ``contextvars``
* Example of members: Andrew Sveltov, Yury Selivanov

PEP only modifying ``asyncio`` and ``contextvars`` can be discussed on
the async-sig mailing list, whereas changes impacting the Python
language must be discussed on python-dev.

Type Hints Team
---------------

* Website: http://mypy-lang.org/
* Repository: https://github.com/python/typing
* GitHub label for mypy project: `topic-pep-484
  <https://github.com/python/mypy/labels/topic-pep-484>`_
* Stdlib modules: ``typing``
* Example of members: Guido van Rossum, Ivan Levkivskyi,
  Jukka Lehtosalo, ?ukasz Langa, Mark Shannon.

Note: There is a backport for Python 3.6 and older, see
`typing on PyPI <https://pypi.org/project/typing/>`_.


Version History
===============

History of this PEP:

* Version 7: Adjust the Steering Committee

  * The Steering Committee is now made of 5 people instead of 3.
  * There are no term limits (instead of a limit of 2 mandates:
    6 years in total).
  * A committee member can now be a PEP delegate.

* Version 6: Adjust votes

  * Specify the Condorcet method: use Schulze/Beatpath/CSSD variant to
    elect Python Steering Committee members. Specify how to deal with
    tie and the constraint on the employers.
  * Vote on promoting a contributor and on PEPs now requires ``>= 2/3``
    rather than ``50%+1``.
  * Vote on changing this PEP now requires ``>= 4/5`` rather than
    ``50%+1``.
  * Explain how to deal with a company acquisition.

* Version 5: Election of Python Steering Committee Members uses secret
  ballots
* Version 4:

  * Adjust votes: open for 1 week instead of 1 month, and announced
    in advance.
  * Rename the "Python Core Board" to the "Python Steering Committee";
  * Clarify that this committee doesn't approve PEPs and that committee
    members cannot cumulate more than 2 mandates;
  * Add the "Type Hints" team to the annex.

* Version 3: Add "Special Case: Ban a core developer" and "How to update
  this PEP" sections.
* Version 2: Rename the "Python board" to the "Python Core Board",
  to avoid confusion with the PSF Board.
* Version 1: First version posted to python-committers and
  discuss.python.org.


Copyright
=========

This document has been placed in the public domain.

From vstinner at redhat.com  Thu Nov 15 07:08:38 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 15 Nov 2018 13:08:38 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
Message-ID: <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>

Le sam. 3 nov. 2018 ? 03:37, Victor Stinner <vstinner at redhat.com> a ?crit :
> According to the PEP 8001: "The vote will happen in a 2-week-long
> window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's
> now in less than two weeks.

It seems like the vote is going to start tomorrow, but see discussions at:

- https://discuss.python.org/t/does-the-nov-16-nov-30-voting-timeframe-still-work/434
- https://discuss.python.org/t/pep-801x-authors-are-you-on-track-for-the-vote-between-nov-16-nov-30/432

For the 3 core developers (on 95) who didn't fill their email address
in the voters repository, please do so! (I sent you an email :-))

=> https://github.com/python/voters/issues/1

Note: This repository is private and will remain private, only
accessible to core developers (to not leak your email addresses).


> I see that the PEP 8001 is still being updated (voting method). Should
> we still expect new changes before the vote starts? Can we set a
> deadline, like November 15 (Anywhere-on-Earth)?
> (...)
> What is the deadline to submit new governance PEP and to update
> governance PEPs? November 15 (Anywhere-on-Earth)?

It seems like today is last day to update the 80xx PEPs (8 PEPs: 8001
and 8010..8016). Hurry up if you want to push a last minute change :-)
(Obvious, it's ok if your PEP doesn't need changes anymore ;-))

--

Again, I share the link to my comparison of the 7 governance PEPs:

https://discuss.python.org/t/comparison-of-the-7-governance-peps/392

Please update it (any core dev can modify the first message, it's a
wiki!) if my comparison is inaccurate/out of date. Or add a comment if
you are not sure.

Obviously, only PEPs should be used to take your decision (vote). My
comparison only exists to have a quick overview, but I expect that you
all will ready all PEPs, right? :-D

Victor

From mal at egenix.com  Thu Nov 15 07:55:16 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 15 Nov 2018 13:55:16 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
Message-ID: <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>

I find it rather unusual that we are pushed to vote on PEPs
which will just have been finished in writing tonight.

Shouldn't people who were not involved in the individual creation
processes at least get two weeks to review the final work
to make up their mind before entering a voting period ?

It seems like we're completely skipping the review phase of the
regular PEP process and going straight from PEP writing to
a vote:

https://www.python.org/dev/peps/pep-0001/#id38

which is odd given the importance of this decision and also
odd compared to normal democratic procedures where laws are
first crafted, then put through parliament for discussion and
then decided upon after everyone has had a reasonable chance
for review.

For the people who have been heavily involved in the PEP creations
this may seem unnecessary, but this is just small subset of the
core developers.


BTW: Thank you for writing up the comparison. I hope you have
updated to the resp. final versions of the PEPs as well :-)


On 15.11.2018 13:08, Victor Stinner wrote:
> Le sam. 3 nov. 2018 ? 03:37, Victor Stinner <vstinner at redhat.com> a ?crit :
>> According to the PEP 8001: "The vote will happen in a 2-week-long
>> window from November 16 2018 to November 30 (Anywhere-on-Earth)." It's
>> now in less than two weeks.
> 
> It seems like the vote is going to start tomorrow, but see discussions at:
> 
> - https://discuss.python.org/t/does-the-nov-16-nov-30-voting-timeframe-still-work/434
> - https://discuss.python.org/t/pep-801x-authors-are-you-on-track-for-the-vote-between-nov-16-nov-30/432
> 
> For the 3 core developers (on 95) who didn't fill their email address
> in the voters repository, please do so! (I sent you an email :-))
> 
> => https://github.com/python/voters/issues/1
> 
> Note: This repository is private and will remain private, only
> accessible to core developers (to not leak your email addresses).
> 
> 
>> I see that the PEP 8001 is still being updated (voting method). Should
>> we still expect new changes before the vote starts? Can we set a
>> deadline, like November 15 (Anywhere-on-Earth)?
>> (...)
>> What is the deadline to submit new governance PEP and to update
>> governance PEPs? November 15 (Anywhere-on-Earth)?
> 
> It seems like today is last day to update the 80xx PEPs (8 PEPs: 8001
> and 8010..8016). Hurry up if you want to push a last minute change :-)
> (Obvious, it's ok if your PEP doesn't need changes anymore ;-))
> 
> --
> 
> Again, I share the link to my comparison of the 7 governance PEPs:
> 
> https://discuss.python.org/t/comparison-of-the-7-governance-peps/392
> 
> Please update it (any core dev can modify the first message, it's a
> wiki!) if my comparison is inaccurate/out of date. Or add a comment if
> you are not sure.
> 
> Obviously, only PEPs should be used to take your decision (vote). My
> comparison only exists to have a quick overview, but I expect that you
> all will ready all PEPs, right? :-D
> 
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 15 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/


From p.f.moore at gmail.com  Thu Nov 15 08:09:19 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 15 Nov 2018 13:09:19 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
Message-ID: <CACac1F-2LxQgwZK3Q7mUf16Msax993PDXKWL8Xesb+rnghGRgQ@mail.gmail.com>

On Thu, 15 Nov 2018 at 12:55, M.-A. Lemburg <mal at egenix.com> wrote:
>
> I find it rather unusual that we are pushed to vote on PEPs
> which will just have been finished in writing tonight.
>
> Shouldn't people who were not involved in the individual creation
> processes at least get two weeks to review the final work
> to make up their mind before entering a voting period ?

That's probably the thing that bothers me most, as well. That and the
fact that once I've cast my vote, I can't change it - so I really have
to defer voting until the last minute, in case someone comes up with a
compelling argument for one proposal that I hadn't thought of.

I made a deliberate choice *not* to get involved in the discussions
while the proposals were being prepared, because I find it far too
easy to get an impression of a proposal from an early draft and then
misjudge the proposal by not updating my views once it's updated. I
don't want to do that with this decision, as it's pretty important (!)
and so I've held off reading any of the proposals until they are
announced as final. And yet, it looks like once they are announced,
there's a possibility that people will start voting and then excuse
themselves from discussion (because once you've voted, there's no
point discussing any further). I can read them, but may not have
anyone to discuss them with once I've done so... That doesn't sound
like an ideal way of reaching consensus.

Having said all that, it's not like the decision making process will
be changed at this point, so I think that we're going to have to
accept it, flaws and all, as it stands.

Paul

From vstinner at redhat.com  Thu Nov 15 09:56:29 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Thu, 15 Nov 2018 15:56:29 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
Message-ID: <CA+3bQGG+2E6tg-QhHF6SSv2zv_nExd8CBC+swQ77myNzOd7aqg@mail.gmail.com>

Le jeu. 15 nov. 2018 ? 13:55, M.-A. Lemburg <mal at egenix.com> a ?crit :
> I find it rather unusual that we are pushed to vote on PEPs
> which will just have been finished in writing tonight.

Well, denying to modify PEPs during the PEP is the only reliable
solution to prevent PEP authors to modify their PEP :-)

IMHO latest changes (that I saw) in the governance PEPs are "minor",
they don't change fundamentally the governance model.


> Shouldn't people who were not involved in the individual creation
> processes at least get two weeks to review the final work
> to make up their mind before entering a voting period ?

Two weeks is the duration of the vote. It isn't enough to review PEPs?
Most PEPs have been written one month ago, if not longer.


> For the people who have been heavily involved in the PEP creations
> this may seem unnecessary, but this is just small subset of the
> core developers.

I guess that many people will not start reading the governance PEPs
until they really have to :-) I'm not sure that postpone the vote
would help.


> BTW: Thank you for writing up the comparison. I hope you have
> updated to the resp. final versions of the PEPs as well :-)

You're welcome. Yes, I already updated everything :-) Hopefully, other
PEP authors are also keeping this comparison up to date!

Victor

From njs at pobox.com  Thu Nov 15 13:00:26 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 15 Nov 2018 10:00:26 -0800
Subject: [python-committers] Straw poll: Which governance proposals do you
 like best?
Message-ID: <CAPJVwBmmwNWpJn4JukOL=vB52gUaTdpkqY3kfgDDGw3CpjJcAA@mail.gmail.com>

There's been a lot of clarification and critique for individual
governance proposals, but not a lot of discussion of how they compare
to each other or what different core devs think is important. And I
know that for complicated issues like this, I often don't understand
the trade-offs until I talk them over with other people, so I'm pretty
nervous about voting without having that discussion!

I started a poll on the discourse to get a sense of what people are
thinking, and talk it through. Please join us!

https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From mariatta at python.org  Thu Nov 15 13:11:26 2018
From: mariatta at python.org (Mariatta Wijaya)
Date: Thu, 15 Nov 2018 10:11:26 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
Message-ID: <CAGbohnaQ34PUqv_UrPFBCAZWapKV+0Cc5dMuLxdynNZmt-oLOA@mail.gmail.com>

>
> Shouldn't people who were not involved in the individual creation
> processes at least get two weeks to review the final work
> to make up their mind before entering a voting period ?
> It seems like we're completely skipping the review phase of the
> regular PEP process and going straight from PEP writing to
> a vote:



The period of Oct 8 (date when PEPs were due) up until Nov 15 (before
voting start) was meant as the "review" period, and this was stated in my
original email about timeline:
https://mail.python.org/pipermail/python-committers/2018-August/005960.html

I did propose that there was a period where no more changes to PEP should
be made.

Copy pasting text from that email

*Oct 1 - Nov 15: Review period.*
> All core developers will review the PEPs, and ask any questions to the PEP
> author. This timeline allows for enough time for all core devs to carefully
> review each PEPs, and for authors to respond.
>


> *Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed
> PEPs.
> I figured people will have questions and will need to clarify the PEPs
> during this period. But if we want the PEP to be final by Oct 1, that's
> fine by me. maybe allow typo fixes still.
>


> *Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs.
> No more tweaks to these PEPs. PRs to these PEPs should be rejected.
> This is the final chance to carefully review all governance PEPs, and
> formulate your decisions.
>


> *Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go
> for 2 weeks*
> Send reminders for folks to vote.


But I guess some people think that whole fixed timeline thing was bad idea,
so I didn't go and enforce all of this (also I took a break from life and
reduced responsibilities).

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181115/096ad116/attachment.html>

From barry at python.org  Thu Nov 15 13:39:04 2018
From: barry at python.org (Barry Warsaw)
Date: Thu, 15 Nov 2018 10:39:04 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAGbohnaQ34PUqv_UrPFBCAZWapKV+0Cc5dMuLxdynNZmt-oLOA@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
 <CAGbohnaQ34PUqv_UrPFBCAZWapKV+0Cc5dMuLxdynNZmt-oLOA@mail.gmail.com>
Message-ID: <1A88501D-2203-4290-8225-3A59EDA8F0FF@python.org>

Based on my suggestion on Discourse, I propose that the period between tomorrow and November 30th be an official PEP review period, with voting postponed to December 1 - 16 AOE 2018.

https://github.com/python/peps/pull/841

I am personally going to start reviewing these PEPs after the flood of trypophan is unleashed into my bloodstream following the USA Thanksgiving meal.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181115/7bc31ca5/attachment.sig>

From brett at python.org  Thu Nov 15 13:55:22 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 15 Nov 2018 10:55:22 -0800
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F-2LxQgwZK3Q7mUf16Msax993PDXKWL8Xesb+rnghGRgQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
 <CACac1F-2LxQgwZK3Q7mUf16Msax993PDXKWL8Xesb+rnghGRgQ@mail.gmail.com>
Message-ID: <CAP1=2W5eDJWeAy5kaZiYC8BwhMJ0Ae4ySG3GYrcA6yEH8m9uSg@mail.gmail.com>

On Thu, 15 Nov 2018 at 05:09, Paul Moore <p.f.moore at gmail.com> wrote:

> On Thu, 15 Nov 2018 at 12:55, M.-A. Lemburg <mal at egenix.com> wrote:
> >
> > I find it rather unusual that we are pushed to vote on PEPs
> > which will just have been finished in writing tonight.
> >
> > Shouldn't people who were not involved in the individual creation
> > processes at least get two weeks to review the final work
> > to make up their mind before entering a voting period ?
>
> That's probably the thing that bothers me most, as well. That and the
> fact that once I've cast my vote, I can't change it - so I really have
> to defer voting until the last minute, in case someone comes up with a
> compelling argument for one proposal that I hadn't thought of.
>

OK, so it seems you're unhappy that you only have a day to vote since you
can't change your vote ...


>
> I made a deliberate choice *not* to get involved in the discussions
> while the proposals were being prepared, because I find it far too
> easy to get an impression of a proposal from an early draft and then
> misjudge the proposal by not updating my views once it's updated. I
> don't want to do that with this decision, as it's pretty important (!)
> and so I've held off reading any of the proposals until they are
> announced as final. And yet, it looks like once they are announced,
> there's a possibility that people will start voting and then excuse
> themselves from discussion (because once you've voted, there's no
> point discussing any further). I can read them, but may not have
> anyone to discuss them with once I've done so... That doesn't sound
> like an ideal way of reaching consensus.
>

... but then you don't like that people can vote over two weeks because you
don't want discussions to occur while people can vote to force them to
participate in discussions? I might be missing something, but these two
issues seem contradictory, especially since we can't exactly force people
to not talk about this while voting is open. :)

[I'm going to reply to MAL here as well which is a bit awkward, but it
would have been smoother on Discourse ;) ]

>
> It seems like we're completely skipping the review phase of the
> regular PEP process and going straight from PEP writing to
> a vote:
>
> https://www.python.org/dev/peps/pep-0001/#id38
>
> which is odd given the importance of this decision and also
> odd compared to normal democratic procedures where laws are
> first crafted, then put through parliament for discussion and
> then decided upon after everyone has had a reasonable chance
> for review.
>

I don't know if it's really fair to say the review phase is being skipped.
It's not like anyone *must* vote tomorrow and so there really isn't any
time to think things over. You still have the rest of the month to review
the PEPs and place your vote. It's no different than someone following a
PEP closely, forming their opinion along the way, and then when the final
version lands replying with an opinion immediately even if the PEP delegate
isn't making a final decision for another two weeks.


> Having said all that, it's not like the decision making process will
> be changed at this point, so I think that we're going to have to
> accept it, flaws and all, as it stands.
>

It's totally flawed because we all can't agree on anything. :) For example,
remember that the voting was going to allow people to change their vote
initially in the first version of PEP 8001, but more people wanted the vote
to be private than have the ability to change their vote, so the compromise
was swapped for preferring privacy.

And as for the two week voting time, that was discussed and generally
agreed to way back when the initial timelines were discussed in August and
I believe again in September (both here and at the dev sprints). And people
specifically wanted more than a week to be able to vote, so it was
deliberate to have the voting open for as long as it is (actually if I
remember correctly a proposal for voting time was to be from when PEPs
finalized until the end of November, which would have put it at about six
weeks).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181115/ca0453f1/attachment-0001.html>

From mal at egenix.com  Thu Nov 15 16:15:16 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 15 Nov 2018 22:15:16 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAP1=2W5eDJWeAy5kaZiYC8BwhMJ0Ae4ySG3GYrcA6yEH8m9uSg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
 <CACac1F-2LxQgwZK3Q7mUf16Msax993PDXKWL8Xesb+rnghGRgQ@mail.gmail.com>
 <CAP1=2W5eDJWeAy5kaZiYC8BwhMJ0Ae4ySG3GYrcA6yEH8m9uSg@mail.gmail.com>
Message-ID: <829b20e5-71d3-b83a-81e3-ed2b243859b6@egenix.com>

On 15.11.2018 19:55, Brett Cannon wrote:
> 
>     It seems like we're completely skipping the review phase of the
>     regular PEP process and going straight from PEP writing to
>     a vote:
> 
>     https://www.python.org/dev/peps/pep-0001/#id38
> 
>     which is odd given the importance of this decision and also
>     odd compared to normal democratic procedures where laws are
>     first crafted, then put through parliament for discussion and
>     then decided upon after everyone has had a reasonable chance
>     for review. 
> 
> ?
> I don't know if it's really fair to say the review phase is being
> skipped. It's not like anyone *must* vote tomorrow and so there really
> isn't any time to think things over. You still have the rest of the
> month to review the PEPs and place your vote. It's no different than
> someone following a PEP closely, forming their opinion along the way,
> and then when the final version lands replying with an opinion
> immediately even if the PEP delegate isn't making a final decision for
> another two weeks.

Perhaps I wasn't clear. With "review" I meant debating the PEPs
among everyone, not just the few people interested in working
on them in the crafting stages.

You normally start debating a proposal when the proposal itself
is fleshed out to the point where the people behind the proposal
feel comfortable with presenting it.

The two weeks voting period is not two weeks because people need
time for debate; it's two weeks to enable people to participate
in the vote and deliberately longer to make sure they
have a reasonable chance to vote - even when they are on vacation,
a business trip or have other appointments during those two weeks
which keep them from going to a vote.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 15 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/


From mal at egenix.com  Thu Nov 15 17:38:14 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 15 Nov 2018 23:38:14 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <1A88501D-2203-4290-8225-3A59EDA8F0FF@python.org>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
 <CAGbohnaQ34PUqv_UrPFBCAZWapKV+0Cc5dMuLxdynNZmt-oLOA@mail.gmail.com>
 <1A88501D-2203-4290-8225-3A59EDA8F0FF@python.org>
Message-ID: <1393644c-35ff-bf7a-deb3-0be395d728e0@egenix.com>

On 15.11.2018 19:39, Barry Warsaw wrote:
> Based on my suggestion on Discourse, I propose that the period between tomorrow and November 30th be an official PEP review period, with voting postponed to December 1 - 16 AOE 2018.
> 
> https://github.com/python/peps/pull/841
> 
> I am personally going to start reviewing these PEPs after the flood of trypophan is unleashed into my bloodstream following the USA Thanksgiving meal.

+1

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 15 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/


From p.f.moore at gmail.com  Thu Nov 15 17:50:40 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 15 Nov 2018 22:50:40 +0000
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CAP1=2W5eDJWeAy5kaZiYC8BwhMJ0Ae4ySG3GYrcA6yEH8m9uSg@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
 <CACac1F-2LxQgwZK3Q7mUf16Msax993PDXKWL8Xesb+rnghGRgQ@mail.gmail.com>
 <CAP1=2W5eDJWeAy5kaZiYC8BwhMJ0Ae4ySG3GYrcA6yEH8m9uSg@mail.gmail.com>
Message-ID: <CACac1F-bk60scMGvJuqp6u-u7G37+_zogFFoDnF=tkvC8qnvFQ@mail.gmail.com>

On Thu, 15 Nov 2018 at 18:55, Brett Cannon <brett at python.org> wrote:
> OK, so it seems you're unhappy that you only have a day to vote since you can't change your vote ...
[...]
> ... but then you don't like that people can vote over two weeks because you don't want discussions to occur while people can vote to force them to participate in discussions? I might be missing something, but these two issues seem contradictory, especially since we can't exactly force people to not talk about this while voting is open. :)

No, I'm uncomfortable with the discussion period overlapping the
voting period, because the fact that you can't change your vote means
that once someone votes, there's no incentive to continue discussing.
But I accept that it's how it's going to be, I'm not arguing for any
change here at this late stage.

Paul

From lukasz at langa.pl  Thu Nov 15 18:47:00 2018
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Fri, 16 Nov 2018 00:47:00 +0100
Subject: [python-committers] GOVERNANCE VOTE SCHEDULE UPDATE: Dec 1 - Dec 16
 2018
Message-ID: <A5BC9213-9634-4A08-BB6E-6FC65E7523A7@langa.pl>

Thank you to everybody who voiced concern that the originally planned voting schedule of Nov 16 - Nov 30 was rushed. In the interest of ensuring everybody feels included, as well as to allow time for PEP 801x review and clarifications, Barry Warsaw and the other PEP 801x authors [1]_ decided to move the vote by two weeks. Barry opened a PR [2]_ which I just merged.

Summary of changes:
- starting tomorrow until December 1st we are entering an official PEP 801x review period. Substantive changes to those PEPs are discouraged, clarifications as the result of the discussion are encouraged.
- the actual vote will happen on CIVS between December 1st and December 16th.

All details are in PEP 8001 which has been now Accepted and will be marked Final sometime later this week after the dust settles. Please read it carefully.

We are sorry for the late change and any inconvenience this might have caused you. Our foremost concern is to ensure the vote is going to be considered fair, inclusive and legitimate. We hope adjusting the timing helps with that.

One last thing. During the discussion phase, please try to keep discussions on Discourse where they were held until this point. Moderators will be available in this period to help with readability.

- ?



.. [1]  Well, we couldn't reach Steve who is in Scotland and Jack. We are sorry we couldn't wait for your opinions but the pressure of time didn't allow us to do so.
.. [2]  https://github.com/python/peps/pull/841/

From vstinner at redhat.com  Thu Nov 15 18:47:00 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 16 Nov 2018 00:47:00 +0100
Subject: [python-committers] Timeline to vote for a governance PEP
In-Reply-To: <CACac1F-bk60scMGvJuqp6u-u7G37+_zogFFoDnF=tkvC8qnvFQ@mail.gmail.com>
References: <CA+3bQGEMvzborjcJqda9hFHdazA1S1na3n__n9=30iN4=GgD+Q@mail.gmail.com>
 <CA+3bQGGEknSvUM9+C+Tq=oKsvW-Jsvqqn-u1YmBRcf5+mQG3NA@mail.gmail.com>
 <9004c364-5363-00d1-28ab-e9093a548bdb@egenix.com>
 <CACac1F-2LxQgwZK3Q7mUf16Msax993PDXKWL8Xesb+rnghGRgQ@mail.gmail.com>
 <CAP1=2W5eDJWeAy5kaZiYC8BwhMJ0Ae4ySG3GYrcA6yEH8m9uSg@mail.gmail.com>
 <CACac1F-bk60scMGvJuqp6u-u7G37+_zogFFoDnF=tkvC8qnvFQ@mail.gmail.com>
Message-ID: <CA+3bQGESqMH+fu9eOOtS2v-PKh9DZh=v0m1dfULx+fmuo=d1RQ@mail.gmail.com>

Le jeu. 15 nov. 2018 ? 23:51, Paul Moore <p.f.moore at gmail.com> a ?crit :
> No, I'm uncomfortable with the discussion period overlapping the
> voting period, because the fact that you can't change your vote means
> that once someone votes, there's no incentive to continue discussing.
> But I accept that it's how it's going to be, I'm not arguing for any
> change here at this late stage.

That's why I reduced the vote duration from 1 month to 1 week, but
also announce the vote in advance for discussion, in my PEP 8015:
https://www.python.org/dev/peps/pep-8015/#annex-summary-on-votes

PEP vote announced 1 week in advance, change the governance PEP vote
and Steering Committee members vote announced 3 weeks in advance.

Victor

From tjreedy at udel.edu  Thu Nov 15 19:59:17 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 15 Nov 2018 19:59:17 -0500
Subject: [python-committers] GOVERNANCE VOTE SCHEDULE UPDATE: Dec 1 -
 Dec 16 2018
In-Reply-To: <A5BC9213-9634-4A08-BB6E-6FC65E7523A7@langa.pl>
References: <A5BC9213-9634-4A08-BB6E-6FC65E7523A7@langa.pl>
Message-ID: <ff7b9b9a-e95b-e6f3-551a-1a75d6f69eb7@udel.edu>

On 11/15/2018 6:47 PM, ?ukasz Langa wrote:
> Thank you to everybody who voiced concern that the originally planned voting schedule of Nov 16 - Nov 30 was rushed. In the interest of ensuring everybody feels included, as well as to allow time for PEP 801x review and clarifications, Barry Warsaw and the other PEP 801x authors [1]_ decided to move the vote by two weeks. Barry opened a PR [2]_ which I just merged.

 >All details are in PEP 8001 which has been now Accepted and will be 
marked Final sometime later this week after the dust settles. Please 
read it carefully.

Thank you for making (facilitating) a decision that lets us move forward.

Terry



From antoine at python.org  Sun Nov 18 06:17:44 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 18 Nov 2018 12:17:44 +0100
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
Message-ID: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>


Hello folks,

A couple days ago Nathaniel pushed significant changes to his governance
PEP (PEP 8016).  This means some governance PEPs are apparently still
*not* finalized.  This raises a problem: when can we consider that we
are reading the final version of a proposal (barring wording fixes or
improvements), not some work in progress draft?

Not everyone keeps an eye daily on PEP changes and discussions.  It
would be nice to be able to make one's mind at an idle pace.  But that
requires that PEP authors don't make last-minute changes in an attempt
to gather more support.

In my vote, I may have to devaluate those proposals that keep changing
in the last days before the vote, because it doesn't sound like the
author can be trusted to propose a stable model.

Regards

Antoine.

From mariatta at python.org  Sun Nov 18 11:20:48 2018
From: mariatta at python.org (Mariatta Wijaya)
Date: Sun, 18 Nov 2018 08:20:48 -0800
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <CAGbohnZ6919SQtK6pmhEe9OOSwp=uCQ5FtPx9JFAjXvUiWo36Q@mail.gmail.com>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAGbohnZ6919SQtK6pmhEe9OOSwp=uCQ5FtPx9JFAjXvUiWo36Q@mail.gmail.com>
Message-ID: <CAGbohnaL5qJpnF0LJa1nCtX5YzQM16s289dDvE+in69NgPPaqA@mail.gmail.com>

 As a reminder, PEP 8001 states:

"November 16th, 2018 to November 30th, 2018 is the official governance PEP
review period. We discourage the PEP authors from making major substantive
changes during this period, although it is expected that minor tweaks may
occur, as the result of this discussion period."

Looking at the commit history, the last change to PEP 8016 was on Nov 15 my
timezone, and I'm assuming it was Nov 15 in PEP 8016 authors' timezone too,
so I think it was still allowed. There shouldn't be any more major changes
going forward though.

I would suggest that PEP 8001 can also say that once voting start (Dec 1),
PEPs 801x should be locked and not editable anymore.


On Sun, Nov 18, 2018, 3:17 AM Antoine Pitrou <antoine at python.org wrote:

>
> Hello folks,
>
> A couple days ago Nathaniel pushed significant changes to his governance
> PEP (PEP 8016).  This means some governance PEPs are apparently still
> *not* finalized.  This raises a problem: when can we consider that we
> are reading the final version of a proposal (barring wording fixes or
> improvements), not some work in progress draft?
>
> Not everyone keeps an eye daily on PEP changes and discussions.  It
> would be nice to be able to make one's mind at an idle pace.  But that
> requires that PEP authors don't make last-minute changes in an attempt
> to gather more support.
>
> In my vote, I may have to devaluate those proposals that keep changing
> in the last days before the vote, because it doesn't sound like the
> author can be trusted to propose a stable model.
>
> Regards
>
> Antoine.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181118/3aaa21e0/attachment.html>

From njs at pobox.com  Mon Nov 19 06:24:15 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 19 Nov 2018 03:24:15 -0800
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
Message-ID: <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>

On Sun, Nov 18, 2018 at 3:17 AM Antoine Pitrou <antoine at python.org> wrote:
> A couple days ago Nathaniel pushed significant changes to his governance
> PEP (PEP 8016).  This means some governance PEPs are apparently still
> *not* finalized.  This raises a problem: when can we consider that we
> are reading the final version of a proposal (barring wording fixes or
> improvements), not some work in progress draft?

There were several PEPs that received significant changes in the week
before Nov 16 when the "review period" started (at least 8001, 8014,
8015, 8016), but AFAICT none of the PEPs have had any changes since
then.

> Not everyone keeps an eye daily on PEP changes and discussions.  It
> would be nice to be able to make one's mind at an idle pace.  But that
> requires that PEP authors don't make last-minute changes in an attempt
> to gather more support.

Thanks for raising this. It's an important issue and one where I've
been struggling too.

I'll put my conclusion first. My suggestion:

- We do allow changes to the PEPs until the actual voting starts, but
not afterwards
- We leave it up to the PEP authors' judgement what changes they want to make
- The PEP authors will work together to maintain a single shared
changelog summarizing every change that's made to the PEPs after Nov.
16, no matter how trivial, and including links to the relevant commits
so you can easily see the actual text
- We'll include a link to this changelog prominently in the voting
instructions etc.

This is easy to implement, avoids messy subjective judgements about
which changes are "too big", allows the PEPs to be tweaked and
clarified through the review period, and would mean that so long as
you read the PEPs at least once during the review period and then
check the changelog before voting, you're guaranteed that you won't
miss anything.

Here's my reasoning:

You're absolutely right, it's crucial that everyone know what they're
voting on; that's basic to having a valid vote. (And I almost got
bitten by this too ? PEP 8014 changed a lot on Nov. 9, and it was only
by random chance that I noticed it a week later!) But... right now
people are still reading the proposals for the first time and
requesting changes. And if someone's suggestion would be an actual
improvement, and we turn it down because it's too late ? that's
disenfranchising in a different way, and also, like, deliberately
choosing to make our governance worse than necessary, which is
sub-optimal. Obviously once the vote starts we *can't* change the
PEPs, because that would retroactively change the meaning of votes
that were already cast. But until then, freezing and not freezing both
make me really uncomfortable. It would be good if we could find a
third way.

To make this concrete, here are some examples of things people have
brought up re: PEP 8016 since Nov. 16, where I'm not sure what we
should do:

- Xiang Zhang noticed [1] that PEP 8016 uses a piece of nonstandard
terminology: "strict majority" where it means "simple majority". Oops.
I feel like fixing this is probably a good idea, and as
uncontroversial as any change could be? But OTOH if we don't have a
changelog then even trivial changes like this might make you and
others uncomfortable (they make me uncomfortable!), because without
seeing the change we have no way to judge for ourselves how trivial it
actually is.

- Xiang Zhang and Victor Stinner are arguing [1, 2] for changing PEP
8016 to effectively require a slightly higher threshold for the
steering council to block a new core developer for misconduct
(4-out-of-5 instead of 3-out-of-5, see [3] for the details). This is a
small tweak in a corner of the proposal we hope will never come up in
practice, and it definitely wouldn't change the proposal's overall
character, but it is a change. It would produce some procedural
simplifications, and apparently make at least two core devs more
comfortable. Is that something we should do?

- Steve Dower has suggested [4] tweaking when in the release cycle the
steering council election is held. This discussion isn't resolved yet,
maybe we'll conclude it's a bad idea anyway, but OTOH maybe it would
be an improvement? And again it's a super-tiny change.

It's possible PEP 8016 is particularly prone to this because a design
goal was to be small and explicit enough to encourage
<del>nitpicking</del>detailed review, but I'm not just suggesting this
because "my" PEP has special needs. Other potential changes I'm aware
of:

- Steve Dower is considering withdrawing PEP 8014 entirely [4], which
if it happens would be a major substantive change to PEP 8014 that
voters would want to know about!

- In the course of a discussion that Paul Moore started about
processes for promoting core devs, I realized [5] that there's (what
feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about
how much power the Technical Leader or Trio would actually have ?
specifically I'd been assuming one thing, but realized that the texts
actually don't say either way. I hope Barry and Mariatta will clarify
what they intended before the vote starts. No matter which way they
clarify things, it may feel like a substantive change to some people,
depending on how they read it originally.

In this last case, I *guess* as the co-author of a competing PEP I
could be like "haha, PEP 8001 says it's too late for substantive
changes so your PEP loses", and then they could be like "no these
changes aren't substantive because we're just clarifying what we meant
all along", and then I could be like "well as a voter it feels
substantive to *me*"... but this sounds like a miserable way to live.
I'd really rather Barry and Mariatta have the chance to clarify their
PEPs before the vote, so that we all know what our options are and
that those options are the best they can be, and that we skip any
pointless  arguments about it.

The changelog approach is simple, unambiguous, easily enforceable,
allows the PEPs to be clarified, avoids intrinsically subjective
arguments about what counts as "substantive", and makes it easy for
Antoine to know exactly what he's voting on instead of having to trust
that everyone else's definition of "minor tweak" matches his own.

-n

[1] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/36
[2] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/37
[3] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/35
[4] https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/51
[5] https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436/25

-- 
Nathaniel J. Smith -- https://vorpus.org

From vstinner at redhat.com  Mon Nov 19 06:37:09 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 19 Nov 2018 12:37:09 +0100
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
Message-ID: <CA+3bQGEUUwshZ0cTr88XWVwEkCthT5LsDWkS-MNO0FOSDL+x8A@mail.gmail.com>

I maintain a Version History in my PEP 8015:
https://www.python.org/dev/peps/pep-8015/#version-history

Victor
Le lun. 19 nov. 2018 ? 12:24, Nathaniel Smith <njs at pobox.com> a ?crit :
>
> On Sun, Nov 18, 2018 at 3:17 AM Antoine Pitrou <antoine at python.org> wrote:
> > A couple days ago Nathaniel pushed significant changes to his governance
> > PEP (PEP 8016).  This means some governance PEPs are apparently still
> > *not* finalized.  This raises a problem: when can we consider that we
> > are reading the final version of a proposal (barring wording fixes or
> > improvements), not some work in progress draft?
>
> There were several PEPs that received significant changes in the week
> before Nov 16 when the "review period" started (at least 8001, 8014,
> 8015, 8016), but AFAICT none of the PEPs have had any changes since
> then.
>
> > Not everyone keeps an eye daily on PEP changes and discussions.  It
> > would be nice to be able to make one's mind at an idle pace.  But that
> > requires that PEP authors don't make last-minute changes in an attempt
> > to gather more support.
>
> Thanks for raising this. It's an important issue and one where I've
> been struggling too.
>
> I'll put my conclusion first. My suggestion:
>
> - We do allow changes to the PEPs until the actual voting starts, but
> not afterwards
> - We leave it up to the PEP authors' judgement what changes they want to make
> - The PEP authors will work together to maintain a single shared
> changelog summarizing every change that's made to the PEPs after Nov.
> 16, no matter how trivial, and including links to the relevant commits
> so you can easily see the actual text
> - We'll include a link to this changelog prominently in the voting
> instructions etc.
>
> This is easy to implement, avoids messy subjective judgements about
> which changes are "too big", allows the PEPs to be tweaked and
> clarified through the review period, and would mean that so long as
> you read the PEPs at least once during the review period and then
> check the changelog before voting, you're guaranteed that you won't
> miss anything.
>
> Here's my reasoning:
>
> You're absolutely right, it's crucial that everyone know what they're
> voting on; that's basic to having a valid vote. (And I almost got
> bitten by this too ? PEP 8014 changed a lot on Nov. 9, and it was only
> by random chance that I noticed it a week later!) But... right now
> people are still reading the proposals for the first time and
> requesting changes. And if someone's suggestion would be an actual
> improvement, and we turn it down because it's too late ? that's
> disenfranchising in a different way, and also, like, deliberately
> choosing to make our governance worse than necessary, which is
> sub-optimal. Obviously once the vote starts we *can't* change the
> PEPs, because that would retroactively change the meaning of votes
> that were already cast. But until then, freezing and not freezing both
> make me really uncomfortable. It would be good if we could find a
> third way.
>
> To make this concrete, here are some examples of things people have
> brought up re: PEP 8016 since Nov. 16, where I'm not sure what we
> should do:
>
> - Xiang Zhang noticed [1] that PEP 8016 uses a piece of nonstandard
> terminology: "strict majority" where it means "simple majority". Oops.
> I feel like fixing this is probably a good idea, and as
> uncontroversial as any change could be? But OTOH if we don't have a
> changelog then even trivial changes like this might make you and
> others uncomfortable (they make me uncomfortable!), because without
> seeing the change we have no way to judge for ourselves how trivial it
> actually is.
>
> - Xiang Zhang and Victor Stinner are arguing [1, 2] for changing PEP
> 8016 to effectively require a slightly higher threshold for the
> steering council to block a new core developer for misconduct
> (4-out-of-5 instead of 3-out-of-5, see [3] for the details). This is a
> small tweak in a corner of the proposal we hope will never come up in
> practice, and it definitely wouldn't change the proposal's overall
> character, but it is a change. It would produce some procedural
> simplifications, and apparently make at least two core devs more
> comfortable. Is that something we should do?
>
> - Steve Dower has suggested [4] tweaking when in the release cycle the
> steering council election is held. This discussion isn't resolved yet,
> maybe we'll conclude it's a bad idea anyway, but OTOH maybe it would
> be an improvement? And again it's a super-tiny change.
>
> It's possible PEP 8016 is particularly prone to this because a design
> goal was to be small and explicit enough to encourage
> <del>nitpicking</del>detailed review, but I'm not just suggesting this
> because "my" PEP has special needs. Other potential changes I'm aware
> of:
>
> - Steve Dower is considering withdrawing PEP 8014 entirely [4], which
> if it happens would be a major substantive change to PEP 8014 that
> voters would want to know about!
>
> - In the course of a discussion that Paul Moore started about
> processes for promoting core devs, I realized [5] that there's (what
> feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about
> how much power the Technical Leader or Trio would actually have ?
> specifically I'd been assuming one thing, but realized that the texts
> actually don't say either way. I hope Barry and Mariatta will clarify
> what they intended before the vote starts. No matter which way they
> clarify things, it may feel like a substantive change to some people,
> depending on how they read it originally.
>
> In this last case, I *guess* as the co-author of a competing PEP I
> could be like "haha, PEP 8001 says it's too late for substantive
> changes so your PEP loses", and then they could be like "no these
> changes aren't substantive because we're just clarifying what we meant
> all along", and then I could be like "well as a voter it feels
> substantive to *me*"... but this sounds like a miserable way to live.
> I'd really rather Barry and Mariatta have the chance to clarify their
> PEPs before the vote, so that we all know what our options are and
> that those options are the best they can be, and that we skip any
> pointless  arguments about it.
>
> The changelog approach is simple, unambiguous, easily enforceable,
> allows the PEPs to be clarified, avoids intrinsically subjective
> arguments about what counts as "substantive", and makes it easy for
> Antoine to know exactly what he's voting on instead of having to trust
> that everyone else's definition of "minor tweak" matches his own.
>
> -n
>
> [1] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/36
> [2] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/37
> [3] https://discuss.python.org/t/pep-8016-the-steering-council-model/394/35
> [4] https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/51
> [5] https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436/25
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From p.f.moore at gmail.com  Mon Nov 19 08:30:38 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 19 Nov 2018 13:30:38 +0000
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
Message-ID: <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>

On Mon, 19 Nov 2018 at 11:24, Nathaniel Smith <njs at pobox.com> wrote:
> Thanks for raising this. It's an important issue and one where I've
> been struggling too.
>
> I'll put my conclusion first. My suggestion:
>
> - We do allow changes to the PEPs until the actual voting starts, but
> not afterwards
> - We leave it up to the PEP authors' judgement what changes they want to make
> - The PEP authors will work together to maintain a single shared
> changelog summarizing every change that's made to the PEPs after Nov.
> 16, no matter how trivial, and including links to the relevant commits
> so you can easily see the actual text
> - We'll include a link to this changelog prominently in the voting
> instructions etc.
>
> This is easy to implement, avoids messy subjective judgements about
> which changes are "too big", allows the PEPs to be tweaked and
> clarified through the review period, and would mean that so long as
> you read the PEPs at least once during the review period and then
> check the changelog before voting, you're guaranteed that you won't
> miss anything.

I agree, this is a really difficult question to get right.

My feeling, however, is that the PEPs that are having the most trouble
with this are the ones that are trying to pin down too much detail.
Sure (to pick a random example), it's ultimately going to be important
that a council have a clear idea of how they reach agreement on
banning a core developer, should that situation come up. But is it
really going to be so critical to establish that detail *right now*
that someone would change their vote **to a completely different
governance model** if the number of votes was set at 3 or 4? And is
the proposal explicitly denying us the chance to change that number
based on experience going forward?[1]

I realise this is precisely the point you made about subjective
judgements, but I think it needs to be taken in context. I have a
maximum of 7 proposals to choose from (6 if Steve withdraws his). I'm
interested in the overall "shape" of the proposal (leader or group who
decides vs community voting for example) and the "tone" (is it
concerned with pinning down lots of details, does it assume we'll
trust each other to work in good faith, is it bureaucratic, is it
well-established or novel, etc). The sorts of changes you're talking
about in the examples you give mostly leave me with a feeling of "this
proposal is prone to getting bogged down in details, it's
overspecified", and that's what will affect my vote rather than the
actual detail being debated[2].

> It's possible PEP 8016 is particularly prone to this because a design
> goal was to be small and explicit enough to encourage
> <del>nitpicking</del>detailed review, but I'm not just suggesting this
> because "my" PEP has special needs.

I'd characterise this more as "PEPs that try to specify too much
detail are prone to this because they encourage 'detailed review'"...
;-)

> - Steve Dower is considering withdrawing PEP 8014 entirely [4], which
> if it happens would be a major substantive change to PEP 8014 that
> voters would want to know about!

Knowing about it - definitely. But more importantly, I'd like to know
*why*! If Steve no longer considers his proposal worth voting for,
what is his logic, and what does he consider a reasonable alternative
for people who *did* want to vote for it? Personally, I'm not that
worried as that wasn't one of my preferred proposals, but I do think
that if you have created a proposal, you have a certain level of
responsibility to the people who liked it to give them information on
what you view as the "migration path" from what they voted for to
where you are now (and "not being able to vote for it" is a pretty
extreme case of that!)

> - In the course of a discussion that Paul Moore started about
> processes for promoting core devs, I realized [5] that there's (what
> feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about
> how much power the Technical Leader or Trio would actually have ?
> specifically I'd been assuming one thing, but realized that the texts
> actually don't say either way. I hope Barry and Mariatta will clarify
> what they intended before the vote starts. No matter which way they
> clarify things, it may feel like a substantive change to some people,
> depending on how they read it originally.

And yet, I hope they don't, as a key point for me about their
proposals is that they *don't* try to specify everything up front, but
rather they allow for the leader/council to make judgements as time
goes on. If you feel that as a result their proposals are
underspecified, by all means vote for something else.

> In this last case, I *guess* as the co-author of a competing PEP I
> could be like "haha, PEP 8001 says it's too late for substantive
> changes so your PEP loses", and then they could be like "no these
> changes aren't substantive because we're just clarifying what we meant
> all along", and then I could be like "well as a voter it feels
> substantive to *me*"... but this sounds like a miserable way to live.

So is forming an opinion by viewing the proposals, and then hoping
that no-one publishes a rewrite that means you have to rethink your
position at the last minute. It doesn't really help that you have a
way of being notified about major changes, the point is that we don't
want them to *happen*. (Yes, "major" is subjective once again, I
know.)

> I'd really rather Barry and Mariatta have the chance to clarify their
> PEPs before the vote, so that we all know what our options are and
> that those options are the best they can be, and that we skip any
> pointless  arguments about it.

Assuming that we'll deal with things when they happen is also an
option, IMO. I'd prefer it if we didn't reach a point where no
proposal offered that option. And frankly, changing from a relatively
underspecified position of "give some people authority, and let them
make the decisions" approach to one more like "elect a
group/individual to implement the set of rules we state here" is
*definitely* a substantive change, so one I'd oppose allowing now that
the review period has started.

> The changelog approach is simple, unambiguous, easily enforceable,
> allows the PEPs to be clarified, avoids intrinsically subjective
> arguments about what counts as "substantive", and makes it easy for
> Antoine to know exactly what he's voting on instead of having to trust
> that everyone else's definition of "minor tweak" matches his own.

... but means that in theory, *anything* could change right up to the
start of the voting period, which makes the introduction of an
explicit review period pointless - we could just as easily have
started the voting period on the 16th in that case.

[1] It's possible that it *is* that important for some proposals. That
says to me that those proposals don't have enough built in flexibility
to react to unexpected situations (e.g., they have no mechanism for
deciding on a decision making system for an unanticipated event).
[2] And yes, that does mean that I'm currently inclined towards
particular governance models based more on how they are presented,
rather than on how they are structured. I'm not going to apologise for
that, or even accept that it's wrong. Any system can work if it's
implemented in a sufficiently flexible and sympathetic manner,
conversely any system can fail if it gets bogged down in bureaucracy
and over dependence on rule-book solutions.

Paul

PS I wrote this without going back over the PEPs, apologies if I've
misremembered or misrepresented anyone's proposal as a result of that.
PPS It's quite possible that my comments here aren't 100% consistent
with what I've previously written. I'm still forming my opinions and
they are changing over time - as well as not being super-precise in
the first place (I'm judging a lot of this on "gut instinct" that I
can't always put into words). So apologies for that as well.

From steve.dower at python.org  Mon Nov 19 11:32:11 2018
From: steve.dower at python.org (Steve Dower)
Date: Mon, 19 Nov 2018 08:32:11 -0800
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
 <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>
Message-ID: <024e84c6-2f3f-3efb-57e8-544a31a65e3f@python.org>

On 19Nov2018 0530, Paul Moore wrote:
> On Mon, 19 Nov 2018 at 11:24, Nathaniel Smith <njs at pobox.com> wrote:
>> - Steve Dower is considering withdrawing PEP 8013 entirely [4], which
>> if it happens would be a major substantive change to PEP 8013 that
>> voters would want to know about!
> 
> Knowing about it - definitely. But more importantly, I'd like to know
> *why*! If Steve no longer considers his proposal worth voting for,
> what is his logic, and what does he consider a reasonable alternative
> for people who *did* want to vote for it? Personally, I'm not that
> worried as that wasn't one of my preferred proposals, but I do think
> that if you have created a proposal, you have a certain level of
> responsibility to the people who liked it to give them information on
> what you view as the "migration path" from what they voted for to
> where you are now (and "not being able to vote for it" is a pretty
> extreme case of that!)

[I corrected the quote to read PEP 8013]

FWIW, I'm thinking about withdrawing it because PEP 8016 captures my 
highest priorities (specifically, core developers don't have a monopoly 
on decision-making skills, and don't apply unnecessary constraints on 
whoever leads in this PEP). The rest of my proposal is just enough 
detail to be functional, but I'm not really wedded to it, so if there's 
an alternative that mirrors the core values then I'll tell people to go 
vote for that instead of mine.

Right now there's one blocking concern I have with 8016 [1], but once 
that's fixed I'll happily just tell people that if they were planning to 
vote for PEP 8013, they should have been putting 8016 second anyway, and 
now they can just put it first :)

Cheers,
Steve

1. 
https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333/51?u=steve.dower

From p.f.moore at gmail.com  Mon Nov 19 11:38:36 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 19 Nov 2018 16:38:36 +0000
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <024e84c6-2f3f-3efb-57e8-544a31a65e3f@python.org>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
 <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>
 <024e84c6-2f3f-3efb-57e8-544a31a65e3f@python.org>
Message-ID: <CACac1F81ACJ1Sb3ufov8fRC1-sT5k6c2KQaEEEkjT_SpycNiZQ@mail.gmail.com>

On Mon, 19 Nov 2018 at 16:32, Steve Dower <steve.dower at python.org> wrote:
> FWIW, I'm thinking about withdrawing it because PEP 8016 captures my
> highest priorities (specifically, core developers don't have a monopoly
> on decision-making skills, and don't apply unnecessary constraints on
> whoever leads in this PEP). The rest of my proposal is just enough
> detail to be functional, but I'm not really wedded to it, so if there's
> an alternative that mirrors the core values then I'll tell people to go
> vote for that instead of mine.

Interesting. I considered the distinguishing feature of your proposal
to be that it explicitly *excludes* core devs from the council (to the
extent that you call out that feature as what distinguishes it from
8011). I wasn't keen on that, so I never really got much beyond that
aspect of your proposal to be honest - so it's weird to me that you
don't think it's particularly significant.

But thanks for the clarification.
Paul

From steve.dower at python.org  Mon Nov 19 11:54:27 2018
From: steve.dower at python.org (Steve Dower)
Date: Mon, 19 Nov 2018 08:54:27 -0800
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <CACac1F81ACJ1Sb3ufov8fRC1-sT5k6c2KQaEEEkjT_SpycNiZQ@mail.gmail.com>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
 <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>
 <024e84c6-2f3f-3efb-57e8-544a31a65e3f@python.org>
 <CACac1F81ACJ1Sb3ufov8fRC1-sT5k6c2KQaEEEkjT_SpycNiZQ@mail.gmail.com>
Message-ID: <3b75cf99-21d3-1010-37ba-e942d40a48cc@python.org>

On 19Nov2018 0838, Paul Moore wrote:
> On Mon, 19 Nov 2018 at 16:32, Steve Dower <steve.dower at python.org> wrote:
>> FWIW, I'm thinking about withdrawing it because PEP 8016 captures my
>> highest priorities (specifically, core developers don't have a monopoly
>> on decision-making skills, and don't apply unnecessary constraints on
>> whoever leads in this PEP). The rest of my proposal is just enough
>> detail to be functional, but I'm not really wedded to it, so if there's
>> an alternative that mirrors the core values then I'll tell people to go
>> vote for that instead of mine.
> 
> Interesting. I considered the distinguishing feature of your proposal
> to be that it explicitly *excludes* core devs from the council (to the
> extent that you call out that feature as what distinguishes it from
> 8011). I wasn't keen on that, so I never really got much beyond that
> aspect of your proposal to be honest - so it's weird to me that you
> don't think it's particularly significant.
> 
> But thanks for the clarification.
> Paul
> 

That was mainly just the easiest way to deal with conflicts of interest, 
but it was always a point that I'd bargain away if people were really 
upset about it :)

I'm sure we'll find sensible ways to deal with people who want to get 
elected just to pass their own PEPs.

Cheers,
Steve


From steve at pearwood.info  Mon Nov 19 17:56:38 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 20 Nov 2018 09:56:38 +1100
Subject: [python-committers] How do you find Discourse so far?
In-Reply-To: <2FEFEDB9-55BE-4190-8523-7EDB79F846D9@langa.pl>
References: <2FEFEDB9-55BE-4190-8523-7EDB79F846D9@langa.pl>
Message-ID: <20181119225638.GC11582@ando.pearwood.info>

On Tue, Nov 13, 2018 at 06:00:01PM +0100, ?ukasz Langa wrote:
> Here's a poll:
> https://discuss.python.org/t/how-do-you-find-discourse-so-far/429

In the poll, you say:

"I think we?ve had enough exposure now for you to have an informed 
opinion on the tool."

How many core devs have signed up with an account to use it, out of how 
many active and potentially active core devs? I see 35 people have 
voted. Is that a lot?

I can't vote on this, because there is no option for "I haven't tried it 
yet, I've been too busy to start following yet another discussion 
forum and learning a new tool." I suspect I'm not the only one.

(Having a life away from the computer is not all its cracked up to be... 
*wink*)

I'm sure I could log in and post something just to say I've 
tried it, but that wouldn't be giving it a fair trial.

Just a data point for your consideration.


-- 
Steve

From njs at pobox.com  Tue Nov 20 02:46:43 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 19 Nov 2018 23:46:43 -0800
Subject: [python-committers] A plea to stop last-minute changes to
 governance PEPs
In-Reply-To: <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>
References: <1bf3756a-b3ca-dc35-a8c4-a0b3e666d529@python.org>
 <CAPJVwBkE-NWRPJqbFLV04za5KY4XNoud93XjSn+3bEvq_pAUkw@mail.gmail.com>
 <CACac1F_MinSmhH76kCYaonkKZJfCsSqQVWRpFk+m_YWMv8CC0A@mail.gmail.com>
Message-ID: <CAPJVwBnx6m3wEHAnHJwMrfnZ+taVQFMDOrUDO88KP89yjo7wog@mail.gmail.com>

On Mon, Nov 19, 2018 at 5:30 AM Paul Moore <p.f.moore at gmail.com> wrote:
> My feeling, however, is that the PEPs that are having the most trouble
> with this are the ones that are trying to pin down too much detail.
> Sure (to pick a random example), it's ultimately going to be important
> that a council have a clear idea of how they reach agreement on
> banning a core developer, should that situation come up. But is it
> really going to be so critical to establish that detail *right now*
> that someone would change their vote **to a completely different
> governance model** if the number of votes was set at 3 or 4? And is
> the proposal explicitly denying us the chance to change that number
> based on experience going forward?[1]

PEP 8016 does try to specify all the details needed to get us out of
our current state of ambiguity, so that if we adopt it then we're
ready to go immediately and never have to go back to our current
ill-defined process. That forces it to specify various details, but
beyond that it tries to specify as little as possible (so lots of
details are delegated to the future governance system, rather than
being resolved right now), and for the things that it does specify, it
also specifies how we can change them:
https://www.python.org/dev/peps/pep-8016/#changing-this-document . So
we can totally change things going forward.

If the PEP left blank spaces to be filled in later, then when would we
fill them in, and how? Are you imagining we'd have a second round of
voting to fill in the details, or what are you thinking?

> I realise this is precisely the point you made about subjectivea way to change those details ? see
> judgements, but I think it needs to be taken in context. I have a
> maximum of 7 proposals to choose from (6 if Steve withdraws his). I'm
> interested in the overall "shape" of the proposal (leader or group who
> decides vs community voting for example) and the "tone" (is it
> concerned with pinning down lots of details, does it assume we'll
> trust each other to work in good faith, is it bureaucratic, is it
> well-established or novel, etc). The sorts of changes you're talking
> about in the examples you give mostly leave me with a feeling of "this
> proposal is prone to getting bogged down in details, it's
> overspecified", and that's what will affect my vote rather than the
> actual detail being debated[2].

Well, that's up to you I guess :-). None of the bureaucratic details
in PEP 8016 have anything to do with day-to-day development, and for
uncontroversial decisions, governance doesn't matter at all. The only
time a governance PEP matters is when we hit an ambiguous situation
where people are disagreeing. IMO that means the governance probably
shouldn't leave the details ambiguous and assume people will agree on
how to handle them :-).

But that's kind of neither here nor there... even if you disagree with
me about that, I hope we can still agree on one thing:

> > - In the course of a discussion that Paul Moore started about
> > processes for promoting core devs, I realized [5] that there's (what
> > feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about
> > how much power the Technical Leader or Trio would actually have ?
> > specifically I'd been assuming one thing, but realized that the texts
> > actually don't say either way. I hope Barry and Mariatta will clarify
> > what they intended before the vote starts. No matter which way they
> > clarify things, it may feel like a substantive change to some people,
> > depending on how they read it originally.
>
> And yet, I hope they don't, as a key point for me about their
> proposals is that they *don't* try to specify everything up front, but
> rather they allow for the leader/council to make judgements as time
> goes on. If you feel that as a result their proposals are
> underspecified, by all means vote for something else.

If you're right that Barry's intent for PEP 8010 is to make it a kind
of "template" for a future governance PEP, with details intentionally
left underspecified to be filled in later by some yet-to-be-determined
process, then it would still be helpful for him to specify *that*.
That would give us both the information we need to vote :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From vstinner at redhat.com  Tue Nov 20 05:53:49 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 20 Nov 2018 11:53:49 +0100
Subject: [python-committers] How do you find Discourse so far?
In-Reply-To: <20181119225638.GC11582@ando.pearwood.info>
References: <2FEFEDB9-55BE-4190-8523-7EDB79F846D9@langa.pl>
 <20181119225638.GC11582@ando.pearwood.info>
Message-ID: <CA+3bQGH9rUd5VXo7wF=xrQqKT04uj3qF1jb52jOpPP6Ypm+efQ@mail.gmail.com>

Le lun. 19 nov. 2018 ? 23:56, Steven D'Aprano <steve at pearwood.info> a ?crit :
> "I think we?ve had enough exposure now for you to have an informed
> opinion on the tool."
>
> How many core devs have signed up with an account to use it,

https://discuss.python.org/groups/committers
=> 67 core developers

Victor

From lukasz at langa.pl  Tue Nov 27 09:40:14 2018
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Tue, 27 Nov 2018 15:40:14 +0100
Subject: [python-committers] PEP 8012 FAQ
Message-ID: <16C7FB2A-8638-4D3C-B889-B7E70A68566B@langa.pl>

Answers to some questions I keep getting about PEP 8012: https://discuss.python.org/t/pep-8012-frequently-asked-questions/487 <https://discuss.python.org/t/pep-8012-frequently-asked-questions/487>

- ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181127/61dd338a/attachment.html>

From njs at pobox.com  Thu Nov 29 23:03:00 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 29 Nov 2018 20:03:00 -0800
Subject: [python-committers] Draft ballot text
Message-ID: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>

Hi all,

Since the vote's supposed to be starting in a few days, I figured it
would be good to finish up the fiddly details and avoid any
last-minute editing. So here's a draft proposal for the ballot
instructions and options: https://github.com/python/peps/pull/844

I also set up a test vote on CIVS, so you can see how it will actually
look: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_f3dd3ec110515d32&akey=add219018ca56843

Please post any feedback on the PR or here.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From njs at pobox.com  Fri Nov 30 03:51:33 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 30 Nov 2018 00:51:33 -0800
Subject: [python-committers] Draft ballot text
In-Reply-To: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>
References: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>
Message-ID: <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>

Oh yeah, one odd thing I noticed: according to PEP 8001, the vote runs
from Dec. 1 to Dec. 16, i.e., two weeks + two days. Is this...
intentional? Of course 16 is a good round number, but it still seemed
strange. Maybe it's supposed to give us a little wiggle room in case
the vote doesn't get sent out right at midnight on the 1st, while
still keeping the two week period?

-n
On Thu, Nov 29, 2018 at 8:03 PM Nathaniel Smith <njs at pobox.com> wrote:
>
> Hi all,
>
> Since the vote's supposed to be starting in a few days, I figured it
> would be good to finish up the fiddly details and avoid any
> last-minute editing. So here's a draft proposal for the ballot
> instructions and options: https://github.com/python/peps/pull/844
>
> I also set up a test vote on CIVS, so you can see how it will actually
> look: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_f3dd3ec110515d32&akey=add219018ca56843
>
> Please post any feedback on the PR or here.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org



-- 
Nathaniel J. Smith -- https://vorpus.org

From eric at trueblade.com  Fri Nov 30 04:30:34 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Fri, 30 Nov 2018 04:30:34 -0500
Subject: [python-committers] Draft ballot text
In-Reply-To: <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>
References: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>
 <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>
Message-ID: <97417429-c816-a4c7-2193-1ef4f67e3ac0@trueblade.com>

On 11/30/2018 3:51 AM, Nathaniel Smith wrote:
> Oh yeah, one odd thing I noticed: according to PEP 8001, the vote runs
> from Dec. 1 to Dec. 16, i.e., two weeks + two days. Is this...
> intentional? Of course 16 is a good round number, but it still seemed
> strange. Maybe it's supposed to give us a little wiggle room in case
> the vote doesn't get sent out right at midnight on the 1st, while
> still keeping the two week period?

I assumed it was so the vote would include 2 weekends. Makes sense to me.

Eric

> 
> -n
> On Thu, Nov 29, 2018 at 8:03 PM Nathaniel Smith <njs at pobox.com> wrote:
>>
>> Hi all,
>>
>> Since the vote's supposed to be starting in a few days, I figured it
>> would be good to finish up the fiddly details and avoid any
>> last-minute editing. So here's a draft proposal for the ballot
>> instructions and options: https://github.com/python/peps/pull/844
>>
>> I also set up a test vote on CIVS, so you can see how it will actually
>> look: https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_f3dd3ec110515d32&akey=add219018ca56843
>>
>> Please post any feedback on the PR or here.
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
> 
> 
> 

From antoine at python.org  Fri Nov 30 04:49:45 2018
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 30 Nov 2018 10:49:45 +0100
Subject: [python-committers] Draft ballot text
In-Reply-To: <97417429-c816-a4c7-2193-1ef4f67e3ac0@trueblade.com>
References: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>
 <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>
 <97417429-c816-a4c7-2193-1ef4f67e3ac0@trueblade.com>
Message-ID: <ce127b97-6972-2780-5f29-238256e9b6c7@python.org>


Le 30/11/2018 ? 10:30, Eric V. Smith a ?crit?:
> On 11/30/2018 3:51 AM, Nathaniel Smith wrote:
>> Oh yeah, one odd thing I noticed: according to PEP 8001, the vote runs
>> from Dec. 1 to Dec. 16, i.e., two weeks + two days. Is this...
>> intentional? Of course 16 is a good round number, but it still seemed
>> strange. Maybe it's supposed to give us a little wiggle room in case
>> the vote doesn't get sent out right at midnight on the 1st, while
>> still keeping the two week period?
> 
> I assumed it was so the vote would include 2 weekends. Makes sense to me.

Three weekends (if by weekend you mean Saturday + Sunday).

Regards

Antoine.

From eric at trueblade.com  Fri Nov 30 05:27:09 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Fri, 30 Nov 2018 05:27:09 -0500
Subject: [python-committers] Draft ballot text
In-Reply-To: <ce127b97-6972-2780-5f29-238256e9b6c7@python.org>
References: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>
 <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>
 <97417429-c816-a4c7-2193-1ef4f67e3ac0@trueblade.com>
 <ce127b97-6972-2780-5f29-238256e9b6c7@python.org>
Message-ID: <F7398C15-DD73-4D6D-BCBF-7FE6056F6EF1@trueblade.com>


> On Nov 30, 2018, at 4:49 AM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
>> Le 30/11/2018 ? 10:30, Eric V. Smith a ?crit :
>>> On 11/30/2018 3:51 AM, Nathaniel Smith wrote:
>>> Oh yeah, one odd thing I noticed: according to PEP 8001, the vote runs
>>> from Dec. 1 to Dec. 16, i.e., two weeks + two days. Is this...
>>> intentional? Of course 16 is a good round number, but it still seemed
>>> strange. Maybe it's supposed to give us a little wiggle room in case
>>> the vote doesn't get sent out right at midnight on the 1st, while
>>> still keeping the two week period?
>> 
>> I assumed it was so the vote would include 2 weekends. Makes sense to me.
> 
> Three weekends (if by weekend you mean Saturday + Sunday).

Right. I meant the two weekends at the ends of the range.

Eric


From brett at python.org  Fri Nov 30 12:55:09 2018
From: brett at python.org (Brett Cannon)
Date: Fri, 30 Nov 2018 09:55:09 -0800
Subject: [python-committers] Draft ballot text
In-Reply-To: <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>
References: <CAPJVwBkdZ0M=8WA=RjGO6Q2YoJ4pJbv0uHsRqRjYuarHx5HZtg@mail.gmail.com>
 <CAPJVwBkDwqMW59ZkZ-g=p9rqi=ao2T4oJZNrvmZ52T8dxjrBvA@mail.gmail.com>
Message-ID: <CAP1=2W5ZHLg24C4vPNN4tb+UWFioEgXWQ=Jet5FOYgd1UV3J_w@mail.gmail.com>

Thanks for the proposed text (even though I'm replying before I read it ;) .

As for the dates, it was intentional. Ends on a weekend so no one feels
rushed if they procrastinate and only do open source on weekends, plus Dec
16 is a date people can reason about in terms of the middle of the month.

On Fri, 30 Nov 2018 at 00:52, Nathaniel Smith <njs at pobox.com> wrote:

> Oh yeah, one odd thing I noticed: according to PEP 8001, the vote runs
> from Dec. 1 to Dec. 16, i.e., two weeks + two days. Is this...
> intentional? Of course 16 is a good round number, but it still seemed
> strange. Maybe it's supposed to give us a little wiggle room in case
> the vote doesn't get sent out right at midnight on the 1st, while
> still keeping the two week period?
>
> -n
> On Thu, Nov 29, 2018 at 8:03 PM Nathaniel Smith <njs at pobox.com> wrote:
> >
> > Hi all,
> >
> > Since the vote's supposed to be starting in a few days, I figured it
> > would be good to finish up the fiddly details and avoid any
> > last-minute editing. So here's a draft proposal for the ballot
> > instructions and options: https://github.com/python/peps/pull/844
> >
> > I also set up a test vote on CIVS, so you can see how it will actually
> > look:
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_f3dd3ec110515d32&akey=add219018ca56843
> >
> > Please post any feedback on the PR or here.
> >
> > -n
> >
> > --
> > Nathaniel J. Smith -- https://vorpus.org
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181130/c6a87aca/attachment.html>