Skip to content

Commit 59f0c34

Browse files
pdettoripdettori
authored
Merge pull request rossoctl#1311 from kagenti/docs/governance
docs: Add governance docs
2 parents 32d404b + b6f631c commit 59f0c34

3 files changed

Lines changed: 298 additions & 28 deletions

File tree

‎CONTRIBUTOR_LADDER.md‎

Lines changed: 126 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,126 @@
1+
# Contributor Ladder
2+
3+
* [Contributor Ladder](#contributor-ladder)
4+
* [Contributor](#contributor)
5+
* [Maintainer](#maintainer)
6+
* [Inactivity](#inactivity)
7+
* [Involuntary Removal](#involuntary-removal-or-demotion)
8+
* [Stepping Down/Emeritus Process](#stepping-downemeritus-process)
9+
* [Contact](#contact)
10+
11+
## Contributor Ladder
12+
13+
Hello! We are excited that you want to learn more about the Kagenti contributor
14+
ladder! This contributor ladder outlines the different contributor roles within
15+
the project, along with the responsibilities and privileges that come with them.
16+
Community members generally start at the first levels of the "ladder" and
17+
advance up it as their involvement in the project grows. Our project members are
18+
happy to help you advance along the contributor ladder.
19+
20+
Each of the contributor roles below is organized into lists of three types of
21+
things. "Responsibilities" are things that a contributor is expected to do.
22+
"Requirements" are qualifications a person needs to meet to be in that role, and
23+
"Privileges" are things contributors on that level are entitled to.
24+
25+
### Contributor
26+
27+
Description: A Contributor contributes directly to the project and adds value to
28+
it. Contributions need not be code. People at the Contributor level may be new
29+
contributors, or they may only contribute occasionally.
30+
31+
* Responsibilities include:
32+
* Follow the [Code of Conduct](CODE_OF_CONDUCT.md)
33+
* Follow the project contributing guide
34+
* Requirements (one or several of the below):
35+
* Report and sometimes resolve issues
36+
* Occasionally submit PRs
37+
* Contribute to the documentation
38+
* Show up at meetings, takes notes
39+
* Answer questions from other community members
40+
* Submit feedback on issues and PRs
41+
* Test releases and patches and submit reviews
42+
* Run or helps run events
43+
* Promote the project in public
44+
* Help run the project infrastructure
45+
* Privileges:
46+
* Invitations to contributor events
47+
* Eligible to become a Maintainer
48+
49+
### Maintainer
50+
51+
Description: Maintainers are very established contributors who are responsible
52+
for the entire project. As such, they have the ability to approve PRs against
53+
any area of the project, and are expected to participate in making decisions
54+
about the strategy and priorities of the project.
55+
56+
A Maintainer must meet the responsibilities and requirements of a Contributor,
57+
plus:
58+
59+
* Responsibilities include:
60+
* Reviewing at least 20 PRs per year, especially PRs that involve multiple
61+
parts of the project
62+
* Mentoring new Contributors
63+
* Writing refactoring PRs
64+
* Determining strategy and policy for the project
65+
* Participating in, and leading, community meetings
66+
* Requirements
67+
* Experience as a Contributor for at least 3 months
68+
* Demonstrates a broad knowledge of the project across multiple areas
69+
* Is able to exercise judgment for the good of the project, independent of
70+
their employer, friends, or team
71+
* Mentors other contributors
72+
* Can commit to spending at least 5 hours per month working on the project
73+
* Additional privileges:
74+
* Approve PRs to any area of the project
75+
* Represent the project in public as a Maintainer
76+
* Have a vote in Maintainer decision-making meetings
77+
78+
Process of becoming a Maintainer:
79+
80+
1. Any current Maintainer may nominate a current Contributor to become a new
81+
Maintainer, by opening a PR against the root of the
82+
[kagenti repository](https://github.com/kagenti/kagenti) adding the nominee
83+
to MAINTAINERS.md.
84+
2. The nominee will add a comment to the PR testifying that they agree to all
85+
requirements of becoming a Maintainer.
86+
3. A majority of the current Maintainers must then approve the PR.
87+
88+
## Inactivity
89+
90+
It is important for contributors to be and stay active to set an example and
91+
show commitment to the project. Inactivity is harmful to the project as it may
92+
lead to unexpected delays, contributor attrition, and a loss of trust in the
93+
project.
94+
95+
* Inactivity is measured by:
96+
* Periods of no contributions for longer than 6 months
97+
* Periods of no communication for longer than 6 months
98+
* Consequences of being inactive include:
99+
* Involuntary removal or demotion
100+
* Being asked to move to Emeritus status
101+
102+
## Involuntary Removal or Demotion
103+
104+
Involuntary removal/demotion of a contributor happens when responsibilities and
105+
requirements aren't being met. This may include repeated patterns of inactivity,
106+
extended period of inactivity, a period of failing to meet the requirements of
107+
your role, and/or a violation of the Code of Conduct. This process is important
108+
because it protects the community and its deliverables while also opening up
109+
opportunities for new contributors to step in.
110+
111+
Involuntary removal or demotion is handled through a vote by a majority of the
112+
current Maintainers.
113+
114+
## Stepping Down/Emeritus Process
115+
116+
If and when contributors' commitment levels change, contributors can consider
117+
stepping down (moving down the contributor ladder) vs moving to emeritus status
118+
(completely stepping away from the project).
119+
120+
Contact the Maintainers about changing to Emeritus status, or reducing your
121+
contributor level.
122+
123+
## Contact
124+
125+
* For inquiries, please reach out to:
126+
* [kagenti-maintainers@googlegroups.com](mailto:kagenti-maintainers@googlegroups.com)

‎GOVERNANCE.md‎

Lines changed: 152 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
# Kagenti Project Governance
2+
3+
The Kagenti project is dedicated to providing a secure, open source platform for
4+
deploying and orchestrating autonomous AI agents on Kubernetes. This governance
5+
explains how the project is run.
6+
7+
- [Values](#values)
8+
- [Maintainers](#maintainers)
9+
- [Becoming a Maintainer](#becoming-a-maintainer)
10+
- [Meetings](#meetings)
11+
- [Code of Conduct Enforcement](#code-of-conduct)
12+
- [Security Response Team](#security-response-team)
13+
- [Voting](#voting)
14+
- [Modifications](#modifying-this-charter)
15+
16+
## Values
17+
18+
The Kagenti project and its leadership embrace the following values:
19+
20+
* Openness: Communication and decision-making happens in the open and is
21+
discoverable for future reference. As much as possible, all discussions and
22+
work take place in public forums and open repositories.
23+
24+
* Fairness: All stakeholders have the opportunity to provide feedback and
25+
submit contributions, which will be considered on their merits.
26+
27+
* Community over Product or Company: Sustaining and growing our community
28+
takes priority over shipping code or sponsors' organizational goals. Each
29+
contributor participates in the project as an individual.
30+
31+
* Inclusivity: We innovate through different perspectives and skill sets,
32+
which can only be accomplished in a welcoming and respectful environment.
33+
34+
* Participation: Responsibilities within the project are earned through
35+
participation, and there is a clear path up the contributor ladder into
36+
leadership positions.
37+
38+
## Maintainers
39+
40+
Kagenti Maintainers have write access to the
41+
[project GitHub repository](https://github.com/kagenti/kagenti). They can merge their
42+
own patches or patches from others. The current maintainers can be found in
43+
[MAINTAINERS.md](./MAINTAINERS.md). Maintainers collectively manage the
44+
project's resources and contributors.
45+
46+
This privilege is granted with some expectation of responsibility: maintainers
47+
are people who care about the Kagenti project and want to help it grow and
48+
improve. A maintainer is not just someone who can make changes, but someone who
49+
has demonstrated their ability to collaborate with the team, get the most
50+
knowledgeable people to review code and docs, contribute high-quality code, and
51+
follow through to fix issues (in code or tests).
52+
53+
A maintainer is a contributor to the project's success and a citizen helping
54+
the project succeed.
55+
56+
The collective team of all Maintainers is known as the Maintainer Council, which
57+
is the governing body for the project.
58+
59+
### Becoming a Maintainer
60+
61+
To become a Maintainer you need to demonstrate the following:
62+
63+
* commitment to the project:
64+
* participate in discussions, contributions, code and documentation reviews
65+
for 3 or more months,
66+
* perform reviews for at least 15 non-trivial pull requests,
67+
* contribute at least 10 non-trivial pull requests and have them merged,
68+
* ability to write quality code and/or documentation,
69+
* ability to collaborate with the team,
70+
* understanding of how the team works (policies, processes for testing and code
71+
review, etc),
72+
* understanding of the project's code base and coding and documentation style.
73+
74+
A new Maintainer must be proposed by an existing Maintainer by opening a PR
75+
against the root of the [kagenti repository](https://github.com/kagenti/kagenti)
76+
adding the nominee to MAINTAINERS.md. The nominee will add a comment to the PR
77+
testifying that they agree to all requirements of becoming a Maintainer.
78+
A simple majority of existing Maintainers must approve the PR.
79+
Maintainer nominations will be evaluated without prejudice
80+
to employer or demographics.
81+
82+
Maintainers who are selected will be granted the necessary GitHub rights,
83+
and invited to the
84+
[private maintainer mailing list](mailto:kagenti-maintainers@googlegroups.com).
85+
86+
### Removing a Maintainer
87+
88+
Maintainers may resign at any time if they feel that they will not be able to
89+
continue fulfilling their project duties.
90+
91+
Maintainers may also be removed after being inactive, failure to fulfill their
92+
Maintainer responsibilities, violating the Code of Conduct, or other reasons.
93+
Inactivity is defined as a period of very low or no activity in the project
94+
for six months or more, with no definite schedule to return to full Maintainer
95+
activity.
96+
97+
A Maintainer may be removed at any time by a 2/3 vote of the remaining
98+
maintainers.
99+
100+
Depending on the reason for removal, a Maintainer may be converted to Emeritus
101+
status. Emeritus Maintainers will still be consulted on some project matters,
102+
and can be rapidly returned to Maintainer status if their availability changes.
103+
104+
## Meetings
105+
106+
Time zones permitting, Maintainers are expected to participate in the public
107+
developer meeting, which occurs weekly.
108+
109+
Maintainers will also have closed meetings in order to discuss security reports
110+
or Code of Conduct violations. Such meetings should be scheduled by any
111+
Maintainer on receipt of a security issue or CoC report. All current Maintainers
112+
must be invited to such closed meetings, except for any Maintainer who is
113+
accused of a CoC violation.
114+
115+
## Code of Conduct
116+
117+
[Code of Conduct](./CODE_OF_CONDUCT.md) violations by community members will
118+
be discussed and resolved on the
119+
[private Maintainer mailing list](mailto:kagenti-maintainers@googlegroups.com).
120+
If a Maintainer is directly involved in the report, the Maintainers will instead
121+
designate two Maintainers to work with the Code of Conduct Committee in
122+
resolving it.
123+
124+
## Security Response Team
125+
126+
The Maintainers will appoint a Security Response Team to handle security
127+
reports. This committee may simply consist of the Maintainer Council themselves.
128+
If this responsibility is delegated, the Maintainers will appoint a team of at
129+
least two contributors to handle it. The Maintainers will review who is assigned
130+
to this at least once a year.
131+
132+
The Security Response Team is responsible for handling all reports of security
133+
holes and breaches according to the [security policy](SECURITY.md).
134+
135+
## Voting
136+
137+
While most business in Kagenti is conducted by
138+
"[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)",
139+
periodically the Maintainers may need to vote on specific actions or changes.
140+
A vote can be taken on
141+
[the developer mailing list](mailto:kagenti-contributors@googlegroups.com) or
142+
[the private Maintainer mailing list](mailto:kagenti-maintainers@googlegroups.com)
143+
for security or conduct matters. Any Maintainer may demand a vote be taken.
144+
145+
Most votes require a simple majority of all Maintainers to succeed, except where
146+
otherwise noted. Two-thirds majority votes mean at least two-thirds of all
147+
existing maintainers.
148+
149+
## Modifying this Charter
150+
151+
Changes to this Governance and its supporting documents may be approved by
152+
a 2/3 vote of the Maintainers.

‎MAINTAINERS.md‎

Lines changed: 20 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -1,36 +1,28 @@
11
# Project Maintainers
22

3-
This document lists the individuals responsible for maintaining this project.
3+
The current Maintainers Group for the Kagenti Project consists of:
4+
5+
| Name | Employer | Responsibilities |
6+
| ---- | -------- | ---------------- |
7+
| [Alan Cha](https://github.com/Alan-Cha) | IBM | Keycloak, State Management, Workload Identity and Security, Authorization and Policy Management |
8+
| [Ed Snible](https://github.com/esnible) | IBM | MCP Gateway, Agent Runtime |
9+
| [Evaline Ju](https://github.com/evaline-ju) | IBM | Guardrails, Observability & Token Cost, State Management |
10+
| [Gloire Rubambiza](https://github.com/rubambiza) | IBM | Automation |
11+
| [Hai Huang](https://github.com/huang195) | IBM | MCP Gateway, Network Security, Agent Runtime, Intent Based Access Control, Authorization and Policy Management |
12+
| [Jarek Cwiklik](https://github.com/cwiklik) | IBM | Agent Lifecycle Management |
13+
| [Jenna Winkler](https://github.com/jenna-winkler) | IBM | Product Management |
14+
| [Kelly Abuelsaad](https://github.com/kellyaa) | IBM | Metrics and Measurements, Benchmarking, State Management |
15+
| [Ladislav Smola](https://github.com/Ladas) | Red Hat | Sandboxing, Automation |
16+
| [Maia Iyer](https://github.com/maia-iyer) | IBM | Workload Identity and Security, State Management |
17+
| [Mariusz Sabath](https://github.com/mrsabath) | IBM | Project Technical Lead, Workload Identity, Security |
18+
| [Morgan Foster](https://github.com/usize) | Red Hat | Workload Identity and Security |
19+
| [Paolo Dettori](https://github.com/pdettori) | IBM | Project Technical Lead, Agent Lifecycle Management |
20+
| [Ryan Jenkins](https://github.com/RyanJenkins99) | Red Hat | Automation, HyperShift CI |
21+
| [Varsha Prasad Narsing](https://github.com/varshaprasad96) | Red Hat | |
422

523
## Contact
624

725
For general questions, feedback, or to reach the maintainer team:
826
**kagenti-maintainers@googlegroups.com**
927

10-
## Core Maintainers
11-
12-
* **Paolo Dettori** (@pdettori, @ingpaolodettori-dev)
13-
* **Mariusz Sabath** (@mrsabath)
14-
* **Hai Huang** (@huang195)
15-
* **Maia Iyer** (@maia-iyer)
16-
* **Ed Snible** (@esnible)
17-
* **Morgan Foster** (@usize)
18-
* **Ladislav Smola** (@Ladas)
19-
* **Gloire Rubambiza** (@rubambiza)
20-
* **Varsha Prasad Narsing** (@varshaprasad96)
21-
22-
## Module-Specific Maintainers
23-
24-
* **Jarek Cwiklik** (@cwiklik) - Lifecycle Management, Operator
25-
* **Alan Cha** (@Alan-Cha) - Keycloak, Identity, SPIFFE/SPIRE
26-
* **Kelly A** (@kellyaa) - Agent and Tools development
27-
* **Michael Le** (@mvle) - Security, MCP Gateway
28-
* **Evaline Ju** (@evaline-ju) - Guardrails, Token Mgmt, Observability
29-
* **Ryan Jenkins** (@RyanJenkins99) - Automation, HyperShift CI
30-
31-
## Responsibilities of Maintainers
32-
33-
* Reviewing and merging pull requests.
34-
* Addressing issues and bug reports.
35-
* Guiding project development and feature implementation.
36-
* Ensuring code quality and adherence to project standards.
28+
See [the project Governance](GOVERNANCE.md) for how maintainers are selected and replaced.

0 commit comments

Comments
 (0)