Kubernetes v1.38
Docs Team

The people you'll be working with

Two teams matter to us: the v1.38 release team, and our own six.

v1.38 Release Team

Our team

Six of us, across five timezones.

You have one buddy for the whole cycle, and you share accountability for both of your KEP slices: either of you can answer an author, update the board, or continue a thread. Buddy assignments are in the responsibility sheet. I'm buddied up too, with a KEP slice of my own — this isn't a hierarchy, it's six people covering ~60 enhancements across every timezone.

What the Docs team owns

Since v1.36, Release Notes folded into Docs. That means we ship two things at once.

The whole cycle on one page

Sixteen weeks. Two of the three capacity holes fall after Code Freeze, which is why our internal dates run a week ahead of the published ones.

Every date twice — theirs and ours

The left date is what the community sees. The right date is what we tell KEP owners and what we hold ourselves to. The gap is buffer we never spend.

What you personally own

Three layers: a standing KEP slice that's yours all cycle, a buddy, and rotations that move week to week.

Your KEP slice — end to end

You'll be assigned roughly 10–14 tracked enhancements, grouped by SIG and by shared owner so one message can cover several. "End to end" means you own all of this, not just the first step:

• Reminders R1 through R5 (section 06)
• Reviewing the docs PR when it lands
• Keeping Docs Status current on the board — the same day you learn something, not at the end of the week
• Logging every reminder in Sheet 7 of the responsibility sheet
• Telling me early when a KEP goes quiet. Early is free; late is expensive

Rotations — from the responsibility sheet

If you can't make something

Let the team know 2–3 hours ahead in your meeting's timezone, especially if you're on the hook for a responsibility that day. Everyone has other priorities and things come up — advance notice just lets us redistribute. No explanation needed.

The release notes rotation

Every tag gets a notes PR: one assignee, one reviewer. Nine rows, two of which don't exist in the handbook.

Running it

• Install krel and always use the latest build — it gets fixes every cycle.
• Generate the bundle for the tag, then open a PR against kubernetes/sig-release.
• Edit with krel release-notes --fix. It's session-based, so you can pause and resume. Edits are saved as map YAML files.
• Always keep release-notes-draft.md and release-notes-draft.json in sync. The JSON drives tooling; drift between them is silent and painful.
• Cross-check the note count against merges in k/k since the previous tag — krel can skip PRs during rc fast-forward syncs.

Style rules that cause the most churn

A note has to stand alone: a reader should understand the change without opening the PR. If one is too vague to do that, open the PR and rewrite it with the actual symptom.

The reminder ladder

Five touches to get placeholder PRs open. The channel changes as the problem changes — the first two are informational, the rest are human.

The ready-for-review and Docs Freeze phases use shorter versions of the same ladder — four touches each, same channel logic. Dates are in the responsibility sheet.

Sending a Slack reminder, step by step

This is the page to reopen when R3 comes around. Four steps, and the fourth is the one people skip.

The weekly branch sync

Merge main into dev-1.38 every Friday. This is the task most likely to be quietly skipped, and the one that bites hardest on release day.

Use the script rather than the manual steps:

The sequence, by hand

Run it manually your first two or three times. The script is faster, but you need to recognise what a sync gone wrong looks like before you let something else do it for you.

Then open the PR against kubernetes/website — and change the base to dev-1.38.

Two ways to get it wrong

The sanity check catches both. git log --oneline upstream/dev-1.38..HEAD should print one merge commit plus whatever came from main. Hundreds of commits, or a diff deleting feature docs, means you started from the wrong base — delete the branch and start again.

The Fridays

Two are moved: Nov 27 is the day after Thanksgiving, so that sync happens Wed 25 Nov. Tue 15 Dec is the final pre-release sync and I'll run that one.

When it conflicts

Conflicts are the normal pain point — a page updated on both main and the dev branch. The dev-branch change is almost always an in-progress feature doc, so preserve it and layer the main update on top where they don't clash. If a conflict isn't obvious, git merge --abort and ask in #release-docs before re-attempting. Verify the branch builds before pushing.

Reviewing a docs PR

SIG Docs has limited capacity, so we review actively. A PR needs both a technical /lgtm and a docs /approve to merge.

For technical accuracy, go to the reviewers and approvers named in the KEP's kep.yaml, or the SIG owner. It's fine — expected, even — not to understand every technical component. Get a technical LGTM when you're unsure.

Need help? #sig-docs, and the weekly PR Wrangler is your best resource.

Board vocabulary

We live in the Docs view of the v1.38 Release Tracking board. Two fields matter, and every value means something specific.

Board: v1.38 Release Tracking — Docs view

After Code Freeze — one more stamp

A few days after Code Freeze, once code-freeze exceptions settle, every tracked KEP gets marked:

The four-box template in the templates folder decides which: PR linked in the issue description, targets dev-1.38, in Ready to Review state, and mergeable by Docs Freeze. All four checked means Tracked.

When a KEP goes quiet

There's a defined path. Work it in order, and start earlier than feels necessary.

1. Comment on the PR and send a Slack DM to the KEP owner.
2. Ping the SIG chairs and tech leads in #chairs-and-techleads.
3. Join the SIG's regular meeting and raise it in person.
4. Last resort — escalate to the Subproject leads and Release Lead. Reach out at least a week before you need it, not the day you need it.

Reporting status

We report a colour every week. The most important thing to know: SIG Docs actively wants to hear yellow and red early.

The handbook's own wording: "SIG Docs prefers and welcomes a status of yellow or red on anything that needs attention, has the possibility to miss deadlines or target dates, or requires follow-up from feature authors and SIGs that you're not receiving."

What to bring to the meeting

Be specific in the last row. "A few KEPs are slow" gets nothing; "SIG Storage KEP #1234 hasn't replied to three touches, can someone from the release team nudge the chairs" gets action.

Meetings, channels, groups

Slack — join all of these

Plus our private Docs team group, where the templates are pinned and weekly assignments are posted every Monday.

Google Groups

Meetings

• Release team meeting — weekly through week 12. APAC instance begins Wed 9 Sep. If you're assigned the update and can't make it, tell the team 2–3 hours ahead.
• SIG Docs — APAC and EMEA instances. Both need a Docs voice; if you can't attend, put the update in the meeting notes so the community stays informed.
• Burndown — Mon/Wed/Fri from Mon 23 Nov, then daily with Tue/Thu over Slack from Mon 30 Nov.
• Our onboarding call — ran Mon 14 Sep, and was not recorded. This deck is the reference instead; ask in the team group rather than by DM and the answer is there for everyone.

Subscribe to the Kubernetes Release calendar so none of this is a surprise.

Your action items

React ✅ in the Slack thread as you finish each one, and reply in-thread with any PRs or issues you open so we can track them.

• Read the Release Team onboarding guide end to end
• Review the Community Guidelines and sign the CLA
• New members: open a dummy PR in kubernetes/contributor-playground now to trigger the CLA bot, so it isn't blocking you later
• Apply for org membership in kubernetes and kubernetes-sigs, listing sponsors @sreeram-venkitesh and @fsmunoz or @katcosgrove. Skip if you're already a member of both.
• Join every Slack channel and Google Group in section 13
• Subscribe to the Kubernetes Release calendar
• Skim the docs style guide before your first review
• Skim the Docs handbook, especially the Release Timeline
• Claim your rotations in the responsibility sheet
• Install krel and fork kubernetes/website and kubernetes/sig-release

Where everything lives