[llvm-dev] LLVM Discourse migration: goals justify means?

[Johannes Doerfert via llvm-dev]

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