The new SIG creation procedure #226
Conversation
Following up the discussion, initiated at https://groups.google.com/forum/#!topic/kubernetes-dev/LEtIxeG0i84 and #90, this procedure describes the process of creating the new SIG (as well as optimizing the existing ones) within the Kubernetes community. These steps were performed and reproduced for the newly created SIG-OnPrem, existing SIG’s should be updated via this procedure as well.
k8s-ci-robot
added
the
cncf-cla: yes
|
cc @bgrant0607 @grodrigues3 @justinsb @kubernetes/sig-contributor-experience-misc |
sig-creation-procedure.md
Outdated
| * sig-foo-pr-reviews | ||
| * sig-foo-api-reviews | ||
|
|
||
| I.e: |
There was a problem hiding this comment.
I.e. means "that is". Should be "for example".
|
@idvoretskyi Thanks! Could you please move additional SIG-creation-related content from README.md to the new doc, and put a reference to it in README.md? |
|
cc @grodrigues3 |
sig-creation-procedure.md
Outdated
| ### SIG creation procedure | ||
|
|
||
| #### | ||
| **Create the GitHub teams** |
There was a problem hiding this comment.
I would put the team creation last, so that you can mention that the users should be added to the teams.
There was a problem hiding this comment.
Put the "How to start a SIG" section first.
Move the comment about slack channel archiving to that section, where it mentions creation of a slack channel.
We need to explain how the notifications are intended to be used, perhaps in yet another doc, under contributors/devel, which could be linked to from this one. That can be done in a later PR.
|
|
||
| Name convention: | ||
|
|
||
| * kubernetes-sig-foo-misc |
There was a problem hiding this comment.
it looks like you have examples of the convention for each section but you do not explicitly definite the convention ever. Something like "Names should follow the convention kubernetes-sig-<YourSigName> where YourSigName has individual words divided by slashes."
|
|
||
| Create the GitHub users at [https://github.com/join](https://github.com/join), using the name convention below. | ||
|
|
||
| As an e-mail address, please, use the Google Group e-mail address of the respective Google Group, created before (i.e. - for user ‘k8s-sig-foo-misc’ use ‘[kubernetes-sig-foo-misc@googlegroups.com](mailto:kubernetes-sig-foo-misc@googlegroups.com)’). After creating the GitHub users, please, request @idvoretskyi (backup person - @sarahnovotny) to add these users to the Kubernetes organization. |
There was a problem hiding this comment.
In the past, github has flagged such efforts as robot accounts and possibly in violation of ToS. I had to manually email them and ask them to reinstate an account for me.
There was a problem hiding this comment.
@thockin how can we avoid this? /cc @bgrant0607
There was a problem hiding this comment.
@idvoretskyi Could you ask github to ask them to exempt these accounts from whatever policy that is?
We could potentially extend one of the bots to do the forwarding, but using the existing notification mechanisms seems simpler.
There was a problem hiding this comment.
There was a problem hiding this comment.
@bgrant0607 thank you for clarifying (unfortunately, I've missed the previous comment here).
|
|
||
| Name convention: | ||
|
|
||
| * kubernetes-sig-foo-misc |
There was a problem hiding this comment.
If *-misc is intended to be main group, it looks very misleading. Why not use main group like kubernetes-sig-foo?
There was a problem hiding this comment.
Having discussed this question with @bgrant0607 we've decided to avoid having non-suffixed groups.
If you have any suffix changing proposal (instead of *-misc), let's discuss it here.
There was a problem hiding this comment.
I would go with -main for discussion group and maybe -team for actual team in GH.
There was a problem hiding this comment.
These new groups are intended to be purely additive -- the existing discussion groups will continue to exist as they are.
There was a problem hiding this comment.
Is this also a case for Github groups? If yes, then I have no concerns
There was a problem hiding this comment.
I assume not… someone renamed all the existing sig teams and appended -misc
There was a problem hiding this comment.
I renamed the groups. I do not want unsuffixed github teams. They are already notified in many, many issues and PRs, and, from experience, people will frequently notify the less specific team if it exists rather than choose more appropriate ones, especially given how autocompletion works.
|
|
||
| Name convention: | ||
|
|
||
| * sig-foo-misc |
There was a problem hiding this comment.
Same note as above: looks very misleading to name main team (used by actual humans) with *-misc.
There was a problem hiding this comment.
Agree… tagging foo-misc in a github issue is really strange
There was a problem hiding this comment.
@liggitt The intent is to almost never tag foo-misc.
I intentionally do not want a "main" github team for each SIG.
@bgrant0607 done. |
| * Request a Zoom account from @sarahnovotny if you expect more than 30 attendees or attendees from China. | ||
| * Add the meeting to the community meeting calendar by inviting cgnt364vd8s86hr2phapfjc6uk@group.calendar.google.com. | ||
| * Use existing proposal and PR process | ||
| * Announce new SIG on kubernetes-dev@googlegroups.com and ask a repo maintainer to create a kubernetes/community directory and github team for the new group |
There was a problem hiding this comment.
Remove " and github team for the new group"
| ### SIG creation procedure | ||
|
|
||
| * Propose the new SIG publicly, including a brief mission statement, by emailing kubernetes-dev@googlegroups.com and kubernetes-users@googlegroups.com, then wait a couple of days for feedback | ||
| * Create a group (see the detailed instructions below) |
| * Use existing proposal and PR process | ||
| * Announce new SIG on kubernetes-dev@googlegroups.com and ask a repo maintainer to create a kubernetes/community directory and github team for the new group | ||
| * Submit a PR to add any SIG-related docs, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory. | ||
| * Slack activity is archived at [kubernetes.slackarchive.io](http://kubernetes.slackarchive.io). To start archiving a new channel invite the slackarchive bot to the channel via `/invite @slackarchive` |
There was a problem hiding this comment.
Please move this bullet to be immediately under the slack bullet above.
|
|
||
| Name convention: | ||
|
|
||
| * kubernetes-sig-foo-misc |
There was a problem hiding this comment.
Please add * kubernetes-sig-foo to the beginning of the list. This is the discussion group. The other groups are just for mirroring github notifications. It would be useful to include one sentence about that here.
| * k8s-sig-foo-proposals | ||
| * k8s-sig-foo-pr-reviews | ||
| * k8s-sig-foo-api-reviews | ||
|
|
There was a problem hiding this comment.
It's worth calling out here that there is deliberately no k8s-sig-foo user corresponding to the discussion group.
| * sig-foo-proposals | ||
| * sig-foo-pr-reviews | ||
| * sig-foo-api-reviews | ||
|
|
There was a problem hiding this comment.
It's worth calling out here that there is deliberately no sig-foo team corresponding to the discussion group.
|
@idvoretskyi |
| * kubernetes-sig-foo-feature-requests | ||
| * kubernetes-sig-foo-proposals | ||
| * kubernetes-sig-foo-pr-reviews | ||
| * kubernetes-sig-foo-api-reviews |
There was a problem hiding this comment.
perhaps we think all of these team names are self explanatory, but I feel like we're lacking a guide that will direct new participants to the project to the appropriate team to notify? description of what these teams are intended to accomplish, why you would want to notify them, where to escalate, etc
|
prior SIG team naming discussions for context -- https://groups.google.com/forum/#!topic/kubernetes-dev/8pUqKMGcLY0 |
9 participants
Following up the discussion, initiated at https://groups.google.com/forum/#!topic/kubernetes-dev/LEtIxeG0i84 and #90, this procedure describes the process of creating the new SIG (as well as optimizing the existing ones) within the Kubernetes community.
These steps were performed and reproduced for the newly created SIG-OnPrem, existing SIG’s should be updated via this procedure as well.