I would like to clarify, what would be a typical time-line for a PEP? Will it look like this:

0. Preliminary discussions to determine whether an idea is PEP-worthy (can happen anywhere, python-ideas, SIGs, even offline)
1. A PEP number is requested by a champion and assigned by a PEP editor (in python/peps repo)
2. PEP is drafted and discussed by a narrow circle of interested participants (happens in a separate repo)
3. When PEP is ready and polished make a PR to python/peps repo, and post it to python-dev to get feedback (if any) from a wider audience
4. If reasonable objections appear at this step, go to step 2
5. Repeat steps 2-4 until accepted/rejected/deferred

Is this what you propose? Or you want to completely avoid posting to python-dev?

-- Ivan

On 18 May 2018 at 18:25, Guido van Rossum guido@python.org wrote:

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.

PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).

Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

-- --Guido van Rossum (python.org/~guido)

---

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/

On Fri, May 18, 2018 at 3:58 PM, Ivan Levkivskyi levkivskyi@gmail.com wrote:

I would like to clarify, what would be a typical time-line for a PEP? Will it look like this:

0. Preliminary discussions to determine whether an idea is PEP-worthy (can happen anywhere, python-ideas, SIGs, even offline)
1. A PEP number is requested by a champion and assigned by a PEP editor (in python/peps repo)

I expect some proposals to get stuck before they're ever in a state acceptable even as draft PEP, so I'd like to put off requesting a PEP number as long as possible.

2. PEP is drafted and discussed by a narrow circle of interested participants (happens in a separate repo)
3. When PEP is ready and polished make a PR to python/peps repo, and post it to python-dev to get feedback (if any) from a wider audience

I expect there to be a long trajectory where the PEP does exist in the peps repo but should still be discussed in its own repo. Mentions on python-dev should be limited to the occasional link to the PEP's own repo, with strongly worded requests to go to that repo to provide feedback.

4. If reasonable objections appear at this step, go to step 2

The process should be clear that objections posted to python-dev will be ignored -- only objections posted to the PEP's own repo's issue tracker will be considered.

5. Repeat steps 2-4 until accepted/rejected/deferred

Is this what you propose? Or you want to completely avoid posting to python-dev?

I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)

There are probably some other parts needed too, e.g. guidelines as to when a PEP is considered ripe for copying to the peps repo (and scripts/bots to make repeated copies easy -- e.g. there could be a bot that copies a PEP from that PEP's own repo to the peps repo each time a commit is made to the master branch in its own repo). There could also be guidelines to ensure a PEP is in a fairly non-controversial state (probably using the IETF's motto "rough consensus and working code") before being considered for approval. There's definitely some time when a PEP has an assigned number but is still controversial -- during that state debate on python-dev should be strictly redirected to the PEP's own repo.

For some PEPs it may make sense to assign a senior reviewer who decides what's considered non-controversial.

We can borrow more from the IETF process for RFCs: https://www.rfc-editor.org/pubprocess/

--Guido

PS. Carol: Jupyter's process looks great! I just don't have the guts to propose any serious changes to the physical logistics of publishing PEPs, since changes to the structure of the peps repo are so hard. We still haven't converted all PEPs to .rst format, despite efforts by Mariatta and others, and attempts to move all PEPs to a subdirectory have also failed, due to perpetual lack of resources to complete the task (and e.g. the need to update scripts on python.org whenever the peps repo structure changes).

-- Ivan

On 18 May 2018 at 18:25, Guido van Rossum guido@python.org wrote:

...

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.

PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).

Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

-- --Guido van Rossum (python.org/~guido)

---

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/

-- --Guido van Rossum (python.org/~guido)

On 18 May 2018 at 19:46, Gregory P. Smith greg@krypto.org wrote:

I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.

