Adding requirement for the organization team to be created #90
Conversation
|
It's definitely worth, also it's already used though not mandatory. |
|
the only challenge is maintaining it... and that's why it hasn't been mandatory. I'm happy to create them but it lies with the SIG and individuals to request the updates. |
|
@sarahnovotny as SIG is responsible for some area, it should be really useful to have ability to "ping" it easily in case that requires their attention. |
|
There are very few people who can invite others to the organization. Once someone is in the organization they can be added to, or request to join, individual sig lists. Those second steps can be handled entirely by the sig leader(s). But that first step can be a bump for new people. I don't have a problem if sig leaders create a sig team but I don't know if I've seen the value enough to say it is mandatory and leaders should have to deal with the paperwork/maintenance. What does it get other than being able to I guess I don't love having multiple 'lists' you have to join... |
|
I feel this step as useful - i.e. in the features repo we require paying SIG's attention to the ongoing thread. It will be difficult and non-productive to find someone who is responsible for the area of interest; I don't see any other way to mention all the people, who are familiar with some specific area. |
|
@sarahnovotny so, any final decision on this? |
| * Put a description of the topic in the welcome message | ||
| * Set "Join the group" and "Post" to "Public" | ||
| * Ask a repo maintainer to create a github label, if one doesn't already exist: area/foo | ||
| * Ask organization maintainer to create a SIG-team within the [Kubernetes GitHub organization](https://github.com/orgs/kubernetes/teams) |
There was a problem hiding this comment.
@sarahnovotny do we have a standard when we crate a SIG? Since we have a ton of SIGs already, and we are waiting on more standards, I am wondering if it would be prudent to leave this off.
There was a problem hiding this comment.
the standards for creating a SIG are outlined in README.md. Basically, it's a loose consensus that some topic is not covered in existing SIGs and that there is a need to create a new one. There is work going on in the kubernetes-pm group discussing this. https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-pm/joQ_q0MaJ0w/hMdaklE-AgAJ
I think SIG teams is the plan.
|
cc @calebamiles |
|
Discussed in more detail here: https://groups.google.com/forum/#!topic/kubernetes-dev/LEtIxeG0i84 |
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.
|
Closing in favor of #90 |
Add "choose repo" to features issue template
…etes#90) Co-authored-by: Kevin Wang <kevinwzf0126@gmail.com>
7 participants
Having a SIG-"team" will be useful to be mentioned in some threads that require attention from the SIG.