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

[Renato Golin via llvm-dev]

On Tue, 29 Jun 2021 at 17:47, Mehdi AMINI <joker.eph at gmail.com> wrote:

> To me the fracturing on the IRC side is that we didn't just close the IRC
> channel and move over the IRC. The fragmentation came from the non-decision
> that led to Discord and IRC co-existing: I don't see immediately how
> migrating the llvm-dev@ to the Discourse forums would repeat this.
>

Exactly, is the proposal a move or an addition?
 * If the proposal is to move, this will "solve" the fragmentation problem
(there's only one) but would create a massive alienation problem (enough
people in the community would be really angry).
 * If the proposal is to add a new one, then we'll have the same problem as
IRC vs. Discord and fragment the community, which would continue working on
their own, but disconnected.

On the topic of "fragmentation", I would argue that is to me a great
> advantage to these new tools instead: the mailing list aren't as easily
> discoverable, and they live on their own isolated "islands" (Just like it
> would be on IRC if we had all these different IRC channels).
>

I don't think there's any feature in the new tools that would "fix"
fragmentation because enough people in the list would just not use it,
however wonderful it is to some people.

Discord/Discourse moves the paradigm from separate IRC channels/mailing
> lists to a single "instance" where topics fit into categories: this
> provides a unified view of all the llvm-project. At the moment any time
> there is a mailing-list cross-post, I get bounced because I'm not
> subscribed to OpenMP, LLDB, ... mailing-lists. Similarly, poking at what's
> happening in one of these other mailing lists requires navigating the
> online list archive, which has quite an impedance mismatch with the
> expected way of interacting with the list (email...). I also can't answer a
> topic on the CFE mailing-list that I would see in the archive if I wasn't
> subscribed to the list in the first place, so in practice I'm unlikely to
> participate in these projects occasionally. You would think that email
> makes it easy to CC me on an existing thread, but not being subscribed, I
> still can't participate in the mailing-list thread.
> This is all another angle on the existing "fragmentation" in the community
> created by the tools (IRC and mailing-list) that aren't designed for
> managing what we have: a community composed of many subcommunities.
>

I challenge this. Not because I love mailman (I really don't), but because
mailman has a lot of features for sub-communities for decades.

I'm not saying it's easy to setup or intuitive to users who had no contact
with mailing lists before, but they exist and other communities use them.

I've seen enough back and forth in all the threads on this subject to
realise the "impedance mismatch" is more of a generational thing (people
who dig new tooling vs. people who find it hard to change their ways), than
it is a technical thing.

Finally, one last advantage of Discourse/Discord over mailing-lists/IRC is
> the "agility" through evolution: it is trivial to add or reorganize
> categories in face of a change in the community or sub-projects. Any new
> category is directly integrated in the platform and immediately visible (I
> discovered new channels on Discord over the last year as they got added, I
> could easily skim through them and participate as needed, get pinged on
> some specific topics, etc.). theu are suitable to manage the entire
> llvm-project community instead of the existing silos.
>

I'm not an expert in mailman but I believe this can be done, too, with
mailing lists. There a lot of options for sub-lists, aggregation lists,
cloning settings that can be done to make that work.

Even the fact that llvm-dev@ is the place to organize the entire project is
> still a historical artifact that mixes the llvm core development with the
> plurality of the projects.
>

Absolutely, but that says more about our ability to manage mailman (and
other infra) than our desire to have organised communications channels.
We're compiler engineers after all.

So, this is not about which tool is better, but how to we optimise
communication. And whatever the real answer ends up being, replacing one
tool with another definitely isn't it.

For context, I was born with a brain that doesn't adapt well to
environmental changes, especially if they're not central to what I do.
Communication is affected the most.

After more than a decade working with LLVM, I've come to know enough people
like me in our community that a change in the communication style would be
considered radical.

Some of them are already gone because of similar past changes, and I think
some people were happy to see them go because of that impedance mismatch.
"They don't think like I do, so they're better gone".

So, while I welcome new participants to the project, I'd really like to not
have to choose between them and the people I know can still deliver radical
changes to the project and have done so repeatedly.

My proposal: instead of discussing which tool is "better", why not discuss
how can we move to a new tool without breaking the communication model that
people (like me) would find too radical to change?

If the tool you propose can't do that, let's find a new tool. Let's work
with that tool to improve it. Let's do something.

Anton K. is doing a remarkable and thankless job at trying to get a better
git repo and issue tracker, despite ferocious impediments. His aim is to
keep the status quo as much as possible while moving on to better tools. It
takes a long time.

I think we should follow his lead in this discussion, and try not to force
people to pick sides. THAT is what creates fragmentation.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210629/ed360954/attachment.html>