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.