[Bug 568043] Consider opening up more administrative GitHub controls to Project Leads

Bugzilla Link	568043
Status	NEW
Importance	P3 normal
Reported	Oct 20, 2020 09:12 EDT
Modified	Oct 21, 2020 08:47 EDT
Reporter	Simeon Fitch

Description

Given the continual improvements in tooling and integration options for GitHub-hosted projects, it is often desirable and more efficient to make configuration changes oneself rather than having to file a Bugzilla ticket, describe the issue in detail, attempt to convey the settings that need changing without being able to see them, and verify after the fact that things are working as desired.

This back and forth is natural and expected--not a reflection of the service provided--but ultimately discourages adoption of time saving and quality improving technologies as they evolve. If there were a means of removing some of the friction I think benefits will be experienced on both the developer side and The Foundation side.

According to the documentation, the permission levels are:

• Read: Recommended for non-code contributors who want to view or discuss your project\
• Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access\
• Write: Recommended for contributors who actively push to your project\
• Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions\
• Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository

I don't know what level Project Leads currently are assigned.

If Project Leads are currently at the "Write" level, what would be the implications of promoting us to "Maintain"?

If Project Leads are already at "Maintain", what processes, procedures, safeguards would be needed to ensure Foundation rules are ensured?

added Bugzilla legacy ~16280 labels

(In reply to Simeon Fitch from comment #0)

I don't know what level Project Leads currently are assigned.

If Project Leads are currently at the "Write" level, what would be the
implications of promoting us to "Maintain"?

We are currently in the finishing phase of giving project leads the maintain permissions by default.

You can see the differences between the permissions in this table here:
https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level\

If Project Leads are already at "Maintain", what processes, procedures,
safeguards would be needed to ensure Foundation rules are ensured?

Maintain permissions are reasonably save. They don't give potentially destructive rights, except for the "Push to protected branches" permission. We trust project leads to act responsibly. If we notice any actions that violate rules of the Eclipse Development process, we reserve the right to restrict permissions, etc.

By Simeon Fitch

Definitely a step in a helpful direction. If it's possible to fine tune these settings, all that would be missing from my standpoint would be (in order of importance):

• Manage webhooks and deploy keys \
• Edit the repository's default branch\
• Change a repository's settings

Unfortunately, we can't adjust the permission roles/capabilities ourselves.
Please open a feature request at GitHub for this.

Discussion continues in #1531 (closed). Closing.

closed