Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Victor Stinner
Le jeu. 15 nov. 2018 à 23:51, Paul Moore  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Paul Moore
On Thu, 15 Nov 2018 at 18:55, Brett Cannon  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread M.-A. Lemburg
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/

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread M.-A. Lemburg
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/

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Brett Cannon
On Thu, 15 Nov 2018 at 05:09, Paul Moore  wrote:

> On Thu, 15 Nov 2018 at 12:55, M.-A. Lemburg  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).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Barry Warsaw
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



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Mariatta Wijaya
>
> 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).

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Paul Moore
On Thu, 15 Nov 2018 at 12:55, M.-A. Lemburg  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread M.-A. Lemburg
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  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@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/

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-15 Thread Victor Stinner
Le sam. 3 nov. 2018 à 03:37, Victor Stinner  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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Antoine Pitrou

Le 05/11/2018 à 23:08, Victor Stinner a écrit :
> Le sam. 3 nov. 2018 à 10:39, Antoine Pitrou  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Victor Stinner
Le sam. 3 nov. 2018 à 10:39, Antoine Pitrou  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Paul Moore
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  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  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  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Tim Peters
[Paul Moore ]
> 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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Brett Cannon
On Mon, 5 Nov 2018 at 11:29, Paul Moore  wrote:

> On Mon, 5 Nov 2018 at 19:11, Brett Cannon  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Donald Stufft


> On Nov 5, 2018, at 2:29 PM, Paul Moore  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.___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Brett Cannon
On Mon, 5 Nov 2018 at 11:22, Paul Moore  wrote:

> On Mon, 5 Nov 2018 at 19:11, Brett Cannon  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Paul Moore
On Mon, 5 Nov 2018 at 19:11, Brett Cannon  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Paul Moore
On Mon, 5 Nov 2018 at 19:11, Brett Cannon  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Brett Cannon
On Sun, 4 Nov 2018 at 10:53, Paul Moore  wrote:

> On Sun, 4 Nov 2018 at 15:25, Steve Dower  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 

Re: [python-committers] Timeline to vote for a governance PEP

2018-11-05 Thread Nathaniel Smith
On Sun, Nov 4, 2018 at 10:53 AM, Paul Moore  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-04 Thread Paul Moore
On Sun, 4 Nov 2018 at 15:25, Steve Dower  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-04 Thread Tim Peters
[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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-04 Thread Steve Dower

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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-04 Thread Antoine Pitrou

Le 04/11/2018 à 12:38, Paul Moore a écrit :
> On Sun, 4 Nov 2018 at 00:21, Steven D'Aprano  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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-04 Thread Guido van Rossum
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  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.
>
> E ... 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=E_4191dbfb94efecb6=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=E_31f80ce0986ce98c=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 

Re: [python-committers] Timeline to vote for a governance PEP

2018-11-04 Thread Donald Stufft


> On Nov 4, 2018, at 1:52 AM, Donald Stufft  wrote:
> 
>> 
>> On Nov 3, 2018, at 11:56 PM, Tim Peters > > wrote:
>> 
>> [Donald Stufft mailto:don...@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.


https://discuss.python.org/t/pep-8001-public-or-private-ballots/374___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Donald Stufft


> On Nov 3, 2018, at 11:56 PM, Tim Peters  wrote:
> 
> [Donald Stufft ]
>> 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=E_4191dbfb94efecb6=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=E_31f80ce0986ce98c=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 
>> 

Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
[Donald Stufft ]
> 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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Donald Stufft


> On Nov 3, 2018, at 8:41 PM, Donald Stufft  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 

- 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
 

- PEP 8012 - The Community Model - 
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 

- PEP 8014 - The Commons Model - 
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 

 
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
 
.

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). 

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Steven D'Aprano
On Sat, Nov 03, 2018 at 10:55:14AM +, 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
[Steven D'Aprano ]
> 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 ;-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Steven D'Aprano
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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
 [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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Antoine Pitrou

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).
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
[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 soo 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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Donald Stufft


> On Nov 3, 2018, at 4:45 PM, Donald Stufft  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 
. Not going to merge it myself, just 
figured I’d offer it as an alternative option.

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Donald Stufft


> On Nov 3, 2018, at 3:09 PM, Donald Stufft  wrote:
> 
> 
> 
>> On Nov 3, 2018, at 2:06 PM, Barry Warsaw > > 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/  
> which includes in it a link to vote. Going to that link gives you a page like 
> 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/ 
> . Once the election is over, the 
> results are available and look like 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.



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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Antoine Pitrou

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
[Antoine Pitrou ]
> ...
> 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 :-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Antoine Pitrou

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Donald Stufft


> On Nov 3, 2018, at 2:06 PM, Barry Warsaw  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/  
which includes in it a link to vote. Going to that link gives you a page like 
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/ 
. Once the election is over, the results 
are available and look like 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).___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
[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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Antoine Pitrou

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Tim Peters
[Antoine Pitrou ]
> ...
> 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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Stefan Krah
On Sat, Nov 03, 2018 at 11:06:12AM -0700, Barry Warsaw wrote:
> On Nov 2, 2018, at 20:24, Tim Peters  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




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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Barry Warsaw
On Nov 2, 2018, at 20:24, Tim Peters  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



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Donald Stufft


> On Nov 3, 2018, at 11:22 AM, Antoine Pitrou  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.

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Antoine Pitrou

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Stefan Krah
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



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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Ethan Furman

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


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


+1

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Paul Moore
On Sat, 3 Nov 2018 at 02:37, Victor Stinner  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-03 Thread Antoine Pitrou

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.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Tim Peters
[Victor Stinner ]
>> 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 ]
> 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."
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Nathaniel Smith
On Fri, Nov 2, 2018 at 8:40 PM, Victor Stinner  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Tim Peters
[Victor Stinner ]
> 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 :-)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Eric Snow
On Fri, Nov 2, 2018, 21:44 Victor Stinner  Le sam. 3 nov. 2018 à 04:40, Eric Snow  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

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


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Victor Stinner
Le sam. 3 nov. 2018 à 04:40, Eric Snow  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Victor Stinner
> > 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  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Eric Snow
On Fri, Nov 2, 2018, 21:24 Tim Peters  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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


Re: [python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Tim Peters
[Victor Stinner ,
 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".
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


[python-committers] Timeline to vote for a governance PEP

2018-11-02 Thread Victor Stinner
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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/