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.