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

Tanya Lattner via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 27 09:10:08 PST 2022



> On Jan 27, 2022, at 7:24 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> 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.

Paul,

I have spent a great deal of time researching how nonprofits are structured and I am well versed in the different ways. There are many open source nonprofits that are member based and many that are not. Many that are member based are actually 501c6 which is very different. One way is not the best way for all. Given the role of this board, we felt that this was the best approach. 

I have also answered questions about the board election process and we have tried to make the process as transparent as we can but also maintaining confidentiality of those who applied but did not get selected (we could change that). If you have further questions or clarifications, please let me know. 

Thanks,
Tanya


> 
> --paulr
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



More information about the llvm-dev mailing list