[python-committers] Can we choose between mailing list and discuss.python.org?

[Gregory P. Smith]

On Tue, Feb 12, 2019 at 1:59 PM Antoine Pitrou <antoine at python.org> wrote:

>
> Le 11/02/2019 à 20:00, Barry Warsaw a écrit :
> > On Feb 11, 2019, at 09:48, Victor Stinner <vstinner at redhat.com> wrote:
> >>
> >> tl; dr How can we decide if we should stop using mailing list or if we
> >> should stop using discuss.python.org?
> >
> > Point of order: I think we need a PEP for this decision.  Such a PEP
> would organize and consolidate the arguments both pro and con of the three
> choices.  It should also cover whether the current Discourse experiment
> translates to larger mailing lists like python-dev, -ideas, and -list (for
> which I personally have uncertainty about).
>
> Same uncertainty here.  I don't think Discourse works well for long
> threads.
>
> Here is a 161-message Discourse thread (at the time of this writing):
> https://discuss.python.org/t/pep-517-backend-bootstrapping/789
>
> I know I can browse easily through a 161-message mailing-list or
> newsgroup thread using a traditional threaded view, read what I want,
> come back later to read the rest, etc.  But Discourse's linear
> presentation pretty much kills that ability.  It doesn't even allow
> *seeing* the structure of the discussion.
>

Neither does my email client.  It never will, nor can we require mailing
list participants to use any specific type of email client.

If we want to enforce an *interface* on people, IMNSHO that is what
something like Discourse is for.  It levels the playing field and provides
modern features way beyond 1900s style email listserv communication while
still allowing interaction via email.

To wit, I also agree with the flat-by-design link posted further down
thread.  Scrollwheel skimming further it looks like what I've said
reinforces points already made by Paul and others.

I don't personally find that _anything_ works well for long threads.  I'm
not convinced that problem is solvable for more than a minority fraction of
participants.  So lets not try ourselves, but lets not reject change
because it doesn't solve that problem.  Look at the existing problems it
_does_ solve and seek to address and understand new problems it creates.
That'd all be part of a Discourse related PEP.

Remember, we could still be using cvs.  Lets not be that project.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20190213/dc8401d5/attachment.html>