Define and implement entry/exit criteria for kubernetes-maintainers GitHub team

The legacy kubernetes-maintainers GitHub team has write access to the k/k repo. This issue is to discuss pruning the team.

There has been previous discussion about removing the team in kubernetes/kubernetes#57667. Given that we don't have good automated solutions around editing issue/PR bodies, completely removing write access and deleting the team is not feasible today.

Having said that, the kubernetes-maintainers team hasn't had any significant updates over the last ~3 years (!!!). There are members in that team who are no longer active in the Kubernetes project and should not have write access to k/k anymore.

My suggestion - we could limit this to milestone-maintainers + all approvers in k/k.

If there is general consensus on this GitHub issue, I'll start a thread on the k-dev and leads mailing lists.

@dims

cc @kubernetes/owners
GitHub admin team

cc @dims @derekwaynecarr @johnbelamaric
sig-arch leads

cc @liggitt @sttts @deads2k @tpepper @justaugustus
who've had opinions about this team before (in kubernetes/kubernetes#57667 + #2330)

+1. It's been needed for some time.

+1 to prune. isn't milestone-maintainers a larger group?

+1

My suggestion - we could limit this to milestone-maintainers + all approvers in k/k.

Is this suggesting we remove current members of the kubernetes-maintainers list if either of the following are true:

they are not in milestone-maintainers
they are not an approver in k/k

If so, that seems very reasonable to me and moves in the desired direction of shrinking the list.

Is this suggesting we remove current members of the kubernetes-maintainers list if either of the following are true:

they are not in milestone-maintainers

they are not an approver in k/k

Yes 👍

To clarify - we won't bulk-add milestone-maintainers + k/k approvers if they aren't already in the kubernetes-maintainers GitHub team.

If someone in milestone-maintainers + k/k approvers wants to be on the team, they can create a PR to add themselves separately.

Want to keep the team as small as possible.

@nikhita

@nikhita @liggitt sounds like a good plan. Let's do this!

One note

If someone in milestone-maintainers + k/k approvers wants to be on the team, they can create a PR to add themselves separately.

What would be the approval process here?
My one concern is that Release Team members (specifically Release Team shadows) are on the milestone-maintainers group and I'm not in favor of them getting write access to k/k without some process in place.

Thinking more about this, how about:

If an existing member of kubernetes-maintainers is not a k/k approver, we remove them from the team
We don't add any new members to the team

@dims

* If an existing member of `kubernetes-maintainers` is not a k/k approver, we remove them from the team

I like this.

* We don't add any new members to the team

Hmmmmm, so I think there should be a route to write access.

@dims is not a root approver for k/k, but I do feel he's deserving of the access that was granted in #2330.

How can we cover those cases in future?

Add bentheelder to Kubernetes maintainers team.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

Mark this issue or PR as fresh with /remove-lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

/remove-lifecycle rotten
/lifecycle frozen

I have also recently found it more productive to fix PR bodies that do not meet our template criteria after one attempt at telling the author to please do this than lengthy back and forth (especially with time zone latency this can become very drawn out). Things like the release-note "language" code block trip people up and are trivial for a maintainer with write to fix.

TIL https://prow.k8s.io/command-help /release-note-edit (which ... can't be linked to ... that's broken ...)

It looks ... awkward to use (multi-line??) but ... one possible option for that aspect ... if we make people aware of it. I'm also not sure if this works in the face of mangling the "language" as mentioned previously, I think it just substitutes the contents of an already correctly formatted block.

Still, a somewhat promising thought.

In addition to brach protection we also monitor pushes and alert in other repos, we should be doing this here.

we should still really have this

How about taking roll here today right now in this discussion. How many bots are here and how many humans are present.

A little help would be appreciated

Do we still need this group of today or are we fine to remove it?

cc @kubernetes/steering-committee

I'm not sure if that's the group via which I have label and description edit access, but if so, I regularly use those to fix up labels run amok and PR / issue descriptions. With github fine-grained permissions improvements, is there a way to just grant lower-level permissions like that?

Right now the kubernetes-maintainers have a bunch of write permissions to a set of repos defined in:

