Why change?

This is in fact the most interesting question. It is tempting to think that if mailing list users declare they are happy with mailing lists, then there is nothing to discuss. However, we have to think (and to Risker’s point) that mailing list users who aren’t happy just go elsewhere, or don’t even join a mailing list, usually relying on commercial social media products completely outside of the Wikimedia movement and its values.

Here we are trying to propose a Space for discussion, collaboration and support that can bring (back) together those who are still using mailing lists AND those who are having their Wikimedia conversations in Facebook, Telegram, etc.

Private mailing lists

Yes, private mailing lists can be mirrored or emulated, and access permissions can be granted more or less like in Mailman. Space admins can create a group (corresponding to a mailing list) and assign the mailing list admins as owners, then the owners can invite & unsubscribe users. And then a private category can be created to host the messages, with access permissions restricted to members of that group.

Space administrators have access to all content, just like they have access to all the content in the site. And just like with Mailman (I guess) SRE and whoever has access to the servers have the technical possibility to access to the content too, which is not encrypted in the database.

Replying from Discourse to mailing list mirrors

Not possible. Mailing list mirrors are read-only. If posting from Discourse is wanted, then you want mailing list emulation (which means leaving your current Mailman mailing list behind).

Editable archives

The content of mailing list mirrors is not supposed to be edited. However, Space admins have edit permissions that can be exercised if something HAS to be edited. They can also delete messages archived.

In the case of mailing list emulation, regular permissions apply and authors can edit their own posts within a time frame that can be defined in the site preferences. Moderators and administrators can edit past messages too.

Guidelines specific to a certain mailing list / category

Totally negotiable for private, invitation-only categories/mailing lists where people join for a specific task, in a specific role, and the content is not even visible for the Space community. Common sense prevails. If a category wants to set additional guidelines for themselves on top of the general guidelines, they probably can as long as the whole is consistent.

If a group e.g. ArbCom has special needs that might conflict with a literal reading of the guidelines (e.g. investigate users that have been reported in a project) common sense keeps prevailing, trust matters, and an official and legitimate activity in one Wikimedia channel should be able to operate under the same premises in Wikimedia Space.

Mailing lists without archives

An equivalent of this functionality is currently not supported in Discourse. We could commission the development of a plugin that would delete posts from the web UI and the database after they have been distributed via email. When asked, Discourse maintainers said it wouldn’t be difficult to write such plugin, it is just not a priority for them.

“What we’d lose (user experience)”

https://meta.wikimedia.org/wiki/Discourse#What_we’d_lose_(user_experience) lists some points as potential disadvantages of Discourse over Mailman (fun fact, the archived email containing this question has a broken link). 😏

• Problems with email rendering? The promise is to offer no functionality loss to Mailman users. We want to test mailing list mirroring and emulations precisely to get a first impression about problems in real use if any (and file bugs accordingly).

• Email forwarding? Same thing, let’s test and see what are the problems if any.

• Problems subscribing. OK, there is room for improvement indeed, both for making easier to understand how subscribing works (the subscription itself is easy, clicking a button) and for implementing mailing list mode per category. Again, testing just helps understanding the actual impact of this problem (which can be compared with the problems that users face the first time they learn about mailing lists, which also brings a learning curve).