doc: Governance Roles by stevenhorsman · Pull Request #415 · kata-containers/community

stevenhorsman · 2024-10-22T16:30:48Z

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 · 2024-10-22T20:54:54Z

README.md

-A Maintainer has the ability to merge code into the Kata Containers project. Maintainers are active Contributors and participants in the projects. In order to become a Maintainer, you must be nominated and approved by the established Maintainers. Maintainers have write access to the Kata Containers repos on GitHub.
+Kata Containers Committers (as defined by the [kata-containers-committer team](https://github.com/orgs/kata-containers/teams/kata-containers-committer))
+have the ability to merge code into the Kata Containers project.
+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


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 · 2024-10-22T20:59:52Z

README.md

+e.g. https://github.com/kata-containers/community/issues/403. Committers have write access to the Kata Containers repos on GitHub, which
+gives the ability to approve PRs, trigger the CI and merge PRs.
+
+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


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 · 2024-10-22T21:02:34Z

README.md

+gives the ability to approve PRs, trigger the CI and merge PRs.
+
+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
+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


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 · 2024-10-22T21:03:40Z

README.md

+
+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
+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
+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.


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 · 2024-10-22T21:06:08Z

README.md

+
+Kata Containers Admins (as defined by the [kata-containers-admin team](https://github.com/orgs/kata-containers/teams/kata-containers-admin) have admin access to
+the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others.
+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


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 · 2024-10-22T21:06:37Z

README.md

+Kata Containers Admins (as defined by the [kata-containers-admin team](https://github.com/orgs/kata-containers/teams/kata-containers-admin) have admin access to
+the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others.
+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
+we should try and minimise this access. The admin list should be reviewed and updated after each Architecture Committee election and typically contain:


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 · 2024-10-22T21:07:34Z

README.md

+
+### Owner
+
+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:


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 · 2024-10-22T21:08:18Z

README.md

    * [Developers](#developers)
        * [Contributor](#contributor)
-        * [Maintainer](#maintainer)
+        * [Maintainer](#committer)


Suggested change

* [Maintainer](#committer)

* [Committer](#committer)

stevenhorsman · 2024-10-23T08:41:02Z

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 · 2024-10-23T08:36:46Z

README.md

+
+Kata Containers Admins (as defined by the [kata-containers-admin team](https://github.com/orgs/kata-containers/teams/kata-containers-admin) have admin access to
+the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others.
+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


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

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.

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 · 2024-10-23T08:44:14Z

README.md

+### Admin
+
+Kata Containers Admins (as defined by the [kata-containers-admin team](https://github.com/orgs/kata-containers/teams/kata-containers-admin) have admin access to
+the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others.
+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.
+The Admin list is reviewed and updated after each Architecture Committee election and typically contains:
+- The Architecture Committee
+- Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to manage the CI)


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.

IMO this language is fine since it mostly codifies what is already roughly the current state of things.

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.

I suggest discussing adding this clause in another PR/issue since this PR has already been up for so long.

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.

I don't think the proposed text hampers trust in any way. People will still manage to gain admin powers if this is beneficial for the project. The concern is more around the housekeeping when people leave the project IMHO.

sprt

Thanks @stevenhorsman! No major objection from me.

sprt · 2024-12-03T21:03:46Z

README.md

 ## Developers

-For code contributors, there are currently two roles relevant to project governance:
+For contributors, there are several roles relevant to project governance:


To solidify "developer" as the umbrella term for all 4 roles:

Suggested change

For contributors, there are several roles relevant to project governance:

For Kata developers, there are several roles relevant to project governance:

sprt · 2024-12-03T21:08:36Z

README.md

 ## Architecture Committee

-The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Maintainers disagree. It is comprised of 7 members, who are elected by contributors.
+The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by contributors.


In general in this doc I would use:

"Contributor" (capitalized) to refer to the specific Contributor developer role.

"developer" to refer broadly to the 4 developer roles.

Suggested change

The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by contributors.

The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by Contributors.

I think I've updated based on your suggestions...

sprt · 2024-12-03T21:09:51Z

README.md

+### Committer

-A Maintainer has the ability to merge code into the Kata Containers project. Maintainers are active Contributors and participants in the projects. In order to become a Maintainer, you must be nominated and approved by the established Maintainers. Maintainers have write access to the Kata Containers repos on GitHub.
+Kata Containers Committers (as defined by the [kata-containers-committer team](https://github.com/orgs/kata-containers/teams/kata-containers-committer))


Note that this link isn't public - you have to be an org member to access it. We may or may not want to keep it here.

So I think we'd also publish the proposed committers twice a year under these proposals. I think for github permissions we have to have that team as the primary source of committers though.

sprt · 2024-12-03T21:11:30Z

README.md

-A Maintainer has the ability to merge code into the Kata Containers project. Maintainers are active Contributors and participants in the projects. In order to become a Maintainer, you must be nominated and approved by the established Maintainers. Maintainers have write access to the Kata Containers repos on GitHub.
+Kata Containers Committers (as defined by the [kata-containers-committer team](https://github.com/orgs/kata-containers/teams/kata-containers-committer))
+have the ability to merge code into the Kata Containers project.
+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


Typos

Suggested change

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

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

sprt

LGTM!

sprt · 2025-03-06T22:00:20Z

README.md

-A Maintainer has the ability to merge code into the Kata Containers project. Maintainers are active Contributors and participants in the projects. In order to become a Maintainer, you must be nominated and approved by the established Maintainers. Maintainers have write access to the Kata Containers repos on GitHub.
+Kata Containers Committers (as defined by the [kata-containers-committer team](https://github.com/orgs/kata-containers/teams/kata-containers-committer))
+have the ability to merge code into the Kata Containers project.
+Committers are active Contributors and participants in the project. 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


Suggested change

Committers are active Contributors and participants in the project. 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 project. In order to become a Committer, you must be nominated by an established Committer and approved by quorum of the active Architecture Committee via an issue against the community repo

Fixed - thanks!

sprt · 2025-03-06T22:18:40Z

README.md

+### Admin
+
+Kata Containers Admins (as defined by the [kata-containers-admin team](https://github.com/orgs/kata-containers/teams/kata-containers-admin) have admin access to
+the kata-containers repo, allowing them to do actions like, change the branch protection rules for repositories, delete a repository and manage the access of others.
+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.
+The Admin list is reviewed and updated after each Architecture Committee election and typically contains:
+- The Architecture Committee
+- Optionally, some specific people that the Architecture Committee agree on adding for a specific purpose (e.g. to manage the CI)


IMO this language is fine since it mostly codifies what is already roughly the current state of things.

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.

I suggest discussing adding this clause in another PR/issue since this PR has already been up for so long.

Update the contributor role descriptions and guidelines for review, based on the vPTG discussion Signed-off-by: stevenhorsman <steven@uk.ibm.com>

gkurz

/lgtm

Thanks @stevenhorsman and sorry for the insanely long delay before reviewing this.

stevenhorsman force-pushed the governance-roles-review branch 2 times, most recently from 93b9c1b to ea1e19b Compare October 22, 2024 16:38

ildikov requested changes Oct 22, 2024

View reviewed changes

stevenhorsman force-pushed the governance-roles-review branch from ea1e19b to 69ae07d Compare October 23, 2024 08:40

fidencio reviewed Oct 23, 2024

View reviewed changes

sprt reviewed Dec 3, 2024

View reviewed changes

stevenhorsman force-pushed the governance-roles-review branch 2 times, most recently from f57962b to 4723bbd Compare December 4, 2024 15:49

stevenhorsman marked this pull request as ready for review March 3, 2025 09:15

stevenhorsman mentioned this pull request Mar 3, 2025

Add @RuoqingHe to the maintainers list #419

Closed

sprt approved these changes Mar 6, 2025

View reviewed changes

doc: Governance Roles

6c29767

Update the contributor role descriptions and guidelines for review, based on the vPTG discussion Signed-off-by: stevenhorsman <steven@uk.ibm.com>

stevenhorsman force-pushed the governance-roles-review branch from 4723bbd to 6c29767 Compare March 7, 2025 09:27

gkurz approved these changes Mar 11, 2025

View reviewed changes

ildikov approved these changes Mar 11, 2025

View reviewed changes

gkurz merged commit 2207fe5 into kata-containers:main Mar 11, 2025
3 checks passed

stevenhorsman deleted the governance-roles-review branch June 23, 2025 15:42

	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

	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,

	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

	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.

	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.

	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:


		### Owner

		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:

	For contributors, there are several roles relevant to project governance:
	For Kata developers, there are several roles relevant to project governance:

	The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by contributors.
	The Architecture Committee is responsible for architectural decisions, including standardization, and making final decisions if Committers disagree. It is comprised of 7 members, who are elected by Contributors.

Conversation

stevenhorsman commented Oct 22, 2024

Uh oh!

ildikov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stevenhorsman commented Oct 23, 2024

Uh oh!

fidencio left a comment

Choose a reason for hiding this comment

Uh oh!

fidencio Oct 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fidencio Oct 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkurz Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sprt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sprt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gkurz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

fidencio Oct 23, 2024 •

edited

Loading

fidencio Oct 23, 2024 •

edited

Loading

gkurz Mar 11, 2025 •

edited

Loading