org/config/kubernetes/org.yaml

Lines 1409 to 1435 in 0dd2650

    
           kubernetes-maintainers: 
        
             description: Write access to the kubernetes repo. Follow the process in https://github.com/kubernetes/community/blob/master/community-membership.md 
        
             maintainers: 
        
             - cblecker 
        
             - thelinuxfoundation 
        
             members: 
        
             - apelisse 
        
             - BenTheElder 
        
             - cheftako 
        
             - dchen1107 
        
             - deads2k 
        
             - dims 
        
             - jsafrane 
        
             - liggitt 
        
             - smarterclayton 
        
             - soltysh 
        
             - sttts 
        
             - thockin 
        
             - wojtek-t 
        
             privacy: closed 
        
             repos: 
        
               apiextensions-apiserver: write 
        
               client-go: write 
        
               kube-aggregator: write 
        
               kubernetes: write 
        
               sample-apiserver: write 
        
               sample-controller: write

We don't have custom roles for k/k or any of those repos (yet), but we could think about moving to the predefined maintain role instead of write: https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/about-custom-repository-roles#about-the-inherited-role

I'm not sure if that's the group via which I have label and description edit access, but if so, I regularly use those to fix up labels run amok and PR / issue descriptions.

+1, I do this as well. I have close knowledge of the systems (that part of prow has not changed much) and sometimes they are broken either the webhooks (github side) or our CI infrastructure (the bit under SIG Testing), it is useful to have a few people handle these situations and I've seen and trust Jordan for this.

We don't have custom roles for k/k or any of those repos (yet), but we could think about moving to the predefined maintain role instead of write

maintain is actually a superset of write but a subset of admin, triage is the pre-defined role that is a subset without write permissions but retaining label fixup. I think triage is at least pretty close to what we really wanted, we just only had read / write / admin at the time.

It now goes read > triage > maintain > write > admin:
https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization

triage does lose the original topic: Editing a PR description, which is occasionally useful for stuck PRs but far less common now that we have /release-note-edit since that's usually the sensitive bit new contributors struggle with which has to be in the original PR comment and cannot be in a comment from another user (and difficult to explain ... maybe someday we can revisit the special code-block approach).

Navigation Menu

Repository navigation

Define and implement entry/exit criteria for kubernetes-maintainers GitHub team #2332

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	kubernetes-maintainers:
	description: Write access to the kubernetes repo. Follow the process in https://github.com/kubernetes/community/blob/master/community-membership.md
	maintainers:
	- cblecker
	- thelinuxfoundation
	members:
	- apelisse
	- BenTheElder
	- cheftako
	- dchen1107
	- deads2k
	- dims
	- jsafrane
	- liggitt
	- smarterclayton
	- soltysh
	- sttts
	- thockin
	- wojtek-t
	privacy: closed
	repos:
	apiextensions-apiserver: write
	client-go: write
	kube-aggregator: write
	kubernetes: write
	sample-apiserver: write
	sample-controller: write

Define and implement entry/exit criteria for kubernetes-maintainers GitHub team #2332

Description

Activity

nikhita commented on Nov 18, 2020

mrbobbytables commented on Nov 18, 2020

dims commented on Nov 18, 2020

idvoretskyi commented on Nov 18, 2020

liggitt commented on Nov 18, 2020

nikhita commented on Nov 18, 2020

nikhita commented on Nov 18, 2020

dims commented on Nov 18, 2020

justaugustus commented on Nov 18, 2020

nikhita commented on Nov 18, 2020

justaugustus commented on Nov 18, 2020

fejta-bot commented on Feb 16, 2021

justaugustus commented on Feb 16, 2021

32 remaining items

k8s-triage-robot commented on Dec 15, 2021

justaugustus commented on Dec 21, 2021

BenTheElder commented on May 19, 2022

Chiefy0x1 commented on Jun 7, 2025

Chiefy0x1 commented on Jun 7, 2025

saschagrunert commented on Nov 10, 2025

liggitt commented on Nov 10, 2025

saschagrunert commented on Nov 11, 2025

BenTheElder commented on Nov 11, 2025

BenTheElder commented on Nov 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions