[lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update

[John McCall via lldb-dev]

On 3 Jun 2021, at 18:19, James Y Knight via llvm-dev wrote:
> I've just tried out discourse for the first time. It is not clear to me how
> to use it to replace mailing lists. It has a setting "mailing list mode",
> which sounds like the right thing -- sending all messages via email. Except
> that option is global -- all messages in all categories on the llvm
> discourse instance. Which definitely isn't what I want at all. I don't want
> to subscribe to MLIR, for example.
>
> In general, I'd say I'm pretty uncomfortable with switching from a mailing
> list to discourse. Discourse seems entirely reasonable to use for
> end-user-facing forums, but I'm rather unconvinced about its suitability as
> a dev-list replacement. Other communities (e.g. python) seem to have a
> split, still: mailing lists for dev-lists, and discourse for
> end-user-facing forums.
>
> I'd also note that Mailman3 provides a lot more features than what we're
> used to with mailman2, including the ability to interact/post through the
> website.
>
> Maybe someone can convince me that I'm just being a curmudgeon, but at this
> point, I'd say we ought to be investigating options to have Someone Else
> manage the mailman service, and keep using mailing lists, rather than
> attempting to switch to discourse.

I think that mailing lists have proven repeatedly that they’re actually
very bad for the sort of technical conversations we want to have in the
community.  It’s possible to put a lot of work into your mailing-list
experience and end up with something that half-solves some of these
problems, but it takes a lot of time and expertise, and you’re left with
something that still suffers the inherent flaws of email.

Let me try to explain why, using the ongoing byte-type RFC as a focusing
example.


First off, this is an important conversation that ought to be of interest
to a large number of LLVM developers.  Monitoring a high-traffic mailing
list takes a lot of time; I would say that most LLVM developers don’t
proactively keep up with llvm-dev.  I only became aware of this
conversation because someone thought to explicitly CC me into it.  There
are almost certainly some people who ought to be engaged in this
thread who still aren’t aware of it.

A major part of why that’s the case is that mailing lists lack structure
beyond the Reference structure of threads.  There is no inherent
categorization or tagging in a mailing list; by default, readers see a
jumble of every single thread.  And people are often reluctant to split
mailing lists by topic, and when they do sometimes conversations get
unnaturally divided, or something that should be of broader interest
gets unnecessarily pigeon-holed.  So if I want to find things that are
interesting to me, I have to look at every single active thread to see
what’s going on.

Now, in some cases, I can have that done automatically for me.  I could,
for example, set up a filter that puts all the RFC threads in a
high-priority mailbox that I can scan more frequently.  But that has
two problems.  First, not every generally-important thread is marked
as an RFC; notably, this thread isn’t.  If I set up this filter, I’d
probably be a lot less likely to read the mail mailbox for the list,
and so I’d probably miss most of these threads.  And second, I can do
that for myself, but I can’t make other people do it.  There are people
who aren’t reading and contributing to important threads because they
aren’t aware of them.  The lack of structure creates a firehose effect
that undermines the ability of conversations to reach a broader
consensus, no matter what I do locally.

And honestly, I think that’s one of the biggest problems affecting LLVM
right now: we have no good consensus mechanism as a community to change
LLVM IR.  We have RFC threads, and then we have “make a presentation at
at an LLVM Developer’s Conference, probably the US one, and then convene
a roundtable to try to get people on board with your plan.”  As a result,
I think there’s a lot of reluctance to change IR when, honestly, IR
is supposed to be an evolving tool that needs to change in order to
solve problems better.  I’m not saying that the mailing list is the sole
cause of this problem, but I do think it contributes.


Secondly, what structure does exist for mailing lists is not good
for technical conversations.  The deep problem is the tree structure
of threads, which is mathematically pleasing but manifestly leads to
worse results.  Different forks of the thread end up repeating the
same arguments because people don’t see that that conversation has
already happened — or worse, different forks *don’t* repeat the same
arguments because the people involved in them aren’t aware of the rest
of the thread.  I’ve seen so many threads where different branches
continued on to reach completely different conclusions, or where
one contributor jumps from one branch to another, leaving the people
who were only engaged in the old branch thinking that the thread has
come to a resolution.  Again, it undermines the process of reaching
a consensus.

Now, again, some mail clients help to solve this problem.  Usually you
don’t want to abandon a threaded view entirely, but some clients support
a flat-threaded view where new posts simply appear sequentially.
But, again, you can’t count on other people reading the thread that
way, and that makes a big difference.  If you want to build a consensus,
you probably need to reply to everyone individually, in case they’re
not reading the rest of the thread.  And you can’t assume that people
reading your reply to one part of the thread will have read some post
in a different part.


Finally, there are a ton of minor technical/usability annoyances with
email that I think people too often neglect:

- Reference headers seem to get regularly messed up, and any
  sizable conversation inevitably ends up with not just multiple
  forks within a thread, but actually multiple threads that happen
  to share a subject line.

- Email is immutable, so problems like that can’t be retroactively
  fixed.  Along the same lines, people can’t go back to edit their
  posts to fix typos or technical errors, or to tone them down if
  they realize they got a little too heated.

- Long-running threads would often benefit from someone maintaining
  an index of important posts, but that’s not something you can do
  in email, because you can’t insert posts at the top of a thread
  or keep those posts current.

- You can’t split a thread in email without completely losing
  context.  For example, if you realize that the last five posts
  are really the start of a new conversation that ought to be in
  its own thread, you can’t just move those posts to a new thread,
  you actually have to start a new thread and copy-and-paste the
  old emails in and hope that nobody continues to reply in the old
  place.

- If you try to explicitly CC people into a thread, and you use
  the wrong email address, you’ll actually contaminate the thread
  with that wrong email address, so that everybody who replies to
  you will also send email to the wrong email address, and you
  can’t rely on anyone else you CC’ed having actually gotten the
  email.

Now, forums have their own usability annoyances, without question.
I’ve been using Discourse fairly heavily for about three years (over
at forums.swift.org), and I’ve got my share of complaints.  My
point is that those problems should not be treated as blockers
when we have equal or worse problems with mailing lists that we’ve
just come to accept.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210616/025339a5/attachment.html>