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

As part of [onboarding Istio into the CNCF](https://github.com/cncf/sandbox/issues/206), 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](https://github.com/cncf/foundation/blob/main/maintainers-election-policy.md) 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](https://contribute.cncf.io/about/maintainers-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](https://github.com/istio/community/blob/master/ROLES.md#maintainer) 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.)

Read maintainers-election-policy.md alongside the linked TAG Contributor Strategy Maintainer Circle documentation, then compare the role definitions in Istio's ROLES.md and the maintainers CSV process described in the issue. Clarify the intended meaning of “maintainer,” whether a different CNCF role name is needed, and whether a listing or voting cap applies; done means the policy and process are unambiguous.

Written by the indexing model from the issue text.