llvm dev - Jan 2022 - LLVM Discourse migration: goals justify means?

On 27/01/2022 00:47, Philip Reames via llvm-dev wrote:
> I want to chime in to say that Roman is definitely not alone in his 
> impressions here.  I have previously shared my objections to the 
> original proposal, and will not repeat myself.
> 
> I don't have the energy to engage in this discussion, and have already 
> decided to put up with this and deal with the fallout. Given that, 
> please do not expect further response from me on this topic.
I would like to make sure that we separate the two issues here:

  - The decision to move to Discourse.
  - The way in which decisions are made for the project.

There are a lot of problems with LLVM mailing lists.  People don't know 
which lists to post things on, things are cross-posted to cfe-dev and 
llvm-dev (for example) but not all replies go to both, which makes 
following discussions difficult because they essentially end up in two 
forks.  Some things only go to llvm-dev, so you have to subscribe to the 
fire hose and try to skip the 90% of messages that are likely to be 
irrelevant to you.

Given how low the bar is for the starting point, Discourse seems like it 
is definitely a less bad solution.  I'm even willing to accept that it 
is the least-bad solution currently available.

That said, I completely agree with the comments by Roman, Philip, and 
Renato in this thread.  This is not the first decision where my 
perception of the consensus of the broader LLVM community and the 
consensus of the folks that turn up to Silicon Valley socials have been 
in opposite directions and the group in the valley's decision has been 
pushed through with everyone else then having to live with the fallout.

There is a significant need for a more transparent decision process that 
reflects all stakeholders on multiple axes:

  - Industrial, academic, or individual contributors.
  - Contributors to core LLVM libraries, to tightly coupled components 
and to largely independent projects.
  - Direct LLVM contributors and downstream consumers.
  - Groups shipping a complete LLVM toolchain and those shipping some 
LLVM components.

The LLVM Foundation board is heavily skewed in most of these axes and, 
as a self-selecting entity, is not likely to address this without an 
intentional policy of doing so and without a broader effort to 
explicitly engage with the segments of the LLVM community that are not 
directly represented.

David

> I would like to make sure that we separate the two issues here:
> 
>   - The decision to move to Discourse.
>   - The way in which decisions are made for the project.
> 
> There are a lot of problems with LLVM mailing lists.  People don't know
> which lists to post things on, things are cross-posted to cfe-dev and
> llvm-dev (for example) but not all replies go to both, which makes
> following discussions difficult because they essentially end up in two
> forks.  Some things only go to llvm-dev, so you have to subscribe to the
> fire hose and try to skip the 90% of messages that are likely to be
> irrelevant to you.
> 
> Given how low the bar is for the starting point, Discourse seems like it
> is definitely a less bad solution.  I'm even willing to accept that it
> is the least-bad solution currently available.
About Discourse itself:

Given the number of people who seem to have opted for email notification,
and that we're bumping up against some limit imposed by the provider,
it's clear that email has advantages over a forum.  I've been dutifully
trying to engage with Discourse through the web UI, and it has serious
drawbacks compared to a mail client, for people who are mostly reading
it and not posting a lot.  For example:
- AFAICT the only way to mark a post read, is to read it. With a mail
  client, I can mark it read, or just delete it from the mail folder.
  Having to read a post takes extra time; Discourse doesn't think you've
  read a post unless you spend enough time with it visible in your browser.
- My mail client shows many threads in a small amount of screen real estate.
  Discourse gives each thread a relatively huge amount of space, which
  again reduces the efficiency of looking at What's New Today.
- Reading a topic/post and then going back to the list of unread stuff is
  not particularly efficient; page loading feels slower than with gmail,
  for example. There are other poor choices that are harder to describe.
- I'm never 100% sure that I've actually seen everything new in the web
UI;
  Discourse seems to distinguish an unread new topic from an unread post,
  presenting them separately, which just feels weird and counter-intuitive.

All this means the time I spend on Discourse is *higher* than what I spent
reading the dev lists.

I do agree with David Chisnall's remark about cross-posting, which the
unified Discourse eliminates; arguably posts might still align with
multiple categories, but many categories are no longer artificially 
constrained to 'llvm-dev' or 'cfe-dev' so I think that the
situation
there has improved overall.

Clearly, the most effective way to handle reading all the traffic is
- mute the categories you're pretty sure you'll never care about
- set up email notifications
- go back to reading the traffic efficiently in the email client.
And at least you can be sure you've been notified about everything,
rather than hoping you found everything in the web UI.

> That said, I completely agree with the comments by Roman, Philip, and
> Renato in this thread.  This is not the first decision where my
> perception of the consensus of the broader LLVM community and the
> consensus of the folks that turn up to Silicon Valley socials have been
> in opposite directions and the group in the valley's decision has been
> pushed through with everyone else then having to live with the fallout.
Regarding the decision-making process:

