Re: [Wikimedia-l] Mailing list usability: Observations about Mailman 3

[Erik Moeller]

On Thu, Aug 17, 2017 at 7:59 AM, rupert THURNER
 wrote:
>> A somewhat related ticket about trying to unify our discussion platforms
>> was discussed in a session at Wikimania:
>> https://phabricator.wikimedia.org/T155678

> Interesting thanks for the pointer. Compared to the options listed there a
> mailman upgrade looks rather straight forward and, personally I d really
> appreciate if it could be done, for the benefits Eric listed.

To be clear, I don't think an upgrade to MM3 would be straightforward;
it would be quite a hairball keeping multiple people busy and should
only be done incrementally. I say this only to avoid feeding a "Why
haven't we done this simple thing yet" narrative that sometimes
develops around software updates/upgrades, not in order to
specifically criticize your statement. This isn't a simple update by
any means.

I think the Q/A site vs. mailing list are very complementary
approaches. A StackExchange style knowledge platform certainly may
serve certain use cases identified in the ticket Niharika linked to,
and some experimentation with different approaches seems wise.

One word of caution -- open source clones are often poor carbon copies
that lack important functionality and algorithmic sophistication that
made the platforms they are cloning successful. This may include even
wiki-style functionality (for example, Quora has an "Answer Wiki"
feature sometimes used to highlight the salient aspects of the best
answers).

Without such correctives, you may replicate certain well-known
problems with upvote/downvote systems, such as a bias towards old
answers that received lots of votes early on but have been superseded
by much better responses.

The upvote/downvote feature in the Mailman 3  UI [*] that I mentioned
is so minimal that I think it can be ignored for all intents and
purposes, and would probably best be removed or disabled to minimize
confusion and clutter.

Erik

[*] to be precise, it is a feature of Hyperkitty, the archive frontend
that also allows posting through the web

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Mailing list usability: Observations about Mailman 3

[Niharika Kohli]

A somewhat related ticket about trying to unify our discussion platforms
was discussed in a session at Wikimania:
https://phabricator.wikimedia.org/T155678




On Mon, Aug 14, 2017 at 6:27 PM, Erik Moeller  wrote:

> Hi folks,
>
> The topic of list usability has come up here a few times in the past,
> and efforts have been made over the years to pilot alternative forum
> systems like Discourse, or to redirect more conversations to talk
> pages.  Yet the mailing lists continue to be used for a significant
> share of long-form Wikimedia discussions and announcements (see stats
> at [1]).
>
> There's a Phabricator ticket [2], currently marked as stalled, for
> upgrading Wikimedia's mailing list software, Mailman, to the newest
> version. Mailman 3 is a complete rewrite, and this upgrade would
> unquestionably be a major team-level effort. I've recently set up a
> Mailman 3 install [3] (without archive migration) and wanted to share
> some observations that may help with a decision to stay on the Mailman
> 2 line or attempt an upgrade. Sent to wikimedia-l because I think this
> discussion deserves a bit more mind-share beyond the developer
> community.
>
> To see an active Mailman 3 community, check out the Fedora project's:
>
> https://lists.fedoraproject.org/archives/
>
> == The good ==
>
> You can make a user account (including with third party providers,
> opening the door for Wikimedia account integration), which makes
> managing your subscriptions a bit easier. You don't have to sign up to
> subscribe.
>
> You can post through the web. This is a pretty big deal, as it opens
> up list participation to folks who don't want to use email for this
> purpose. It makes the whole experience more forum-like for those who
> prefer that.
>
> The interface is responsive and mobile-friendly. It uses the
> widespread "Bootstrap" theme which is a bit generic but pleasing
> enough.
>
> You can search the archives.
>
> There are some nice forum-like activity indicators in the web
> interface and (sure to be controversial) upvote/downvote buttons for
> posts, though the latter seem to largely be ignored in real-world
> installations.
>
> While setting the software up was difficult (easier if you have prior
> familiarity with Django), I did not encounter any showstopper bugs.
>
> == The bad ==
>
> The web interface does not degrade gracefully to users without
> JavaScript: important features just stop working.
>
> The list administration tool has some new features, but it has also
> lost old features. For example, while Mailman 2 lets you easily change
> per-user moderation from the the "held messages" interface, this is
> still an open task in Mailman 3. [4]
>
> The more modular approach in Mailman 3 means that features don't
> always play together. For example, you can delete a list, but deleting
> the archives requires manual execution of an un-official Python code
> snippet. [5]
>
> This modularity also means some defaults are unhelpful. For example,
> the default emails generated by the software do not link to the web
> interface, because the web interface is a separate module that may not
> be installed.
>
> == The ugly ==
>
> The platform is not yet ready for translation, and the interface is in
> English only. Quoth the project leader in response to whether it is
> possible to change the UI language: [6]
>
> > Unfortunately no. We've never gotten much traction for fully
> > translating Mailman 3. We've had some interest but what we really
> > need is a champion to drive the initiative. One of our biggest blockers
> > is choosing a translation platform that's compatible with our free
> software
> > constraints, but also requiring a minimal amount of ongoing
> infrastructure
> > support from us.
>
> (Hey, I think I know such a platform.)
>
> Faithful migration will likely also require some level of custom
> development. Quoth the docs: [7]
>
> > The short version is that as of now, upgrading from Mailman 2.1
> > to Mailman 3.1 is buggy.
> >
> > Now the long version. Because of the changes in Database Schema,
> > migrating from Mailman 2.1 to Mailman 3.1 is not very easy, though it
> > can be done with some scripting. We are working on it and it should be
> > working soon, we don’t have an exact timeline on it though.
> >
> > Archives however can be imported into Hyperkitty easily, however URLs
> > to attachments are going to break because the URL paths are different
> > in Hyperkitty. Although, You might be able to retain your HTML archives
> > from Mailman 2.1 and continue archiving newer emails in Hyperkitty.
>
> == What to do? ==
>
> It's doubtful that Mailman 3 will magically advance in leaps and
> bounds over the coming years. Adoption generally tends to drive
> interest and development, and a WMF decision to upgrade may motivate
> others to work towards solving longstanding problems like the i18n
> issue. The Fedora installation appears to show that it's possible to
> run Mailman 3 at 

