Update repo permissions on k/enhancements

[justaugustus]

Feature Enhancement maintainers often use GitHub settings like Milestone to determine which Features Enhancements require triage.

It's important that these settings are only touched by Feature Enhancements Maintainers to ensure better signal during the release process.

As such, I'd like to do the following:

• Remove write access for:
  • kubernetes-maintainers
  • kubernetes-release-managers
• Give write access on k/enhancements to kubernetes-milestone-maintainers
• Expand on the definition of milestone maintainers
• Prune enhancements-maintainers to only include the SIG PM maintainers (@calebamiles, @idvoretskyi, @jdumars, @justaugustus) - sig-pm: Update enhancements-maintainers team org#498

I suggest kubernetes-milestone-maintainers for write access because that team:

• is exactly the list of contributors that would need milestone privileges
• likely also the list of people that would need to edit enhancement issue content
• is actively pruned across release cycles

Previous idea:

- remove the `kubernetes-maintainers` and `kubernetes-release-managers` from having direct write access to k/features~
- update the membership of `features-maintainers` to only include the following:
  - SIG PM leadership
  - Product Management subproject leadership
  - Program Management subproject leadership
  - current Release Team Feature Lead & Shadows
- ensure the following are Maintainers of the `features-maintainers` GitHub group:
  - SIG PM leadership
  - Product Management subproject leadership
  - Program Management subproject leadership

Here's the current list to simplify the updates:
- Maintainers: @apsinha @idvoretskyi @calebamiles @justaugustus @dustinkirkland @jdumars
- Members: @kacole2 @robertsandoval @rajendar38

We'll go with lazy consensus for this on Wednesday, 7/25.

Google Group thread: https://groups.google.com/forum/#!topic/kubernetes-pm/JFthLm0q-uA

cc: @kubernetes/kubernetes-maintainers @kubernetes/kubernetes-release-managers @kubernetes/features-maintainers

/assign
/assign @cblecker
/sig pm

[liggitt]

seems like that should be harmonized with membership of https://github.com/orgs/kubernetes/teams/kubernetes-milestone-maintainers and feature-approvers and milestone-maintainers aliases in https://github.com/kubernetes/kubernetes/blob/master/OWNERS_ALIASES

[liggitt]

cc @kubernetes/kubernetes-milestone-maintainers

[liggitt]

As long as this repo is where kubernetes/kubernetes features are planned/tracked, I think milestone modification permissions should be consistent between the two repos.

[smarterclayton]

I'm also surprised at the proposal that maintainers aren't able to decide the status of their features. That seems... unusual, especially since those are the people most likely to have an accurate assessment of the feature.

I'm also unsure as to how the "protect the milestone label" translates to "maintainers and release managers don't have write access to this repo".

[justaugustus]

@liggitt @smarterclayton -- hmmm, this is more of a "too many cooks" concern than anything else.
If someone who doesn't actually maintain the Features Tracking spreadsheet moves a milestone, we (currently) have no clever way of tracking that without sweeping this repo again.

If that could be solved though...

[liggitt]

Yeah, it seems like fixing the current manual issue tracker <-> spreadsheet process would be better than putting obstacles in the way of the actual milestone maintainers

Can sig-release/sig-pm look into pulling snapshot reports of milestone items from the features repo automatically? A bot that scrapes the milestone items daily/weekly/whenever and snapshots that as a committed md file would stay up to date and show change over time.

[justaugustus]

Can sig-release/sig-pm look into pulling snapshot reports of milestone items from the features repo automatically? A bot that scrapes the milestone items daily/weekly/whenever and snapshots that as a committed md file would stay up to date and show change over time.

Absolutely, @liggitt. I've previously opened some issues around the topic and plan on taking up this effort:

• Add a Features plugin / bot test-infra#8316
• Define triage and tracking process for kind/feature issues / PRs in k/k community#2307

Would love any feedback around the process on those issues as well! :)

[cblecker]

Two thoughts:

• Limiting direct write access to the repo is in line with our ongoing efforts to move this over to bots. I think that's still worth moving forward with.
• We could enable the milestone prow plugin to allow the /milestone command to work in this repo, similar to k/k.

[liggitt]

Limiting direct write access to the repo is in line with our ongoing efforts to move this over to bots. I think that's still worth moving forward with.

