Closed jacobweinstock closed 2 years ago
The GH admin team is a legacy solution to governance.
The GOVERNANCE.md section on Admins and #20 establish that GH owners
and CNCF maintainership will be assigned to community members recognized as 'admins', with associated GH and CNCF Tinkerbell responsibilities.
If the admin
team is removed, the folks whose access to Tinkerbell repositories would be affected are:
If GH owners are made to match the proposed admin list, the following folks would have reduced roles:
CNCF representatives, Linux Foundation, and robots would be preserved as owners
:
I am fine with a reduced role
Works for me
@matoszz's current role and commitment has unfortunately been understated here.
There are several responsibilities and access controls that he and his team manage, which include:
For each of these (and likely others) there are billing, credentials, configuration, and contacts (administrative, technical, billing) that are associated.
The goal of the 'admin' governance work is to move responsibilities (including code, technical leadership, and infrastructure management) to a multi-organization / organizationally-agnostic body, such as the CNCF, to give the Tinkerbell Admins and Maintainers full ownership and access control as stated in the GOVERNANCE.md file.
The reality is that the Tinkerbell community has dependencies on several Equinix resources and managed resources today. I think we'll want to create separate issues to track each of these.
We should definitely retain @matoszz in the owner list. I believe this should then extend @matoszz to the CNCF maintainer list especially as that list is how we discussed distributed access to shared credentials, TFA, and email resets.
Yep, ok with reduced role here.
The org wide settings that control all of these aren't granular in github to perform without owner level permissions
might be worth checking out github's docs on what owner permissions entail / control as there's effectively one level for the vast majority of the system administration that occurs @jacobweinstock https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
@displague @matoszz, Apologies, I've read the GitHub docs on permissions for organization roles but still don't understand why owner permissions is needed for something like, DNS hosting (tinkerbell.org). Can you walk me through it?
Re: DNS, GH, S3, Zoom/Calendar, This list demonstrated the current and previous link between Equinix and Tinkerbell community ownership functions. As the community takes on more of these responsibilities with the intent to further manage and redistribute access and responsibilities, we'll want to address each of these technical functions.
Two of the examples provided are Zoom and calendaring. The Zoom accounts that have been used have been associated with individual Equinix Metal users and associated with billing, storage, and administrative access controls managed by Equinix Metal. The GH group has the same associations. We will address that through tinkerbell/org issues. We have one issue open for moving Zoom and calendaring to CNCF management.
The GH owner
role and CNCF maintainers list are both needed to fulfill the functions of the 'admin' role. The owner role is the method to provide:
Infrastructure owners:
These responsibilities converge when (among other things):
We have CNCF and Equinix members that are not active contributors to tinkerbell GH code that serve in infrastructure and administrative functions. We should more transparently reflect this in the governance doc.
There could be a different strategy here that does more dissection of responsibilities. One that we have already brought up in community discussion is whether a security group would be distinct from the maintainer's group. Another is whether an infrastructure owners/admin group should be distinct from other forms of owners and admins. I think this is something that we'll want to discuss as we address new open issues that shift responsibility.
At present, I think the simplest path is to align the governance doc with the reality that we have infrastructure owners with intrinsic access needs that can only be supported with admin-level access to lists and, among other things, GH. This is especially easy because the change is a no-op on GH and a maintainers list update which we will be submitting in any case.
@jacobweinstock sure thing - for example related to DNS configurations, in Github's setup to be able to add something even as simple as a "verified domain" you have to, as an Owner, add the domain references and the UI spits you back out the TXT verification records you need to add to your respective DNS provider configs. Could you manually exchange information like this with an owner? Sure. But I think the take away here is given I have to bear the administrative overhead of the actual DNS provider it makes little to no sense to insert an intermediary w/r/t transfer of that information, or ensuring it's updated properly when things like certificates for Pages have to get regenerated, or any of the like.
The GH owners have been updated to:
@caniszczyk @displague @jacobweinstock @jeremytanner @matoszz @thelinuxfoundation @tinkerbot
This issue is to request the granting of the following governance guidance for the admin role found here.
The community has proposed the following individuals, chosen from the existing maintainers, as Admins and as such this issue requests that they be added as GitHub owners in the Tinkerbell GitHub org:
@displague @jeremytanner @jacobweinstock
This list of owners will be inclusion, so any existing owners not in this group will be removed. The only exception to this is the current owners the CNCF requires. Also, this list can be expanded as needed.