Mailing List Status Update

LLVM Project
1

Hi,

We recently[1] ran into some issues with the mailing lists that caused
us to disable automatic approval of subscriptions. Over the past few
months, the LLVM Foundation Board of Directors have been investigating
solutions to this issue and are recommending that the project move its
discussion forum from mailman to Discourse[2].

The proposed migration plan is to move the discussion lists (e.g *-dev,
*-users lists) to Discourse as soon as possible. The commit email lists
(*-commits lists) will remain on mailman until a not-yet-determined date
in the future, after which they will be replaced by something else.
Some commit lists alternatives include Discourse and GitHub commit
comments (but there may be others).

Here are the reasons why the LLVM Foundation Board of Directors is
recommending this change:

- The LLVM project discussion lists cannot be adequately maintained by our
   current volunteer infrastructure staff and without changes we run the
   risk of a major outage.

- We are able to make this change without significant impact to user's or
   developer's daily workflows because Discourse supports email subscriptions
   and posting (NOTE: if you are concerned that your workflow may be impacted
   by this change, please contact the Infrastructure Working Group[3], so
   they can help test your workflow with Discourse.)

- Discourse gives us additional features that will benefit the community:
   - Easy to signup and subscribe to categories
   - Better moderation tools.
   - Web-based user interface.
   - Ability to send announcements to multiple categories to avoid having to
     cross-post community wide announcements.

- A subset of the community (MLIR) have been experimenting with Discourse
   for over a year and are able to provide feedback about this experience
   to the Board of Directors.

We did also consider one alternative, which was migrating our lists to a
mailman hosting service. However, we concluded that with all the work it
would take to migrate our lists to another service, it would be better
if we moved to a service (like Discourse) that provided more features
than what we have now.

We understand that moving to Discourse is a change for the community and
that people may be worried about this having a negative impact on their
participation in the project. As mentioned above, we believe that this
change can be done without significant impact to anyone’s workflows.
If you disagree, please contact the Infrastructure Working Group, to
document the impact to your workflow, so we can work together to find
a solution for your issue.

If you have any other questions or comments you can raise them on this
thread and please keep criticisms constructive and on topic.

LLVM Foundation Board of Directors

[1] [llvm-dev] IMPORTANT NOTICE - Subscription to Mailman lists disabled immediately
[2] https://www.discourse.org/
[3] https://github.com/llvm/llvm-iwg

2

Did you consider creating a simple webform that would allow one to subscribe to the mailing lists instead?
It can be either simply put behind a proxy like Cloudflare (free) to filter out bots. Or, if not sufficient, authenticate the person using openid/github/google/whatever, like phabricator does. These things are fairly simple to implement these days.

Thanks,
Nuno

3

Hi,
Nice idea. Will make talks realtime. Not sure it supports commit and review over email. Consider having introduce yourself channel etc. Consider whether run it on THEIR or YOUR servers. There is some competition etc. I mite lookup some projects: zulip comes to mind.

Best regards,
Pawel

wt., 1.06.2021, 22:51 użytkownik Tom Stellard via llvm-dev <llvm-dev@lists.llvm.org> napisał:

4

Hi Tom,

5

I’ve just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting “mailing list mode”, which sounds like the right thing – sending all messages via email. Except that option is global – all messages in all categories on the llvm discourse instance. Which definitely isn’t what I want at all. I don’t want to subscribe to MLIR, for example.

In general, I’d say I’m pretty uncomfortable with switching from a mailing list to discourse. Discourse seems entirely reasonable to use for end-user-facing forums, but I’m rather unconvinced about its suitability as a dev-list replacement. Other communities (e.g. python) seem to have a split, still: mailing lists for dev-lists, and discourse for end-user-facing forums.

I’d also note that Mailman3 provides a lot more features than what we’re used to with mailman2, including the ability to interact/post through the website.

Maybe someone can convince me that I’m just being a curmudgeon, but at this point, I’d say we ought to be investigating options to have Someone Else manage the mailman service, and keep using mailing lists, rather than attempting to switch to discourse.

6