Can few related PEPs share the same repository? For example, I want to start writing three PEPs about extensions to PEP 484 type system: literal types, final/const qualifier, and integer generics (simple dependent types). They all are tightly connected (but I don't want a single mega-PEP), can I put these three in the same repo?

-- Ivan

On Fri, May 18, 2018 at 3:25 PM, Guido van Rossum guido@python.org wrote:

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

PEP 572 seems like something of a perfect storm... it's simultaneously a bikeshed and a nuclear power plant [1], and also the rare proposal that you like but that significant numbers of core devs find deeply objectionable; any one of these would tend to produce a lot of email, and then the combination is something else again. Is this proposal mostly responding to that, or something that you've been thinking for a while?

[1] For those unfamiliar with this example: https://en.wikipedia.org/wiki/Law_of_triviality#Examples

I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

To some extent this has been happening informally for a while. Just off the top of my head:

PEP 465: https://github.com/numpy/numpy/pull/4351 PEP 543: https://github.com/python-hyper/pep543/issues/2#issuecomment-309199376 PEP 513: https://github.com/pypa/manylinux#the-pep-itself A repo full of packaging PEPs: https://github.com/pypa/interoperability-peps

For a lot of us these days, putting a document in a repo is just the default way to work on it (and get feedback, etc.).

Managing the relationship between these repos and the main peps repo is currently pretty awkward. They tend to get out of sync in both directions – people make edits directly to the PEP repo – plus in general some pieces of information are in one place and some in another, there's no link between them, the original repo can get misplaced over time...

This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.

PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).

I'd be somewhat tempted to require people to use Github and to move the repo into the python/ organization when it gets a number, so that there's one canonical place to look for the history and we have some control over its lifecycle.

More radical idea: what if the PEPs index just linked to the Github rendering of each file? That's always going to be up to date, it comes with a link to the issue tracker at the top, it has a nice "Edit" button if someone wants to submit small fixes as a PR...

Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Rust's RFC process is a bit different, but may be of interest: https://github.com/rust-lang/rfcs

One thing people might worry about is missing out on discussion they're interested in – there wouldn't be one central place to subscribe to see discussions. Rust's concept of a "final comment period" is a nice way to manage this.

-n

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

Hi,

Note that some PEPs are, still, mostly uncontroversial (PEP 574 is an example).

I agree with Nathaniel : PEP 572 is the poster child for lengthy, heated discussions. I'm still surprised you thought it was a good idea to discuss this. Perhaps it we tried to discourage syntax change and/or builtin change PEPs a little more we'd have less heated PEPs :-)

It would be *very* interesting if someone was willing to do some stats on PEPs over time: e.g. number of PEPs discussed every year, discussion length, number of discusssion participants. I actually expect overall PEP activity to have gone down since the 2000s.

Le 19/05/2018 à 01:41, Guido van Rossum a écrit :

I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)

Are you saying PEPs wouldn't even be *validated* by python-dev? If so, it's not a mere change to focus discussions, it's also a change in governance.

And while we may decide to change this piece of the governance model, the replacement process should IMO be something a little less vague than « discussion happens on Github with whoever happens to be interested or available ». Sorry if this is misrepresenting your position.

Regards

Antoine.

There are probably some other parts needed too, e.g. guidelines as to when a PEP is considered ripe for copying to the peps repo (and scripts/bots to make repeated copies easy -- e.g. there could be a bot that copies a PEP from that PEP's own repo to the peps repo each time a commit is made to the master branch in its own repo). There could also be guidelines to ensure a PEP is in a fairly non-controversial state (probably using the IETF's motto "rough consensus and working code") before being considered for approval. There's definitely some time when a PEP has an assigned number but is still controversial -- during that state debate on python-dev should be strictly redirected to the PEP's own repo.

For some PEPs it may make sense to assign a senior reviewer who decides what's considered non-controversial.

We can borrow more from the IETF process for RFCs: https://www.rfc-editor.org/pubprocess/

--Guido

PS. Carol: Jupyter's process looks great! I just don't have the guts to propose any serious changes to the physical logistics of publishing PEPs, since changes to the structure of the peps repo are so hard. We still haven't converted all PEPs to .rst format, despite efforts by Mariatta and others, and attempts to move all PEPs to a subdirectory have also failed, due to perpetual lack of resources to complete the task (and e.g. the need to update scripts on python.org http://python.org whenever the peps repo structure changes).

On 18 May 2018 at 23:25, Guido van Rossum guido@python.org wrote:

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

It's not scalable, certainly. But it's still (IMO) fine for all but the larger PEPs - the trick is spotting which PEPs are "too big" :-)

I'm not sure that the issue with python-ideas is that bad. That list is *designed* for incomplete and unformed proposals, and so long threads are common (and accepted) on there. People on python-ideas are used to skimming or ignoring/blocking threads they aren't interested in. So by the time things are ready to go to python-dev (or wherever) there's a good sense of whether the PEP is likely to be controversial. I'd suggest that this is the point when the decision to go to python-dev or github could be made.

I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.

PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).

