Unfortunately, pining a team only works inside the organization. So when pinging ansible-collections/cloud in an issue in a repository inside the ansible-collections organization the members of the team are pinged (and the name is clickable), but when pinging the same team from the ansible-build-data repository (which is inside the ansible-community organization) the team members will not get notified (and the team name isn’t clickable). What’s worse, the list of team members can only seen by folks who are members of the team’s organization themselves. (I can see the members for ansible-collections/cloud, for example, but others cannot.)
So now we have to figure out what to do. Some ideas:
Allow teams only from specific organizations that are part of Ansible, like ansible-collections, ansible-community, ansible-network, and ansible itself. Then at least the Ansible Community team can always look up the member list for us if we can’t see them ourselves.
Always request real GitHub usernames instead of team names. We will then likely quickly end up with no longer active names on our lists.
Use some automatism to update member lists automatically. This will likely only work for teams in Ansible controlled organizations. Also someone needs to set this up and maintain it.
…
If you have other ideas, please mention them here!
My main goal was to remove a wrong entry. @gotmax23 objection to not having any named maintainers anymore and the (imho good) argument from the new maintainers that they would prefer to not have to maintain a static list of staff in multiple places lead to the suggestion to use a GitHub team.
TBH I’ve never looked into collection metadata who I could ping for a specific collection. So I could live with missing maintainers, or not having maintainers documented there at all.
I can work on this. In the meantime, I guess I’m fine with merging the vmware.vmware_rest PR, but maybe let’s hold off on the other one that changes the rest of the cloud collections. Perfect is the enemy of good, and we can always adjust it later.
I would suggest removing the maintainers field from collection’s metadata entirely and forget about it.
It’s not gonna actually work.
you can’t be sure the lists are relevant , so we cannot rely on it.
If we need to ping maintainers, we’ll just open an issue in a corresponding repo (what we always do).
If there’s no response, the collection will get removed as maintainers responsiveness is a requirement.
So I suggest removing unnecessary and unreliable entities.
Maintainers should be interested in getting notified in a timely manner first of all, not SC or package release engineers should be interested in the maintainers being responsible.
It’s not hard to press the “Watch → All activity” button once in life:)
Ok. In any case I strongly disagree. We use this field to keep track of the maintainers mentioned in the initial inclusion application, and update it if possible. This allows us to ping who last officially was responsible for the collection. Obviously it might not be longer up to date, but it’s better than not having any contact.
(Even if this field would be part of the collection itself, it wouldn’t be much more trustworthy.)
@felixfontein i’m not strongly against of having it as it doesn’t hurt, though i don’t understand why we should care if they don’t care:)
The primary interested party in keeping their stuff included and resp responding to issues imo should be the maintainers, not the release engineers or SC.
Moreover, I think it can hurt actually, e.g. when you ping irrelevant people in issues (which can lost their work emails after quitting their companies), the other, relevant maintainers, can skip the stuff thinking those issues are addressed to someone else:) It’s safer to go directly to repos and raise issues there just for maintainers than to ping certain people in other places like, e.g. here.
I don’t think it’s a big deal though, so not strongly against of continuing to have that metadata field:)
from me.