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

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>

On Tue, 29 Jun 2021 at 18:55, Mehdi AMINI <joker.eph at gmail.com> wrote:
> I read the original proposal in this thread as a move. The llvm-dev@
> mailing-list would not exist anymore.
>
Right, but that still doesn't fix the problem that many people, some of
them long term contributors, may choose not to participate at all if that
happens.

It would just be another type of fragmentation.

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 have no idea how mailman works but I did use well setup mailmain
instances that had hundreds of mailing lists, cross posts, sub-lists and so
on, as early as as late 90s and as late as 2016.

The few times I tried to set that up myself I had nightmares for weeks, so
not going to even search for that on the net. :)

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

But what we want to model is highly driven by the tools we know how to use,
so it's no surprise that people who use tools A think it does a better job
at feature x, just because that's what it has. Tool B doesn't even know
what x means, so how people that use it can understand?

That was my point about preference, not that "some people like A others
like B", but that "people who use x with A can't see how B can
work if it
doesn't provide x (but does provide y)".

That's what I've seen in this thread: people talking past each other
because they're talking about similar concepts but implemented in different
ways.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210629/c1afde31/attachment-0001.html>