I will be the jerk to ask why we should choose a Google Group rather than a Mailman list. Is this sensitive data that needs to be hidden from the community? Will there ever be a potential for non-WMF staff subscribers? Is there another compelling business need like an associated Google Drive shared folder or easy Google Calendar invite management that makes a Google Group a more relevant solution than a FOSS-backed mailing list?

In T361262#9671474, @bd808 wrote:

I will be the jerk to ask why we should choose a Google Group rather than a Mailman list. Is this sensitive data that needs to be hidden from the community? Will there ever be a potential for non-WMF staff subscribers? Is there another compelling business need like an associated Google Drive shared folder or easy Google Calendar invite management that makes a Google Group a more relevant solution than a FOSS-backed mailing list?

Hi @bd808, thank you for sharing your insights.

I suggested a Google Group primarily because our emails are already integrated with Gmail, facilitating an effortless opt-in mechanism for SREs interested in these notifications. This approach also introduces an easy opt-out option, which our current system lacks. As outlined in the task, this is merely a proposed solution given our existing tools.

While a Mailman list appears to be a viable alternative, it might not address the fundamental issue at hand—the volume of non-critical emails flooding SREs' inboxes. Transitioning to a Mailman list might just shift the problem to a different platform without truly resolving it. Furthermore, considering that SREs often resort to Gmail filters to manage this influx, it's unlikely that non-WMF staff would find a subscription to such a list appealing.

Ultimately, the challenge isn't the medium through which we dispatch these notifications but the nature of the emails themselves.

The focus should be on alerts that are both actionable and relevant. Currently, the reprepro email alerts fail to meet these criteria for most SREs. Therefore, we might want to consider redirecting these alerts or discontinuing them altogether to mitigate unnecessary inbox clutter.

In T361262#9671541, @andrea.denisse wrote:

because our emails are already integrated with Gmail, facilitating an effortless opt-in mechanism for SREs interested in these notifications

This doesn't sound like anything special in the client's mail provider, but maybe you are assuming that SREs are not otherwise using public or private Mailman lists and thus would not be familiar with the subscription interface?

Furthermore, considering that SREs often resort to Gmail filters to manage this influx, it's unlikely that non-WMF staff would find a subscription to such a list appealing.

Never underestimate the curiosity and interest in mundane technical details of the technical community. Taavi knew more about WMF operational internals than many full-time paid staff SREs before he finished his upper secondary education.

Ultimately, the challenge isn't the medium through which we dispatch these notifications but the nature of the emails themselves.

The struggle against the ease of use of non-libre and community excluding solutions is very real and very challenging.

Hi @bd808 thanks for kindly sharing your insights.

I appreciate the time you’ve taken to engage with the points I’ve raised. However, I'd like to address a few elements in our conversation to ensure we're moving forward constructively.

Your points bring up several important considerations, but they seem to diverge from the initial argument's core through various logical fallacies. I also perceive an undercurrent of sealioning in our dialogue, where persistent questioning diverts us from productive discussions.

maybe you are assuming that SREs are not otherwise using public or private Mailman lists and thus would not be familiar with the subscription interface?

For instance, this is a loaded question suggesting that my proposal is based on an assumption that SREs are not familiar with Mailman lists. This shifts the focus away from the practicality and ease of Gmail integration, which was the crux of my argument. This also resembles a strawman fallacy, where the original stance is misrepresented rather than directly countered.

Never underestimate the curiosity and interest in mundane technical details of the technical community. Taavi knew more about WMF operational internals than many full-time paid staff SREs before he finished his upper secondary education.

Furthermore, while I respect the anecdotal evidence about individual capabilities and interests within our community, generalizing based on singular experiences seems like a hasty generalization based on anecdotal evidence that may not fully encompass the wide range of perspectives and experiences within our entire community.
In addition to this, this comment reflects a meritocratic view of reality that ignores the structural differences within the members of our community and full-time paid staff SREs which doesn't align with our values.

Your comments also suggest an assumption that I underestimate our community's curiosity and engagement, which is far from my intentions or beliefs and it's something I never did or said. This can be seen as an argumentum ad hominem and I'd greatly appreciate it if you could stop making such assumptions.

The struggle against the ease of use of non-libre and community excluding solutions is very real and very challenging.

This comment looks like it aims to evoke an emotional response (argumentum ad passiones) based on a false dichotomy regarding the use of proprietary vs. open-source (libre) solutions. This diverts from the discussion by framing it as a moral or ideological struggle, rather than focusing on the practical aspects of the notification system being discussed. In addition to this, my intention never was to exclude our communities by using a proprietary solution (that we're already using) and implying so is an association fallacy.

In moving forward, I hope we can continue this discussion with an emphasis on constructive, solution-focused dialogue that aligns with our values and follows the Effective and Responsible Communications guidelines.

The last comment is reading some things into its previous comment which could also be taken differently, and unfortunately seems to make some assumptions while (ironically) criticizing exactly that. This conversation is rather sad to see.

Hi @Aklapper , thanks for your comment.

and unfortunately seems to make some assumptions

Could you elaborate on which assumptions I made? I didn't made any assumptions of @bd808 beliefs or ideas, but he did of me by asking loaded questions like:

maybe you are assuming that SREs are not otherwise using public or private Mailman lists and thus would not be familiar with the subscription interface?

I never assumed that, why say that? That's a loaded question.

Never underestimate the curiosity and interest in mundane technical details of the technical community.

I have never done underestimated our community in any way, why even say that? Saying it implies that I'm underestimating our community which I have never done, I'm grateful for all the things they do and I appreciate the diversity in our community.

So no, if someone bombards you with loaded questions and implies assumptions you don't have and you reply it's not the same, I didn't ask loaded questions nor made incorrect assumptions about someones beliefs or someones ideas.

One point of our values is:

I contribute to making spaces safe for people to express themselves.

I don't think that loaded questions, the use of logical fallacies, and incorrect assumptions is the right way to have discussions of technical topics, this just makes people not want to share their ideas as it's not a safe space to do so.

Another relevant point of our values are:

Assumptions and biases are at the root of most misunderstandings.
I communicate honestly, clearly, and with empathy.

The comment I replied to made several unnecessary assumptions that I already mentioned and did it without empathy, diverting us from the root of the issue.