I’ve just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting “mailing list mode”, which sounds like the right thing – sending all messages via email. Except that option is global – all messages in all categories on the llvm discourse instance. Which definitely isn’t what I want at all. I don’t want to subscribe to MLIR, for example.

I don’t use the “mailing list mode” personally, but it has a little note under it that “Muted topics and categories are not included in these emails”. I think you could mute everything you aren’t interested in (e.g. MLIR) and still get emails for the things you are.

– River

7

I've just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting "mailing list mode", which sounds like the right thing -- sending all messages via email. Except that option is global -- all messages in all categories on the llvm discourse instance. Which definitely isn't what I want at all. I don't want to subscribe to MLIR, for example.

In general, I'd say I'm pretty uncomfortable with switching from a mailing list to discourse. Discourse seems entirely reasonable to use for end-user-facing forums, but I'm rather unconvinced about its suitability as a dev-list replacement. Other communities (e.g. python) seem to have a split, still: mailing lists for dev-lists, and discourse for end-user-facing forums.

I'd also note that Mailman3 provides a lot more features than what we're used to with mailman2, including the ability to interact/post through the website.

Maybe someone can convince me that I'm just being a curmudgeon, but at this point, I'd say we ought to be investigating options to have Someone Else manage the mailman service, and keep using mailing lists, rather than attempting to switch to discourse.

+1 to this. I've tried discourse in the past and not found it to be a
palatable replacement for mailing lists. Some of that is certainly
inertia (I've been using mailing lists for a *long time*) that I could
work to overcome, but my preference is to continue with mailing lists.

~Aaron

8

Hi Tom,

Over the past few
months, the LLVM Foundation Board of Directors have been investigating
solutions to this issue and are recommending that the project move its
discussion forum from mailman to Discourse[2].

Will this be a self-hosted Discourse instance, or one hosted by CDCK? I don't have particularly strong opinions either way: the CDCK privacy policy looks pretty sane (it's a shame opting out of Google Analytics requires a browser extension, which is presumably not an option in their mobile apps, but aside from that it looks fine after a quick skim).

It wouldn't be self-hosted.

-Tom

9

Can you elaborate why or what aspect makes it unsuitable? We’ve been using this exclusively without a “dev list” for MLIR and it is working perfectly well as far as I can tell. I believe Swift does the same thing as well.

Thanks,

10

I’ve just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting “mailing list mode”, which sounds like the right thing – sending all messages via email. Except that option is global – all messages in all categories on the llvm discourse instance. Which definitely isn’t what I want at all. I don’t want to subscribe to MLIR, for example.

In general, I’d say I’m pretty uncomfortable with switching from a mailing list to discourse. Discourse seems entirely reasonable to use for end-user-facing forums, but I’m rather unconvinced about its suitability as a dev-list replacement.

Can you elaborate why or what aspect makes it unsuitable? We’ve been using this exclusively without a “dev list” for MLIR and it is working perfectly well as far as I can tell. I believe Swift does the same thing as well.

My first concern is that it does not appear to be actually usable via email in the same way the existing collection of mailing lists is. I wonder if these others primarily interact with it through the website, rather than via email? It certainly seems like a reasonable web forum, even if not a reasonable mailing list service.

I have not used discourse enough to really have a firm opinion on whether (or why) it would be a bad idea to switch from an email workflow to a webforum workflow using the discourse website. Possibly that could be OK (although, at this point, unconvinced), but it would be a major change in workflow, and is not what the original pitch was.

11

I have concerns about this proposal. Those concerns aren’t necessarily unaddressable, but I do want to share them. My concerns fall into two broad categories.

The first category is the process one. My understanding when the LLVM foundation was established was that the role of the foundation and the board was to support the community, not to make major decisions for the community. I understand there is a degree of pragmatism we have to accept - e.g. sometimes the situation forces our hand, and we need to act, even if in a sub-optimal way - but this runs dangerously close to the edge of the board dictating the solution to the community. I do want to acknowledge that I truly do thing everyone on the board is acting in good faith here. I’m not so much worried about the intentions of anyone involved so much as the appearance and precedent this sets.

