Hi I am generally open to such experiments. I would start with the easiest parts, such as users@, and see where it goes.
I would advise against mirroring it to users@ behind the scenes, as it may cause privacy problems (we need user consensus to mirror it). When a user uses GitHub, they know what to expect. As for Discourse, many use that now, but I find it very overwhelming and stressful. I prefer the clean Github discussions approach. I haven't checked against ASF policies but feel positive about this move for the arguments you have given Kind regards Christian On Thu, Oct 10, 2024, at 10:58, Volkan Yazıcı wrote: > *Abstract:* Modern email system security measures make it practically > impossible for mailing lists to work – many subscribers don't get all > emails. This not only hinders communication, but blocks an inclusive > one. *Shall > we, as Logging Services, experiment with alternatives?* > > *Motivation #1: mailing lists technically don't work* > > Several widely-used email providers (GMail, Yahoo, iCloud, etc.) have in > the last couple of years enabled new measures (DMARC, SPF, DKIM, etc.) to > verify the authenticity of emails. In short, these measures enrich email > content with checksums and signatures capturing its authenticity. When a > mailing list system (e.g., ezmlm, mailman) receives such an email, it > performs several changes on its content (adds information about the mailing > list, etc.), and delivers it to all subscribers. When the mail server of a > subscriber receives such tampered mail, and if that mail server happens to > have earlier shared authenticity checks enabled, it discards the email, or > at best, marks it as spam. > > Ralph, Matt, Piotr stated many times that they don't receive all emails. > Ralph actually stated many ASF mailing list emails end up in his spam > box > <https://the-asf.slack.com/archives/CBX4TSBQ8/p1728032221080189?thread_ts=1727958807.348019&cid=CBX4TSBQ8>. > Recently we witnessed even Brian Proffitt (VP, Marketing & Publicity) > suffer > from the same problem > <https://lists.apache.org/thread/yfmrpjslcbo5jmsqqpvtok1o6lht11rb>. > INFRA > is crawling with related tickets: INFRA-24574 > <https://issues.apache.org/jira/browse/INFRA-24574>, INFRA-24790 > <https://issues.apache.org/jira/browse/INFRA-24790>, INFRA-24845 > <https://issues.apache.org/jira/browse/INFRA-24845>, INFRA-24850 > <https://issues.apache.org/jira/browse/INFRA-24850>, INFRA-24872 > <https://issues.apache.org/jira/browse/INFRA-24872>, INFRA-25947 > <https://issues.apache.org/jira/browse/INFRA-25947>, INFRA-26171 > <https://issues.apache.org/jira/browse/INFRA-26171> – there are dozens > more. > > This technical difficulty is not only known to us. AFAIK, this is one of > the main reasons PSF (Python Software Foundation) decided to switch from > mailing lists to Discourse. Mailman documents several DMARC mitigations > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html>, > but I think these are workarounds/hacks rather than well-established > solutions. > > *Motivation #2: ezmlm is dead* > > ezmlm, the mailing list software ASF uses, is dead – it is neither > developed, nor maintained anymore. (Last official release was in 1997, > there > is the `ezmlm-idx` add-on, which later on became a successor > <https://untroubled.org/ezmlm/faq/What-is-the-difference-between-ezmlm-and-ezmlm_002didx_003f.html>, > which last produced a release in 2014, and so on. Long, dead story.) > INFRA > maintains a very big, sophisticated set of Perl rules for running ASF > ezmlm > instances. If you look closely at the INFRA tickets I cited above, some > suggest INFRA to fork ezmlm and fix some long standing bugs, etc. We can > discuss the possibility of migrating from ezmlm to mailman (yet another > mailing list software, but one that is still maintained), whether such a > migration should be practiced ASF-wide or only for Logging Services, > etc. > But eventually, we will still be using a mailing list, and as I tried to > explain above, IMO, they just don't work good. > > *Proposal #1: Experimenting with GitHub Discussions* > > GitHub is our development bread and butter. We use its tickets, PRs, > reviews, discussions, CI, security & code quality checks, etc. It works > perfectly and components are integrated well, i.e., you can link issues, > comments, PRs, CI runs, etc. Users like it too – we all witnessed the > sudden increase in user interactions after migrating to GitHub Issues > and > Discussions. We can configure sections & categories in Discussions > <https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-categories-for-discussions> > to make it serve as our main communication medium. It also provides mail > notifications and the possibility to respond to them for those who still > prefer their email client over a browser. > > In short, we can quickly configure Discussions, update our support policy > page, and start experimenting with it. > > One can raise the argument that what if Discussions disappear? We can > mirror communication there to a mailing list to be on the safe side. Yet, > we need to evaluate the necessity of this. > > *Proposal #2: Experimenting with Discourse* > > We can get a VM from INFRA and manage our Discourse instance. Though, > AFAIC, this will result in a "GitHub Discussions"-like setup with all the > integration goodies missing and added server maintenance burden. > > *F.A.Q.* > > *What if GitHub Discussions disappear?* > > In such a case, I presume they will allow us to download the existing > archives. In the worst case, we can decide to mirror the communication > there to a mailing list. Yet, we need to evaluate the necessity of this. In > particular, how big of a problem is this at the experimentation stage? > > *How will private communication work with GitHub Discussions?* > > We can create private repositories for internal/private communication. > For > users/researchers wanting to submit & discuss security issues, they can > get > in touch with us (either via email to `security@logging` or some other > ASF/INFRA mailing list), we can grant them permissions to collaborate > privately on a repository security advisory > <https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories> > . > > *Don't the ASF legals require mailing lists?* > > I am aware that several ASF policies require mailing list communication, > e.g., for voting and such. I first want to establish a consensus among us, > and then pitch to the board for exemption as a pilot. > > *Shouldn't this proposal be practiced ASF-wide?* > > This will be a very (very very very, actually!) daunting route to pursue. > I'd rather start small, solve our problem first (if we can), and then think > about widening the scope.
