Mailing List Options

dev@, private@, commits@

Collaborative open source projects, at Apache and elsewhere, typically generate many different kinds of email.

Public:

• dev-discussion
• user-discussion
• release-announcements
• security-announcements
• version-control-changes
• issue-tracker-changes
• wiki-changes
• ci-notifications
  

Private:

• personnel-discussion
• security-discussion
• legally-sensitive-ip-discussion (trademark, copyright, patent, etc)
  

At Apache, every top-level project must maintain a minimum of two mailing lists – dev@PROJECT.apache.org and private@PROJECT.apache.org:

• dev@ – all public emails
• private@ – all private emails
  

Projects generally request additional lists. The exact configuration is up to the project – only the names dev@ and private@ are mandated. It is common to start off with three lists:

• private@ – all private emails.
• commits@ – version-control-changes, possibly wiki-changes, possibly issue-tracker-changes. Replies go to dev@.
• dev@ – everything else.
  

Other lists

user@

The ASF encourages shunting user-discussion traffic to the dev@ list at first for the sake of community building. However, projects with sustained high volume on their dev lists may request a separate user@ list. (Historically, user@ lists were de rigueur, but this is no longer the case.)

notifications@ / issues@ / ci@

Some projects configure their issue tracker to send its notifications to their dev list. This tends to shunt dev-discussion traffic through the issue tracker, which may be good or bad depending on your perspective. Some contributors may prefer the web interface of the issue tracker over email; on the other hand, newbies and lurkers may find the proliferation of poorly formatted, often irrelevant autogenerated emails tiresome.

Sending continuous integration traffic to the dev list is similarly controversial: some see a broken build as an opportunity to get involved, while others resent the constant deluge of autogenerated email.

Projects which prioritize keeping the signal-to-noise ratio of their dev list high and keeping people on the periphery engaged may choose to shunt issue-tracker-changes, ci-notifications, and occasionally wiki-changes onto either a combined notfications@ list, dedicated lists such as issues@
or ci@, or possibly the commits list. Such lists are typically configured so that replies go to the dev list.

announce@

Projects are encouraged to send release-announcements and security-announcements to the ASF-wide announce@apache.org list in addition to their dev@ and user@ lists. A handful of projects also maintain a dedicated project-specific announce@ list as a fourth channel for announcements.

general@, subproject-dev@

Historically, some top-level projects have served as "umbrella" projects comprising many subprojects, necessitating separate subproject dev lists and a
general@ list for shared concerns. Umbrella projects are now discouraged, so such lists are rarely needed any more.