Add the concept of a Subproject Lead

[dims]

Change-Id: Icbefa39349c2f3c214ec174f50d39c3baf543ed7

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims

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:

• committee-steering/OWNERS [dims]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dims]

/hold

[bgrant0607]

@dims For a long time in the project, we've called subproject leads "owners". There were comments in some OWNERS files indicating which approvers were owners. The contributor ladder included the concept even before subprojects were formalized.
https://github.com/kubernetes/community/blob/master/community-membership.md#subproject-owner

It would be confusing to create a separate "lead" concept. I could imagine renaming "owner" to "lead" in order to reduce confusion between subproject owners and OWNERS files.

[bgrant0607]

Unless this is about separating technical responsibilities with project management responsibilities, as with SIG TLs vs. Chairs?

[dims]

right, this was to make things similar to SIG TLs vs. Chairs at the sub project level

[nikhita]

xref kubernetes/steering#36

[bgrant0607]

I think "lead" would be extremely confusing. Project manager?

I also think it has to be a suggested role, for larger, more active subprojects. kube-proxy, for instance, probably wouldn't need one.

It was also suggested that points of contact would be useful.

[timothysc]

What I was looking for in the conversation last week was simple lines of communication for a sub-project to bootstrap new folks. A slack channel is sufficient for that purpose and is can add a slack channel for each subproject then I think the current problems are solved.

[bgrant0607]

I'd prefer to first discuss subproject management best practices, and then figure out what roles are needed.

We can use this as a starting point:
https://github.com/kubernetes/community/blob/master/sig-cluster-lifecycle/grooming.md

[nikhita]

Personally, I think it would be useful to have a Project Manager role in addition to Owner since subprojects are somewhat like "mini SIGs" (since they can have meetings and slack channels). The PM role would be optional. If a subproject decides not to opt-in for the role, the Owner would take care of the project management responsibilities (like some SIGs say in their charters that Chairs also have TL responsibilities).

On the naming - I think we shouldn't use the term Technical Lead. In case a subproject decides not to opt-in for the PM role, the TL would be responsible for project management too. The name Owner seems more reflective of such "defaulting" than Technical Lead IMO.

---

I'd prefer to first discuss subproject management best practices, and then figure out what roles are needed.

SIG Cluster Lifecycle to the rescue again: https://github.com/kubernetes/community/blob/master/sig-cluster-lifecycle/charter.md#deviations-from-sig-governance :)

Wdyt about the following definitions for the subproject roles?

Project Manager:

• This is an optional role.
• Run operations and processes governing the suproject (like organizing meetings, ensuring recordings are uploaded in a timely fashion and reporting updates to the parent SIG)
• Determine the subproject release cadence, produce releases, and communicate releases with SIG Release and the parent SIG.
• Ensure that issues are correctly associated with milestones and are triaged in a timely manner.
• Ensure that active pull requests are addressed in a timely manner.
• Number: 1-2
• Membership tracked in sigs.yaml

Owner:

• Seed members established at subproject founding.
• SHOULD be an escalation point for technical discussions and decisions in the subproject.
• SHOULD set milestone priorities or delegate this responsibility.
• Additionally, if the Project Manager role is not defined for the subproject, the Owner has the responsibilities of the Project Manager role.
• Number: 2-3
• Membership tracked in sigs.yaml

[nikhita]

/cc @timothysc

[bgrant0607]

@nikhita I like much of your suggested definition. One part I'm not sure about is the responsibility for deciding the release cadence and producing releases. I could see that responsibility belonging to the owner in many cases.

[nikhita]

One part I'm not sure about is the responsibility for deciding the release cadence and producing releases. I could see that responsibility belonging to the owner in many cases.

Yeah, I was a little doubtful of that too. Agree that we should move that responsibility to the Owner role. 👍

[nikhita]

/cc @kubernetes/steering-committee

[philips]

I read the thread and agree with @bgrant0607's feedback. I just can't remember how we ended up on this problem to begin with. Is there any context somewhere?

[nikhita]

I just can't remember how we ended up on this problem to begin with. Is there any context somewhere?

The main blocker to setting up the automation for subprojects was having well-defined "leads". The discussion then led to creating a PM-like role for subproject leadership too, since subprojects can have meetings and slack channels.

More details here - #2619 (comment)
Complete context about the subprojects issue here - kubernetes/steering#36 (comment)

[timothysc]

I added a comment to the PR which was a follow on from steering. Today we just need a communication point to bootstrap newcomers. If we can simply point them at a slack channel that will solve the current issues we have today.

[spiffxp]

If we can simply point them at a slack channel that will solve the current issues we have today.

I will PoC this for sig-testing subprojects shortly and see if that helps

[spiffxp]

#3483 adds the Contacts field to subprojects, so they can have slack, mailing list, github teams etc. specified

[timothysc]

I'd move to close this PR and if needed we can follow up on steering.