Skip to content

Latest commit

 

History

History
274 lines (196 loc) · 18.7 KB

README.md

File metadata and controls

274 lines (196 loc) · 18.7 KB

Enhancements Lead Handbook

Overview

While the Enhancements Lead serves as a member of the Release Team (a subproject of SIG Release), this role is also a liaison to sig-arch-Enhancements subproject of SIG Architecture.

Responsibilities

An Enhancements Lead holds the following responsibilities:

  • Maintain the active status of Enhancements within kubernetes/enhancements
  • Facilitate communication between Enhancement Owners, and SIG leadership, as necessary
  • Collate the major themes of the release, including but not limited to:
    • new enhancements
    • long-awaited enhancements
    • enhancements moving into GA
    • enhancement deprecations
    • notable changes to existing behaviors
  • Assist in Communications activities (in conjunction with the Communications Lead & the CNCF Communications team):
    • Draft and / or review https://kubernetes.io/blog/ release announcement post, leveraging the themes collected across the release cycle e.g., 1.17 Announcement
    • Engage with media analysts during the embargo period to discuss the release themes
    • CNCF Kubernetes Release webinar
    • Identify potential contributors for the “5 Days of Kubernetes” blog series
  • Identify candidates to assume the Enhancements Lead role (according to the Release Team selection process) in the following release cycle
    • Chose Enhancement shadows whom you believe would be a good fit for succession and help mentor them throughout the release cycle

Prerequisites for Enhancements Lead and Shadows

General Requirements

Before continuing on to the Enhancements specific requirements listed below, please review and work through the tasks in the Release Team Onboarding Guide.

Enhancements Specific Requirements

Helpful characteristics of an Enhancements Lead include:

  • experience with the Kubernetes community, code layout, ecosystem projects, organizational norms, governance, SIG structure, architecture, and release process
  • product / project / program management experience
  • release management experience

Approximate Time Commitments

  • Beginning of the cycle through enhancement freeze: 6-10 hours a week fluctuating based on how many SIG meetings need to be attended
  • Enhancement Freeze through Code Freeze: 4-7 hours a week
  • Code Freeze through Release Day: 1-4 hours a week

Mentoring Shadows

The selected shadows should be:

  • Interested in learning more about the Kubernetes release process.
  • Able to dedicate a couple hours each week to attending the Release meeting in addition to helping with weekly tasks.

The shadows should be selected keeping in mind that one of them may eventually be taking up the Enhancements Lead role. It is important to delegate tasks and give the shadows broad exposure to the different aspects of the role.

Getting Started

Access Required

Ensure that the previous Enhancements Lead has given (or facilitated getting) you access to:

  • GitHub teams
  • Access to the previous Kubernetes Release Enhancements Tracking Sheet.

Process

Standards

As mentioned previously, the Enhancements Lead role encompasses several cross-functional responsibilities with sig-arch-Enhancements subproject of SIG Architecture.

The process of maintaining an enhancement in Kubernetes is documented in the kubernetes/enhancements repo. Any questions / concerns / suggestions for improvement to the Enhancements process should be raised as GitHub issues / PRs to k/enhancements.

It is important that this process be followed and documentation remain up-to-date as the Enhancements repo is the primary ingress point for contributors interested in tracking enhancements.

Milestone Activities + Timing

Note: The week #n timings given below are tentative. There are special releases like Kubernetes 1.19 or releases at the end of the year which may not strictly conform to that.

