Add notes on Milestone Maintainers

[justaugustus]

This adds a quick note on the milestone-maintainers GitHub team, as requested here: kubernetes/community#2424

We should follow-up with detailed information on the process.

/sig release
/cc @tpepper @jberkus @AishSundar @spiffxp @dims

rel:

• Update repo permissions on k/enhancements enhancements#590 (comment)
• https://kubernetes.slack.com/archives/C2C40FMNF/p1532626731000397

[jberkus]

Is the above two per SIG, or two in the whole project? If the former, that's 2 leads and 2 delegates, or four per SIG, or 124 people total.

If it'sffour for the whole project, that doesn't seem nearly enough.

Suggest instead: at least one sig lead

[justaugustus]

@jberkus how about at least one lead and at least two delegates?

[tpepper]

I think this should have a parallel commit on the sig charter template, existing sig charters, and get added to the currently in flight sig charters. Ie: go through top level and affirm SIGs know what they’re being signing up for and have it documented in their operations. Otherwise the ongoing management is less likely to happen.

With respect to numbers I’m ambivalent. I can see saying at least one SIG lead. And noting the operation choice is up to each SIG. They could have their lead(s) do all /milestone management, or add/remove additional delegates to spread their load. Pick the preferred one for the SIG, document how the SIG operates, get on with things.

For what I imagine the volume to be, it’s reasonable to say “SIG leads contact the release lead with adds/removes” instead of two sig folks with list maintainer privs at all times. Again the key is to have clear expectation and communication, versus people out of the blue requesting access without supporting justification from a sig.

So I’d go simpler, leave maintenance mechanics on GH group to release lead, but clarify SIGs are responsible for picking a policy and telling the release lead what they want for changes. This way there’s four changes to maintainers of the list per year (four releases) instead of a lot more probably, and more clear ownership of 1 versus 124 owners.

[justaugustus]

@tpepper --

I think this should have a parallel commit on the sig charter template, existing sig charters, and get added to the currently in flight sig charters. Ie: go through top level and affirm SIGs know what they’re being signing up for and have it documented in their operations. Otherwise the ongoing management is less likely to happen.

Agreed. I can drop a follow-up for charters once we hit consesus on the process.

With respect to numbers I’m ambivalent. I can see saying at least one SIG lead. And noting the operation choice is up to each SIG. They could have their lead(s) do all /milestone management, or add/remove additional delegates to spread their load. Pick the preferred one for the SIG, document how the SIG operates, get on with things.

Sounds good. At least one SIG lead, with the option to add delegates per SIG determination is reasonable.

For what I imagine the volume to be, it’s reasonable to say “SIG leads contact the release lead with adds/removes” instead of two sig folks with list maintainer privs at all times. Again the key is to have clear expectation and communication, versus people out of the blue requesting access without supporting justification from a sig.

Still think SIG leads can / should get Maintainer access to the group to alleviate the SPOF.

So I’d go simpler, leave maintenance mechanics on GH group to release lead, but clarify SIGs are responsible for picking a policy and telling the release lead what they want for changes. This way there’s four changes to maintainers of the list per year (four releases) instead of a lot more probably, and more clear ownership of 1 versus 124 owners.

It'd be 31 / x SIG leads vs 124 owners. Big upside of this is we multiplex the maintenance of the GitHub team and introduce a continuity aspect i.e., SIG leads survive the release cycle, whereas Release Leads do not.

[jberkus]

As in SIG Leads, as well as the RL, can add new members? Seems fine, but then we need to give them some guidance. I suggest "maximum of 3 members per SIG".

[dims]

Also we should add a note here to prune the list when folks stop using their powers.

[justaugustus]

@dims -- will clarify the language

[spiffxp]

Agree this needs clarification. If you're not actively willing to participate in issue/pr triage for a given release cycle, you shouldn't need access to these commands. With great power comes great responsibility.

[jberkus]

Do we have any ability to actually pull this information? I know I can't do it with devstats (there's a problem with adds-milestone events).

[AishSundar]

Thanks for taking a stab at this @justaugustus. One thing I see missing (or not catching my attention easily) is the clarification as to when and how various SIG leads should contact the release lead to prune the list for their respective SIGs. Can this happen only at the start of a release (i,e., the list is locked for the release) or at any time. If its the former then when the next release lead gets request to update the list, he/she can also effectively prune the list to ensure each SIG sticks to their quota.

