remove inaccurate representation of subprojects #8179
Conversation
work groups CANNOT sponsor subprojects, only suggest and participate in them. work groups are discussion groups for interests that potentially cross sigs.
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
size/XS
| @@ -51,12 +51,6 @@ The WG Serving will operate in several workstreams with different areas of focus | |||
| - [Orchestration](https://docs.google.com/document/d/1hbEx3ZEqdXCqWH9RL3uy9FIy35B8pFJ5KiK3HsOz2FE/edit?usp=sharing) | |||
| - [DRA](https://github.com/kubernetes/community/tree/master/wg-device-management) | |||
|
|
|||
| ## Sponsored Subprojects | |||
|
|
|||
| * [LLM Instance Gateway](https://github.com/kubernetes-sigs/llm-instance-gateway) | |||
There was a problem hiding this comment.
Is sponsored by SIG Apps and already listed there. It may be sponsored by SIG Network instead in the future.
| ## Sponsored Subprojects | ||
|
|
||
| * [LLM Instance Gateway](https://github.com/kubernetes-sigs/llm-instance-gateway) | ||
| * [Serving Catalog](https://github.com/kubernetes-sigs/wg-serving/tree/main/serving-catalog) |
There was a problem hiding this comment.
This is not a subproject, it is at most some experimental code.
If it were a subproject, it would need to be sponsored through the relevant SIG (Probably Apps?), who already has a charter encompassing this and has the discretion over project lifecycle.
Please do not advertise subprojects without going through the processes we have in place for managing projects and avoiding conflicting ownership.
There was a problem hiding this comment.
Can we rephrase this to be something like "Relevant projects"? The main idea is just to get more visibility for the projects we are working on.
There was a problem hiding this comment.
We really shouldn't be advertising a "Serving catalog" project that no one approved as a project to be hosted in the organization.
As for LLM Instance Gateway, it is advertised as a SIG Apps project for now, and we have a pretty standardized format for the SIG/WG documentation.
There was a problem hiding this comment.
I think we can revisit a way to link WGs to subprojects they may be participating in, but currently that's supposed to be documented by way of the SIGs they are involved with / sponsored by, and these are pretty clearly within the scope of SIG Net and SIG Apps.
I have previously requested this correction in kubernetes-sigs/llm-instance-gateway#41, that repo also needs updating to clarify still, as it has similarly inaccurate language in the README.
To be clear: I hope you all succeed in your efforts, but we have the governance for a reason, to avoid arbitrarily hosting projects under the kubernetes umbrella and to avoid conflicts between overlapping groups.
Work Groups are easy to create because they allow creating a place to focus on something across or within the SIGs without hammering out an ironclad, conflict-free charter. But that also means that the projects they spawn roll up to one of the SIGs.
There was a problem hiding this comment.
Thanks for the clarification!
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, terrytangyuan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Work groups CANNOT sponsor subprojects, only suggest and participate in them. work groups are discussion groups for interests that potentially cross sigs.
Also, subprojects are tracked in sigs.yaml in a standardized format with specific metadata required.
Which issue(s) this PR fixes:
Fixes #
/assign @kubernetes/steering-committee
FYI @ArangoGutierrez @Jeffwan @SergeyKanzhelev @terrytangyuan