I would prefer that PEP repos remain on github, and that once the PEP is finalised (accepted, rejected, whatever) moved under the CPython organisation (the whole repo, issue tracker, history, everything) so that the history of discussion isn't lost. Current PEP discussions are retained on the list archives, and I think the discussion history is valuable (even if a lot of it ends up being noise at the moment). I'd rather not have to maintain extra accounts for bitbucket or gitlab, and learn how notifications and tracking work on those platforms. A common interface is important. Adding barriers to contribution does filter out casual commenters, but I'm sure we don't want to be seen to be deliberately making it *hard* for outsiders to get involved.

Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

(Later)

I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)

Avoiding *discussion* is probably OK. But regular summaries of progress would, I think, be critical. Otherwise python-dev is essentially cut out of the loop, and this becomes more of a change in governance, as Antoine mentioned.

I'm not quite sure what your intention was, but I'd like to see a series of announcements on python-dev for a PEP which is being discussed offline:

1. An initial announcement of the creation of the PEP repo, giving a summary of the PEP (the abstract from the proposal), and a pointer to where interested parties should go to participate in discussions.
2. Progress announcements, maybe once a month, repeating the summary and adding a "what has changed" summary.
3. Preliminary announcement of the decision on the PEP (a "release candidate" if you like) stating that the decision has been made, what that decision is, and that it will be officially announced in (say) a week.
4. Final announcement, giving the summary, the decision, and pointers to the final PEP text and the discussion (now hosted permanently under the cpython org on github).

The point of the "release candidate" stage is the same as the RC for a release - last chance to raise showstopper problems, plus announcing the start of the "release" work (moving the repo, specifically).

I'm not that wedded to the RC announcement, but it will avoid the final decision coming as a complete surprise to python-dev. As a data point, I currently have no idea whether the discussions on the binding expression PEP are still just rumbling on, or whether a decision is imminent. Of course, if the progress announcements are sufficiently good, the RC may not be necessary (it would effectively just be the last in a series of summaries).

Paul

Hi,

2018-05-19 7:45 GMT+02:00 Antoine Pitrou antoine@python.org:

It would be *very* interesting if someone was willing to do some stats on PEPs over time: e.g. number of PEPs discussed every year, discussion length, number of discusssion participants. I actually expect overall PEP activity to have gone down since the 2000s.

I counted the number of emails per PEP (sent to python-dev or python-ideas) on the period Jan 2017 - April 2018: https://mail.python.org/pipermail/python-committers/2018-April/005310.html

My script: https://github.com/vstinner/misc/blob/master/python/parse_mailman_mbox_peps....

I downloaded "[ Gzip'd Text 227 KB ]" links from https://mail.python.org/pipermail/python-dev/ and https://mail.python.org/pipermail/python-ideas/ and then uncompressed them.

Victor

On May 22, 2018, at 5:50 PM, Victor Stinner vstinner@redhat.com wrote:

IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.

FWIW, I think this is a key thing— Mailing lists are not easily moderatable. There’s no way to pause discussion, redirect, etc besides generating *more* email (and the tooling to do it is lackluster, it’s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.

On Tue, May 22, 2018 at 2:50 PM, Victor Stinner vstinner@redhat.com wrote:

2018-05-19 0:25 GMT+02:00 Guido van Rossum guido@python.org:

...

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

Which problem do you want to solve? Reduce the number of emails per month on python-ideas and python-dev? Reduce the number of messages per PEP?

Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with.

If the number of messages per PEP is the problem, I don't see how replacing emails with GitHub would help. GitHub allows to add comments on:

• commits
• issues
• pull requests

Anyone can open new issues and new pull requests. It might be harder to follow discussions if they are occur at different parts of a single repository.

That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement.

The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo).

I guess that your motivation is to prevent another PEP 572 mess.

IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.

What action *can* you take on mailing lists like python-{ideas,dev}?

A moderator can try to summarize the discussion or can ask to stop discussing the PEP until the PEP is updated. For the PEP 572, it seems like a few issues have been spotted in the PEP, but I don't recall an email saying "these points must be fixed in the PEP, please wait until the PEP is updated".

Will it be simpler to moderate discussions on GitHub? Or do you expect that less people will go to GitHub, than on python-dev/python-ideas, to discuss?

GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}.

If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit.

I like emails because it's plain text, it's easily readable on all devices, there are archives (controlled by Python) which are readable online, etc. I also like threads in emails. It's easy to see if I missed messages. On GitHub, there is no markers of unread messages, only notifications (well, there are also notifications with messages ;-)).

Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone.

