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

[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

[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

[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

[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

[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] Suggestion: A PSF grant for running a "Core Dev Mentorship Program"

[Tal Einat]

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

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


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

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

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


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


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

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

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


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

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

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

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


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

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

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

[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

[Donald Stufft]

> On Nov 3, 2018, at 1:24 PM, Donald Stufft  wrote:
> 
> 
> 
>> 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.
> 


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

___
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

[Antoine Pitrou]

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

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

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

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

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

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

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

Regards

Antoine.
___
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

[Donald Stufft]

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


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

TBH I find threaded views nonsensical in every medium I’ve ever seen them in, 
even things like Reddit or the such feel really poor to me. Either the 
threading is so in your face that the same points end up getting repeated at 
different sub threads, or the threading is so minimal that people are replying 
to things cross sub-thread and treating it like a “flat” discussion.___
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] [OT] email clients

[Antoine Pitrou]

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

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

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

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

Regards

Antoine.
___
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] Suggestion: A PSF grant for running a "Core Dev Mentorship Program"

[Steve Dower]

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


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


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


Cheers,
Steve
___
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

[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] Suggestion: A PSF grant for running a "Core Dev Mentorship Program"

[Antoine Pitrou]

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

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

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

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

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

Regards

Antoine.
___
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

[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

[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] [OT] email clients

[Donald Stufft]

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

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

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

To be honest, I’m not even sure how you’d represent some of these things in a 
threaded view. For instance within discourse I can multi quote different posts 
to tie multiple lines of discussion together. How would you present that in a 
threaded view? A merge? I’m not aware of any threaded system that actually 
allows it.___
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

[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] [OT] email clients

[Antoine Pitrou]

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

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

Regards

Antoine.
___
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] [OT] email clients

[Ethan Furman]

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

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


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


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


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


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

[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

[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

[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] [OT] email clients

[Donald Stufft]

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


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

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

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

___
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] [OT] email clients

[Antoine Pitrou]

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

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

Regards

Antoine.
___
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] [OT] email clients

[Donald Stufft]

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

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

My experience with the Governance discussion lead me to post 
https://mail.python.org/mm3/archives/list/distutils-...@python.org/message/VXXPZCVRLH27N46TR3P6IEOKIA47POCM/
 

 last night, so I’m pulling myself generally out of distutils-sig as well.

___
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] [OT] email clients

[Donald Stufft]

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


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

___
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] [OT] email clients

[Donald Stufft]

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

One last bit! 

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

___
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

[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] [OT] email clients

[Ethan Furman]

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

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


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


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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Donald Stufft]

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

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

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

[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

[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

[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&id=E_4191dbfb94efecb6&algorithm=beatpath
 
.

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

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, d