Streamlining localization processes

[divya-mohan0209]

This discussion is to seed ideas for streamlining the processes around our localisation subproject so that @a-mccarthy and @seokho-son can co-lead it more easily. As subprojects, we want to give them the autonomy to run it as they see fit and lean on SIG Docs leadership for overarching governance guidance.

• First, we need to use our sig-docs-localization Google group a little more than we are doing now. Most folks who join localisation efforts aren't aware that this Google group exists and directly join the sig-docs group. While this is currently okay, if we need to streamline efforts and make it easier for folks to contribute, this would be an important step. I propose we broadcast it in all the localisation subgroups and during the meeting. We can also socialise it during the regular SIG meetings.
• Another thing that would be beneficial is aligning the SIG Docs localisation meetings (the monthly one + the individual translations) with the Google group calendar for localisations. Abbie and Seokho should be able to do these on the calendar as co-leads.
  • Create meetings for existing or newer localisations
  • Change the cadence of localisation meetings if need be.
  • Delete meetings once they're no longer required or if localisation is inactive.
• Given the interest we will get around localisation, its processes, and how to get involved after KubeCon, I suggest we consider forming a sub-team of stewards. I've typically seen @sftim being engaged for bootstrapping every localisation. We should consider documenting the process and having existing localisation members engage to staff these roles.
• We also need to document these as accesses that must be handed over to the future generation under k/community.

@tengqm @reylejano @natalisucks : Your thoughts, please?

[natalisucks]

Thanks for starting this discussion, @divya-mohan0209. What you've just proposed is supported by me, given we used this approach to recently set up the Arabic localization team bi-weekly meetings, with their own Zoom setup and calendar invite. I'd be happy to start documenting that specific process with @a-mccarthy and @seokho-son if needed, so it can be repeated across teams.

Another reason that I'm a fan of this approach is to help bring localization teams into a transparent space for possible new contributors to their languages (as I know some localizations seemingly work in private repositories, which isn't advised), alongside being able to better broadcast messaging that will effect localization teams (big changes coming downstream, for example, come to mind here, like the Dockershim removal).

Overall, huge +1 from me.

[reylejano]

+1 from me.

We should add a link to the sig-docs-localization Google group on this page https://kubernetes.io/docs/contribute/localization/ along with additional links to any new process documentation.
I believe what's proposed by this discussion helps new contributors localize Kubernetes docs.

[a-mccarthy]

yup, we haven't historically used the existing google group b/c there wasn't as much organization or centralization around localization teams until recently. There is also a much larger footprint of readers on the sig docs list, so it was easier to reach a wider audience using the sig docs list, verses the small number of folks on the localization group list when we had broad communications to send out.

If we want to start promoting using the localization list more, thats fine. Just so i'm clear, we should:

• Make sure @seokho-son and I are admins of the list
• Move over all localization meetings to the localization google group. This includes the monthly meeting and the Arabic team's meeting
• Update documentation to point folks to the localization meetings. This includes the contribution docs, the meeting agenda, and the localization subproject docs in the community repo.
• Document role permissions in on boarding/off boarding localization lead docs. This is something that needs to be moved into the subproject docs, right now its in a google doc
• Reach out to localization teams to see if they are interested in either creating a meeting or moving their existing meeting to the google group
• Communicate that these changes are taking affect
• zoom meeting will be set up using the sig docs account. Credentials for that account should be shared with localization leads.

Is there any community resources or trainings for helping folks to lead community meetings? I feel like this a big area of help we can provide to teams, or at least if we are expecting them to adhere and promote the Code of conduct, it might be nice to send them some resources on doing that as well.

One item @seokho-son has mentioned before is making sure the localization leads has the right repo permissions to help localization teams to merge PRs. There is usually a gap between when new teams get org access and a language OWNERS file up and when they want to start merging content

[a-mccarthy]

@natalisucks, @divya-mohan0209, @reylejano maybe you could shed some light on which permissions we'd need to have to approve language PRs in the repo?

[divya-mohan0209]

