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

[Mehdi AMINI via llvm-dev]

On Tue, Jun 29, 2021 at 10:19 AM Renato Golin <rengolin at gmail.com> wrote:

> 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?
>

I read the original proposal in this thread as a move. The llvm-dev@
mailing-list would not exist anymore.


>  * 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.
>

Maybe, I'm not an expert. I just observe that these "decades" of experience
haven't panned out to a good experience for our needs. It may be just a
matter of setting up these features though, I'd be happy to read about this
if you have pointers.


>
> 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.
>

No, not here: I was mentioning an impedance mismatch between what you can
model with the tool and the actual reality of what needs to be modeled.
To clarify: you can talk about impedance mismatch on a personal level
between how a tool works and your preference, but that's different from my
point here.


>
> 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/d7edadd3/attachment.html>