Update SIG Release leadership

[justaugustus]

Chairs:

• Move Jaice Singer DuMars to Emeritus status
• Add Stephen Augustus
• Add Tim Pepper

/assign @calebamiles @jdumars @tpepper
/sig release

Signed-off-by: Stephen Augustus foo@agst.us

[calebamiles]

@justaugustus,

IMO this charter should live with the rest of the (non-generated) SIG Release information in the github.com/kubernetes/sig-release namespace like our other documentation. Generally, the charter needs to square the content that already exists in the README. We're also proposing a change of leadership without documenting how these changes should be proposed and are approved

[tpepper]

Elaborating a bit on Caleb's comment, this week's SIG Release meeting (see Oct. 9, 2018 recording) started with discussion of this draft.

Regarding location of charter files: other SIGs have theirs in k/community repo, with subdir and file of sig-${NAME}/charter.md. It seems confusing for SIG Release to then put ours in k/sig-release. Are there other sigs which place their charter in a non-k/community repo location? My suggestion would be to reduce the content in k/sig-release/README.md and have it mostly link to the charter in k/community/sig-release/charter.md.

Leadership changes: my reading of the current contents of the directory at https://github.com/kubernetes/community/tree/master/committee-steering/governance including the README.md, sig-governance.md, sig-governance-requirements.md, and the new shorter template (which Stephen has copied as is the guidance) is that the intent is for individual SIG charters to mostly say "we follow the normal documented path, plus the following deviations". In particular https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md covers a basic path for continuity across members of defined roles in SIGs. If nothing else is proposed for this SIG, the charter could explicitly state that.

That said, this PR introduces changes to SIG chair membership. That should be a separate PR.

I'll note a few other things in the charter directly, but I don't think this draft charter really needs much. It's very aligned with what has come out of steering in the past months for simplified charter guidelines. If we don't have much deviation, we don't have much that needs to be in the charter. Yes the charter is redundant today with k/sig-release's README, but that's because that README was standing in as a rough charter.

[tpepper]

Lines 12-14 are a remnant of copying the charter template and should be removed.

[tpepper]

An initial item here might be "support". While the release team operates the crank that produces new releases, manages patch releases, and ends patch release streams on older releases, the SIG itself is not responsible for end user support or creation of patches for support streams. There are support forums for end users to ask questions and report bugs, subject matter experts in other SIGs triage and address issues and when necessary mark bug fixes for inclusion in a patch release.

[tpepper]

Remove either "follows" or "adheres".

It might be more clear to add something like:

Specifically, the common guidelines (see: [sig-governance.md](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md)) for continuity of membership within roles in the SIG are followed.

[tpepper]

I agree currently, but can see this changing for a few reasons. First, we don't have any subprojects listed in the charter yet. As patch manager becomes less a role for three individuals, one per each of the prior three releases that are considered supported, and more of a team effort, this patch release team might become a subproject formally. If so that would have subproject chairs, but if not, it probably should have a tech lead. Also presuming a WG LTS is formed, I can see having a SIG Release tech lead associated with that, until such time as it either disbands or returns an implementable LTS KEP to SIG Release, which would then likely become a subproject with chairs.

[tpepper]

Since this is a first charter for SIG Release and we're thinking of adding some subprojects, I think it would make sense to explicitly say here that there are currently no formal subprojects of SIG Release, but that {give list} are being considered for proposal as subprojects in the near future. Any of those that don't pass muster for subproject status may also then end up in the Out Of Scope section.

[tpepper]

In the last year there's been talked about subprojects for the 1.X release teams, driving release engineering process and automation improvements, doing more around source code license and compliance management, improving security and adding provenance / threat modeling, and changing the support stream model (ie: to LTS or to not LTS).

[spiffxp]

/committee steering

[justaugustus]

(following the thread, btw. I'm just away at a company event at the moment, so I won't be able to address feedback until later.)

[justaugustus]

