#79 Recording historical SIG membership
Closed 2 years ago by spotz. Opened 2 years ago by jcpunk.

As folks move on to new roles or interests, they may leave a SIG. When they do leave, they will by necessity drop off the active members list. Today, when folks drop off the active members list, there isn't a clear place or method to record historical membership.

The work these folks are doing is valuable to the CentOS project and we should have a way of recording alumni/former members.

I'd like to open the discussion here with our existing SIGs to see what process we can arrive at which captures this data, but doesn't create an extra record keeping burden.

Would existing SIGs be willing to keep a membership list within their https://sigs.centos.org/ repo? Is another place better?


(infra / sig member comment here)

Well, the group membership at IPA/noggin level should be reflecting the SIG group as that's what is used to grant/revoke access to koji/cbs.centos.org (and eventually to other things under centos infra control) , and it's all visible directly through noggin ui (https://accounts.centos.org/group/sig-<name>) or can be queried through fasjson (https://fasjson.fedoraproject.org)

So part of the onboarding process is : someone with sponsor right for that group can add. Then if someone wants to leave, someone with sponsor right can just remove it from the group.

If that's a SIG chair himself leaving, they should elect at least another chair, and then ask for new elected chair (normally/hopefully a sig member already) to be promoted as "sponsor" for that group, and demoting previous chair (or removing if leaving the sig completely)

Does that make sense ?

+1 in having a record of both active and historical list of members to recognize the work done.

Well, the group membership at IPA/noggin level should be reflecting the SIG group as that's what is used to grant/revoke access to koji/cbs.centos.org (and eventually to other things under centos infra control) , and it's all visible directly through noggin ui (https://accounts.centos.org/group/sig-<name>) or can be queried through fasjson (https://fasjson.fedoraproject.org)

Does this contain historical information of previous membership?

Metadata Update from @jcpunk:
- Issue assigned to jcpunk

2 years ago

Well, the group membership at IPA/noggin level should be reflecting the SIG group as that's what is used to grant/revoke access to koji/cbs.centos.org (and eventually to other things under centos infra control) , and it's all visible directly through noggin ui (https://accounts.centos.org/group/sig-<name>) or can be queried through fasjson (https://fasjson.fedoraproject.org)

Does this contain historical information of previous membership?

That's what I thought something that is used for authentication would have as audit trail (including who did what, and so history for adding/removing users) but it seems (Free)IPA doesn't do that nor record anything like that, so no.
And because group memberships is really what triggers the rights/permissions in infra/apps, documenting that "manually" through a wiki page (or else) isn't appropriate. Ideally a kind of simple script that would parse group memberships and reflect that in a git repo (to track changes) or else would work but "async"

Ideally a kind of simple script that would parse group memberships and reflect that in a git repo (to track changes)

That sounds wonderful, is that something the infra sig would be able/willing to write/host/run?

Ideally a kind of simple script that would parse group memberships and reflect that in a git repo (to track changes)

That sounds wonderful, is that something the infra sig would be able/willing to write/host/run?

That sounds like a candidate for a ticket on https://pagure.io/centos-infra/issues that will be tagged as "feature-request" and that can be eventually worked on (at least in backlog) :-)

This issue is being tracked and worked on by Infra as noted. If there is nothing else needed by the Board we will close this issue out on 11/23/2022

This should have been closed already from our side

Metadata Update from @spotz:
- Issue status updated to: Closed (was: Open)

2 years ago

Log in to comment on this ticket.

Metadata