Mailing Lists

Mailing Lists hosted on lists.gothub.org

We provide an unrestricted amount of hosted mailing lists on our lists.gothub.org server. Hosting is provided on a fair-use basis as part of any of our subscription tiers. Our goal is to facilitate communication within communities and organizations, among developers of a software project, as well as communication between users and developers. Both public and private lists can be hosted.

Our mailing list infrastructure is kept completely separate from our Git hosting infrastructure. Most interactions with the mailing list management software happens by email. Users are identified by email addresses rather than SSH keys. There is no connection to user accounts declared in gotsys.conf.

Public mailing lists can be archived on our servers. Archives can be accessed by email. Web-based access to the archives is planned for the future.

Requesting a Mailing List

To request a mailing list, contact us and tell us:

• Which project (yourproject.gothub.org) the mailing list will be associated with.
• Your own custom domain name, if you want to use your own domain instead of lists.gothub.org. We will coordinate required DNS configuration with you.
• The address of the list you would like to create. When using the lists.gothub.org domain the list address should begin with the name of your project to avoid naming conflicts.
• The email addresses of the initial owners and moderators of the mailing list. Owners can accept or deny new subscription requests. Moderators can pass or deny messages held for moderation. If not specified, the email address you are sending from will be used as initial owner and moderator.
• To uphold our fair-use criteria, we want to know the purpose of your mailing list. See our mailing list types, usage recommendations, and request templates below for guidance.

While we take care of the infrastructure, you will be largely responsible for managing your own mailing lists. This includes:

• Managing your list's configuration on your own, as far as made possible by the mailing list management software we run (currently mlmmj). We will of course try to assist you when questions arise.
• Ensure active mailing list moderators are in place. Moderators need to filter out spam sent to the list, and uphold our terms of service during discussions.
• If you cancel your subscription or stop your involvement in a project which depends on your mailing list for communication, you should let us know and hand the list over to someone else who can continue to be responsible for it. Orphaned lists not backed by any subscription can receive a grace period during which a new subscription can be arranged.

On the Usefulness of Mailing Lists

The Game of Trees Hub admin team decided to offer hosted mailing lists because:

• We want to make use of mailing lists easy for projects which are starting out today, or have to migrate away from a mailing list server which is being shut down. Unfortunately, running a self-hosted e-mail setup is not trivial on today's internet. Many projects still self-hosting their own mailing lists today have been doing so since the 1990s. Hosted solutions for small and independent software projects which are not already part of a bigger foundation with custom project infrastructure are few and far between.
• We know how to use mailing lists ourselves. Some of our admin team members have been using mailing lists for professional software development work across 20+ years.
• We know how to host email ourselves. We have close relations to the OpenSMTPD project, with developer overlap between OpenSMTPD and the Game of Trees Hub.
• Mailing lists can, to some extent, cover use cases which are not (yet?) served by Game of Trees, but which are standard forge features on other Git hosting sites. This includes public discussion forums, code review, bug reports, and private communication channels between software project members.
• Email is federated by design. Almost everyone already has an email address which provides a low barrier to entry for new people wanting to join a public discussion. Most other Git hosting sites only use email sparingly, even though virtually all of them make use of email for initial account setup because email is still unmatched for providing an initial user identifier. A renowned exception is of course Sourcehut, which integrates email at the core of its workflows even further than we are willing to take it. And we are aware that some Git hosting sites are working on federation with ActivityPub, which is not something we would feel comfortable integrating in our own hosting site's design.

We understand that mailing lists may not be a perfect tool for everyone today. Mailing lists have downsides: patches can be mangled, text-only communication without visible avatars and faces can be awkward, and spam can be a problem. Some email clients make mailing lists easier to use than others. Advantages of mailing lists are an inherently asynchronous workflow where real-time notifications are the exception rather than the norm, a lack of client-side and server-side vendor lock-in, low requirements on resources, relatively low software complexity when compared to the web, and flexible client-side user interfaces. The fact that others will only be able to perceive you as what you write can be awkward but is equally a blessing at times. Not every meeting needs to be a video call.

If you have questions about the optimal use of mailing lists for your project, do not hesitate to contact us.

Mailing List Types

Mailing list software we use (currently mlmmj) provides many configuration options which need to be set according to the use case of the mailing list. To make it easier to get started, we define several types of mailing lists which you can choose from: public, public read-only, private, and confidential.

If none of our pre-defined types fit your needs, please contact us.

• General behaviour of all types of lists:
  • The default size limit for incoming messages is 4MB.
  • List owners are notified when someone (un-)subscribes.
• Behaviour of public mailing lists (e.g. dev@, users@, community@, bugs@):
  • Subscription is not moderated.
  • Only subscribers can post. Avoids spam.
  • Anyone, even non-subscribers, can fetch the email archive.
  • Senders will receive a copy of messages they post.
• Behaviour of public read-only mailing lists (e.g. announce@, commits@, notifications@):
  • Subscription is not moderated.
  • Only moderators and selected email addresses are allowed to post.
