That’s because a lot of other things are also using Slack. On the other hand, I had to disable notifications from Slack due to people misusing it to DM me instead of sending emails to the Secretary properly (unrelated to Log4j).
> On Oct 14, 2024, at 15:53, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > I can’t say I agree with that. It didn’t take me very long to get used to > using Slack. > > Ralph > >> On Oct 14, 2024, at 1:47 PM, Matt Sicker <m...@musigma.org> wrote: >> >> There’s a very, very small chance I’ll ever remember to visit a website to >> find out about what are essentially emails that could have been sent to me. >> I have a regular habit of reading email nearly every day, but developing new >> habits is unlikely to stick. >> >>> On Oct 14, 2024, at 14:50, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> >>> Maybe we just need to start contributing to PonyMail to improve the UI to >>> eliminate actually needing the email delivered to our accounts. >>> >>> I am only 1/4 serious about this. There has to be a better solution. >>> >>> Ralph >>> >>>> On Oct 14, 2024, at 10:25 AM, Matt Sicker <m...@musigma.org> wrote: >>>> >>>> I didn’t get the original email in this thread once again, so I think I’d >>>> support trying somewhere else to host discussions. Besides archiving those >>>> messages into a mailing list, it would be great if the solution provided >>>> allowed for email interactivity (e.g., you can reply to the notification >>>> of a message and it’s added to the thread appropriately; this is how >>>> GitHub notification emails typically work). >>>> >>>>> On Oct 10, 2024, at 05:40, 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. >>>> >>> >> >
