Page MenuHomePhabricator

Decide on future of public services@ mailing list (which has no maintainers)
Open, LowPublic

Description

Re: https://lists.wikimedia.org/mailman/listinfo/services
Last posting in April 2019.

Nobody moderates the moderation queue (77 hold messages).

Someone from Services please provide input / guidance. Close? If not, please propose/set up list moderators. Also see T78815. Thanks.

Event Timeline

The current list admins are gwicke and mobrovac, neither of who have access to their wikimedia.org emails anymore I'd assume.

Aklapper renamed this task from Decide on future of public services@ mailing list to Decide on future of public services@ mailing list (which has no maintainers).Mar 26 2021, 6:36 PM

Imho it should be part of offboarding workflows to check for list adminship and replace them with new admins.

Imho it should be part of offboarding workflows to check for list adminship and replace them with new admins.

This is T248384: Delete email addresses with privileged @domain names from mailing lists at offboarding.

I've replied on the list, but we use this in citoid as a contact point for crossref to report traffic issues from us (I hope none of those are stuck in moderation :( ). If deleted we'd need to replace it with a different email; open to suggestions.

( Any chance I could temporarily be an admin so I can check the ones held in moderation? )

Mentioned in SAL (#wikimedia-operations) [2021-04-28T18:21:05Z] <legoktm> added mvolz as listadmin for services@ and reset admin pw (T278516)

I've replied on the list, but we use this in citoid as a contact point for crossref to report traffic issues from us (I hope none of those are stuck in moderation :( ). If deleted we'd need to replace it with a different email; open to suggestions.

Typically noc@wm.o (goes to all SRE) is the entrypoint for external entities to reach out to us for traffic/abuse issues, we could either forward them onto you or set up a different alias that includes noc@ and you.

( Any chance I could temporarily be an admin so I can check the ones held in moderation? )

Done, you should have received an email with the new list admin password.

I've replied on the list, but we use this in citoid as a contact point for crossref to report traffic issues from us (I hope none of those are stuck in moderation :( ). If deleted we'd need to replace it with a different email; open to suggestions.

Typically noc@wm.o (goes to all SRE) is the entrypoint for external entities to reach out to us for traffic/abuse issues, we could either forward them onto you or set up a different alias that includes noc@ and you.

That seems much more sensible than using a members-only list. :). I'll update it and then we can delete this list if no one else objects for another reason.

( Any chance I could temporarily be an admin so I can check the ones held in moderation? )

Done, you should have received an email with the new list admin password.

Thanks, it was all spam :)

Change 683563 had a related patch set uploaded (by Mvolz; author: Mvolz):

[operations/deployment-charts@master] Switch to a different contact email

https://gerrit.wikimedia.org/r/683563

Change 683570 had a related patch set uploaded (by Mvolz; author: Mvolz):

[mediawiki/services/zotero@master] Change crossRef contact email

https://gerrit.wikimedia.org/r/683570

for the record: it's also possible to request a shared google group that acts like a shared inbox for multiple people. So you can actually see which mail was read or acted upon on the group level. We do this for maint-announce mails.

Of course this still is a members-only group and group members need to be managed, but that seems to always be the case. noc@ itself is also a members-olny group, via the redirect to root users.

We can also do a special alias that does "forward to noc@ AND some other team email of the services team" but then it seems like the services mailing list we are about to remove here already was the team email address. Or is there another existing group address that is nowadays your team, @Mvolz?

What we should avoid though is having an alias that does "noc AND mvolz" in SRE controlled exim config. We are trying to get away from individual names there.

Yet another way is to ask the Google admins to make a special alias that just forwards to $team and use that.

Change 683570 merged by jenkins-bot:

[mediawiki/services/zotero@master] Change crossRef contact email

https://gerrit.wikimedia.org/r/683570

Change 683563 merged by jenkins-bot:

[operations/deployment-charts@master] Switch to a different contact email

https://gerrit.wikimedia.org/r/683563

Change 685747 had a related patch set uploaded (by Mvolz; author: Mvolz):

[operations/deployment-charts@master] Update Zotero to use new email for crossRef

https://gerrit.wikimedia.org/r/685747

Change 685751 had a related patch set uploaded (by Mvolz; author: Mvolz):

[operations/deployment-charts@master] Bump chart version to use new crossref e-mail

https://gerrit.wikimedia.org/r/685751

Change 685751 merged by jenkins-bot:

[operations/deployment-charts@master] Bump chart version to use new crossref e-mail

https://gerrit.wikimedia.org/r/685751

Change 685747 merged by jenkins-bot:

[operations/deployment-charts@master] Update Zotero to use new email for crossRef

https://gerrit.wikimedia.org/r/685747

for the record: it's also possible to request a shared google group that acts like a shared inbox for multiple people. So you can actually see which mail was read or acted upon on the group level. We do this for maint-announce mails.

Of course this still is a members-only group and group members need to be managed, but that seems to always be the case. noc@ itself is also a members-olny group, via the redirect to root users.

We can also do a special alias that does "forward to noc@ AND some other team email of the services team" but then it seems like the services mailing list we are about to remove here already was the team email address. Or is there another existing group address that is nowadays your team, @Mvolz?

Thanks! Services team no longer exists. It was rolled into core platform, I think! (And I was never in services!)

What we should avoid though is having an alias that does "noc AND mvolz" in SRE controlled exim config. We are trying to get away from individual names there.

Yet another way is to ask the Google admins to make a special alias that just forwards to $team and use that.

This is now deployed, using noc@wikimedia.org, so it is fine to now archive/delete the list.

I've now changed the settings to respond with the following message to all new posts to the list:

This list has been decommissioned and is no longer accepting new
messages.  See https://phabricator.wikimedia.org/T278516 for further
details.