Sig-release: Consider using kubernetes-release-team@ instead of kubernetes-milestone-burndown@

[spiffxp]

We currently use a [kubernetes-milestone-burndown@] google group for the meeting invite for release team meetings, and in general as a google group for ACLs related to the release team. But it's really got so many more people than just the release team on it.

It turns out there is a [kubernetes-release-team@] google group that didn't really get documented as part of the 1.12 cycle. I noticed it when I was pruning acls for https://bit.ly/k8s114-enhancements. I'd like to pick it back up for the 1.14 release cycle. Release team leads and shadows should get added here. cc @justaugustus

Need to decide/document how this is used.

/milestone v1.14
/kind cleanup
/sig release

[spiffxp]

Step 1: I'd like to purge membership of kubernetes-release-team@ to match that of the v1.14 release-team + release-team subproject owners (let's call that sig-release leads for now) + patch-release team. Long term I feel like the patch-release team should be split into its own entity

[justaugustus]

As the person who created the group, I'm definitely in favor of this :)
/assign

[spiffxp]

/area release-team

[justaugustus]

The Kubernetes Release Team list membership has been updated.
After some discussion on Slack, it seems that the milestone-burndown serves no purpose that couldn't just as well be served by the top-level sig-release list.

That said, I'd like to get rid of it and @spiffxp is in agreement.

I'll let the other SIG Release Chairs chime in, on the off-chance I'm missing some context and then I'll put the request official on k-dev, k-milestone-burndown, and k-sig-release.

Lazy consensus timebox EOD PT Monday, 1/28.
/assign @calebamiles @tpepper

[tpepper]

I'm good with this.

[spiffxp]

Here's my proposal for use of the lists as it relates to calendars and docs:

• ensure sig chairs have owner privileges to the kubernetes-release-team@ and kubernetes-milestone-burndown@ lists
• release doc ACL's should be as follows
  
  
  
  • release team contact info should be readable only by kubernetes-release-team@ and kubernetes-sig-release-leads@
  
  
  • all other release related docs should be commentable by everyone
  
  
  • all other release related docs should be writable by kubernetes-release-team@ and kubernetes-sig-release-leads@
  
  
• there should be a shared calendar for the current release, owned by:
  
  
  
  • the release lead
  
  
  • release lead shadows
  
  
  • kubernetes-sig-release-leads@
  
  
• the shared calendar should contain the following meetings, with the following invitees:
  
  
  
  • release-team weekly and release-team eu weekly (pre-burndown):
  
  
  • kubernetes-release-team@
  
  
  • kubernetes-sig-release@
  
  
  • community-shared-calendar
  
  
  • release-team weekly and release-team eu weekly (burndown):
  
  
  • kubernetes-release-team@
  
  
  • kubernetes-milestone-burndown@
  
  
  • kubernetes-sig-release@
  
  
  • community-shared-calendar
  
  
  • release-team burndown meetings:
  
  
  • kubernetes-release-team@
  
  
  • kubernetes-milestone-burndown@
  
  
  • kubernetes-sig-release@
  
  
  • all-day events for major deadlines or events:
  
  
  • community-shared-calendar
  
  

I would also be fine dropping the kubernetes-milestone-burndown@ list entirely, since in this proposal I'm not suggesting they be used for any additional ACL's, just scoping the invite to burndown meetings

Also note I'm not putting burndown meetings on the community calendar due to noise. I can, if that seems relevant.

[spiffxp]

• who gets to be on kubernetes-release-team@ ref: https://github.com/kubernetes/sig-release/issues/458
• membership on kubernetes-release-team@ would be one of the access requirements for release team members ref: https://github.com/kubernetes/sig-release/issues/479

[tpepper]

I worry that the final burndown meetings aren't as discoverable as might be best. But today that's liable to be the case just the same as if they're on the community calendar, since the community calendar itself isn't super visible. We do at least follow normal practices around meeting minutes docs and where somebody who would need to attend should understand how to go hunt down info (same as for all other SIG and WG meetings). And if they've got a major problem, they better also already understand how to get ahold of the release lead, so...I think things are sufficient as proposed above in https://github.com/kubernetes/sig-release/issues/440#issuecomment-461590722

[BenTheElder]

Have we decided on this yet? asking re: https://github.com/kubernetes/sig-release/issues/479

[justaugustus]

Announcement to move forward with this on k-dev: https://groups.google.com/d/topic/kubernetes-dev/QIfxAp0xv98/discussion

[justaugustus]

606 removes the references to the burndown group.

[justaugustus]

/milestone v1.15
/priority important-soon