I thought this was recently discussed on @members, but now I can't find the thread! I'm not even sure if it was on @members, which exemplifies the scaling problem discussed on the list, among other issues: When you look at PonyMail's UI, there are about 60 internal mailing lists under the ' apache.org' project! How am I supposed to find anything? Searching my Gmail inbox didn't help, but I did not look for more than 30 seconds. Having to search yet another place...
This thread I can't find pointed to examples of Reddit like UIs from FOSS providers. I agree that GH rocks. One topic that remains and is a must, is that wherever the data lives, it must end up recorded on Apache-owned resources, which GH is not. Gary On Thu, Oct 10, 2024 at 7:07 AM Apache <ralph.go...@dslextreme.com> wrote: > I cannot express an opinion without knowing what the replacement is and > having experience with it. Mailing lists have one great feature - they are > easy to search. For that reason anything we choose should be just as easy > or better. We must also stick to a single medium for formal communication > for the same reason. > > We do have the ability to experiment with whatever we want but votes need > to continue here until we have ASF approval. > > Ralph > > > On Oct 10, 2024, at 3:41 AM, Christian Grobmeier <grobme...@apache.org> > wrote: > > > > 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. > >