• Behaviour of private mailing lists (e.g. private@, admins@):
  • Subscription is moderated.
  • Only subscribers can post.
  • Senders will receive a copy of messages they post.
  • Mailing list archive is disabled because we do not want to store private email on our servers.
• Behaviour of confidential mailing lists (e.g. security@):
  • Subscription is moderated.
  • Moderators will have to accept all messages manually.
  • Senders will not receive a copy of messages they post.
  • Mailing list archive is disabled because we do not want to store confidential email on our servers.

Usage Recommendations

If you are unsure how mailing lists can be used for your project, we provide some ideas below, based on how mailing lists have traditionally been used in open source and free software projects. We also recommend reading the Message Forums / Mailing Lists chapter of Karl Fogel's book Producing Open Source Software for additional guidance.

• A community mailing list can be used for general discussion within a community. We can host such mailing lists even if their purpose is unrelated to software development. Such lists could be used for discussion within a group of people sharing particular interests, friends, families, members of a club or organization, etc. Such lists could either be public (open for subscription by anyone) or private (new subscriptions require approval).
• An announce mailing list can be used to publish news about your project. Such lists are typically low-volume with a few messages per month at most, much like a blog. The authors of messages posted to this list are usually representatives of the project. Subscribers of such lists are usually only reading the messages posted, and will not send messages back to the list. Feedback can be collected via other channels, such as another mailing list.
• A development mailing list can be used for development discussion and code review. We recommend to send only plain-text email (no HTML) to such lists, with attachments of non-text files if necessary. Patches can be sent inline as part of the message text, or as attachments. We recommend to avoid top-posting (writing a response above the original message). Instead, responses to particular sections of the original message should appear below a block of lines which quotes the section being replied to. This is particularly important when reviewing patches, but also helps with keeping general discussion threads focussed and organized.
• A users mailing list is usually intended for public discussion among users of a software project. Developers might also be reading along and respond, e.g. to provide expertise when a question remains unsolved. However, users can often support each other quite well. Beware that the public nature and loose technical focus of such lists may require more moderation effort than other types of lists.
• A private mailing list is usually intended for private communication between project developers. Communication is kept private in the sense that only selected recipients will find the messages in their email inbox. It is also possible to encrypt messages with PGP but in practice this is rarely done for group discussions. If your project needs to discuss matters which cannot be responsibly discussed in public, such as proposals of new candidates for commit access to a project, or the organization of events which could be disclosing information about people's travel routes, a private mailing list could be a good fit for this purpose.
• A security mailing list is usually intended for the collection of bug reports which identify security issues. The main purpose of such lists is to provide a dedicated point of contact for security researchers who expect to have a private conversion with the project before a security problem is disclosed to the public. Such lists are usually kept private, meaning that only selected recipients will be able to read messages sent to them. There could also be a public PGP key which security researchers can use to encrypt messages sent to the list, ensuring information about the security issue will not be leaked in transit. If your project intends to support people who rely on your software in production there should definitely be an obvious point of contact for security researchers, and a security mailing list is well-suited for this task. On the other hand, not having a security contact address is an indication that your project does not provide support for security issues, which might be a desirable signal to send if you don't want to or cannot support other peoples' production deployments. Such work should be nobody's burden to bear in their spare time, especially for production deployments which are commercial endeavours.
• A bugs mailing list is usually intended for collection of general bug reports. Tools such as sendbug can send bug reports in a structured text format. Mailing lists are not well equipped for tracking the state of an issue from triage until eventual resolution. Discussion of bugs will naturally also occur on other types of lists, such as the users list or the security list. Having a mailing list dedicated to bugs is only recommended if there is no better alternative available to you, and should be accompanied by external tracking of the state of reported issues.
• A commits mailing list is usually intended for commit notifications sent by email. Such lists allows subscribers to obtain notifications about changes made to the software project in real time. Subscribers will rarely, if ever, manually send messages to this list.

  Mailing List Request Templates

  Example 1: Public users list

  From: Yourself <you@example.com>
  To: Gothub Admins (see here)
  Subject: Requesting new public mailing list
  
  Hi,
  
  I would like to request a public mailing list for user questions
  and general discussion about my project.
  
  My project is: example.gothub.org
  
  The list name should be: example-users@lists.gothub.org
  
  I will be the list owner.
  
  Please add them@example.com and they@example.com as moderators.
  
  Regards,
  Yourself
  

  Example 2: Private project list

  From: Yourself <you@example.com>
  To: Gothub Admins (see here)
  Subject: Requesting new private mailing list
  
  Hi,
  
  I would like to request a private mailing list for my project.
  We will be discussing confidential matters such as event
  organization and security issues on this list.
  
  My project is: example.gothub.org
  
  My custom domain is: myproject.example.com
  
  The list name should be: private@myproject.example.com
  
  The owners of this list should be you@example.com, them@example.com,
  and they@example.com.
  
  Regards,
  Yourself