Identify owning SIG

[BenTheElder]

Workgroups are temporary time bounded groups, this project should specify the owning sig and be listed as a subproject of one of the SIGs in the metadata in github.com/kubernetes/community, you can identify the workgroup as a place to discuss the project but it cannot be the owner and we should sort that out sooner than later so we don't have confusion when the workgroup winds down.

cc @kubernetes/steering-committee

[SergeyKanzhelev]

sig network or sig autoscaling might be a good home

added as. an agenda item for the wednesday meeting: https://docs.google.com/document/d/1aExJFtaLnO-TM6_2uILgI8NI0IjOm7FcwLABBKEMEo0/edit?tab=t.0#heading=h.zd57bzqasuuz

[ahg-g]

I think sig networking would be the most appropriate

[BenTheElder]

We just need agreement from a SIG to be responsible for hosting the project long term and to setup pointers in sigs.yaml and the README, it sounds like it could be SIG net and that sounds like the closest fit to me personally.

[ahg-g]

@robscott fyi

[aojea]

can you put this in the next sig network agenda? or open an email thread in sig-network mailing list with the request?

[BenTheElder]

FYI kubernetes/community#8056, it was introduced under SIG Apps, actually.

I have a thread with the github management team about preventing this sort of confusion in the future by tweaking the request template to clearly ask for the sponsoring SIG for future repos to be one particular SIG.
In my case I saw the WG serving README PR and this repo's README but not the commit to SIG Apps, and both sigs listed in the request.

If you all are fine with SIG Apps being the sponsoring SIG, then lets just clarify the README here and in the wg-serving README/charter to make it clear that SIG Apps owns it and wg-serving is where it's being discussed.

[terrytangyuan]

cc @shaneutt

[shaneutt]

I think sig networking would be the most appropriate

If you all are fine with SIG Apps being the sponsoring SIG, then lets just clarify the README here

I am open to the suggestion to put this under SIG Network, especially given that it has close ties with Gateway API and deals with application level routing and load-balancing for LLM inference traffic. However given what @BenTheElder is saying, it sounds like we should discuss this at some length. Looking forward to further discussion on this.

[BenTheElder]

I have a thread with the github management team about preventing this sort of confusion in the future by tweaking the request template to clearly ask for the sponsoring SIG for future repos to be one particular SIG.

[this part is done: https://github.com/kubernetes/org/pull/5266]

I am open to the suggestion to put this under SIG Network, especially given that it has close ties with Gateway API and deals with application level routing and load-balancing for LLM inference traffic. However given what @BenTheElder is saying, it sounds like we should discuss this at some length. Looking forward to further discussion on this.

ACK, from talking to a few folks, it seems like SIG-Apps is OK but SIG Net may be a better fit, when you all have a conclusion if we need to change things just send a PR to kubernetes/community and this repo and we can update things.

I just ask that even if we don't move it, please cleanup references in this repo and in kubernetes/community wg-serving that indicate that wg serving "owns" this as opposed to a place to discuss this project being sponsored by Apps or Network.

Sometimes workgroups last for many years but they eventually wind down and the distinction is important, we make sure things roll up to SIGs because of this and because SIGs have carefully reviewed charters to avoid conflict, while as we see here it is normal and expected for working groups and conceptual efforts to span many SIGs, as opposed to projects.

Thanks all! Let me know if there's anything I can do to help.

[soltysh]

This was discussed yesterday during wg-serving, it'll be presented later today during sig-networking call (https://docs.google.com/document/d/1_w77-zG_Xj0zYvEMfQZTQ-wPP4kXkpGD8smVtW_qqWM/edit?tab=t.0#). We should get the decision after that call.

[BenTheElder]

Filed one of the interim cleanup PRs at kubernetes/community#8179

[terrytangyuan]

Based on @BenTheElder's comment kubernetes/community#8179 (comment), Serving Catalog is not a project yet as it needs sponsorship from SIGs. cc @ahg-g @jjk-g

[soltysh]

Based on @BenTheElder's comment kubernetes/community#8179 (comment), Serving Catalog is not a project yet as it needs sponsorship from SIGs. cc @ahg-g @jjk-g

Looking at kubernetes/community#7988 it seems, it landed under sig-arch, although looking at kubernetes/org#5072 I only see folks from sig-scheduling acking that repo.

[ahg-g]

Looking at kubernetes/community#7988 it seems, it landed under sig-arch, although looking at kubernetes/org#5072 I only see folks from sig-scheduling acking that repo.

The wg-serving repo is a generic playground for the working group, it is not meant to be only for the serving catalog.

Based on @BenTheElder's comment kubernetes/community#8179 (comment), Serving Catalog is not a project yet as it needs sponsorship from SIGs. cc @ahg-g @jjk-g

Thanks for flagging, it is fine if we remove it.

[BenTheElder]

The wg-serving repo is a generic playground for the working group, it is not meant to be only for the serving catalog.
Thanks for flagging, it is fine if we remove it.

I'm not even suggesting the code has to be removed, I'm less clear on that, but we should not advertise "subprojects" with code that are not sponsored by a SIG. I imagine (though can't guarantee) Apps would be willing to sponsor something like this with a repo? (without having looked deeply into this)

If it's just a playground, it doesn't need to be advertised as projects yet.
If any of them are serious subprojects, it should be sponsored through the usual process.

I would recommend creating specific subprojects and using the wg repo for docs and not code. This is true for other sigs and wgs to my knowledge.

There are some repos like "test-infra", "windows-testing" with a grab bag of prototypes and tools, but the "sig-foo" and "wg-foo" projects aren't normally code hosts and definitely aren't "subprojects". We also pretty clearly flag them that way (e.g. the experiment/ directory in test-infra) and don't advertise them as subprojects.

I'm not worried about you all working on this, but the precedent to create subprojects out of band is not something we want, lots of people will be interested to do the same to attempt to introduce projects into our github that the community has not agreed to host, and steering needs to not "play favorites", is all.

[BenTheElder]

regarding:

I just ask that even if we don't move it, please cleanup references in this repo and in kubernetes/community wg-serving that indicate that wg serving "owns" this as opposed to a place to discuss this project being sponsored by Apps or Network.

Filed #52 to close that out:

I think this is reasonable? It allows WG-Serving to claim credit for launching this project, drives interest in the WG, but still clearly identifies the sponsoring SIG and the official subproject listing. I think the split into two sentences is more readable.

[BenTheElder]

[I would close this out now, but it seems we may have lingering follow up threads about if SIG Net is a better home etc]