The EF manages the GitHub Teams and GitLab groups based on project lead/committer/contributor status

Make it as clear as possible that the EF manages the GitHub Teams and GitLab groups based on project lead/committer/contributor status and that we provide no other means to grant privileges.

Here's a summary that I gave in another context that we might be able to leverage:

• Committers hold the ultimate authority.
• Committers must be elected to join a project team following public demonstration of merit.
• An Eclipse project have a GitHub organisation that contains one or more Git repositories (likewise for our GitLab instance).
• Committers have the GitHub Write role on all project repositories.
• Project leads must also be committers. Project leads are granted the Maintain role on GitHub.
• There is a formal notion of Contributor who are granted the Triage role on GitHub.
• Specific committers can be designated as owners via GitHub's CODEOWNERS feature. The means by which a committer becomes an owner must be documented and must follow the open source rules of engagement (open, transparent, meritocratic). To be an owner, one must also hold committer status.
• To be clear... no working group or company gets to appoint anybody to a project lead or committer role, owner, or any informal role defined by the project.
• GitHub teams are defined and managed by the Eclipse Foundation based on individuals who hold project lead, committer, or contributor roles. Additional teams cannot be created.
• The Maintain role grants project leads the ability to manipulate GitHub teams. Project leads should not add or remove people from teams. Our scripts will override any changes. The handbook has more to say about adding and removing project leads and committers.
• Additional informal roles can be defined by a project team. Informal roles have as much authority as the committers and community grant them. That is, we provide no means of enforcing specific privileges for informal roles.