Pre-Collection (Week 0)

  • Duplicate the previous enhancement collection spreadsheet into your own Google Drive and adjust it for the current milestone. Enhancements Tracking sheet is shortlinked with the pattern k8sxyy-enhancements e.g., http://bit.ly/k8s113-enhancements. Create a free account on bitly to create a shortlink for the new enhancement collection spreadsheet.
  • Clean up the spreadsheet by removing all currently tracked issues from both the Enhancements and Docs tabs
  • Update the permissions on the enhancement collection sheet
  • Make a pull request to add the shortlinked Enhancement Tracking sheet to the current release page in sig-release
  • Find Issues from previous milestone that have graduated to Stable. Remove tracked/yes or tracked/no labels. Check to see if the KEP status has been updated to implemented. If it has, close the issue. If it has not, ask the issue contact to both update the KEP status field and close the Enhancement issue once the update PR has merged.
  • Find Issues labeled tracked/yes and change to tracked/no until the Enhancement is ready to be tracked for the upcoming release.
  • Close previous milestone by ensuring that there are no open issues/PRs in that milestone.

Pre-Enhancements Freeze (Week 1)

  • Gather Shadows to have them read this handbook and give expectations on what the process looks like and their particular role. If possible, try to schedule a call with the shadows to get them accustomed to the team. This helps as a great team building exercise.
  • Send an email to the Kubernetes-Dev mailing list and a message to #chairs-and-techleads slack channel with a call for enhancements and how to opt-in to the release.
  • Verify issues have k/k PRs associated so they can be referenced and easily tracked. This is going to be critical come Enhancement Freeze and Code Freeze to see the status of the code.
  • Work with the Release Lead to introduce yourself, talk about release information, and relay information about opting into the release with SIG Leads.
  • Weekly Release meetings require updates of current status. Use the Feature stats tab to update the release team on counts of enhancements in good and bad progress.
  • Start reminding Issue owners that KEPs are required for each enhancement and that KEPs must be in an implementable state by Enhancement Freeze.

Collection Monitoring and Triage (Week 2-3)

  • Move data from KEP Collection into the data tab to be tracked officially for the release
  • Stay on top of comments in issues when owners respond. Apply correct labels, milestone information, update their status in the sheet if necessary.
  • Mark features as At Risk if there is no communication, active PRs on the issues, or it is missing other requirements coming into Enhancement Freeze.
  • Start syncing with Communications Team on giving an induction what's coming up for the release.

Enhancements Freeze (Week 4)

  • On Freeze day, send an email to Kubernetes-Dev that freeze has happened. "We are at X enhancements, and any new ones will require an exception." Examples 1 2.
  • Remove any enhancements that failed to meet the criteria by the Enhancement freeze deadline. Set their status in the sheet to Removed from Milestone and use the Enhancements -> Remove Enhancements from Milestone menu option to move them over to the Removed from milestone tab.
  • Any enhancements removed from the milestone will now require an exception. As exception requests come in, discuss each with the Release Lead (and Shadows) to arrive at an approve/reject decision. Create an exception file in the Release for exceptions Example 1. If a previously removed Enhancement has had their exception Approved, set their status to Tracked and use the Enhancements -> Track Removed Enhancements menu option to move it back to the Enhancements and Docs tabs.

Post Enhancements Freeze (Week 5-10)

  • Stay on top of issues and continually monitor them twice a week and look at attached PRs. As Code Freeze gets closer, if there are PRs that have not been merged, move the issue to At Risk. If there is no activity, ping issue owners on either the issue or the k/k PR.
  • Monitor issues that are At Risk closely, almost daily. Code Freeze means no new code and keeping tabs on the status of the k/k PR is critical to planning. Make decisions if the enhancement should be deferred and work with SIG Leads to determine the best path forward.

Code Freeze (Week 10+)

Start planning for the next release while assisting the Release Lead with anything relating to Analyst or Public Relation planning. Work with the Communications Lead to develop major themes for the official Kubernetes blog post.

Working with the Enhancement Tracking Sheet

Cross Release Enhancement Tracking

The source of truth for Enhancements is the data tab within the tracking sheet. It contains items that do not often change state. All other tabs are driven off the data in this tab. It should be kept as up-to-date as possible.

