Role accounts for existing mailing lists
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
GitLab provides a great and rich way of tracking issues and notifying users, including explict mention callouts, being able to watch projects, and even subscribe to labels. This works very well for projects fully committed to a web-first GitLab workflow, including greenfield projects, those coming from GitHub, internal company use, etc.
Integration with Slack & co also provides a great way for people using modern tooling and workflows to consume GitLab information by having it piped to those.
Many older open-source projects (e.g. the Linux kernel and much of low-level development) are still using much less modern tools, in particular mailing lists. For many projects on freedesktop.org, the mailing list is the primary method of communication; much of what would normally go on an issue tracker happens there. When the issue tracker is used, mailing lists are often CCed by the tracker, to inform everyone.
GitLab does not provide a sensible way of streaming information to mailing lists in the same way as it does to, e.g., Slack. Having such a way would be helpful for projects migrating to GitLab from legacy tooling and workflows.
Further details
gitlab-ce#4272 introduces the functionality of hosting a mailing list to GitLab, but that is orthogonal for all but the name. Many existing open-source projects would be unable to migrate to using GitLab mailing lists as it does not offer public archives; it would require rewriting from their existing list addresses (established for 20+ years) to the new ones, and would break old archive links. Enterprise users are likely unable to make use of them as they already have established mail services.
Creating a user with the list address would implement most of what is desired, but with some flaws:
- mailing lists never want to log in to your web service or make API calls
- if the list is publicly archived (Mailman or Google Group), sending a password-reset mail to the mailing list is not a good idea
- if reply-by-mail is enabled, messages in public archives give SMTP spammers a viable target to aim at
Phabricator implements user roles which at least fulfill the first two criteria.
Examples of lists which subscribe to the issue-tracker firehose include wayland-bugs and dri-devel, though there are many many more.
Proposal
What does success look like, and how can we measure that?
-
Mailing list subscriptions are expressed as a first-class concept in GitLab, being added and managed by instance or group/project admins -
Mailing lists can be used to subscribe to an issue firehose (all issues for a project/group, track particular labels, etc) -
In the outbound direction (GitLab -> list), having very rough feature parity with Slack integration
-
-
A 'mailing list' can never reset its password or log in -
Kernel developers who are uneasy about web-based workflows can consume information via their favourite CLI mail client and only interact with the web UI when required, making transition easier for established open-source projects
Links / references
/cc @victorwu