Probably so, though description editing of issues created by someone else is probably done more in this repo than any other I work in (all sig-auth leads work to maintain/curate our sig's feature issues, for example). The bots don't let us do that.

We could enable the milestone prow plugin to allow the /milestone command to work in this repo, similar to k/k.

we could, but the premise of this issue was to prevent modification of feature milestones by some of the people responsible for the content of the milestone

[cblecker]

description editing of issues created by someone else is probably done more in this repo than any other I work in

That I didn't know. I know that's still a pending issue for removing it from k/k, but wasn't aware that same use case applies here.

My thought on the milestone command was to offer a way to still allow milestone modification, but not need direct write access. The milestone command could also be modified to do things like ping a team when a milestone is modified so that changes can be tracked.

[justaugustus]

@cblecker @liggitt --

To summarize:

Feature Owners (SIG Leads + people implementing / sheparding feature) need to:

• edit issues
• edit milestones

Feature Maintainers (SIG PM - Product Management, Release Team Features Lead & Shadows) need to:

• edit issues
• edit labels
• edit milestones
• have trusted signal on the current status of a feature in the milestone

In addition, passerbys (users or contributors) should be able to have a clear idea of the likelihood of an issue being delivered within a milestone, without having to read the entire discussion or get into the technical weeds.

So as a solution, how about we do the following:

• allow feature-maintainers and milestone-maintainers access to edit issues
• clean up feature-maintainers and milestone-maintainers
• enable /milestone command
• introduce a set of Feature triage labels and accompanying /feature command, that would be reserved for Feature Maintainers

The latter lends itself to @liggitt's suggestion for a milestone scraping bot and echoes some of the intent of kubernetes/test-infra#8316.

[m1093782566]

@justaugustus

clean up feature-maintainers and milestone-maintainers

What does it mean? And what's the clean-up rule?

[justaugustus]

What does it mean? And what's the clean-up rule?

@m1093782566 --
I'd like to audit the GitHub teams and ensure only the required people are a part of it.

For features-maintainers:

update the membership of features-maintainers to only include the following:
SIG PM leadership
Product Management subproject leadership
Program Management subproject leadership
current Release Team Feature Lead & Shadows

For milestone-maintainers, we'll likely need to include members of past and present Release Teams, as well as ping SIGs for appropriate reps and then document it for posterity.

[justaugustus]

@liggitt @smarterclayton -- please provide feedback on this PR about maintaining milestone-maintainers: kubernetes/sig-release#239

[fejta-bot]

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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[nikhita]

/remove-lifecycle stale

[spiffxp]

As of today:

• /milestone is available for anyone in kubernetes-milestone-maintainers
• kubernetes-maintainers has direct write access (IMO they should not)
• kubernetes-release-managers has direct write access (IMO they should not)
• enhancements-maintainers has direct write access (IMO they should)

I can't speak to the policy of who is in what team at present, though FWIW:

• the membership of kubernetes-release-managers is disjoint with enhancements-maintainers
• the membership of kubernetes and enhancements-maintainers is not cleanly separated, I would rather move over whomever needs write access to this repo to enhancements-maintainers

[justaugustus]

Thanks for resurrecting this one, @spiffxp!

How about we do the following?

• Remove write access for:
  • kubernetes-maintainers
  • kubernetes-release-managers
• Give write access on k/enhancements to kubernetes-milestone-maintainers
• Expand on the definition of milestone maintainers
• Prune enhancements-maintainers to only include the SIG PM maintainers (@calebamiles, @idvoretskyi, @jdumars, @justaugustus) - sig-pm: Update enhancements-maintainers team org#498

I suggest kubernetes-milestone-maintainers for write access because that team:

• is exactly the list of contributors that would need milestone privileges
• likely also the list of people that would need to edit enhancement issue content
• is actively pruned across release cycles

[justaugustus]

@cblecker -- thoughts on the plan above?

[cblecker]

I personally don't have any concerns about the above. That said, I'm not an active feature contributor, so I am not up on the current features/enhancements process. I'd suggest re-seeking feedback from @liggitt.

[justaugustus]

Slack convo with @liggitt yesterday:

justaugustus [8:08 PM]
Hey Jordan, could I get your thoughts on this one when you have a chance? #590 (comment)

liggitt [8:37 PM]
Seems sensible overall. Have you figured out who would be losing permissions? Sometimes that's helpful to compute, along with how recently some of those users did actions that would have been affected, to see if there's a dimension that has been forgotten.

justaugustus [8:41 PM]
Hmmm, I did not. Operating off of the premise that those who should be doing the actions should really be part of kubernetes-milestone-maintainers anyway, so funneling them through that process instead. If there's an easy to calculate the diff then perhaps, but I think we'd want to steer them into getting milestone privs regardless of the result.

[justaugustus]

Sent notification to mailing list regarding this change: https://groups.google.com/d/msg/kubernetes-pm/JFthLm0q-uA/SzMBBCzIBQAJ

Lazy consensus: Thursday, 2/21 EOD PT
Change to happen: Friday, 2/22

[cblecker]

All the team memberships are in k/org.. so to pull the diff:

• Grab membership lists of kubernetes-maintainers, kubernetes-release-managers
• Combine and de-dupe
• Grab membership of kubernetes-milestone-maintainers
• Remove intersection between the two lists

Then you have a list of those who would have their access removed.

Then you should be able to use something like https://k8s.devstats.cncf.io/d/46/pr-reviews-by-contributor?orgId=1&var-period=d7&var-repo_name=kubernetes%2Fenhancements&var-reviewers=All&from=now-90d&to=now to find out if they have touched anything in k/enhancements.

Data is power!

[justaugustus]

Okay, I did a little massaging here:

• Original list: https://gist.github.com/justaugustus/5b2012f892720df4d7bb4c8dfa746b6b#file-combined-original-yaml
• Updated list: https://gist.github.com/justaugustus/5b2012f892720df4d7bb4c8dfa746b6b#file-combined-updated-yaml
• Contributors being added: https://gist.github.com/justaugustus/5b2012f892720df4d7bb4c8dfa746b6b#file-add-yaml
• Contributors being removed: https://gist.github.com/justaugustus/5b2012f892720df4d7bb4c8dfa746b6b#file-remove-yaml

Overall, that devstats board won't be useful here.
From the thread, what people actually care about is whether or not they can edit descriptions for existing issues, which I don't think can be easily gleaned from DevStats.

So for people:

• who have created an enhancement tracking issue - no problem; you can edit your own issue
• who want to edit an enhancement tracking issue - I'd qualify as milestone-maintainers and they should PR to k/org with their SIG's approval for access

For the sake of overcommunication...

---

@kubernetes/kubernetes-maintainers and @kubernetes/kubernetes-release-managers --

We are updating the permissions on k/enhancements and will be removing groups that don't require write access to the repo, namely kubernetes-maintainers and kubernetes-release-managers. Additionally, we will be granting @kubernetes/kubernetes-milestone-maintainers write access.

The most requested use case for write access to this repo is being able to edit the descriptions for Enhancement tracking issues.

If you feel you should have this capability, you should be a part of the kubernetes-milestone-maintainers GitHub team. To gain access to this team, please file a PR in k/org updating this team and have the SIG that you'll be maintaining milestones for approve the PR.

The following list of contributors will be losing write access to k/enhancements:
@aleksandra-malinowska
@alex-mohr
@apelisse
@aronchick
@bgrant0607-nocc
@bprashanth
@brendandburns
@caesarxuchao
@cjcullen
@david-mcmahon
@davidopp
@ecordell
@eparis
@erictune
@errordeveloper
@euank
@fabioy
@fgrzadkowski
@freehan
@gmarek
@grodrigues3
@hongchaodeng
@ingvagabund
@ixdy
@janetkuo
@jbeda
@jessfraz
@jingxu97
@jlowdermilk
@jsafrane
@jszczepkowski
@k8s-release-robot
@Kargakis
@kashomon
@kevin-wangzefeng
@krousey
@lukemarsden
@MaciekPytel
@madhusudancs
@maisem
@matchstick
@mbohlool
@mdelio
@mike-saparov
@mml
@mtaufen
@ncdc
@nikhiljindal
@philips
@pmorie
@pweil-
@q-lee
@quinton-hoole
@random-liu
@rmmh
@sarahnovotny
@smarterclayton
@sttts
@thelinuxfoundation
@timstclair
@vishh
@xiang90
@yifan-gu
@yujuhong
@zmerlynn

[BenTheElder]

the last bit of that list doesn't seem to be registering... 🤔
@pweil-
@Q-Lee
@quinton-hoole
@Random-Liu
@rmmh
@sarahnovotny
@smarterclayton
@sttts
@thelinuxfoundation
@timstclair
@vishh
@xiang90
@yifan-gu
@yujuhong
@zmerlynn

[justaugustus]

the last bit of that list doesn't seem to be registering...

@BenTheElder -- probably maxed out on @ mentions on the comment, but everyone should've been notified as a result of being part of those teams.

[justaugustus]

Announced on k-dev as well: https://groups.google.com/d/topic/kubernetes-dev/fU-U1JSZ8E4/discussion

[spiffxp]

/unassign @cblecker
/assign @spiffxp
Doing the needful as described in #590 (comment)

[spiffxp]

Dropped the following teams (their ACL):

• kubernetes-maintainers (write)
• kubernetes-reviewers (read) (this is unnecessary since it's a public repo)
• kubernetes-release-managers (write)

Added the following teams (their ACL):

• kubernetes-milestone-maintainers (write)

[spiffxp]

Removed the hold on kubernetes/org#498, it will take some time for those changes to propagate. Suggest leaving this open until they're verified.

[justaugustus]

Thanks for making the changes, @spiffxp! I've verified that the updates to enhancements-maintainers have taken effect.

I've opened two PRs to close the loop on this:

• Update the description of the kubernetes-milestone-maintainers GitHub team: sig-release: Update kubernetes-milestone-maintainers description org#523
• Update description of Milestone Maintainers in k/sig-release to include a note on write privs to k/enhancements and how to request access: Add notes on milestone maintainer privs and requesting access sig-release#517

(the latter will close this issue once it merges)

[justaugustus]

x-post from #enhancements:

The Triage role

Recommended for contributors who need to proactively manage issues and pull requests without write access

ref: https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

did not exist on GitHub when we initially configured privileges for k/enhancements, so we needed to grant milestone-maintainers write access to the repo to allow them to edit the descriptions on Enhancement issues.

Given this role does exist now, I've downgraded the access of milestone-maintainers from Write to Triage to prevent accidental pushes in the future.

@annajung -- FYI, in case enhancement owners encounter issues during enhancement collection.

cc: @kubernetes/enhancements