Rodrigo Camacho writes:
> If your company uses mailing lists to run, please reach out. We are
> currently using Gitlab issues to collaborate which has been quite
> successful. I would be very interested to trade tips.
While (obviously :-) I support the use of mailing lists for
collaboration and have used them successfully in multiple contexts for
decades, you should pay careful attention to the user experience.
1. Mail user agents vary widely in their capabilities and user
interfaces. Sometimes that means quality. For example, Gmail's
customizable filters seem to be ordinary Sieve filters, that's
fine, but the user interface is terrible. In other cases, they're
just different (think Emacs-based MUAs vs Gmail). You should
consider providing support to users of various MUAs, and lean to
"more" resources for that rather than "less".
Make sure that users have access to good threading in their
MUAs. Gmail "conversations" aren't a great model; that's about
the minimum capability.
For corporate mail, both internal and incoming from suppliers
and customers, etc, you should provide an IMAP server. This
allows you to deal with document retention policy and privacy
requests centrally. But you need to remember that users may be
keeping local copies.
You may also want to provide a corporate webmail server. I can't
recommend a good one; we just decommissioned ours in favor of IMAP
access because everybody has a personal MUA with a better UI. (I
think we're using Cyrus imapd suite.)
2. Avoid the temptation to create many precisely defined lists. In
my experience, it's more important that it be easy to choose the
lists to post to and to subscribe to, than they be closely focused
on specific interests. Focus is better served by an MUA that
allows collapsing and suppressing individual threads and
subthreads.
3. More important than wiping out top-posting is that everyone agree
on style. I've seen a few lists where people absolutely could not
get the concept of "appropriate amount of context" where switching
to top-posting improved the flow. In general for technical
content interlinear responses are best. However for managerial
content ("Do this" -> "Done" -> "What about" -> "That too"
conversations) top-posting is often fine because it's so linear.
"Bottom posting" of course is right out.
4. The HyperKitty archiver was designed with the "we demand Discord"
crowd in mind. As an archive, it provides the obvious features,
including integration with various full-text indexers for search.
But the authors also added a bunch of forum-like features,
including the ability to post from the HyperKitty web ui and
likes. There are alternatives, such as the IETF's MailArchive,
which uses a maildir message store, which makes it easy to add an
IMAP server to the archive, one feature that HyperKitty doesn't
provide. This allows seamless access to the archive via the MUA
(personally I don't like switching back and forth between the MUA
and the browser). I think it's also possible to configure IMAP
servers like Cyrus to function as list archives, but I'm not sure
about how to configure MUAs for that architecture. (Note that
IETF is the kind of place where people are always experimenting
and don't hesistate to rewrite applications to test it. But I
thought the idea was cool.)
5. Choice of full-text indexing backend is important. We default to
Whoosh because it's pure Python and just a pip away. We recommend
Xapian for production, but I don't think we thought terribly
carefully about it. The Django-Haystack project appears to
recommend Solr or ElasticSearch for Haystack 2.0.0 (and these are
"included" in Haystack 2.0,0, not sure what that means, while
Xapian is a separate download). I don't think we support Haystack
2 yet, but surely we will.
6. Colleagues who are new to mailing lists will need training and
encouragement in netiquette. Reply style (top vs interlinear) is
mentioned above. Mailing lists are prone to branching threads.
Members need to learn to (1) change the subject when mutating the
topic so that subthreads can be distinguished and (2) use new
posts to start a new topic (ie, "don't hijack threads"). You
write that GitLab collaboration has been successful for you, so it
may be that your discussions are usually quite linear, and (1)
may not be so important for you.
7. Some people (like me :-) may take naturally to "long form", which
is enabled by mailing lists. Others may find long, discursive
posts annoying. Be sensitive to people who have different
preferences.
8. Some posters will tend to combine several somewhat related issues
in one post, which naturally leads to many branches into
subthreads. This likely will work itself out, but it can be a
point of irritation for some users. Just remember that mailing
lists afford that style of posting more so than forums or tracker
issues do.
9. Remember that email is not adapted to modern affordances such as
live editing. Nor is it suitable for realtime interactions such
as incident response. Often it will be obvious, but sometimes it
will take some time to work out which channels are well-served by
mailing lists and which need an alternative medium.
In general, just remember that people will respond to the change in
different ways, and the goal is to improve communication, not to get
people to adapt to a particular notion of "how it *should* work".
Steve
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
_______________________________________________
Mailman-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/[email protected]/message/E74RH3J5CAOMPQQTCYMGY7WCK5KNGQKU/
This message sent to [email protected]