As part of this new process, we should also try prune the list before hand, after asking current folks on the list if they still need the powers and if so which SIG do they identify themselves with?

[spiffxp]

This feels super process heavy. I have yet to see "a foo role per SIG" efforts work out. I would focus more on the motivation behind the milestone-maintainer team, and describe entry/exit criteria.

[spiffxp]

Not trying to be the well actually guy, but the team is actually called kubernetes-milestone-maintainers

We gate /status and /milestone behind this team. Currently for all repos in the kubernetes org. We can configure this on a per-repo basis if there were a desire to do so (ie: I'm thinking about opening up test-infra to a different team of people)

AFAIK the main place the release team cares about these commands is kubernetes/kubernetes, I have historically not seen a ton of involvement in the kubernetes/features repo. I would use devstats to find out, but apparently it's not tracking either of these bot commands.

[spiffxp]

The main motivation I saw behind this team was to ensure that not any-old-random dev could shove their code into a milestone, once it came time for code freeze. I personally don't find the status/ labels helpful at all.

[spiffxp]

We'd be allow 31*2 people to add new members to this team? That would certainly remove the release team as the bottleneck in updating team membership, but I thought gating team membership behind "ask the release team" was a forcing function to ensure the team wasn't growing recklessly, and contained members that had been vetted by the release team.

[spiffxp]

Agree this needs clarification. If you're not actively willing to participate in issue/pr triage for a given release cycle, you shouldn't need access to these commands. With great power comes great responsibility.

[jberkus]

I have added this to the agenda for tommorrow's SIG-Release meeting.

[justaugustus]

Thanks everyone for the speedy feedback! I'll try to update prior to today's SIG Release meeting.

[jberkus]

Before we finalize this, I think we need to have a long conversation about how milestone, approved-for-milestone, code freeze, etc. work. Because it has a direct bearing on this.

For example, if we decide to get rid of approved-for-milestone (I would like to) then it becomes much more critical to carefully govern who is in the milestone-maintainers group. If we don't get rid of approved-for-milestone, then I'd argue that we should allow anyone to add a milestone to a PR/Issue.

[tpepper]

Before we finalize this, I think we need to have a long conversation about how milestone, approved-for-milestone, code freeze, etc. work. Because it has a direct bearing on this.

I agree, but that is going to be a 9 months discussion moving towards KEPs and a restructured feature or value definition process, which @jdumars and @justaugustus.

In the short term, as release lead and current custodian of kubernetes-milestone-maintainers GitHub team, I'd really prefer something for more specific guidance on who I admit. If folks are comfortable with the release lead just doing this in an ad hoc way for the next few cycles, then I would say we bin the PR until the broader KEPs and features management flow enhancements are decided.

[jberkus]

@tpepper I'm not sure that it is, because we need to replace milestone-munger now, and whatever we replace it with will need new rules.

[spiffxp]

FWIW we disabled the milestone-maintainer munger earlier this morning, ref: kubernetes/test-infra#8909

[spiffxp]

We discussed "what are we doing about the status/foo labels" on today's release team call, and I pointed this issue out as a place to document our decision

There was reference to "the discussion" wanting to get rid of these labels, which was this issue #243 where we ultimately just settled on disabling the munger that reminds people to use the right labels for a given phase of the release lifecycle

Whatever decision this group comes to on the use of labels, I would suggest it high affects the issue triage guide, ref: kubernetes/community#2430 and #240

[justaugustus]

Okay, before I update this again, I want to make sure I'm capturing everyone's feedback (both from the meetings and the comments on the PR).
Based on everything, I've heard and read, along with my $0.02 on some of this:

• Managing kubernetes-milestone-maintainers GH Team:
  • Membership
    • Maintainers
      • Current Release Team Lead
      • SIG Release Chairs (adding this for continuity across releases)
    • Members
      • At least one member of SIG leadership (SIG Chairs / Technical Leads) from all SIGs
      • Some number of SIG delegates per SIG (up to 2?)
      • (@jberkus) Special code reviewers as selected by SIG Release (the reason for "Special Reviewers" is mostly that I want Dims and Liggit to have MM status)
  • How frequently during the release cycle can someone update the GH team?
    • As much as is required
• What do we do about milestone-munger?
  • milestone-munger has been disabled
• With milestone-munger disabled, what should we do about /status & status/* labels?
  • Consensus seems to be to get rid of them; there was value when the bot was using this as a gate to manipulate milestones, but now that it's disabled, it's just an additional set of labels for a human to manage
• Should we prune the list now or later?
  • There was some desire to get historical data on who's using the labels, but this doesn't seem to be easy to do.
    • from Josh: Yeah, just to confirm: we do not have solid data on who applies the labels because of limitations with the GH event stream
  • I think we should prune ASAP

Let's also timebox this thing, as it's been hanging around for a bit.
If there are no strong objections by Thursday, 8/16 (5pm PT), we should update the copy and get this in.

Pinging everyone involved + SIG Chairs for a review of this summary:
/cc @tpepper @spiffxp @jdumars @calebamiles @AishSundar @jberkus @dims

[tpepper]

I can be tribute to trigger a pruning of the list, binning folks by likely sig and directly asking each and their likely associated sig leads if they should remain in the list as a delegate for the sig. If instead of a GH team, this were list were yaml based to feed the /milestone command we could have a field describing their status for example from the set of ("release team", "sig-foo-lead", "sig-foo-delegate", "dims", "liggit" ;)

[justaugustus]

@tpepper -- peribolos is also looming in the background w.r.t. GH team mgmt. Will leave it to @fejta, @stevekuznetsov or @spiffxp to comment on whether it'll fit this need and timeline.

[stevekuznetsov]

I think integration there is coming soon, but the only influence it will have on this process is to make everything a little more visible by checking team management choices into git.

[justaugustus]

The notes on Milestone Maintainers have been updated, and the review period has passed, so this is ready to be approved (barring any doc nits).

Some follow-on items:

• Prune / update kubernetes-milestone-maintainers GitHub team
  • GitHub issue: (dup) Prune / update kubernetes-milestone-maintainers GitHub team #258
  • Tracking sheet for Milestone Maintainers membership: https://docs.google.com/spreadsheets/d/1BhKpWwAVMxhtGAd_wOTCzduj-B4SDAp6C_wcSqo7SwA
• Remove status/* labels
  • GitHub issue: Remove status/* labels #259

Holding this for explicit approval by @tpepper or @spiffxp.
/hold

[spiffxp]

/lgtm
Save the /approve for @tpepper I know he was mulling this over

[tpepper]

After going through the current list membership last week, I really believe we've aimed for something too proscriptive here.

[tpepper]

It's important for us to have membership criteria here documented, especially as we will soon move to this team being managed via a yaml file in the k/k repo and thus PRs against it should have a clear review criteria.

But I still think this is overly specific. I'd like to see this more pragmatic and less proscriptive on the broader k8s community. If a SIG does not and has not had anybody on the list, that's not a problem in my mind. It means they've:

• had all features captured early in conjunction with the Features Lead from SIG Release who set the milestone (or whatever that process evolves to between SIG Release and SIG PM).
• had all required code merged ahead of code freeze
  That's a well performing SIG. It adds process on them to require them keep their milestone maintainers membership up to date for no utility.

What do you think of this wording, with the word "should" being deliberate versus "must" or "at least N, up to M", because I believe it's not just okay but actually normal case good if a SIG is getting by with zero members:

Membership to the kubernetes-milestone-maintainers GitHub team should comprise:

• SIG Release Chairs
• Current Release Team Lead
• Per-SIG leadership (SIG Chairs / Technical Leads / Approver delegates)
• Special code reviewers, as selected by SIG Release for their exceptional contribution activity and project oversight

[justaugustus]

Alrighty! After having a little SIG 🚲 🏚️ meeting w/ @tpepper, we've updated the copy to reflect:

• Maintainers (of the GH team) will include SIG Release Chairs & the current RT Lead
• Members can include any combination of SIG leadership, delegates, or special code reviewers, with no upper or lower bounds on each category

[tpepper]

/lgtm

The key distinctions now here for me:

1. maintainers of the maintainers list is basically 3 people, easy clear ownership, not 30+ people needing to each remember to take care of something every quarter...Once a quarter a couple SIG Release people check the list as up to date.
2. SIG leadership pragmatically gets membership if/when needed, each instance of which can be a reminder for SIG Release to have a conversation with that SIG to see that their members are up to date.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus, spiffxp, tpepper

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [spiffxp,tpepper]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[justaugustus]

Hehe, mind reader!
/hold cancel

[justaugustus]

Thanks to everyone who helped kick around ideas and provide historical context on this one! 🎉