Formalize sub-projects about steering HOT 12 CLOSED

@nikhita - The biggest issue is adding fields to enumerate leads+slack channels for subprojects.

Right now we point to owners files but that is pretty messy imo, subprojects should have well defined leads or points of contact.

from steering.

/assign @spiffxp @bgrant0607

from steering.

/committee steering

from steering.

Ref https://github.com/kubernetes/community/issues/1673

from steering.

Subprojects are called out distinct entities in k/community/governance.md and in the k/community README.md. That said I suspect if you pulled a random member of the community aside and asked them what a subproject is and why we have them, you wouldn't get much of an answer.

Current open issues related to this:

• https://github.com/kubernetes/community/issues/1673 - there is a lack of automation built around OWNERS files to reconcile and unify metadata about subprojects
• kubernetes/community#2619 - subprojects need more details than OWNERS files, like humans and contact info (we could pull some of this out of OWNERS files if there was info in them)

from steering.

I am punting this to Backlog because I don't expect to make any substantive progress on this before the end of the year

from steering.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

from steering.

/remove-lifecycle stale

@spiffxp I'd like to move the automation around subprojects forward. Is there any progress from steering around this?

I'm also wondering what the term "formalize subprojects" really entails.... 🤔

from steering.

@nikhita @spiffxp @timothysc

Initially "formalize" meant "make it real". Aaron did a fair bit of that already.

I envision subprojects being the main bridges between our people organization and our code organization.

Some ideas that have been proposed to improve the use of subprojects as an organizational and management construct:

• Consolidate subproject owners (leads), approvers, and reviewers into aliases that can be used in all repos and subdirectories of each subproject, to simplify maintenance of our thousands of OWNERS files.
• Automatically populate the subproject OWNERS file lists in sigs.yaml, or just replace those with subproject names
• Document additional information about each subproject, such as meeting times and slack channels, if any
• Replace relevant area/ labels with subproject/ labels
• Perhaps add subproject-level info to devstats
• Maybe label single-purpose repos with subproject tags
• Document best practices for managing subprojects within SIGs, perhaps based on what SIG Cluster Lifecycle has done
• Identify relevant subprojects as test owners

from steering.

Thanks, Brian!

A few points/questions to better understand the ideas:

Consolidate subproject owners (leads), approvers, and reviewers into aliases that can be used in all repos and subdirectories of each subproject, to simplify maintenance of our thousands of OWNERS files.

I'm guessing this means adding support for github teams or using a central config for all OWNERS file across an org: kubernetes/test-infra#10065.

I can try moving this forward from a contribex point of view in kubernetes/test-infra#10065 but I think it'll take time to figure out how to proceed with this from a technical perspective and refactor most of our approve/lgtm plugins. I think this can proceed independently from the "formalize subproject" part and shouldn't be a blocker to it. Wdyt?

Automatically populate the subproject OWNERS file lists in sigs.yaml, or just replace those with subproject names

IIUC to automatically populate the subprojects OWNERS files, we'll still need a canonical source of truth to figure out which subproject falls under which sig -- what would be the canonical source of truth for this subproject -> sig mapping? Right now, it is sigs.yaml itself. :)

Document additional information about each subproject, such as meeting times and slack channels, if any

Possible via changes to the generation code. 👍 There is already a POC in kubernetes/community#273.

Replace relevant area/ labels with subproject/ labels

Maybe we should use both? I find labels like area/apiserver useful...but apiserver wouldn't be a subproject by itself.

Perhaps add subproject-level info to devstats

Possible. Happy to drive this from contribex's side. 👍

from steering.

This was discussed in the latest Public Steering Committee meeting (recording, meeting notes).

Current status: we are discussing subproject roles in kubernetes/community#3413. Once that gets finalized, we can move to incorporating this into our automation (sigs.yaml).

For complete context, these are the issues/PRs about subprojects open right now:

• https://github.com/kubernetes/community/issues/1673 - similar umbrella issue in the community repo (has some more details)
• kubernetes/community#2619 - issue for adding subproject details in sigs.yaml
• kubernetes/community#2731 - PR adding some more fields to subprojects in sigs.yaml
• kubernetes/community#3413 - PR to add a project-manager-like role for subprojects

Additionally, this google doc discusses adding the concept of a subproject and some ideas about the kind of metadata we'd need for it in sigs.yaml.

from steering.

Thanks @nikhita for all your help with this!

from steering.