<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 3 Jun 2021, at 18:19, James Y Knight via llvm-dev wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #3983C4; color:#3983C4; margin:0 0 5px; padding-left:5px"><p dir="auto">I've just tried out discourse for the first time. It is not clear to me how<br>
to use it to replace mailing lists. It has a setting "mailing list mode",<br>
which sounds like the right thing -- sending all messages via email. Except<br>
that option is global -- all messages in all categories on the llvm<br>
discourse instance. Which definitely isn't what I want at all. I don't want<br>
to subscribe to MLIR, for example.<br>
<br>
In general, I'd say I'm pretty uncomfortable with switching from a mailing<br>
list to discourse. Discourse seems entirely reasonable to use for<br>
end-user-facing forums, but I'm rather unconvinced about its suitability as<br>
a dev-list replacement. Other communities (e.g. python) seem to have a<br>
split, still: mailing lists for dev-lists, and discourse for<br>
end-user-facing forums.<br>
<br>
I'd also note that Mailman3 provides a lot more features than what we're<br>
used to with mailman2, including the ability to interact/post through the<br>
website.<br>
<br>
Maybe someone can convince me that I'm just being a curmudgeon, but at this<br>
point, I'd say we ought to be investigating options to have Someone Else<br>
manage the mailman service, and keep using mailing lists, rather than<br>
attempting to switch to discourse.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I think that mailing lists have proven repeatedly that they’re actually<br>
very bad for the sort of technical conversations we want to have in the<br>
community. It’s possible to put a lot of work into your mailing-list<br>
experience and end up with something that half-solves some of these<br>
problems, but it takes a lot of time and expertise, and you’re left with<br>
something that still suffers the inherent flaws of email.</p>
<p dir="auto">Let me try to explain why, using the ongoing byte-type RFC as a focusing<br>
example.</p>
<p dir="auto">First off, this is an important conversation that ought to be of interest<br>
to a large number of LLVM developers. Monitoring a high-traffic mailing<br>
list takes a lot of time; I would say that most LLVM developers don’t<br>
proactively keep up with llvm-dev. I only became aware of this<br>
conversation because someone thought to explicitly CC me into it. There<br>
are almost certainly some people who ought to be engaged in this<br>
thread who still aren’t aware of it.</p>
<p dir="auto">A major part of why that’s the case is that mailing lists lack structure<br>
beyond the Reference structure of threads. There is no inherent<br>
categorization or tagging in a mailing list; by default, readers see a<br>
jumble of every single thread. And people are often reluctant to split<br>
mailing lists by topic, and when they do sometimes conversations get<br>
unnaturally divided, or something that should be of broader interest<br>
gets unnecessarily pigeon-holed. So if I want to find things that are<br>
interesting to me, I have to look at every single active thread to see<br>
what’s going on.</p>
<p dir="auto">Now, in some cases, I can have that done automatically for me. I could,<br>
for example, set up a filter that puts all the RFC threads in a<br>
high-priority mailbox that I can scan more frequently. But that has<br>
two problems. First, not every generally-important thread is marked<br>
as an RFC; notably, this thread isn’t. If I set up this filter, I’d<br>
probably be a lot less likely to read the mail mailbox for the list,<br>
and so I’d probably miss most of these threads. And second, I can do<br>
that for myself, but I can’t make other people do it. There are people<br>
who aren’t reading and contributing to important threads because they<br>
aren’t aware of them. The lack of structure creates a firehose effect<br>
that undermines the ability of conversations to reach a broader<br>
consensus, no matter what I do locally.</p>
<p dir="auto">And honestly, I think that’s one of the biggest problems affecting LLVM<br>
right now: we have no good consensus mechanism as a community to change<br>
LLVM IR. We have RFC threads, and then we have “make a presentation at<br>
at an LLVM Developer’s Conference, probably the US one, and then convene<br>
a roundtable to try to get people on board with your plan.” As a result,<br>
I think there’s a lot of reluctance to change IR when, honestly, IR<br>
is supposed to be an evolving tool that needs to change in order to<br>
solve problems better. I’m not saying that the mailing list is the sole<br>
cause of this problem, but I do think it contributes.</p>
<p dir="auto">Secondly, what structure does exist for mailing lists is not good<br>
for technical conversations. The deep problem is the tree structure<br>
of threads, which is mathematically pleasing but manifestly leads to<br>
worse results. Different forks of the thread end up repeating the<br>
same arguments because people don’t see that that conversation has<br>
already happened — or worse, different forks <em>don’t</em> repeat the same<br>
arguments because the people involved in them aren’t aware of the rest<br>
of the thread. I’ve seen so many threads where different branches<br>
continued on to reach completely different conclusions, or where<br>
one contributor jumps from one branch to another, leaving the people<br>
who were only engaged in the old branch thinking that the thread has<br>
come to a resolution. Again, it undermines the process of reaching<br>
a consensus.</p>
<p dir="auto">Now, again, some mail clients help to solve this problem. Usually you<br>
don’t want to abandon a threaded view entirely, but some clients support<br>
a flat-threaded view where new posts simply appear sequentially.<br>
But, again, you can’t count on other people reading the thread that<br>
way, and that makes a big difference. If you want to build a consensus,<br>
you probably need to reply to everyone individually, in case they’re<br>
not reading the rest of the thread. And you can’t assume that people<br>
reading your reply to one part of the thread will have read some post<br>
in a different part.</p>
<p dir="auto">Finally, there are a ton of minor technical/usability annoyances with<br>
email that I think people too often neglect:</p>
<ul>
<li><p dir="auto">Reference headers seem to get regularly messed up, and any<br>
sizable conversation inevitably ends up with not just multiple<br>
forks within a thread, but actually multiple threads that happen<br>
to share a subject line.</p></li>
<li><p dir="auto">Email is immutable, so problems like that can’t be retroactively<br>
fixed. Along the same lines, people can’t go back to edit their<br>
posts to fix typos or technical errors, or to tone them down if<br>
they realize they got a little too heated.</p></li>
<li><p dir="auto">Long-running threads would often benefit from someone maintaining<br>
an index of important posts, but that’s not something you can do<br>
in email, because you can’t insert posts at the top of a thread<br>
or keep those posts current.</p></li>
<li><p dir="auto">You can’t split a thread in email without completely losing<br>
context. For example, if you realize that the last five posts<br>
are really the start of a new conversation that ought to be in<br>
its own thread, you can’t just move those posts to a new thread,<br>
you actually have to start a new thread and copy-and-paste the<br>
old emails in and hope that nobody continues to reply in the old<br>
place.</p></li>
<li><p dir="auto">If you try to explicitly CC people into a thread, and you use<br>
the wrong email address, you’ll actually contaminate the thread<br>
with that wrong email address, so that everybody who replies to<br>
you will also send email to the wrong email address, and you<br>
can’t rely on anyone else you CC’ed having actually gotten the<br>
email.</p></li>
</ul>
<p dir="auto">Now, forums have their own usability annoyances, without question.<br>
I’ve been using Discourse fairly heavily for about three years (over<br>
at forums.swift.org), and I’ve got my share of complaints. My<br>
point is that those problems should not be treated as blockers<br>
when we have equal or worse problems with mailing lists that we’ve<br>
just come to accept.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>