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.
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.)
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.
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.
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.)
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.
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.
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.
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.
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