feat: Define Permissions of Global Maintainers

[aepfli]

Adding a definiton for global maintainers.

I do see the global maintainers as the support crew for TSC and GB - sometimes things need to be merged fast and bypass certain automations. Eg. small fixes, etc. Currently only the TSC and GB can do this, due to their ADMIN rights.

Global maintainers have proven to be reliable and trustworthy, hence i think we should grant those more rights, to support the community better.

Signed-off-by: Simon Schrottner [email protected]

[gemini-code-assist]

Summary of Changes

Hello @aepfli, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request formalizes the introduction of a 'Global Maintainer' role within the project's contributor ladder. The primary goal is to empower highly trusted and experienced contributors with elevated permissions, enabling them to provide more effective support to the community, particularly in facilitating rapid merges for critical fixes and overseeing cross-repository technical decisions. This change aims to streamline project operations and enhance overall community support by distributing some administrative capabilities beyond just the TSC and Governing Board.

Highlights

• Introduction of Global Maintainer Role: A new 'Global Maintainer' role has been formally defined in the CONTRIBUTOR_LADDER.md document, establishing a new tier in the project's contributor hierarchy.
• Role Definition and Scope: The pull request details the broad permissions, responsibilities, and privileges of Global Maintainers, emphasizing their top-level technical authority across all repositories and their role in facilitating cross-language and cross-repository collaboration.
• Requirements and Process for Becoming a Global Maintainer: Clear requirements for this new role are established, including prior maintainer experience and significant contributions. A detailed nomination and approval process is outlined, involving existing Global Maintainers and TSC members.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new 'Global Maintainer' role to the contributor ladder, defining their requirements, responsibilities, and the process for becoming one. The changes are well-structured, but I've found a couple of areas that need clarification to ensure the governance process is clear and consistent. Specifically, there's an incomplete sentence in the approval process and an inconsistency regarding who can object to a nomination. My detailed comments provide suggestions to address these points.

[toddbaert]

@aepfli I am approving, but please wait for one additional approval from each of both the TC and the GC, excluding Dynatrace employees.

[askpt]

Makes sense to me. 👍

[lukas-reining]

Makes sense to me! Left one question.

[kinyoklion]

I am approving, and I think I agree with this in concept.

I do have questions though. Is this proactive, or an attempt to address issues that have been encountered?

Is there anything more nuanced we can do, like two global maintainers to bypass checks?

Do we have any limitations on distribution of global maintainers? Number of them, numbers employed by specific companies, etc?

[toddbaert]

I am approving, and I think I agree with this in concept.

I do have questions though. Is this proactive, or an attempt to address issues that have been encountered?

There's been a few times where things like broken CI checks prevent us from releasing, or fixing otherwise trivial issues. None of them have been "911's" or security issues or anything like that, but they suggested to me having a few more trusted people with override access might not be a bad idea.

We also have a few maintainers that regularly work on release automation, but don't have access to the credentials associated with publishing - it makes it really hard for them to work on such tasks independently.

Is there anything more nuanced we can do, like two global maintainers to bypass checks?

Perhaps, but at a certain point it might defeat the purpose; for now, I would just say we leave this role to highly trusted individuals, and make clear what the expectations are for any significant bypasses.

Do we have any limitations on distribution of global maintainers? Number of them, numbers employed by specific companies, etc?

No; that was one of the reasons I tried to make clear that there's no decision-making power associated with this role (unlike the GC/TC); this role is purely operational, so IMO I don't think there's as much concern on conflict of interest.

@kinyoklion please let me know if you disagree with any of my reasoning; I'd definitely like consensus on this.

[kinyoklion]

Is there anything more nuanced we can do, like two global maintainers to bypass checks?

Perhaps, but at a certain point it might defeat the purpose; for now, I would just say we leave this role to highly trusted individuals, and make clear what the expectations are for any significant bypasses.

So my main concern is the broad power of these roles, and maybe there isn't a good way to have a better balance. In the work I do day-to-day I have less power in the repositories that I work in than this role will have. Breaking glass still requires at least 2 people in most circumstances.

Which isn't a matter of trust, but of robustness of the overall system. The difference between a compromised SSH credential being a major problem or simply a nuisance.

[toddbaert]

Is there anything more nuanced we can do, like two global maintainers to bypass checks?

Perhaps, but at a certain point it might defeat the purpose; for now, I would just say we leave this role to highly trusted individuals, and make clear what the expectations are for any significant bypasses.

So my main concern is the broad power of these roles, and maybe there isn't a good way to have a better balance. In the work I do day-to-day I have less power in the repositories that I work in than this role will have. Breaking glass still requires at least 2 people in most circumstances.

Which isn't a matter of trust, but of robustness of the overall system. The difference between a compromised SSH credential being a major problem or simply a nuisance.

I would be in favor of a requirement to force 2 people to bypass checks, but I don't think this is possible in Github (I think all the bypass operations are just big red buttons only 1 person need push (assuming they have admin rights). @aepfli Do you have any proposals? @kinyoklion is correct that we are certainly increasing the security surface area here in terms of who has admin rights.

[askpt]

Is there anything more nuanced we can do, like two global maintainers to bypass checks?

Perhaps, but at a certain point it might defeat the purpose; for now, I would just say we leave this role to highly trusted individuals, and make clear what the expectations are for any significant bypasses.

So my main concern is the broad power of these roles, and maybe there isn't a good way to have a better balance. In the work I do day-to-day I have less power in the repositories that I work in than this role will have. Breaking glass still requires at least 2 people in most circumstances.
Which isn't a matter of trust, but of robustness of the overall system. The difference between a compromised SSH credential being a major problem or simply a nuisance.

I would be in favor of a requirement to force 2 people to bypass checks, but I don't think this is possible in Github (I think all the bypass operations are just big red buttons only 1 person need push (assuming they have admin rights). @aepfli Do you have any proposals? @kinyoklion is correct that we are certainly increasing the security surface area here in terms of who has admin rights.

We may need to adjust our rulesets to allow bypassing (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-branch-or-tag-ruleset). I don't have the necessary permissions, so I'm unable to view the current configuration. I think GitHub doesn't have any functionality for 2 people approving a bypass (that would be the same as asking 2 people to approve a PR). Bypass is for "very urgent" factors only.

[aepfli]

I do not have insights into our role definitions, and/or what we can do organizational wise, but we have encountered issues, where eg. in java by error a binary incompatibility got released - hard to grasp at the beginning. currently we do need two approvers for a pull request to get merged - but there is only a limited amount of people who could bypass the automation to rollback this change. I agree that we increase the attack surface, but maybe we find a solution, which allows only global-maintainers to bypass reviewer limitations for mitigating such issues faster. To be honest I do not want to gain permissions to push to main, nor do i want to adapt those settings, but as a maintainer, I am currently not able to fix those issues. To be honest, by now i would have applied for the TSC but i think this would create an unfair balance (and might not even be allowed due to our definitions) as Dynatrace does have already a seat in the TSC.

To be honest i am fine if we do not increase the permissions, but i also do see currently a big dependency on tasks to the TSC and GB although there expertise is not really needed. eg. having enough approvers, or moving forward with a task, even if it is a small one.

[guidobrei]

Maybe also nominated by TSC?