Please consider defining what a "maintainer" is, perhaps using a different word, and document any cap on the number.

[craigbox]

As part of onboarding Istio into the CNCF, we were asked to list our maintainers. I mentioned we have 87, and sought clarity if I should add them all; @amye said "no", and @dims commented to say

LOL no to 87 :)

As projects and communities evolve, there is inevitable drift between intentions and realities. I'm always keen to use moments like this as an opportunity to make sure that tribal knowledge can be written down for the benefit of everyone to come.

I take from the maintainer election policy the intention that all maintainers of all CNCF projects all get to vote for GB and TOC seats.

Looking at TAG Contributor Strategy's Maintainer Circle documentation points out the differing meanings of the word. It further states:

"CNCF has a pool of listed maintainers for each project that vote on behalf of their project in TOC elections"

This suggests that not all project maintainers are necessarily "part of the pool of listed maintainers".

Istio is an "old" (mature?) and "large" project; it's not of the scale of Kubernetes, of course, but I imagine it's going to be in the top 5 by most metrics. At the time of writing, we have 87 maintainers, defined here as people who have earned approval access to a part of the project, and have earned voting rights within the working groups.

We've been told that this is too many people to list on https://maintainers.cncf.io/, or to put it another way, grant voting rights to.

By comparison, gRPC has 49 maintainers listed in this file, and Cilium has 42. Given the large community of developers and breadth of companies that contribute to Istio, it's fair to assume that ratio of maintainers between Istio and those projects is roughly accurate. (I would assume that these projects all use "maintainer" in a similar fashion to how Kubernetes uses "owner". )

Conversely, there are only 17 people listed on behalf of Kubernetes on https://maintainers.cncf.io/, with 10 of them listed as non-voting. There are many sandbox projects that have a higher number of maintainers listed, and if I have this right, a higher influence on voting for the TOC seat? (This is less relevant for the GB seats, one of which I understand is chosen by the Kubernetes steering committee, the other from the maintainers of all other projects.)

It would be useful to understand the intention of this policy before we proceed with adding some or all of our maintainers. Some things that might make it more clear, depending on the intention:

• using a different word for the CNCF role: it sounds like you're asking for a number of "project liaisons" or "leads"?
• capping the number in some fashion: assuming the intention is treat all projects like US states

(I'm going to give Amye the e-mail addresses of a few project leads to proceed with the transition, and await clarification here before updating the CSV.)

[aliok]

I think we have a similar situation at Knative community.

To give an overview:

• Knative has a similar governance structure to Istio (and Kubernetes).
• We have multiple working groups (like Kubernetes SIGs), a steering committee and a technical oversight committee
• Working groups have leads and also "approvers" (who can approve PRs)

While we have more approvers in various components of Knative, we only have in https://github.com/cncf/foundation/blob/main/project-maintainers.csv people that are in steering committee or TOC.

Practical issue for this is for example:

• I am not part of those committees
• I am an approver of some components
• There's a mentorship opportunity I would like to provide, but I am not in the project-maintainers.csv and the CNCF mentoring program leads are unsure if I can do that (we communicate and solve issues though).

See https://github.com/cncf/mentoring/pull/779/files#r1088070416 for more context.

Anyway, what I am pursuing are these:

• (to be documented this repository) Criteria of being added to project-maintainers.csv file is well defined.
• (to be documented this repository) Understanding if it is up to Knative community to put people in project-maintainers.csv OR if CNCF decides on who to have in the CSV file.
• (to be documented this repository) Understanding what happens when somebody is added on that file: gets voting rights? what else?
• (to be documented in https://github.com/cncf/mentoring repository) Mentoring WG to specify who can submit mentorship opportunities OR if mentoring WG needs approvals form people in that CSV file for mentorship opportunities.

[rarjun7777]

can i work on this ?