Ten best practices for scientific software development.
Communication is key to successful scientific software development. Mailing lists provide a transparent and archivable discussion medium.
"The medium is the message," as Marshall McLuhan stated in 1964. That being said, this particular best practice may seem outdated ("isn't email dead?"). But there are a number of important reasons to use email lists to communicate.
The first is that email is a principal mode of asynchronous communication - and nothing has truly replaced email for this purpose. While new tools like Slack or Hipchat are on the rise in terms of popularity, these toolsare so specialized that they don't replace, but rather supplement, the purposes of email.
The second is that email lists provide a method for archiving important discussions in a way that can be accessed later - there is no risk of ephemeral knowledge being locked up on some server somewhere. Good mailing list software will provide ways of archiving discussions for later reference.
The third is that email is, and will remain, a common and democratic technology that everyone can have access to. Fancy new tools may be great for teams where everyone has access to the latest, greatest, meanest, leanest, Javascript-widget-running machine, but email is (in principle, anyway) more accessible to everyone, and therefore more inclusive.
Fourth, and certainly not least, mailing lists can offload some of the time-intensive work of developers assisting users by providing a mechanism by which anyone can provide answers to questions - not just developers. That way, a user who is stuck can send their question to a large group of people, rather than emailing a single developer (who may be on vacation) and anxiously awaiting a reply that may not come for a week.
There is a problem, however, in setting up email lists, and that lies with the difficulty of setting up an email server. (The underlying cause of this is how easy it is for a misconfigured email server to end up serving as a magnet for spammers.)
Mailing list software, sometimes called a listserv, is possible to set up yourself, but it can be tricky to get the mailing server working. Alternatively, ask a system administrator for help.
If you work for or with an institution, they most likely already have mail servers and listserv software already set up that you can leverage.
Another option that is extremely easy to set up and low-maintenance to maintain is Google Groups. While these don't integrate as seamlessly with your own domain, it is dead simple to set up.
If you decide to set up your own mailing list software, Mailman is one of the most common and popular listserv software packages out there, and is written in Python. This software runs in addition to, not in place of, an email server. That means you'll need to set up a mail server first, then set up Mailman.
If you must set up a mail server, here's a piece of advice: do not use sendmail. Sendmail is for Linux commandos only, and will intoduce you to a world of pain you never knew existed.
Postfix is a relatively easy mail server to get set up. You can find more information on installing a Postfix mail server on the charlesreid1.com wiki.
While the number of mailing lists will depend on the size and scope of the project, there are typically a minimum of three email lists associated with a given project.
The first is an announcements list, used to announce new versions of the software. This is a mailing list for users who wish to stay on top of the latest and greatest developments in the software.
Another mailing list is a users mailing list - this is a mailing list where users of the software can go to ask questions about the use of the software, get help with problems, raise issues, and interact with others who have used the software.
Finally, there is usually a developers mailing list, which is a forum by which developers of the software can communicate. Code development often takes place among developers located in the same physical location, working in offices that are close by. This tends to make the software development process, and in particular the decision-making process, less transparent and more evanescent. If developers utilize a mailing list, it can create a documented record of decisions that were made, issues that were raised and discussed, and reasonings for various decisions.
For software developers stepping into lead developer roles in large frameworks, or at institutions where there is a high turnover rate (such as an academic research group), documenting the reasoning behind important decisiosn is absolutely crucial to help later developers understand the logic, address new needs for the code, and keep from accidentally shutting out legacy users or applications.
The entire purpose of mailing lists is to encourage discussion and openness, so pay no mind to people complaining about too much traffic on the mailing list. That's why email software provides you the ability to filter incoming mail.
That being said, make sure it is easy to unsubscribe from the software mailing lists. The last thing you want is to make an enemy.