IMHO a PEP should summarize the most important discussed points. Otherwise, each time that someone who don't know the PEP will read it, the same discussion will restart from scratch. And I don't think that PEP 572 made that.

That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments).

...

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Apart the PEP 572, I recalled that I have been annoyed by the fspath protocol before a PEP has been written. I also recall that the discussions stopped when I asked to wait until Brett (and someone else, sorry I forgot) writes a PEP. For other PEPs, I think that the volume of emails is acceptable.

That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation).

I also like the idea of getting all PEPs in python-dev because it's easier for me to be aware of currently discussed PEPs, even if I don't read the discussions.

But it seems like I'm getting old and resist to the shiny new GitHub which will solve all our issues ;-)

To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane.

-- --Guido van Rossum (python.org/~guido)

On May 22, 2018, at 5:21 PM, Guido van Rossum mailto:guido@python.org> wrote:

On Tue, May 22, 2018 at 2:50 PM, Victor Stinner mailto:vstinner@redhat.com> wrote: 2018-05-19 0:25 GMT+02:00 Guido van Rossum mailto:guido@python.org>:

...

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)

I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.

Which problem do you want to solve? Reduce the number of emails per month on python-ideas and python-dev? Reduce the number of messages per PEP?

Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with.

If the number of messages per PEP is the problem, I don't see how replacing emails with GitHub would help. GitHub allows to add comments on:

• commits
• issues
• pull requests

Anyone can open new issues and new pull requests. It might be harder to follow discussions if they are occur at different parts of a single repository.

That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement.

The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo).

I guess that your motivation is to prevent another PEP 572 mess.

IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.

What action *can* you take on mailing lists like python-{ideas,dev}?

A moderator can try to summarize the discussion or can ask to stop discussing the PEP until the PEP is updated. For the PEP 572, it seems like a few issues have been spotted in the PEP, but I don't recall an email saying "these points must be fixed in the PEP, please wait until the PEP is updated".

Will it be simpler to moderate discussions on GitHub? Or do you expect that less people will go to GitHub, than on python-dev/python-ideas, to discuss?

GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}.

If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit.

I like emails because it's plain text, it's easily readable on all devices, there are archives (controlled by Python) which are readable online, etc. I also like threads in emails. It's easy to see if I missed messages. On GitHub, there is no markers of unread messages, only notifications (well, there are also notifications with messages ;-)).

Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone.

IMHO a PEP should summarize the most important discussed points. Otherwise, each time that someone who don't know the PEP will read it, the same discussion will restart from scratch. And I don't think that PEP 572 made that.

That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments).

...

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Apart the PEP 572, I recalled that I have been annoyed by the fspath protocol before a PEP has been written. I also recall that the discussions stopped when I asked to wait until Brett (and someone else, sorry I forgot) writes a PEP. For other PEPs, I think that the volume of emails is acceptable.

That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation).

I also like the idea of getting all PEPs in python-dev because it's easier for me to be aware of currently discussed PEPs, even if I don't read the discussions.

But it seems like I'm getting old and resist to the shiny new GitHub which will solve all our issues ;-)

To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane.

