[PROCESS CHANGE]: add a simple inactivity measure and process for removal

[lance]

The ROLES.md document was recently updated to more accurately reflect how the Knative organization should work with regards to a "contribution ladder" and methods of moving up and down that latter based on project contributions. What was not addressed in those changes was how to handle stepping away from the project or being removed for some reason.

This change is a first pass at addressing that omission. The text is taken directly from the CNCF contribution ladder template located here:

https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md#inactivity

What still remains unaddressed is what, if anything happens in peribolos. I think that should probably be stated somewhere in this document or another.

Clearly, when users step away from the project or WG leads change, they should be removed from teams that have elevated priviledges (writers, reviewers, admin, etc). To date, this just mostly means that they end up remaining members of the knative and knative-sandbox orgs, but no longer have write priveleges for specific repos or administrative capabilities.

It's not clear to me, however, what is the best way to deal with people stepping away from the project entirely or being removed for some cause (e.g. violation of the code of conduct). Users in the knative and knative-sandbox orgs in Peribolos already have restricted, read-only rights. Does it make sense to create an emeritus group to explicitly move these users into a recognized team that still has restricted, read-only rights but is recognized explicitly as no-longer contributing?

Related: #1383

/cc @knative/steering-committee

/kind documentation
/hold as WIP

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lance

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lance]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aliok]

(non-binding comment)

This change is a first pass at addressing that omission.

LGTM!

What still remains unaddressed is what, if anything happens in peribolos. I think that should probably be stated somewhere in this document or another.
...
Does it make sense to create an emeritus group to explicitly move these users into a recognized team that still has restricted, read-only rights but is recognized explicitly as no-longer contributing?

It is reasonable. @puerco mentioned in the call today that some SIG (can't remember which one) is doing it this way and I think it makes sense.

Thanks for driving this @lance

[lance]

I've added some verbiage around Peribolos changes. We should create that group before landing this PR.

[geekygirldawn]

Thanks for addressing this, and this looks like a good way of handling it.

[aliok]

I just saw this in the graduation criteria:

Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence.

This PR change addresses some of that requirement, which is great.

We also need an audit too. Let's not worry about that in this PR though.

[lance]

I have added an Emeritus group to Peribolos, and included for now @abrennan89 and @jcrossley3 since they have both definitely stepped away from the project. I think actually moving other folks who have stopped contributing should happen in a separate PR. This is just being done for illustrative purposes.

[aliok]

I have added an Emeritus group to Peribolos

ping @knative/productivity-leads

[upodroid]

The best course of action is removing someone from GitHub teams. Privileges are granted via GitHub Teams and prow checks GitHub Teams when considering /approve commands.

Being an org member is effectively having 0 permissions given we don't have private repos.

emeritus_approvers aren't that helpful as there should be no GitHub usernames in any OWNERS files.

[upodroid]

Projects can add emeritus_approvers to OWNERS files to thank someone but approvers and reviewers should be GitHub Teams

[lance]

@knative/productivity-leads et. al. I've made some changes to the text, removing the emeritus team and simplifying the process of voluntary and involuntary removal. PTAL 🙏 /cc @geekygirldawn @aliok

[lance]

/unhold

[psschwei]

+1 from me (though I'm not on steering, so don't think my vote counts 😄 )

[lance]

+1 from me (though I'm not on steering, so don't think my vote counts 😄 )

@knative/steering-committee ptal

[upodroid]

/retest

[csantanapr]

I took @aliok recommendation and committed

[csantanapr]

/lgtm

[jberkus]

Belatedly, +1 from me.