update sigs.yaml with more wg info

[parispittman]

It would be good to see if the WG is horizontal, domain-specific, etc. and maybe what SIGs they cross into on the sigs/wg list. if folks are in agreement, we'd need to update sigs.yaml.

ie:

name	horizontal (y/n) OR list of cross cutting SIGs	contact	meeting info

[parispittman]

/sig contributor-experience

[jdumars]

+1

This distinction is becoming more important as sigs proliferate.

[cblecker]

How would you see this looking? Are these well defined for each working group? Adding fields and such to the sig docs generator isn't hard, but it isn't clear to me what is being asked for, or how this would look in the final generated doc.

[parispittman]

I put the 'what it would look like' at the bottom of the issue.

name	horizontal (y/n) OR list of cross cutting SIGs	contact	meeting info

If it's the wg apply it would be something like:
apply | sig api machinery, sig foo | contact info | meeting info

We need this info to make sure we are getting regular updates from the wg's at the community meetings, auditing, and reviewing wgs, etc. and this would be an easy way to figure out that information.

[parispittman]

in order for a working group to be formed, they need to have sponsoring sigs so they are defined.

[cblecker]

If all WGs need sponsoring sigs, would listing "sponsoring sigs" work? I guess it's the "OR" bit that's confusing and unclear to me.

[parispittman]

Ah - I meant OR as a suggestion of a title - I'm 100% ok with "sponsoring sigs".

[cblecker]

/assign
I'll take a stab, probably next week.

[dchen1107]

+1

[spiffxp]

ref: kubernetes/steering#27

[spiffxp]

We discussed during steering and were ok with adding a field. Uncertain how clearly defined this list of sigs is for each wg

[zjs]

I looked through the resources linked to from the sig-list and organized the information about the relationships in the following table:

Working Group	Working Group Name	Status	Relevant SIGs
wg-app-def	Application Definition	Inactive [1]	sig-api-machinery, sig-apps, sig-cli [2]
wg-apply	Apply	Unclear [3]	sig-cli [3]
wg-container-identity	Container Identity	Inactive [4]	sig-auth [4]
wg-iot-edge	IoT Edge	Active [5, 6]	sig-networking, sig-multicluster [5]
wg-kubeadmn-adoption	Kubeadm Adoption	Inactive [7]	sig-cluster-lifecycle [7]
wg-machine-learning	Machine Learning	Active [8]	sig-apps, sig-big-data, sig-node [9]
wg-multitenancy	Multitenancy	Active [10]	sig-auth, sig-api-machinery, sig-networking, sig-node, sig-scheduling, sig-storage [11]
wg-policy	Policy	Active [12]	sig-architecture, sig-auth, sig-network, sig-node, sig-on-premise, sig-multicluster, sig-scheduling, sig-storage, wg-multitenancy*, wg-resource-management* [13]
wg-resource-management	Resource Management	Active [14]	sig-autoscaling, sig-instrumentation, sig-networking, sig-note, sig-scheduling, sig-storage [15]
wg-security-audit	Security Audit	Active [16]

* - These are other working groups, but are included for completeness.

[nikhita]

@zjs Thanks!

/committee steering
I guess steering still needs to weigh in on this (?)

[nikhita]

Created #3069 to try to move this forward. I think we still need input from steering and/or each WG on their stakeholder SIGs -- but I created the PR so that we can either iterate or start the discussion on it.

[parispittman]

@zjs - want to PR in each one of these individually for those that are still blank and then tag the appropriate chairs of the wg as the approvers? I'll send you a shirt or swag item of your choice after if you'd like. :)

[zjs]

@parispittman - I'd be happy to help with that, assuming it's not urgent; I'm on vacation next week, and I'm not sure I'll get to it before I leave.

[timothysc]

@parispittman - what else needs to get done here?

[parispittman]

hey @zjs - back from vacation and want to PR this?

[zjs]

Yes, @parispittman, I'll take a stab at that — and thank you for the ping.

[zjs]

@timothysc, the remaining work as I understand it is to generate a PR for each WG that doesn't have any stakeholder SIGs listed on the SIG/WG list based on our best guess (#2176 (comment)) and get review from the chairs of the WG.

[zjs]

I've posted a set of PRs to fill in the blanks.

Working Group	Pull Request	Notes
wg-apply	#3495	Updated with feedback from WG leader. Pending re-review.
wg-iot-edge	#3496	Merged!
wg-machine-learning	#3497
wg-multitenancy	#3498	Approved by a WG leader, but in need of approval by someone in the OWNERS file. (#3498 (comment))
wg-policy	#3499	Open question about listing other WGs as stakeholders. (#3499 (comment))
wg-resource-management	#3500

[nikhita]

@zjs just want to explicitly say thank you for all the work! And for the pretty table linking each pull request! 😍

[nikhita]

Just needs one more PR for wg-security-audit and then this can be closed. 👍

[nikhita]

/good-first-issue

@zjs if you want to take up wg-security-audit, feel free to remove the good first issue and help wanted label :)

[k8s-ci-robot]

@nikhita:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue

@zjs if you want to take up wg-security-audit, feel free to remove the good first issue and help wanted label :)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cji]

👋 Hello from wg-security-audit! I was reached out to on the kube slack by @nzoueidi about this issue and wanted to try and provide some clarification and ask questions about what makes sense to include for our WG.

The origin of the WG came from the proposal by CNCF and the PST starting with members of sig-auth to construct the wg. kubernetes/steering#71 (comment)

While sig-auth is definitely a stake holder in our results then, the audit being conducted is something that covers many (if not all) sig's in its results.

Trying to better understand the intent here - Would it make sense to list them all? keep it to sig-auth as the originator? and/or use the new CNCF sig-security instead?

[parispittman]

@cji - i would just do sig-auth then. intent is for mapping sigs to wgs so we can get updates, points of contact, flow of info, etc. for organizational purposes.

[cji]

Thank you @parispittman !