Thoughts on adding non-technical provider implementor guidance in the Cluster API Book

[elmiko]

As discussed into today's community meeting, I would like to start a conversation about adding some non-technical guidance to the Cluster API Book. The original question as posed on the meeting agenda is:

i’m curious if we might add a section to the book giving some guidance to new providers about things that go beyond the code, things like release cadences/process, and suggestions on creating meetings and communication channels. some of this is in the kube community repo as well, but i’m wondering if we might be able to share some of the cluster api community wisdom?

To that end, here are some issues that I am currently working through with the kubemark provider that I think would be beneficial to share with the wider community:

• Release versions and cadence
  • What is a good cadence for release?
  • Should provider versions have any relation to Cluster API versions?
  • Where are the best places to advertise new provider versions?
  • Is there any specific process for distributing a release to the community?
• Community organization
  • When should a project think about starting to have meetings?
  • What types of organizational type activities should a project follow to maximize their time/effort?

These are just some introductory questions that I have asked myself, or search for answers on. I think it would be great to hear what others might think, and also if this information exists already maybe we can link it in its current form rather than duplicating the effort.

There seemed to be some good support for this idea in the meeting, what other questions should we be asking? what are we missing? how can make this experience better for the next communities to create their provider implementations?

[fabriziopandini]

+1 to the idea
There are also some operational issues like

• how to create/donate a new sub project
• how to create a meeting calender
• how to create a zoom calendar
• how to setup/maintain contributor.md
• how to setup/maintain roadmap.md
• how to setup/maintain owner files
• how to set up CI

But we can start small and then iterate

[elmiko]

i think we can definitely find prior art for some of those, but i really like the direction you are thinking. making it easier for a new provider to approach the project, create their code, and ultimately share it with the wider community is a great target imo.

[dntosas]

sounds to me like "Best Practises for Provider Development" +1

[elmiko]

a recent email to the sig cluster-lifecycle list was asking about office hours cadence, in response i offered my thoughts about some possible options. i'm posting it here to help stimulate some discussion and also as possible inspiration for materials we create.

these are my thoughts on what i consider to be three strong options when considering setting up a community meeting.

1. weekly meeting. good for high cadence, and/or high user community size. gives many opportunities for issues and discussion.
2. bi-weekly meeting. good for high, or medium, cadence with a smaller user community size. gives regular opportunity for issues and discussion, but also places lower demand on the maintainers
3. monthly meeting. good for low, or medium, cadence with a small user community size. lowest demand on maintainers at the cost of infrequent public meetings.

[elmiko]

the topic of creating new slack channels came up in today's community meeting, this docs site has a lot of information that seems useful to this conversation.

https://www.kubernetes.dev/docs/contributor-cheatsheet/
https://www.kubernetes.dev/docs/comms/

[elmiko]

from today's community meeting, i raised the topic of repostiory owners/admins and how to add/remove, what are the minimums for good repo health, is their guidance around diversity of ownership. no solid answers, but i figured this is a good topic for this discussion as well.

[elmiko]

@neolit123 shared this link for the sig-cluster-lifecycle repository owners, https://github.com/kubernetes/org/blob/main/config/kubernetes-sigs/sig-cluster-lifecycle/teams.yaml