1.35 Sneak Peak email links are dependent on directory being merged

[drewhagen]

What happened:

The link in the "1.35 Sneak Peak" email to the release-1.35 directory files results in 404 (at least over the last day) because the release-1.35 directory and release-team.md were (as time of reporting) not yet merged.

This issue has been highlighted by this raised PR that presents an "under construction" page: #2861

What you expected to happen:

Clicking on the links would bring the "Sneak Peak" email recipients to these pages, including the release-team.md where contributors can look at the next cycle's release team. Ideally, these docs should be merged in before sending a "Sneak Peak" email to prevent confusion.

How to reproduce it (as minimally and precisely as possible):

At least as of time of reporting, go to the "1.35 Sneak Peak email" and click on these links:
sig-release/releases/release-1.35
sig-release/releases/release-1.35/release-team.md

Notice this results in 404.

Anything else we need to know?:

These links in the original email will no longer 404 soon after merging
#2859
which contributes the missing files.

Further Remediation Steps

I can send out a follow-up email to the community with links to my fork for now.

Going forward for future releases, I'll amend the Release Lead Progress issue template to make this dependency more clear. Ideally, the release-xx directory is merged before the email.

Environment:

• Any email client that has received the email.
• Google group, and the specific email: https://groups.google.com/g/kubernetes-sig-release/c/_qi8z7qualM/m/q9YPtD6WAQAJ

[dipesh-rawat]

We ran into something similar on the docs side last release - the upcoming release schedule link (here) ends up being broken. As a fix, we’ve added a note on the page stating: "This link may be temporarily unavailable during early release planning phases.”

Maybe we could do something like this here in future:

• At the end of current release someone from the release team (current/incoming lead or any shadow) could open a PR to add the release-vNext dir and a placeholder README.md. It would just say "The schedule is being finalized and will populate here once approved".
• Once the schedule PR is merged, that placeholder README gets updated with the final dates.
• In the Sneak Peek announcement email, we can link the opened release schedule PR so the community has a chance to give feedback on the proposed dates.
• Maybe we drop the broken release-team.md link from the email template, since it will be updated in a few weeks in the release once the team is finalized.

That way we avoid 404s, keep the user experience clean, and still give the community a clear path to follow updates.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale