Update Roadmap page in CAPI book

[killianmuldoon]

The [roadmap page in the CAPI book] (https://cluster-api.sigs.k8s.io/roadmap.html) is in need of an update including:

• removal of the goals for v1alpha4 (0.4)
• add record of changes for v1beta1 (1.0)
• add placeholder for TBC details of the roadmap for release 1.1, and beyond. (exact timeline depending on community preferences)

/kind documentation

[killianmuldoon]

/assign

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[fabriziopandini]

/lifecycle frozen

[fabriziopandini]

/unassing @killianmuldoon

I'm working on this
/assign

[fabriziopandini]

/unassign

[oscr]

Since #6253 was closed without being merged, may I suggest removing the stale information from the Cluster API book for now and adding it later when/if a roadmap has been agreed upon?

[sbueringer]

+1

[oscr]

With #6680 the outdated roadmap has been removed and the CAPI book refers to GitHub for future roadmaps. So this issue is at least partly fixed. The question is should there be a roadmap in the CAPI book? Maybe it's good enough to just have it in GitHub?

[killianmuldoon]

I'd definitely be happy to close this issue and keep the roadmap going in the github discussion. IMO the future of the roadmap is going to be somewhere more dynamic like that rather than a static MD that will need to be updated often (and will easily go out of sync with the world).

[sbueringer]

+1 to not duplicating information we have in issues as a list in the book.

That being said, today it's very hard for users to figure out what will be in an upcoming release (not only for users...). Would be nice to have some kind of overview somewhere.

Could be an umbrella issue / a project (something I'm currently trying out a bit: https://github.com/orgs/kubernetes-sigs/projects/17) / a filtered issue list (currently our release milestones contain way to much things we don't implement) ...

But this would require more investment/time/effort than in the past to have a clear / more or less dependable roadmap for the next release(s)

[fabriziopandini]

What I would like to do is to remove the milestone from all the issues, than add it back only when someone actually commit to complete the work for a release.
Then we should find a way to pick relevant issue and show them in the milestone...

[sbueringer]

@fabriziopandini Sounds good to me. Just that I get it right that would mean:

• remove milestones from all open issues
• remove the Next milestone
• only set a milestone if someone commits to doing the work until the next release (currently ~ v1.3)

[fabriziopandini]

Yes, that's + probably we need to startu using /triage label to track when some maintainer take a first look at issues

[killianmuldoon]

The roadmap page is now a placeholder with a link to the github discussion: #6680.

There's an ongoing conversation in #6828 about how to make plans for the next minor release clearer by changing the way milestones are used on the repo.

Closing this issue for now to continue the discussion on more appropriate issues, in the community, and in the PR.

/close

[k8s-ci-robot]

@killianmuldoon: Closing this issue.

In response to this:

The roadmap page is now a placeholder with a link to the github discussion: #6680.

There's an ongoing conversation in #6828 about how to make plans for the next minor release clearer by changing the way milestones are used on the repo.

Closing this issue for now to continue the discussion on more appropriate issues, in the community, and in the PR.

/close

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.