Documentation co-chairs/tech leads onboarding/offboarding procedures

[divya-mohan0209]

Per the discussion during the docs sprint held during KubeCon NA 2022, documentation around the onboarding/offboarding procedure for co-chairs & leads was found to be missing.

Areas for discussion:

• What do we need to document? For example, here are a few questions

--> What does a chair/tech lead need access to? (Answer: k/website, Google Groups, Zoom, Youtube, Netlify)
--> What is the level of access that needs to be granted? (elevated privileges mostly)
--> Will this be self-service, or do we need someone to provision access? (mostly automated, but there is scope for improvement)

• Where do we need to document it?

--> Should this be in k/website? Or would it be better placed in k/community under the SIG Docs folder?

• Can we codify this into a PR type during access raising?

cc: @a-mccarthy @natalisucks @reylejano @nate-double-u @sftim @tengqm @kbhawkey @onlydole @jimangel

[a-mccarthy]

This is great @divya-mohan0209! I agree that we should have this documented.

| --> Should this be in k/website? Or would it be better placed in k/community under the SIG Docs folder?

To me, this feels like something that should be in the community repo, because it is about how the sig is run. But i dont have a strong opinion if folks feel like this should be in the kubernetes website

I have a bit separate, but related question: Is there a different list of access that subproject leads need to have? This is probably something subprojects should document, but i wanted to raise it as a separate group of folks that need elevated access to some of sig docs tools. For example, as a localization lead I need access to Google Groups, Zoom, Youtube, and to be added to the owners file, but maybe not Netlify.

[divya-mohan0209]

That's an excellent point, @a-mccarthy! We don't have that document either, but I reckon it'd be a subset of the chairs' privileges, and it'd be great to document this as well based on your experience/s so far. We should centralize all of this in one location.

[jimangel]

As I offboard as a co-chair, I was going to open a PR with a short summary of offboarding actions after https://kubernetes.io/docs/contribute/advanced/#serve-as-a-sig-co-chair happy to move the content elsewhere if folks think we should carve a spot out in k/community.

Strong +1 on the rest too for onboarding. I think we don't need to make it more complex than it needs to be, maybe a checklist like (with maybe a bit more info on the "what"):

Onboarding

Everyone Needs

• Owners in k/website
• Owners in k/community (GitHub teams)
• Owners in k/org
• README in k/community
• Add to sig-docs leads Google Group
• Analytics?
• YouTube / Uploads

Co-Chairs

• Netlify
• Zoom for bi-weekly

Localization leads

• Zoom for monthly

More PRs coming soon! ❤️

[onlydole]

Thank you all for providing this feedback! I agree that it would be great to document the items identified, with a focus mainly on who owns what, and clearly define the roles of co-chairs, tech leads, and the current release docs lead (adding "Why" would also be a HUGE bonus).

Should this be in k/website? Or would it be better placed in k/community under the SIG Docs folder?

I'd prefer that SIG Docs in the k/community site is where we house our source of truth, and we can link to that from k/website to ensure maximum discoverability for folks.

Can we codify this into a PR type during access raising?

Having specific onboard/offboard issue templates would be helpful, and we can codify some of these by using GitHub actions where applicable.

[jimangel]

I took a draft / opened a PR for k/website (#38864). Let me know if you want me to update to a new location / name (currently github.com/kubernetes/community/sig-docs/offboarding.md): https://github.com/kubernetes/community/pull/7035/files

[divya-mohan0209]

I think we've achieved what we set out to do with this discussion. Hence closing it.
/close