Collection maintainer information for collections included in Ansible

In the collection metadata stored in ansible-build-data we also keep track of collection maintainers for some time now. Unfortunately these lists aren’t always up to date.

Recently two PRs (VMware collection maintainers by mariolenz · Pull Request #333 · ansible-community/ansible-build-data · GitHub, Standardize info for collections maintained by the Ansible Cloud Team by alinabuzachis · Pull Request #334 · ansible-community/ansible-build-data · GitHub) were created to update the maintainer information for some of the Ansible Cloud team maintained collections. It was proposed there to reference GitHub teams (for the Ansible Cloud team, that’s ansible-collections/cloud) instead of a list of GitHub usernames since the team members can change a lot, while the team stays.

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:

  1. Allow all team references. This was opposed by @gotmax23 for example (see VMware collection maintainers by mariolenz · Pull Request #333 · ansible-community/ansible-build-data · GitHub).
  2. 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.
  3. Always request real GitHub usernames instead of team names. We will then likely quickly end up with no longer active names on our lists.
  4. 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’ve started a discussion about Machine-readable maintainers file in collections once, but unfortunately that didn’t lead anywhere.


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:)

1 Like

I’ve never used this and don’t think I ever will, so :+1: from me.

I’m not sure what the maintainers field is in the collection metadata. Do you mean and the similar files in the other directories?

@felixfontein if the question is addressed to me, i think yes, i don’t remember the field to be in other places but who knows

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:)