The second category is the proposed migration itself. I’ll start by saying that the restriction in the proposal text to the *-dev lists (explicitly excluding the *commits lists) does soften my concerns substantially, but I’m left wondering about the long term plan for the commit lists. As has come up in recent threads around phabricator, I feel the commit lists play a critical role in our development practice and, almost more importantly, culture which is hard to replicate. I’m a bit worried that this proposal if accepted will be the camel getting his nose under the tent as it were.

Specific to the dev lists, I’m very hesitant about moving from mailing lists to discourse. Why?

Well, the first and most basic is I’m worried about having core infrastructure out of our own control. For all their problems, mailing lists are widely supported, there are many vendors/contractors available. For discourse, as far as I can tell, there’s one vendor. It’s very much a take it or leave it situation. The ability to preserve discussion archives through a transition away from discourse someday concerns me. I regularly and routinely need to dig back through llvm-dev threads which are years old. I’ve also recently had some severely negative customer experiences with other tools (most recently discord), and the thought of having my employability and ability to contribute to open source tied to my ability to get a response from customer service teams at some third party vendor I have no leverage with, bluntly, scares me.

Second, I feel that we’ve overstated the difficulty of maintaining mailing lists. I have to acknowledge that I have little first hand experience administering mailman, so maybe I’m way off here. However, there are multiple commercial vendors which provide mailman hosting. TBH, this seems like a case where the foundation should simply pay for commercial hosting and migration support to mailman3. It may be this is a lot more expensive in practice than I’m imagining, but this feels like it should be our default answer and that anything else (i.e. discourse) should require major evidence of benefit over that default to be considered.

Third, I’m worried that there are culture elements very tied up in our current usage of the mailing lists. As some specific examples, consider each of the following:

  • Discourse does not allow private responses via email. You have to use their web interface. I spent a lot of time replying privately to other contributors. I’m worried that, in practice, the extra step will cause me to follow up less, and miss even more responses. I’m particularly concerned about the impact for new contributors. (Existing contributors, I probably have an email address for already.)
  • Discourses does not allow cross posts (or at least, it’s not clear how to do so). At least a couple times a year, we have design discussions which cross between sub-projects. This can be addressed with a process change, but it needs some discussion before the migration happens.

It’s not that we can’t adjust our processes to the limitations of discourse; we clearly can. My concern is all of the subtle things we loose along the way.

Now that I’ve finished up, let me explicitly state that I don’t intend my comments here to be blocking. I don’t think this is a good idea, or at least needs further expansion before acceptance, but I’m also not in place where I can really invest in providing a realistic alternative. At the end of the day, pragmatism does require that we give discretion to the folks actually investing their own time, and energy to keep the community running.

Philip

12

I’ve just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting “mailing list mode”, which sounds like the right thing – sending all messages via email. Except that option is global – all messages in all categories on the llvm discourse instance. Which definitely isn’t what I want at all. I don’t want to subscribe to MLIR, for example.

FWIW, it would seem that one secret trick here is to NOT check “mailing list mode” – that option is mostly there to confuse you, I guess.

In general, I’d say I’m pretty uncomfortable with switching from a mailing list to discourse. Discourse seems entirely reasonable to use for end-user-facing forums, but I’m rather unconvinced about its suitability as a dev-list replacement. Other communities (e.g. python) seem to have a split, still: mailing lists for dev-lists, and discourse for end-user-facing forums.

I’d also note that Mailman3 provides a lot more features than what we’re used to with mailman2, including the ability to interact/post through the website.

Maybe someone can convince me that I’m just being a curmudgeon, but at this point, I’d say we ought to be investigating options to have Someone Else manage the mailman service, and keep using mailing lists, rather than attempting to switch to discourse.