-- --Guido van Rossum (python.org/~guido http://python.org/~guido)

---

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

FWIW, I'm going to throw out some negotiation tips since most of what is happening before a PEP is approved or rejected is negotiation of some form. Ideally, I would like to add these to the dev guide in a checklist section for Feedback on PEPs. These are all research driven from Harvard.

One-text principle (All parties work from the same document.) Setting ground rules for feedback on the text such as:

• What is wrong with this draft as it is presented now?

• Do you have important interests that this draft does not adequately address? Which ones? Why are they important?

• What else seems wrong or is missing from the draft? Why are these things important?

• Do you have other ideas for improvement? What are your reasons for suggesting these items? What key unmet interests do they address?

• Do you have other ideas about how conflicting interests can be creatively and fairly resolved?

• Understanding why you would like this particular interest met, but given that it has become clear that it is in direct conflict with other's interests, why should meeting your interest take priority over meeting theirs? What standards or fair process might we apply to deciding this?

Keeping emotions from boiling over

1. Focus on your physical reaction.
2. Listen to what your counterpart is saying
3. Show you have heard them
4. Show some empathy.
5. Find out more.
6. Take a break.

On Tue, 22 May 2018 at 18:07 Steven D'Aprano steve@pearwood.info wrote:

On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:

...

...

On May 22, 2018, at 5:50 PM, Victor Stinner vstinner@redhat.com

wrote:

...

...

IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.

FWIW, I think this is a key thing— Mailing lists are not easily moderatable.

*Unmoderated* mailing lists are not easily moderated.

...

There’s no way to pause discussion, redirect, etc

Does Github allow us to do these things? Not a rhetorical question.

Locking/pausing issues and PRs yes (both temporarily and permanently), redirection not specifically beyond cross-referencing to another issue/PR in a comment.

-Brett

...

besides generating *more* email (and the tooling to do it is lackluster, it’s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.

It is one thing to identify a problem, another thing to state that something is a solution to that problem, and a completely different thing to actually solve the problem. How does fracturing the discussion help?

One of the problems with PEP 372 was that the discussion was fractured across multiple threads on two mailing lists, leading to the same points being raised over and over again. (I think Chris was premature in taking it to Python-Dev while it was still be actively argued on Python-Ideas.)

It seems to me that "fracturing the discussion amongst multiple repos" will have the same effect: increase the total volume, not decrease it, as well as increasing the chances that salient points will be missed. Am I wrong?

As for better tooling for moderation, I asked earlier in this thread how moving to Github will help. What is this tooling?

I think the problem with PEP 572 was that it was a perfect storm of a number of factors:

• it relates to a feature simple enough that everyone has an opinion;

• the statement/expression divide ("assignment is NOT an expression, and that's a feature!") has been a point of distinction between Python and "the competition" for 20+ years;

• hence some very strong feelings;

• legitimate concerns over complexity and the assign/equals bug;

• bike-shedding and arguments over syntax;

• distraction over unrelated proposal to change the way scoping works inside classes;

• lots of newcomers to the community.

I count at least three discussions about this on Reddit:

https://redd.it/8fpv3f https://redd.it/8fokpw https://redd.it/8ex72p

Most PEPs don't get even one.

Trialling Github with a simpler, less emotional and bike-sheddy PEP may not demonstrate how well the process works when everyone and their pet cat has an opinion.

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

Le 28/06/2018 à 13:04, Victor Stinner a écrit :

It seems like the PEP 572 discussions restarted on python-dev mailing list with more than 100 emails in one week.

Stupid idea: we created a mailing list just to fix os.random(): PEP 522 and PEP 524, whereas these discussions were not the ones with the most emails. Why not creating a new pep572 mailing list for the ones who don't want to follow PEP 572 discussions?

PEP 572 is a language-wide change. Presumably those who don't want to follow discussions will still want to give their opinion (or informal vote) at the end. Which will give rise to other discussions...

What strikes me is that we have such long-lasting and intense discussion about a feature which, whether approved or not, will not significantly change Python's popularity or appeal or ability to solve real-world problems.

Perhaps this is a case where « Nature abhors a vacuum » : we're getting focussed on whatever comes up to fill the narrative of Python's evolution.

Regards

Antoine.

On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:

Sorry to bring up this old topic.

I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?

I think this will be a good test of Zulip, as well as incentive for folks to join.

-- ~Ethan~

I like the Zulip idea, though it'll be hard to get permalinks to past discussions.

Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl).

On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman ethan@stoneleaf.us wrote:

On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:

Sorry to bring up this old topic.

...

I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?

I think this will be a good test of Zulip, as well as incentive for folks to join.

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

-- --Guido van Rossum (python.org/~guido)

I just renamed the stream so there's now just a single #. :)

On Wed, 11 Jul 2018 at 11:22 Mariatta Wijaya mariatta.wijaya@gmail.com wrote:

For permalink in zulip, the link from "Copy link to conversation" seems to be sufficient. I've created a stream ( https://python.zulipchat.com/#narrow/stream/130206-.23pep581/subject/hello/n...) but it now has double ## 😅 and it seems I can't rename it to remove the extra "#"

I've been waiting for the "excitement" surrounding PEP 572 to cool down before I want to merge PEP 581 (https://github.com/python/peps/pull/681/)

I was hoping to bypass python-ideas since we've discussed at Python Language Summit :) but if really needed I can start a thread there.

Mariatta

On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum guido@python.org wrote:

...

I like the Zulip idea, though it'll be hard to get permalinks to past discussions.

Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl).

On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman ethan@stoneleaf.us wrote:

...

On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:

Sorry to bring up this old topic.

...

I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?

I think this will be a good test of Zulip, as well as incentive for folks to join.

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

-- --Guido van Rossum (python.org/~guido)

---

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

---

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