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

[Brett Cannon]

On Wed, Feb 13, 2019 at 2:55 AM Paul Moore <p.f.moore at gmail.com> wrote:

> On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou <antoine at python.org> wrote:
> > Here is a 161-message Discourse thread (at the time of this writing):
> > https://discuss.python.org/t/pep-517-backend-bootstrapping/789
>
> As someone directly involved in that discussion, with a strong need to
> understand all of the points being made, that's a great example of
> both the benefits and the flaws of the discourse model.
>

Can I ask if that entire thread is on topic, or is there a reasonable point
in that discussion where side conversations could have been broken off into
a separate topic(s)? When email threads tend to reach that length there
have been side discussions that could have become their own topic if
someone thought to change the subject and Discourse allows for having an
admin break posts off at any point and I'm curious if it would have been
helpful and people simply didn't think about it (I know I don't always
think of it immediately yet).

-Brett


>
> > 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.
>
> I don't use a threaded mail client (I use gmail's web interface) so I
> don't get any of the benefits of threading from a mailing list. So to
> that extent, Discourse's lack of threading is no different for me, and
> shouldn't affect my ability to follow the discussion. But it *does*,
> and in practice, it's substantially worse than a traditional mailing
> list. (Note: this is only a comment about long, complex discussions
> like this one, for shorter threads the Discourse view is fine).
>
> The problem isn't, IMO, so much the lack of threading as the lack of
> *context*. We're all used to (and frustrated by) mailing list threads
> that are 90% quoted text. But Discourse goes to the other extreme, of
> having very *little* context - no thread structure, a tendency towards
> minimal quoting, and an *extremely* non-obvious "reply" UI (you can
> "reply" to any message, or to the thread as a whole, but the
> distinction is almost invisible, and doesn't support "replying to"
> *part* of a long comment.
>
> Also, the lack of any "mark unread" functionality makes it easy to
> lose track of where you're up to - I popped into that discussion to
> check some facts for this post, and found myself needing to read a
> number of quite detailed messages, as otherwise they would no longer
> show as "unread" for me, and I'd risk losing my place in the
> discussion. I know there are bookmarks, but they don't match my mental
> model which is "I saw these posts, but haven't *read* them".
>
> Anyway, I remain generally happy with Discourse for lower-traffic
> lists that have relatively short threads. Medium sized ones (like
> packaging replacing distutils-sig) I'm not certain about yet, but I
> think "probably no worse" is as far as I'd go right now. For groups
> like python-dev or (worse still) python-ideas I feel like they would
> be a terrible fit. There's also the interaction effect - high traffic
> in one category pushes out information about what's new in *other*
> categories, and there's no "list of categories with a count of unread
> messages" view to mitigate it.
>
> tl;dr; I don't think discourse scales particularly well to long,
> complex discussions, but I think it's less about threading than about
> other aspects of the UI. At the end of the day, managing long, complex
> discussions is *hard* and I think Discourse is optimised for different
> parts of the spectrum than mailing lists. But while the day to day
> volume of traffic might be shorter threads, the massive, complex,
> rambling threads are the lifeblood of Python development (much as we
> might all hate them ;-)) and we need to be cautious about making
> decisions for those cases based on evidence from other, simpler,
> situations.
>
> Paul
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20190213/03cdaf5f/attachment.html>