On Tue, 22 May 2018 at 18:07 Steven D'Aprano <st...@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 <vstin...@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/
>
_______________________________________________
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/