Column Entry type Description
Issue Manual Enhancement Issue Number.
Name Generated Enhancement Issue Name and link. Generated from Issue Number.
Responder Manual Last person to respond on behalf of an Enhancement.
SIG Generated* Owning SIG. Generated from KEP path. If no KEP (PR in flight), requires manual entry.
KEP Manual Link to KEP or KEP PR.
KEP State Manual KEP State (Pending, Implementable etc).
Completed in Release Manual The release in which the Enhancement graduated to stable.

Dashboard

The Dashboard tab is intended to be an at-a-glance view of the current Enhancement status from both the perspective of the Enhancements and Docs teams. It is 100% generated from the Enhancements and Docs tabs and should NOT be updated manually.

Enhancement Signal

Enhancements that are missing any criteria should be labeled as At Risk. To help make this easier for the Enhancement team to label. Proposals and KEP State are color coded indicating their current readiness state.

  • Proposal
    • #B7E0CD KEP is merged
    • #FCE8B2 KEP PR in flight
    • #F4C7C3 No KEP or KEP PR found
  • KEP State
    • #B7E0CD Implementable or Implemented
    • #FCE8B2 Provisional
    • #F4C7C3 none or invalid

Removing Untracked Enhancements

Untracked Enhancements are Enhancements that were Pending Inclusion with either no response by the Enhancement Freeze deadline or specifically stated that they should not be included. Once either a response from issue owner stating it should not be tracked or the Enhancement Freeze deadline occurs, their status should be set to Untracked.

Once done, use the Enhancements -> Removed Untracked Enhancements menu item to remove it from the Dashboard, Enhancements and Docs tabs. It will not be moved over to the Removed from Milestone tab.

Removing Tracked Enhancements

If the Enhancement is being bumped to a later release, set it's state to Deferred.

If it is being removed due to missing criteria or lack of response after being included in the milestone, set its state to Removed from Milestone.

Once done, use the Enhancements -> Remove Enhancements from Milestone menu item to automatically to move it to the Removed from Milestone tab removing it from the Dashboard, Enhancements and Docs tabs.

Moving a Removed Enhancement Back into the Milestone

If a removed item has had an exception granted. Set it's status to Tracked in the Removed from Milestone tab. Then use the Enhancements -> Track Removed Enhancement menu option to move it back to the Dashboard, Enhancements, and Docs tabs.

Tips on judging Stage Status

  • If the feature is graduating to Alpha, the status can either be Net New/Major Change. But usually when features are introduced to Kubernetes, they are not Major Changes.
  • If the feature is graduating to Beta/Stable, almost always the state is Graduating/Major Change. One exception to that is some features directly jump the hoop to Beta, in that case, the status can be Net New for even a Beta feature.

Feel free to ask the previous enhancements leads about this when in doubt.

Escalation / Handling Unresponsive Enhancement Owners

For issues where the initial owner is unresponsive, try escalating to the relevant SIG's leadership to determine if the issue is still targeted for the release.

If there is continued unresponsiveness on issues, remove them from the milestone at your discretion.

Exceptions

Exception process is outlined here

CNCF / Media Engagement

  • You may be called upon by the communications lead to help with media engagement near the end of the release cycle. Please ensure that if there are any restrictions or training required by your company before engaging that you have completed those ahead of Code Thaw.

Succession

  • Select who will be the new enhancement lead for the next release. Shadows should be the first source pool. If none are available to lead then look externally through other release team members or members of SIG Architecture Enhancements Subproject
  • Generate new Enhancements Tracking sheet with enhancements that were removed from the current milestone
  • Enhancements Tracking sheet is shortlinked with the pattern k8sxyy-enhancements e.g., http://bit.ly/k8s113-enhancements
  • Continually work to improve Enhancements process
  • Review / update documentation as the release cycle ends
  • Close issues marked as stable that made it into the release, only after the corresponding KEPs have been marked Implemented
  • Close milestones that are complete
  • Cleanup old milestones

Limitations

Signals

Tips & Tricks

Sample Searches (examples)

GitHub Notifications

https://groups.google.com/forum/#!topic/kubernetes-dev/5qU8irU7_tE