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/