Send RFC to LLVM to gather requirements before disabling -commits lists

[rnk]

As outlined in the mailing list archive issue, the *-commits and *-bugs email lists are the highest traffic Mailman lists still running on lists.llvm.org. These services still represent a maintenance burden, they are a potential source of spam, and we would like to disable them if possible. In order to do that, we need to first gather requirements. We need to understand what they are still being used for, and identify alternative solutions for those use cases. This means putting together an RFC to gather input.

I'm trying to shop this task around to my reports.

[asl]

I just checked and it seems at least emails on llvm-bugs ML is opened by 1-2k users daily.

[tlattner]

I just checked and it seems at least emails on llvm-bugs ML is opened by 1-2k users daily.

Are these hits to the list archives webpages? Can we confirm these are not crawlers?

[asl]

No, these are not to archives. These are to live emails sent.

[tlattner]

Ok, got it. These are number of subscribers then? I assume no way to know if people are actually reading them?

[asl]

This is the number of distinct opens. We are tracking them

[tlattner]

Interesting. What are you using to track it? I didn't realize you had added this.

[asl]

This is the standard Mailgun feature. We are using Mailgun to send emails from GH actions.

[tlattner]

Ah ok. It just seems high because we only have 391 subscribers to llvm-bugs. I don't know on average how many bugs get created per day though which would then factor into email views.

[rnk]

Arthur held the RFC, and folks raised the issue that any workflow they set up using Phabricator will be disrupted by any future migration to GitHub Pull Requests. I can't honestly tell people that migration to pull requests won't happen in the next two years, so in the spirit of not disrupting existing workflows, I think it makes sense to leave the -commits lists running.

If spam begins to become a concern, we can reconsider disabling the mailing lists, or explore other options, such as blocking all non-commit email. I'm not sure how easy that is.

However, I think we should update the developer policy and other docs to remove mentions of subscribing to llvm-commits, and replace those with new links or descriptions of new workflows that accomplish the same objectives.

[rnk]

@aeubanks

[ChristianKuehnel]

postponing the topic until he have a decision on pull requests