That's an excellent summary, @a-mccarthy. I didn't know this until yesterday either, but you are the admin of the Google group DL for localisations. I believe you can add @seokho-son. Once we get the consensus from everyone here, all the steps mentioned above can be rolled into effect.

Unfortunately, I know of no training or community resources on leading community meetings. Maybe others on here know of some and can list them here.

[divya-mohan0209]

Regarding the permissions issue, IMO, it's a great next step to follow up with after we finish with the alignment bits. This is because it will be a more significant undertaking given how we currently operate. Our repo has permissions implemented differently than we'd like them to be.

For example, since our main website is the English localisation, approvers/reviewers for the English localisation are given permissions for other localisations as well. Tim is tracking some of this, as far as I know, over this issue.

However, we haven't had the capacity or resources to delineate permissions in the past. First, we should consider the granularity and hierarchy we want to follow. This might be confusing since the main website is a subproject but also falls under the localisation subproject as an "English translation." I agree with Tim's suggestions in the above issue and propose the following hierarchy of permissions:

SIG Docs leadership (co-chairs + tech lead) => Will take over for the subproject owners in case of contingencies
⬇️
Localisation subproject owners (Seokho & Abbie) => Max level of approver/reviewer perms.
⬇️
Localisation owners (localisation, including English approvers)
⬇️
Localisation reviewers (localisation, including English, reviewers)

This aligns with what we have for the blog subproject, which has its own set of approvers/reviewers. However, SIG Docs leadership can step in when needed.

[a-mccarthy]

Given the interest we will get around localisation, its processes, and how to get involved after KubeCon, I suggest we consider forming a sub-team of stewards. I've typically seen @sftim being engaged for bootstrapping every localisation. We should consider documenting the process and having existing localisation members engage to staff these roles.

@sftim Can you share any ideas you have around this? Are there things to know/do when helping a localization team start up that aren't already documented somewhere?

@divya-mohan0209 We are heading into a Kubecon in a few weeks, do you have some ideas things we should prep to help folks that ask about SIG Docs and localization while there? Do you mean specifically how to advise folks who what to start a new localization that you meet at Kubecon, or more that there is a high interest in folks looking to help localizations and docs in general at Kubecon?

[divya-mohan0209]

So, I have mentioned this in the group DM that we have going on. But my idea is this:

Tim and a few others are typically the point of contact for bootstrapping localisation initiatives. While we appreciate their work, there must be a way to increase the pool of people contributing.

• As a first step, we formalise a team for the ongoing localisation platform initiative.
• From the pool of technical contributors we get there, we see if anyone would be interested in continuing in a tech leadership capacity for the subproject AFTER the cohort ends.
• Then, we build our tech leadership team and announce it formally.

[a-mccarthy]

@seokho-son if you have a minute can you review and share your thoughts on this?

[sftim]

@sftim Can you share any ideas you have around this? Are there things to know/do when helping a localization team start up that aren't already documented somewhere?

• I've often offered to pair with someone; we could shift that to making an introduction between the team in formation, and someone who can help as their buddy for the first few PRs.
• It's useful to point to our existing documentation and to help people understand what it means. It's precise, but maybe not that easy to understand.
• Often I've needed to explain to people that there are things they're doing that go beyond what's expected for launch (minimum content), so a review around that can especially help.
• It's good to explain how people can become the approvers and be recognized as contributors given that the thing they eventually want to maintain is not yet launched.
• I've called out likely snags (eg not in Latin alphabet; localization is RTL and we don't yet have support; special pluralization and its implication for localizing plural terms).
  What I mean about pluralization: with a target language that uses reduplication, you might localize “ConfigMaps” to “ConfigMap” (no final s; still valid as an API kind), and also localize “annotations” to “annotation-annotation”. If you were writing the API field annotations you'd leave it verbatim, annotations. It's helpful to have someone with localization or linguistics experience to highlight these potential snags ahead of them cropping up.
• I tell people about the Slack channels (#sig-docs, #sig-docs-localizations, the language specific channel they can have if they want one).
  • I may well help them get that channel added / help with that PR.