Evaluate discourse as replacement for mailing lists?

Should we also evaluate it as mailing list replacement?

Discourse does sport a mailing-list-like operation mode where you don’t have to go to the webui at all. It should thus also be able to serve as mailing list replacement. The advantages that come to mind are: swaths of moderation tools, a fancy webui, that works on mobile, single login instead of per-list, excellent search, onboarding becomes easier, easy to support something via likes on the webui, …

If we were to go down this route it’d be a different discourse instance to keep users and developers separate as it’s all too easy to derail discussions.

  • Yes, let’s try it
  • No, mailman is fine

0 voters

3 Likes

It is possible to configure discource to send plain text emails? I’m honestly not a fan of HTML emails and I currently like it that most emails I received from the mailing lists are plain text.

In any cases, I think this is worth a try at least with a few mailing list at the beginning.

The alternative would be to use mailman 3 that is sensibly better while being a more traditional mailing list system.

3 Likes

I believe emails already come with a plain text payload, so it’s a client choice whether to use that or the html payload.

I believe that mailman 3 would solve most of the problems with list interaction.

1 Like

I’m coming from a purely user perspective. I would prefer to read only one thing, not both. I would prefer the interaction on Discourse, but I would not wish to miss stuff posted to the mailing lists. That said, I understand people who prefer mailing lists, so, if Discourse can satisfy both audiences, those who prefer a Discourse-like forum, and those who prefer mailing lists, so much the better.

It would also reduce the number of points of entry for new users. The rather large number of ways new users can interact with the KDE community can be overwhelming and confusing. In some measure, we have solved the IM problem with Matrix and bridging, bringing together in some degree IRC, Telegram and Matrix – I know it is still a bit clunky clunky, but still better than having 3 independent disconnected communication channels with similar functionalities.

I see a similar solution here: fold forums and mailing lists into one channel of communication, without effectively losing either.

3 Likes

I think it would be a huge win to replace mailing lists per se with Discourse, but preserve the email-only mailing-style interaction method for those who want it. Seems like it could accommodate everyone.

1 Like

Just for the record, this was sprung out of nowhere and i’m deeply unhappy about the way this is being handled.

Especially given I very, very, very recently made a discussion thread about Mailman 3…

Note that kde-bugs-dist and kde-commits will bite the dust if this goes ahead, as those are unarchived due to the volume/size of traffic, which would flood out a Discourse instance quite easily.

Responding to the “advantages” as Harald is comparing to Mailman 2 (which is due to be replaced imminently - the rest of the new mail server build is complete, so it is a bit of Mailman 2->3 migration left to go then we are good to proceed with it)

Pretty much all of the points raised by Harald are null and void as Mailman 3 has said functionality - see Available lists - Fedora Mailing-Lists for an example instance…

2 Likes

Sorry for springing discussion on you?

What makes you say that?

1 Like

I guess it doesn’t have to be an either-or thing. If some stuff cannot be realistically migrated, then just don’t migrate them. If some can, because they are lower traffic or fit into the Discourse mold, whatever that is, then consider those.

1 Like

I think kde-community might be a good mailing list to migrate. Stuff like kde-core-devel a bit less.

Also we have a big number of lists and I’m not how to organize them all inside discource (should we create as many categories?)

1 Like

Why is that?

I’d imagine so. That would certainly be a subject to evaluate. Another option would be to run separate instances for overarching topics to break up the amount of categories per site Multisite configuration with Docker - sysadmin - Discourse Meta

e.g. a Developer (and possibly separately a Community) discourse and separate from that a Bugs discourse

There is also this request Mailing list mirror feature request: multiple mailing lists per category via tags - feature - Discourse Meta

1 Like

kde-commits and kde-bugs-dist are high volume lists. Therefore the “conversations” on those lists will flood out the conversations on just about every other list if you were to show an overall mailing list activity page (Discourse’s “Everything” page I believe)

That would be counter to what we’re trying to achieve as actual human discussions would be completely obscured.

Migrating some lists and not all will fragment the home of our mailing lists so people won’t know where to look for things.

Note that most of the “pro points” of Discourse in this context are met fairly well by Mailman 3.

2 Likes

Do we have data on how much kde-commits and kde-bugs-dist are even still used? My sense is that the utility of these lists has largely been supplanted by better and more modern services.

1 Like

We can filter out categories from the everything page.

1 Like

There will be no perceivable split for people who prefer to stick with mailing lists. One of the reasons for going with Discourse is because you can have your cake and eat it too: you can have user-friendly Discourse forums with the same content replicated into mailing lists (or vice versa).

One of the other points is that there is an onboarding reason for choosing Discourse. Discourse is more accessible and user friendly than mailing lists for the less techie or younger crowd. This is an audience we want to attract: teachers, students, artists, etc… That also means that the highly technical and specialised mailing lists will not be very attractive to this crowd and replicating them will not be a priority.

This means Discourse can contain a subset of replicated mailing lists, and not fragment the knowledge contained within them.

3 Likes

Please check a dictionary for the term “replacement”. It means that Mailman is being disposed of in it’s entirety. Yet above I see quite clearly you mentioning that we would make some lists “Discourse” lists while others would remain as “Mailman” lists.

That is not replacement. Not even close.

Having two systems is awesome from both a “Sysadmin has more to maintain” perspective and a “split the community into two places” perspective (and by awesome I really mean terrible).

The fact that Carl suggests that kde-community is a good candidate while kde-core-devel is not a good candidate suggests to me that Discourse is perhaps not well suited for taking over all our lists.

And that is before we get to “announcement only” lists such as krita-announce and kde-announce, for which we want a pretty much zero-barrier-to-signup approach for people to be able to subscribe (which I imagine Discourse as a mailing list manager cannot do, because it is really a web forum first).

In case people hadn’t got the memo, one of the things I have been trying to do over the past 2-3 years is reduce the number of things we have to look after (and there are a few things like Jenkins I really would like to finish saying goodbye to).

It would be nice not to have discussions like this just thrown up as well - especially when it was agreed we would deal with User forums first and have that well settled before Developer stuff even came into consideration, and especially given I emailed a series of KDE mailing lists about a move to Mailman 3 in the last couple of weeks.

The comparison points above in the poll are MM 2 vs. Discourse, so the whole poll is really void because you should be comparing MM 3 vs. Discourse.

2 Likes

If we replaced Mailmain (2 or 3) with Discourse, wouldn’t sysadmin have fewer things to maintain? If that’s a priority, it seems like this is the clear winner, no?

I agree that migrating some mailing lists to Discourse but not all isn’t a great approach.

1 Like

Again: Why?

It supports that use case just fine. What makes you think that it doesn’t? I’ve misread the requirement, nevermind me.

1 Like