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

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>

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>