Process Proposal:

If a SIG misses two of their quarterly reports in a row, then the community manager should contact the members listed in the account system (monthly?) until they either miss a third report or respond.

If the SIG (a) fails to respond, (b) responds that the SIG completed the work it intended and no further work is required, or (c) responds that they’ve decided to abandon the effort - the following actions should be performed.

(a) An announcement should be sent to CentOS Devel indicating the SIG is reaching end of life. If members believe they can re-energize the SIG, this would be the time to stop the retirement.
(b) A board ticket should be opened for notification purposes only so the board can track if suddenly a bunch of SIGs drop off.
(c) A ticket should be opened with Infra to archive the SIG materials. Steps should be taken to account for both the desire to credit past members with their work and those members who wish to be de-listed from the archive.

Looks good to me. I like that it's light-weight.

I like it and I think if they've missed 2 reports, we're sitting at 6 months, and giving them another month to reply makes sense before we move to the (a) Announcement vs waiting another quarter.

Draft 2 Process Proposal:

If a SIG misses two of their quarterly reports in a row: then the community manager should contact the members listed in the account system. More than a single attempt at contact should be made. If the SIG responds they can be correctly categorized. If they do not respond within 45 days, they can be considered inactive.

If the SIG (a) fails to respond, (b) responds that the SIG completed the work it intended and no further work is required, or (c) responds that they’ve decided to abandon the effort - the following actions should be performed.

(1) An announcement should be sent to CentOS Devel indicating the SIG is reaching end of life. If members believe they can re-energize the SIG, this would be the time to stop the retirement.
(2) A board ticket should be opened for notification purposes only so the board can track if suddenly a bunch of SIGs drop off.
(3) A ticket should be opened with Infra to archive the SIG materials. Steps should be taken to account for both the desire to credit past members with their work and those members who wish to be de-listed from the archive.

Now that the Docs SIG formally exists, let's make sure to file an issue in their issue tracker to update the SIG guide once this policy is adopted.

Looks good to me, let's see what others think

This was approved during the December meeting. Leaving this open until we can get it in the Docs

@jcpunk : question about point (3) : I'd like to retire the Configmanagement SIG but wondering if :

• we should also delete existing FAS/ACO group (even if empty)
• we should still list the specific SIG GPG key on website (https://www.centos.org/keys/)
• just archiving artifacts (rpm or else) to https://vault.centos.org is also to be done

Ideally combining both items in the same process (board + infra) would help

I'm inclined to delete the FAS/ACO group and archive things to vault.centos.org.

I'm not sure if we should list retired keys there. Is there a workflow where one SIG is retired and then reformed years later? Having the "old" key and the "new" key on the same site might be a wonky experience.

@bstinson is there a preferred way you need keys handled due to secureboot requirements?

I think from last meeting this can be closed?

We should get it into our governance before closing this out.

PR in https://git.centos.org/centos/centos.org/pull-request/214

Thanks @jcpunk . Looks great.

Issue on the rebase of https://git.centos.org/centos/centos.org/pull-request/214 once that is fixed we can merge and close

merged