doc: Governance Roles

[stevenhorsman]

Update the contributor role descriptions and guidelines for review, based on the vPTG discussion

[ildikov]

Hi Steve,

Thank you for typing up the updates to the governance rules following the PTG discussion this week.

I added some suggestions to the wording inline, I think the content looks good and covers what we talked about at the PTG.

[ildikov]

Suggested change

	Maintainers are active Contributors and participants in the projects. In order to become a Committer, you must be nominated by established Committer and approved by quorum of the active Architecture committee via an issue against the community repo
	Committers are active Contributors and participants in the projects. In order to become a Committer, you must be nominated by established Committer and approved by quorum of the active Architecture committee via an issue against the community repo

[ildikov]

Suggested change

	One of the requirements to be a committer is that you are an active contributor to the project as adjudged by the above criteria. The committer list will be required for people who no longer meet the criteria
	One of the requirements to be a committer is that you are an active contributor to the project as adjudged by the above criteria. Assessing the list of active contributors happens twice a year,

[ildikov]

Suggested change

	twice a year, lining up with the Architecture Committee election cycle. At/after the election, people who are in the kata-containers-committer team, but who haven't been an active contributor in the last 12 months will be created
	lining up with the preparation for the Architecture Committee election cycle. At that time, the kata-containers-committer team will also be reviewed, and a list of people, who are on the team but haven't been an active contributor in the last 12 months, will be created

[ildikov]

Suggested change

	and shared with the Architecture Committee and community and after a short review period to check of errors in the tooling, will be removed from the team.
	and shared with the Architecture Committee and community. After a short review period, to allow time to check for any errors, inactive team members will be removed.

[ildikov]

Suggested change

	There are sometimes good reasons to temporarily give others admin access, such as to create a secret that is used in a particular CI infrastructure, but generally
	The Admin group is intentionally kept small, however, individuals can be granted temporary admin access to carry out tasks, like creating a secret that is used in a particular CI infrastructure.

[ildikov]

Suggested change

	we should try and minimise this access. The admin list should be reviewed and updated after each Architecture Committee election and typically contain:
	The Admin list is reviewed and updated after each Architecture Committee election and typically contains:

[ildikov]

Suggested change

	GitHub organization owners have complete admin access to the organization, so should be limited for security reasons. The owners list should be reviewed and updated after each Architecture Committee election and contain:
	GitHub organization owners have complete admin access to the organization, and therefore this group is limited to a small number of individuals, for security reasons. The owners list is reviewed and updated after each Architecture Committee election and contains:

[ildikov]

Suggested change

	* [Maintainer](#committer)
	* [Committer](#committer)

[stevenhorsman]

I added some suggestions to the wording inline, I think the content looks good and covers what we talked about at the PTG.

Thanks so much for the care review. I've incorporated your suggestions.

[fidencio]

There's one part that affects me the most, which is "admins".

I left my comment there, but I sincerely feel like we're taking a step on the wrong direction on this one.

[fidencio]

This part affects me the most, for instance.

I'm not part of the AC anymore, but I've been dealing -- maybe even more than AC members? -- with a lot of the admin stuff, ranging from setting up CI systems to simply unblocking PRs.

With this change, theoretically, I should have no access to do so, which will require a better velocity coming from the architecture committee.

More than that, adding someone to temporarily do something feels like a bureaucratic thing that would take more time than just having an AC member doing the thing. :-)

[stevenhorsman]

I'm not part of the AC anymore, but I've been dealing -- maybe even more than AC members? -- with a lot of the admin stuff, ranging from setting up CI systems to simply unblocking PRs.

With this change, theoretically, I should have no access to do so, which will require a better velocity coming from the architecture committee.

So I think that in this circumstances you would probably fall into the

Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to manage the CI)

category, but we also don't want to cover over the problem of the AC not being responsive, so should try and address that as well.

More than that, adding someone to temporarily do something feels like a bureaucratic thing that would take more time than just having an AC member doing the thing. :-)

The idea of temporarily adding is based on things that I've had to do in the CAA repo. People setting up CI wanted to add secrets e.g. AZURE_SUBSCRIPTION_ID that are required in our infrastructure and whilst they could have given an admin the secret and asked them to add it, that doesn't feel like a secure process. An example of this closer to home is when you/Gaby recently added ITA_KEY secret (assuming this is sensitive, if not then sorry for the bad example). If you didn't have access would you (or rather Intel) have preferred to be given admin access temporarily to add that, or to send the secret to the AC for them to add (and therefore have access). I don't believe that anyone on the AC would be interested in exploiting secrets, but speaking personally, I'd rather not be involved in handling any that I don't own.

If you don't think this is a concern and others agree, then it would be more secure to block this, so I can remove it from the proposal.

[fidencio]

People setting up CI wanted to add secrets e.g. AZURE_SUBSCRIPTION_ID that are required in our infrastructure and whilst they could have given an admin the secret and asked them to add it, that doesn't feel like a secure process.

This makes sense, indeed.

[fidencio]

I understand we're taking a security measure to prevent something to happen. However, the community has always been based on trust and work being done.

Having this feels like we're shooting ourselves in the foot, as either you're an AC member, member of OIF, or you depend on their own criteria (regardless of them being actually active or not) to decide who'll be actually helping the project.

Now, if we want to go through a formal process, I'd strongly recommend that any change in the admin side would have to go through a vote and the majority of the admins would have to agree before it happens (including secrets being added, machines being added, PRs being merged, etc). The malicious actor may come from anywhere, including AC / OIF.