On that last point, I’ve gone ahead and asked the folks at osci.io (“Open Source Community Infrastructure”) if they’d be willing to host our mailing lists. They are a group at RedHat whose mission is to support infrastructure for open-source community projects, and they host mailman3 lists for a number of other open-source groups, already (https://www.osci.io/tenants/). So, I believe they have the necessary experience and expertise.

They have said they indeed are willing and have the capacity to run this for us as a service, if we’d like. We’d still need to be responsible for things like list moderation, but they’d run the mailman installation on their infrastructure. In my opinion, we ought to take this option, rather than trying to push a migration to discourse.

To me, it seems this would be a much clearer upgrade path, and would solve the hosting/volunteer-admin issue – including for commit lists – giving the current maintainers quicker relief from the undesired task of running the list service. Additionally, since it would be a migration to Mailman3, we would get many of the additional features mentioned as desirable, e.g. searchable archives and posting from the website.

13

I've just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting "mailing list mode", which sounds like the right thing -- sending all messages via email. Except that option is global -- all messages in all categories on the llvm discourse instance. Which definitely isn't what I want at all. I don't want to subscribe to MLIR, for example.

FWIW, it would seem that one secret trick here is to NOT check "mailing list mode" -- that option is mostly there to confuse you, I guess.

In general, I'd say I'm pretty uncomfortable with switching from a mailing list to discourse. Discourse seems entirely reasonable to use for end-user-facing forums, but I'm rather unconvinced about its suitability as a dev-list replacement. Other communities (e.g. python) seem to have a split, still: mailing lists for dev-lists, and discourse for end-user-facing forums.

I'd also note that Mailman3 provides a lot more features than what we're used to with mailman2, including the ability to interact/post through the website.

Maybe someone can convince me that I'm just being a curmudgeon, but at this point, I'd say we ought to be investigating options to have Someone Else manage the mailman service, and keep using mailing lists, rather than attempting to switch to discourse.

On that last point, I've gone ahead and asked the folks at osci.io ("Open Source Community Infrastructure") if they'd be willing to host our mailing lists. They are a group at RedHat whose mission is to support infrastructure for open-source community projects, and they host mailman3 lists for a number of other open-source groups, already (Tenants — OSCI.IO - Open Source Community Infrastructure). So, I believe they have the necessary experience and expertise.

They have said they indeed are willing and have the capacity to run this for us as a service, if we'd like. We'd still need to be responsible for things like list moderation, but they'd run the mailman installation on their infrastructure. In my opinion, we ought to take this option, rather than trying to push a migration to discourse.

To me, it seems this would be a much clearer upgrade path, and would solve the hosting/volunteer-admin issue -- including for commit lists -- giving the current maintainers quicker relief from the undesired task of running the list service. Additionally, since it would be a migration to Mailman3, we would get many of the additional features mentioned as desirable, e.g. searchable archives and posting from the website.

Thank you for checking into a mailman3 hosting option, I think this
approach would make me feel the most comfortable (far more comfortable
than switching to Discord).

~Aaron

14

Hi folks,

Since there are several questions around using Discourse, I tried to summarize these into a user guide for a potential migration. The document still contains TODOs where I don’t have seen a good answer, yet:

https://github.com/llvm/llvm-iwg/blob/main/discourse_migration/userguide.md

I’d be happy to get feedback on this document. If something is missing or if you have a solution to one of the open TODOs, please let me know or create a Pull Request.

15

I also find Mailman 3 friendlier than Discourse from the UX point of view.

Currently Discourse doesn't directly support standard search functionality in web browsers, requiring workarounds like using the print preview: Compare Disabling unload-on-scroll? - ux - Discourse Meta and Disabling unload-on-scroll? - ux - Discourse Meta

Looking at python-dev Mailman 3 interface doesn't seem to suffer from this issue:
https://mail.python.org/archives/list/python-dev@python.org/

Best,
Matt

16

thank you for putting that together. One thing that has been puzzling me is how Discord and Discourse are related (heck, I wasn't even sure whether one owned the other, or were different UIs onto the same content). I found Discord and Discourse - Better Together | BlogDiscourse, which was certainly informative -- perhaps add a link to it?

nathan

17

I’ve just tried out discourse for the first time. It is not clear to me how to use it to replace mailing lists. It has a setting “mailing list mode”, which sounds like the right thing – sending all messages via email. Except that option is global – all messages in all categories on the llvm discourse instance. Which definitely isn’t what I want at all. I don’t want to subscribe to MLIR, for example.

FWIW, it would seem that one secret trick here is to NOT check “mailing list mode” – that option is mostly there to confuse you, I guess.

In general, I’d say I’m pretty uncomfortable with switching from a mailing list to discourse. Discourse seems entirely reasonable to use for end-user-facing forums, but I’m rather unconvinced about its suitability as a dev-list replacement. Other communities (e.g. python) seem to have a split, still: mailing lists for dev-lists, and discourse for end-user-facing forums.

I’d also note that Mailman3 provides a lot more features than what we’re used to with mailman2, including the ability to interact/post through the website.

Maybe someone can convince me that I’m just being a curmudgeon, but at this point, I’d say we ought to be investigating options to have Someone Else manage the mailman service, and keep using mailing lists, rather than attempting to switch to discourse.

On that last point, I’ve gone ahead and asked the folks at osci.io (“Open Source Community Infrastructure”) if they’d be willing to host our mailing lists. They are a group at RedHat whose mission is to support infrastructure for open-source community projects, and they host mailman3 lists for a number of other open-source groups, already (https://www.osci.io/tenants/). So, I believe they have the necessary experience and expertise.

They have said they indeed are willing and have the capacity to run this for us as a service, if we’d like. We’d still need to be responsible for things like list moderation, but they’d run the mailman installation on their infrastructure. In my opinion, we ought to take this option, rather than trying to push a migration to discourse.

To me, it seems this would be a much clearer upgrade path, and would solve the hosting/volunteer-admin issue – including for commit lists – giving the current maintainers quicker relief from the undesired task of running the list service. Additionally, since it would be a migration to Mailman3, we would get many of the additional features mentioned as desirable, e.g. searchable archives and posting from the website.

Thank you for checking into a mailman3 hosting option, I think this
approach would make me feel the most comfortable (far more comfortable
than switching to Discord).

I also find Mailman 3 friendlier than Discourse from the UX point of view.

Currently Discourse doesn’t directly support standard search
functionality in web browsers,

Could you describe what’s missing/not working in more detail? At least I can use my browser (Chrome)'s search functionality to find words in both the pages linked below.

18

Sure! It may be easier to notice in a longer thread: Compare the following two views--searching for D104227 using the built-in search in a web browser initially finds 0 occurrences in the first one (at the same time it works fine in the print preview and finds 1 occurrence in the penultimate comment, at least at the moment of writing):

The issue is related to the unload-on-scroll behavior of Discourse: When you open a page on https://llvm.discourse.group it doesn't load (or show) the entire thread on one page by default but instead progressively loads (and unloads) partial content as you scroll along.

There's no such restriction in the Mailman web UI since it displays the entire thread on one page by default, even for longer threads, e.g., Mailman 3 Proposal: declare "unstable APIs" - Python-Dev - python.org
Loading the complete thread (displaying all messages) allows the built-in search to work without issues.

Best,
Matt

19

I’ve just tried out discourse for the first time. It is not
clear to me how to use it to replace mailing lists. It has a setting
“mailing list mode”, which sounds like the right thing – sending
all messages via email. Except that option is global – all messages
in all categories on the llvm discourse instance. Which definitely
isn’t what I want at all. I don’t want to subscribe to MLIR, for
example.

FWIW, it would seem that one secret trick here is to NOT check
“mailing list mode” – that option is mostly there to confuse you, I
guess.

In general, I’d say I’m pretty uncomfortable with switching
from a mailing list to discourse. Discourse seems entirely
reasonable to use for end-user-facing forums, but I’m rather
unconvinced about its suitability as a dev-list replacement. Other
communities (e.g. python) seem to have a split, still: mailing lists
for dev-lists, and discourse for end-user-facing forums.

I’d also note that Mailman3 provides a lot more features than
what we’re used to with mailman2, including the ability to
interact/post through the website.

Maybe someone can convince me that I’m just being a curmudgeon,
but at this point, I’d say we ought to be investigating options to
have Someone Else manage the mailman service, and keep using mailing
lists, rather than attempting to switch to discourse.

On that last point, I’ve gone ahead and asked the folks at
osci.io <http://osci.io> (“Open Source Community Infrastructure”) if
they’d be willing to host our mailing lists. They are a group at
RedHat whose mission is to support infrastructure for open-source
community projects, and they host mailman3 lists for a number of
other open-source groups, already (https://www.osci.io/tenants/
<https://www.osci.io/tenants/>). So, I believe they have the
necessary experience and expertise.

They have said they indeed are willing and have the capacity to
run this for us as a service, if we’d like. We’d still need to be
responsible for things like list moderation, but they’d run the
mailman installation on their infrastructure. In my opinion, we
ought to take this option, rather than trying to push a migration to
discourse.

To me, it seems this would be a much clearer upgrade path, and
would solve the hosting/volunteer-admin issue – including for
commit lists – giving the current maintainers quicker relief from
the undesired task of running the list service. Additionally, since
it would be a migration to Mailman3, we would get many of the
additional features mentioned as desirable, e.g. searchable archives
and posting from the website.

Thank you for checking into a mailman3 hosting option, I think this
approach would make me feel the most comfortable (far more
comfortable
than switching to Discord).

I also find Mailman 3 friendlier than Discourse from the UX point of
view.

Currently Discourse doesn’t directly support standard search
functionality in web browsers,

Could you describe what’s missing/not working in more detail? At least I
can use my browser (Chrome)'s search functionality to find words in both
the pages linked below.

Sure! It may be easier to notice in a longer thread: Compare the
following two views–searching for D104227 using the built-in search in
a web browser initially finds 0 occurrences in the first one (at the
same time it works fine in the print preview and finds 1 occurrence in
the penultimate comment, at least at the moment of writing):

https://llvm.discourse.group/t/rfc-introduce-alloca-scope-op/2940

https://llvm.discourse.group/t/rfc-introduce-alloca-scope-op/2940/print

Ah, yep, that demonstrates the issue but for some reason the previous links didn’t (maybe because the previous linked thread was all on one page for me)

The issue is related to the unload-on-scroll behavior of Discourse: When
you open a page on https://llvm.discourse.group it doesn’t load (or
show) the entire thread on one page by default but instead progressively
loads (and unloads) partial content as you scroll along.

Ah, yeah - which is why it hijacks the search shortcut to do a web form search rather than the browser builtin. Seems to work OK - I wouldn’t count this as a major usability problem, at least for me.

There’s no such restriction in the Mailman web UI since it displays the
entire thread on one page by default, even for longer threads, e.g.,
https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
Loading the complete thread (displaying all messages) allows the
built-in search to work without issues.

Great to see too - especially to see that it addresses an issue that’s always pained me about our current mailman setup, where threads get split by week or month - so there’s no nice way to link to a whole thread. I’ll be happy to see that addressed in either/any way.

  • Dave
20

    When
    you open a page on https://llvm.discourse.group
    <https://llvm.discourse.group> it doesn't load (or
    show) the entire thread on one page by default but instead
    progressively
    loads (and unloads) partial content as you scroll along.

Ah, yeah - which is why it hijacks the search shortcut to do a web form search rather than the browser builtin. Seems to work OK - I wouldn't count this as a major usability problem, at least for me.

Fair enough, there's always an element of subjectivity to UX, so YMMV. At the same time one issue with the aforementioned hijacking is that is not complete, either--e.g., it doesn't support built-in search features like "Find Next" or "Find Previous". For users used to keyboard navigation this is a usability problem (especially in development-oriented discussions, when searching for occurrences of identifiers in, say, LLVM IR does come in handy).

    There's no such restriction in the Mailman web UI since it displays the
    entire thread on one page by default, even for longer threads, e.g.,
    Mailman 3 Proposal: declare "unstable APIs" - Python-Dev - python.org
    <https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/&gt;
    Loading the complete thread (displaying all messages) allows the
    built-in search to work without issues.

Great to see too - especially to see that it addresses an issue that's always pained me about our current mailman setup, where threads get split by week or month - so there's no nice way to link to a whole thread. I'll be happy to see that addressed in either/any way.

Agreed, I also see this as an improvement.

Best,
Matt