> On May 22, 2018, at 5:21 PM, Guido van Rossum <gu...@python.org > <mailto:gu...@python.org>> wrote: > > On Tue, May 22, 2018 at 2:50 PM, Victor Stinner <vstin...@redhat.com > <mailto:vstin...@redhat.com>> wrote: > 2018-05-19 0:25 GMT+02:00 Guido van Rossum <gu...@python.org > <mailto:gu...@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.
_______________________________________________ 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/