After discussing with @calebamiles offline, I'm moving the charter to k/sig-release, as we already keep all of our other documentation there: kubernetes/sig-release#348

@tpepper -- I've incorporated your feedback on that PR.

Switching this PR into the PR for the leadership changes.

[jdumars]

I am sad to be a deletion in the file, but also glad to see the next wave of project leadership emerge.

/lgtm
/meow

[k8s-ci-robot]

@jdumars:

In response to this:

I am sad to be a deletion in the file, but also glad to see the next wave of project leadership emerge.

/lgtm
/meow

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[justaugustus]

Announced on k-sig-release, k-sig-release-leads, and steering: https://groups.google.com/d/topic/kubernetes-sig-release/CIe4ekG7GkE/discussion
Maintaining lazy consensus hold until Friday, November 2nd, EOD PT.
/hold

[timothysc]

LGTM - But what does this mean you two plan to stay in this roll for some period of time across (N) releases, b/c historically release managers rotate.

[cblecker]

/cc @timothysc @spiffxp
I don't know if there are specific guidelines for charter location, but CC'ing steering to ensure this is cool with them.

[timothysc]

The charter typically lives in the community repo next to all the other sig details, not in an external repo.

[calebamiles]

all of the important documentation for SIG release lives at github.com/kubernetes/sig-release we are unique in that regard but I would strongly like to continue in that direction. I would say that we shouldn't use a vanity URL in the link though.

[justaugustus]

Hmm... we provide the field to specify charter_link. I feel that implies that charters don't necessarily need to live in k/community as charter.md. If that's not the case, we should remove that field from the generator.

As Caleb mentioned, k/sig-release is the canonical source for all SIG Release information, so I think having the SIG's defining document adjacent to other SIG Release info is important.
While I can get the need of not wanting break current convention, SIG Release is one of the few (maybe only) SIGs that has their own repo, and it's well-organized. Let me know what you think!

[justaugustus]

Also, any reason to not use the vanity URL, @calebamiles?
It's the suggested method (for markdown, at least): https://github.com/kubernetes/community/blob/master/sig-contributor-experience/markdown-link-style-guide.md

[timothysc]

Charters should really be homed in a single location from a discoverability and policy enforcement perspective. If there are bulk edits to how we do charters, the person responsible would have to track across (N). I don't think sig-release is unique from a charter perspective.

[justaugustus]

I do think SIG Release is unique insofar as where the SIGs documentation is constantly put. That said, I don't have a strong opinion (@calebamiles does, however) on where we land our governing document, outside of saying I hope it would stay close to the day-to-day docs we craft.

If Steering would prefer the charter remain in the community repo, as opposed to in k/sig-release, I'd want that to be explicitly said, as well as having charter_link be removed from the generator template. If we're saying that charters will always be within the SIG dir, named as charter.md, than the additional field has no use outside of allowing confusion.

[cblecker]

@justaugustus The field allowed for transition when some charter docs (before there was formal structure) were in docs and the like. I don't think we need to force a technical limitation on the generator here, when a policy one will do just fine. Setting that value to charter.md like most other sigs have works just fine.

[jberkus]

@timothysc SIG-Release Lead != Version Release Lead.

That is, the leads for the SIG are different from the leads for each of the releases. The terminology makes it confusing. But the SIG leads are supposed to focus on long-term release needs, instead of the current release.

[justaugustus]

Yep. What Josh said.
The official terminology would be SIG Release Chair (SIG wide) and Kubernetes x.y Release Team Lead (Release Team subproject-scoped).

[justaugustus]

Removed the charter link. Needs a re-/lgtm.

[cblecker]

/lgtm
/approve
/hold

Feel free to remove hold once lazy consensus period expires.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cblecker

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 [cblecker]

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

[timothysc]

/lgtm

[justaugustus]

Thanks @timothysc!

[justaugustus]

Removing lazy consensus hold.
/hold cancel

[justaugustus]

Thanks everyone who reviewed this!