[Wikimedia-l] Mailing list usability: Observations about Mailman 3

[Erik Moeller]

Hi folks,

The topic of list usability has come up here a few times in the past,
and efforts have been made over the years to pilot alternative forum
systems like Discourse, or to redirect more conversations to talk
pages.  Yet the mailing lists continue to be used for a significant
share of long-form Wikimedia discussions and announcements (see stats
at [1]).

There's a Phabricator ticket [2], currently marked as stalled, for
upgrading Wikimedia's mailing list software, Mailman, to the newest
version. Mailman 3 is a complete rewrite, and this upgrade would
unquestionably be a major team-level effort. I've recently set up a
Mailman 3 install [3] (without archive migration) and wanted to share
some observations that may help with a decision to stay on the Mailman
2 line or attempt an upgrade. Sent to wikimedia-l because I think this
discussion deserves a bit more mind-share beyond the developer
community.

To see an active Mailman 3 community, check out the Fedora project's:

https://lists.fedoraproject.org/archives/

== The good ==

You can make a user account (including with third party providers,
opening the door for Wikimedia account integration), which makes
managing your subscriptions a bit easier. You don't have to sign up to
subscribe.

You can post through the web. This is a pretty big deal, as it opens
up list participation to folks who don't want to use email for this
purpose. It makes the whole experience more forum-like for those who
prefer that.

The interface is responsive and mobile-friendly. It uses the
widespread "Bootstrap" theme which is a bit generic but pleasing
enough.

You can search the archives.

There are some nice forum-like activity indicators in the web
interface and (sure to be controversial) upvote/downvote buttons for
posts, though the latter seem to largely be ignored in real-world
installations.

While setting the software up was difficult (easier if you have prior
familiarity with Django), I did not encounter any showstopper bugs.

== The bad ==

The web interface does not degrade gracefully to users without
JavaScript: important features just stop working.

The list administration tool has some new features, but it has also
lost old features. For example, while Mailman 2 lets you easily change
per-user moderation from the the "held messages" interface, this is
still an open task in Mailman 3. [4]

The more modular approach in Mailman 3 means that features don't
always play together. For example, you can delete a list, but deleting
the archives requires manual execution of an un-official Python code
snippet. [5]

This modularity also means some defaults are unhelpful. For example,
the default emails generated by the software do not link to the web
interface, because the web interface is a separate module that may not
be installed.

== The ugly ==

The platform is not yet ready for translation, and the interface is in
English only. Quoth the project leader in response to whether it is
possible to change the UI language: [6]

> Unfortunately no. We've never gotten much traction for fully
> translating Mailman 3. We've had some interest but what we really
> need is a champion to drive the initiative. One of our biggest blockers
> is choosing a translation platform that's compatible with our free software
> constraints, but also requiring a minimal amount of ongoing infrastructure
> support from us.

(Hey, I think I know such a platform.)

Faithful migration will likely also require some level of custom
development. Quoth the docs: [7]

> The short version is that as of now, upgrading from Mailman 2.1
> to Mailman 3.1 is buggy.
>
> Now the long version. Because of the changes in Database Schema,
> migrating from Mailman 2.1 to Mailman 3.1 is not very easy, though it
> can be done with some scripting. We are working on it and it should be
> working soon, we don’t have an exact timeline on it though.
>
> Archives however can be imported into Hyperkitty easily, however URLs
> to attachments are going to break because the URL paths are different
> in Hyperkitty. Although, You might be able to retain your HTML archives
> from Mailman 2.1 and continue archiving newer emails in Hyperkitty.

== What to do? ==

It's doubtful that Mailman 3 will magically advance in leaps and
bounds over the coming years. Adoption generally tends to drive
interest and development, and a WMF decision to upgrade may motivate
others to work towards solving longstanding problems like the i18n
issue. The Fedora installation appears to show that it's possible to
run Mailman 3 at scale already, though I haven't spoken to them about
their experiences.

I don't believe that the usability advantage Discourse currently
enjoys is inherent to web forums -- Mailman 3 shows that there is a
development path to make mailing lists more accessible and friendly,
as well, even if there is still a lot of work to be done.

My main recommendation would be to evaluate the state of play towards
a more explicit choice between