Common questions re: Mailman to Discourse

Site Feedback
1

Hi,

I’ve received several questions during the past days which possibly makes sense to summarize in a single topic which I can then reference. Hopefully this specific post will help anyone looking for the same set of answers as well. If any additional common question arises I’ll make sure to add it to this topic.

All the lists listed under GNOME Mail Services will be gone?

That’s correct, all the lists listed in there will be turned into RO mode, list archives will remain around for the time being. I want to stress this again, list archives will be kept as-is but no further interactions will be allowed.

Are active lists being migrated to Discourse (https://discourse.gnome.org)?

That’s correct, an evaluation was made around which lists were still being effectively utilized by our community or were mainly receiving spam emails. This particular process started years ago [1], individual list owners slowly migrated their communication workflows to Discourse over time. The platform started being utilized by many more contributors and the number of active lists in Mailman was consistently dropping down as a result of this initiative.

What about inactive lists? Why was this move made necessary?

I poorly worded it in my announcement, this discussion has been going on for so long that I over simplified that part of my announcement, my bad. There are multiple reasons we decided to move away from Mailman, I’m going to summarize them now so you can possibly help with broadcasting:

  1. One of the main focuses we had during the past few years was modernizing our infrastructure (cgit → GitLab, docker → OCP 3, then OCP 4, introducing modern services such as Discourse, IRC → Matrix)
  2. Since we introduced Discourse, GNOME’s Mailman instance has seen a decline in utilization over the past years. The new platform offers way more features than Mailman, including markdown support, RSS feeds, proper spam support, multiple authentication types , topic previews, mobile friendly, multitude of plugins to extend its functionalities, API support and so on and so forth
  3. Discourse provides all the goodies of a web forum but maintain the plain mail interaction if you want to do so, I’ll mention more about this later in the email given you specifically asked for clarification around this
  4. Reduce community fragmentation and consolidating our communication platforms between Discourse and Matrix (with an IRC bridge)
  5. Have more people involved in moderating our communication platforms, with Mailman the person(s) that jumped in and wanted to help moderating a specific list were going away after a few iterations leaving the burden to the Infrastructure team or just leaving dozens of pending moderated emails in the queue. Mailman’s way of moderating new emails just won’t scale in the modern internet, and especially in a community composed of contributors who spend their free time helping out the Project, tools should just work out of the box, have a nice UI and be straightforward enough, Mailman has nothing close to that
  6. Dozens of ways to integrate Discourse with other services via webhooks and other available integrations
  7. The migration has been discussed and was proposed, as I mentioned earlier, several years ago by the GNOME Engagement team and it was accepted by the majority of the tenants

Is it possible to use Discourse over email?

It definitely is, if anyone wants to use their mail client to interact with Discourse, they can. That’s exactly one of the features we looked into when we originally deployed Discourse back then. The workflow mainly is:

  1. You watch a category or a tag or both
  2. You receive mail sent to the registered mail address for your account, hit the reply button in your mail client and respond as you’d do with Mailman, the reply is then stored in Discourse, simple as that

Is this migration causing some headaches?

With any change comes some pain, when we initially moved from cgit to GitLab a lot of people complained that with more features comes additional complexity, when we introduced Matrix to IRC many complained we were slowly going away from a protocol that has been around in the community for ages, the general feeling I have is that no matter how much we explain people’s communication workflow won’t change with Discourse they just won’t care and that’s totally acceptable. What we’re doing right now is engaging with a lot of users and teams to make sure they are onboarded successfully. In the long run Mailman 2 will have to be retired and these people will need to comply or just move to Mailman 3, and another migration will be required.

What will happen to i18n related lists? What about branch updates notifications?

The i18n lists won’t go away at the deadline of the end of October but somewhen mid November to allow Damned Lies to integrate the required code changes in order for this specific workflow to be migrated to GitLab instead. Discourse will be mainly available as a platform where discussions around i18n should happen, anything else including notification messages coming from automation will be posted to GitLab. Please see the following issue for more details on the implementation.

6 Likes
2

I have a specific question regarding the gnome i18n mailing list. I had to use it from time to time when the software I maintain received a branch update. In that case I wrote a notification in the i18n mailing list, like this one: https://mail.gnome.org/archives/gnome-i18n/2017-October/msg00032.html. This is, to my knowledge, done by every maintainer who has software covered by the i18n team.

Now that the gnome-i18n mailing list will be retired by end of October 2022, where and how in particular such notifications must be made in Gnome’s discourse?

Edit: corrected some typos…

3

I’d recommend opening an issue on Damned Lies instead: https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/new

1 Like
4
5

This is surely a great question, I’ve added the reply directly on the original thread post, thanks!

6

It’s important to note that the issue is for (mostly automated) communications from the i18n teams to application developers—like string freeze breaks.

If you want to ask for a string break exception, we have a dedicated venue already and we just need to amend the rules so that the coordinators of the i18n team can give their :+1: or :-1: to requests, just like every other team does.

The specific question from @uwescholz is notifying the Damned Lies maintainer that there is a new translatable branch. Since it applies to the Damned Lies project, the options are to either open an issue against D-L itself, or have some other Team-specific space on GitLab.

1 Like
7

This approach sounds good to me. An official statement about the approach might be worth in the Gnome developer guidelines (for the case the project has a damned-lies entry)?

8

Yes, once we settle for a specific workflow, the documentation for maintainers will be updated.

9

The category ‘International’ is quite broad*, and a ‘Translations’-tag would perhaps be too narrow. Should we create a ‘gnome-i18n’-tag to simulate the mailing list subjects?

[*]: There will be language-specific sections under this category.

10

I tried to create a tag for GNOME Asia under Community category but failure, @averi may you help to create it ?

11

Sure, what tag name would you like there? Just asia?

12

The “International” category is generally for non-English user requests, or event-related topics.

There already is an i18n tag for topics related to localization and internationalization; topics related to localization teams and coordinators can go under the Community category.

13

@averi asia is a good suggestion.

14

The tag you requested has been created, thanks!

15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.