I think it's not really fair to chalk it up to "the consensus of the 
folks that turn up to Silicon Valley socials."  Early on they were small
convivial affairs, but the last few I went to were mob scenes full of
people only vaguely associated with LLVM, drawn by the prospect of free
food and drink.  And of course there haven't been any at all, since the
start of the pandemic.

That said, I don't doubt that there's a relatively small circle of folks
centered around the board membership who talk to each other a lot and
come to their own perception of the consensus.  This is a pretty natural
process, I'm sure well understood in psychology/sociology, and it takes
genuine, conscious and persistent effort to overcome it.  Having the 
good of the community at heart is not enough.
> There is a significant need for a more transparent decision process that
> reflects all stakeholders on multiple axes:
> 
>   - Industrial, academic, or individual contributors.
>   - Contributors to core LLVM libraries, to tightly coupled components
> and to largely independent projects.
>   - Direct LLVM contributors and downstream consumers.
>   - Groups shipping a complete LLVM toolchain and those shipping some
> LLVM components.
> 
> The LLVM Foundation board is heavily skewed in most of these axes and,
> as a self-selecting entity, is not likely to address this without an
> intentional policy of doing so and without a broader effort to
> explicitly engage with the segments of the LLVM community that are not
> directly represented.
Hear, hear.  This has been my chief problem with the board ever since
the Foundation asserted itself into existence.  The board's selection
process is not transparent, and the board is probably too small to
adequately represent all the diverse stakeholder axes that you've
described.  There's a structural deficiency, here.  There is plenty
of research into nonprofit and open-source governance structures, and
the Foundation would benefit from taking a hard look at it.

--paulr

On 1/27/22 04:46, David Chisnall via llvm-dev wrote:
> On 27/01/2022 00:47, Philip Reames via llvm-dev wrote:
>> I want to chime in to say that Roman is definitely not alone in his 
>> impressions here.  I have previously shared my objections to the 
>> original proposal, and will not repeat myself.
>>
>> I don't have the energy to engage in this discussion, and have 
>> already decided to put up with this and deal with the fallout. Given 
>> that, please do not expect further response from me on this topic.
>
> I would like to make sure that we separate the two issues here:
>
>  - The decision to move to Discourse.
>  - The way in which decisions are made for the project.
>
> There are a lot of problems with LLVM mailing lists.  People don't 
> know which lists to post things on, things are cross-posted to cfe-dev 
> and llvm-dev (for example) but not all replies go to both, which makes 
> following discussions difficult because they essentially end up in two 
> forks.  Some things only go to llvm-dev, so you have to subscribe to 
> the fire hose and try to skip the 90% of messages that are likely to 
> be irrelevant to you.
>
> Given how low the bar is for the starting point, Discourse seems like 
> it is definitely a less bad solution.  I'm even willing to accept that 
> it is the least-bad solution currently available.
>
I don't get this point. On the one hand you seem to say things get lost 
(e.g., answers) as people pick a list from the (limited number of) 
options, on the other hand you argue the trees are hidden in the woods, 
is that a reasonable summary?

With discourse you have two choices, neither of which solves both 
problems you bring up. IMHO, the choices make one of the problems worse:
  A) I have to use mailing list mode (somewhat equivalent to watching 
20+ categories and sub-categories) to find the things I want to see for 
sure. We are back to the fire hose, email filters, and skipping things, 
except that we now have 1 mailing list rather than 10. (Arguably, we 
could have merged llvm-dev and cfe-dev to avoid cross posting as well.)
  B) I only watch my categories, sub-categories, and tags and miss out 
on everything relevant not posted in there. While there might not be 
cross posting, we should reasonably assume that 10 people posting about 
the same topic will not all choose the same categories, sub-categories, 
and tags if there is any overlap between them. As an example, "How to 
offload to AMD GPUs with OpenMP" is either a beginner question, an 
OpenMP one, or an AMDGPU one, not to mention it might end up in the 
generic category or any other one if the message also asks about 
optimizing the code, e.g., with MLIR.

I agree with the rest below though.

~ Johannes

> That said, I completely agree with the comments by Roman, Philip, and 
> Renato in this thread.  This is not the first decision where my 
> perception of the consensus of the broader LLVM community and the 
> consensus of the folks that turn up to Silicon Valley socials have 
> been in opposite directions and the group in the valley's decision has 
> been pushed through with everyone else then having to live with the 
> fallout.
>
> There is a significant need for a more transparent decision process 
> that reflects all stakeholders on multiple axes:
>
>  - Industrial, academic, or individual contributors.
>  - Contributors to core LLVM libraries, to tightly coupled components 
> and to largely independent projects.
>  - Direct LLVM contributors and downstream consumers.
>  - Groups shipping a complete LLVM toolchain and those shipping some 
> LLVM components.
>
> The LLVM Foundation board is heavily skewed in most of these axes and, 
> as a self-selecting entity, is not likely to address this without an 
> intentional policy of doing so and without a broader effort to 
> explicitly engage with the segments of the LLVM community that are not 
> directly represented.
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev