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

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