Add Kubeflow TOC Charter

[andreyvelich]

This is initial draft for the Kubeflow TOC charter.
Here is the Google doc for the same proposal for folks who want to review it and don't use GitHub regularly:
https://docs.google.com/document/d/1jskqTsqpuoC1Ed0HfitfSOk_k93RMYDkJPrIO7k0Veo/edit?usp=sharing

A few questions that I have:

• Should we name it TOC or KTOC ? In this doc we name it as KTOC.

• Giving the comment that @juliusvonkohout raised on the last community call, what do we think about electing 3 members on the first year and 2 more members in the second year ?
  Also, we can think about relaxing rules to be nominated (e.g. 25 contributions rather than 50).

• I divided charter in 3 sections: Project direction and roadmap, Project releases, security, and stability, Project oversight and scope. Feel free to propose your ideas and comments.

I keep decision process and other parts of charter the same as for KSC.

We will start elections soon and @akgraner will provide updates.

/cc @kubeflow/wg-training-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-pipeline-leads @kubeflow/wg-automl-leads @kubeflow/wg-manifests-leads @tenzen-y @kuizhiqing @kubeflow/release-team @kubeflow/kubeflow-steering-committee @andreeamun @akgraner @tarilabs @bigsur0 @vara-bonthu @yuchaoran2011

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

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:

• OWNERS [andreyvelich]

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

[google-oss-prow]

@andreyvelich: GitHub didn't allow me to request PR reviews from the following users: andreeamun, bigsur0, kubeflow/wg-notebooks-leads, kubeflow/wg-automl-leads, vara-bonthu, kubeflow/wg-manifests-leads, yuchaoran2011, kubeflow/wg-training-leads, kubeflow/wg-pipeline-leads, kubeflow/release-team, kubeflow/kubeflow-steering-committee.

Note that only kubeflow members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

This is initial draft for the Kubeflow TOC charter.
Here is the Google doc for the same proposal for folks who want to review it and don't use GitHub regularly:
https://docs.google.com/document/d/1jskqTsqpuoC1Ed0HfitfSOk_k93RMYDkJPrIO7k0Veo/edit?usp=sharing

A few questions that I have:

• Should we name it TOC or KTOC ? In this doc we name it as KTOC.

• Giving the comment that @juliusvonkohout raised on the last community call, what do we think about electing 3 members on the first year and 2 more members in the second year ?
  Also, we can think about relaxing rules to be nominated (e.g. 25 contributions).

• I divided charter in 3 sections: Project direction and roadmap, Project releases, security, and stability, Project oversight and scope. Feel free to propose your ideas and comments.

I keep decision process and other parts of charter the same as for KSC.

We will start elections soon and @akgraner will provide update soon.

/cc @kubeflow/wg-training-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-pipeline-leads @kubeflow/wg-automl-leads @kubeflow/wg-manifests-leads @tenzen-y @kuizhiqing @kubeflow/release-team @kubeflow/kubeflow-steering-committee @andreeamun @akgraner @tarilabs @bigsur0 @vara-bonthu @yuchaoran2011

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.

[andreyvelich]

/hold for review

[terrytangyuan]

Would this be diverse enough to make technical decisions? I wonder if it's necessary to form a TOC. An alternative would be getting a list of people from WG leads.

[jbottum]

I propose that we should initially have 5 TOC members. Perhaps 2 members will be initially for 1 year terms.

[StefanoFioravanzo]

WG leads being also TOC members would risk creating conflicts of interest and not encourage enough diversity in ideas and approach. I think starting with 3 now and adding 5 within a 12 month timeframe is a good approach

[andreyvelich]

I agree with @jbottum and @StefanoFioravanzo

[terrytangyuan]

Do we need to control max number of people from each organization similar to what we do for KSC?

[andreyvelich]

@terrytangyuan Sure, let me add this point.

[thesuperzapper]

Typo: says deleted

[thesuperzapper]

I don't quite understand the role of the proposed TOC as it compares to the Working Groups.

I have a few questions:

1. What actual power does TOC have?
2. Isn't the most logical membership of the TOC just the combined chairs of the Working Groups?
   • (assuming we make it more clear how those chairs are to be appointed)
3. It is dangerous to have plain democracy for technical positions, we can mitigate this by doing one of the following:
   • Requiring all candidates to be endorsed by the majority of working group chairs and the KSC (to ensure technical capability); or
   • Have no election process and simply have the KSC appoint members.

For reference, here is the Kubernetes community governance document (NOTE: remember that Kubernetes SIG = Kubeflow Working Group, and we don't have an equivalent concept to Kubernetes Working Group).

Also, at least in the parlance of Kubernetes governance, the concept of a "committee" is an appointee group at the sole discretion of the steering committee.

[jbottum]

This sounds like a top down approach. We have not used this in the Kubeflow community as the WG have set their own directions and roadmaps. Perhaps, we should consider a different word than "Set". I don't know if Socialize or Consolidates are the potentially closer word.

[johnugeorge]

I like this idea. For eg: TOC can look at interesting directions for Kubeflow as a whole like LLMOps in the current space. TOC can plan right technical directions to the reach the overall goal like discussing with different stakeholders, Working Groups for better alignment

[jbottum]

Perhaps the words are "Consolidate and Validate"

[StefanoFioravanzo]

I can think of the TOC as a "Consulted" party when WGs work on design docs, new architectures, challenging implementations etc. From an "integrated product" point of view, I believe the TOC should be responsible to suggest cross-WG end-to-end architecture and user experience roadmap. Each WG would be responsible to take those recommendations in and work with TOC as a partner to align on their plans.

[andreyvelich]

I agree with you @jbottum, that was my initial thinking. Let me re-word it.

[andreyvelich]

@jbottum @StefanoFioravanzo @johnugeorge Added the following statements:

- Consolidate together with WGs the overall technical direction and Kubeflow roadmap.
- Suggest cross-WGs features like LLMOps and work with stakeholders to address it.

[jbottum]

I like this goal but I am not sure how the TOC fits in. Most issues will be at the WG level and theirs to resolve. Will the TOC be responsible to resolve or just additional contributing resources under direction of the WG

[StefanoFioravanzo]

I think we should define what "stability" means. Is this about CICD and testing infrastructure? Defining testing targets, automation pipeline guidelines and recommendations may be well in scope for the TOC

[andreyvelich]

I think, stability covers all of this @StefanoFioravanzo. Also, we can say about Kubeflow LTS. Should we explicitly add it to charter ?

[StefanoFioravanzo]

Oh you bring up a good point! We could add another bullet along the lines of "- Define a long term support (LTS) community SLA and support WGs for security escalations and critical bug fixes"

[jbottum]

I believe the Release Manager has been the final authority for a release. We can change but perhaps the final authority / decision maker needs to be defined. I believe we can have many inputs and influencers, but only 1 decision maker.

[johnugeorge]

+1

[StefanoFioravanzo]

+1 - Agree. The TOC will definitely influence what WGs decide to implement and propose in their roadmap, but ultimate accountability for roadmap readiness should be on the release team

[andreyvelich]

@jbottum @StefanoFioravanzo @johnugeorge Any thoughts on who should be the final authority for Kubeflow releases and what role TOC should play in addition to just a guidelines and suggestions ?

[StefanoFioravanzo]

Depends on whether we want to make the TOC just a "consulted" party or ultimately accountable for the roadmap. Being the primary technical body, I am inclined to say that the TOC should have final approval of the roadmap proposed by the release manager/team. This could become a new action item in the release handbook.

Another way to look at this is: pushing accountability to the Release Manager could be done by having the TOC appoint the Release Manager in the first place, delegating that responsibility.

[StefanoFioravanzo]

Maybe let's look at how other communities are doing this

[jbottum]

We should consider time limits for topics and a best practice for when a formal issue or PR must be created ?. In order to drive for decisions, we should define a process for requesting a vote i.e. can we take a vote before discussion, and at the 10 minute mark or other? In addition, if a member objects to the vote results, what is the process to continue the conversation i.e. does the objecting member need to provide a plan to deliver more information before the discussion can continue.

[andreyvelich]

I agree with you @jbottum, any suggestions on how we can express it in the charter ?
For example, when making changes to the TOC charter we give at least 1 week community to provide comments: https://github.com/kubeflow/community/pull/701/files/5d5a3e473d464b9a036e527040e62adaaa86577c#diff-6a27463fa3d59d96139352472c4244cd45e5fd103c80fc00d5fe320b7c04ca76R183-R184

[jbottum]

The meeting process should include:

Topics should be submitted in the form of a question, which can be voted on.

Topics can be prioritized by the meeting host.

Topics can be reviewed at the beginning of the meeting.

Topics should be addressed one at a time, unless there is a dependency that needs to be considered.

After stating the issue, the host should ask for a non-binding vote.

If there is consensus, then the host can ask for a 2nd to make the vote binding.

After the vote, any member can ask for a discussion period, which by default is ten meeting or less.

After discussion, the host will confirm consensus and/or ask for a vote.

The vote will be recorded.

If member(s) abstain because they need more information, the issue will be documented with the additional information needed before it can be addressed as topic again in a future meeting. If the information is not provided within 2 weeks, a member can ask for a binding vote in the next meeting.

[andreyvelich]

Sounds good. I added it @jbottum

[johnugeorge]

I don't quite understand the role of the proposed TOC as it compares to the Working Groups.

I have a few questions:

1. What actual power does TOC have?

2. Isn't the most logical membership of the TOC just the combined chairs of the Working Groups?

   • (assuming we make it more clear how those chairs are to be appointed)

3. It is dangerous to have plain democracy for technical positions, we can mitigate this by doing one of the following:

   • Requiring all candidates to be endorsed by the majority of working group chairs and the KSC (to ensure technical capability); or
   • Have no election process and simply have the KSC appoint members.

For reference, here is the Kubernetes community governance document (NOTE: remember that Kubernetes SIG = Kubeflow Working Group, and we don't have an equivalent concept to Kubernetes Working Group).

Also, at least in the parlance of Kubernetes governance, the concept of a "committee" is an appointee group at the sole discretion of the steering committee.

As TOC is a technical group, I like the idea of having TOC members coming from WG leads group where WG leads + KSC can vote.

[StefanoFioravanzo]

I think we should define what "stability" means. Is this about CICD and testing infrastructure? Defining testing targets, automation pipeline guidelines and recommendations may be well in scope for the TOC

[StefanoFioravanzo]

It's unclear to me what is the proposed scope for the KTOC - do responsibilities stop at (software, infra) architecture & implementation, security, development guidelines) or do they include product design, usability, UX, user research activities? Some bullets below (e.g. cross-components integration, roadmap oversight) seem to imply a larger focus.

[StefanoFioravanzo]

Also, when saying "set the overall technical direction and Kubeflow roadmap" we need to think how that direction is influenced. Generally these decisions are informed by a higher level product design and research that takes into account user feedback, UX research etc. Where does this input come from? It's either from the TOC itself (then the TOC is responsible for those activities) or from a different appointed entity.

[andreyvelich]

These are good points @StefanoFioravanzo. Ideally, we should have various teams dedicated to UX, user feedback, security, guidelines, etc. We are not there yet. That is why initially folks on TOC should be multi-tasking to address various topics. Once we have enough people dedicated to the specific topic, TOC can delegate those tasks to them. What do you think @StefanoFioravanzo ?

[StefanoFioravanzo]

@andreyvelich I agree and I think we should make this explicit in the charter, especially if the end goal is to delegate these responsibilities to a new group (which I agree should be the case). Actually, the chart could indicate that one of the TOC medium/long-term goal is to drive the creation of such groups.

[StefanoFioravanzo]

WG leads being also TOC members would risk creating conflicts of interest and not encourage enough diversity in ideas and approach. I think starting with 3 now and adding 5 within a 12 month timeframe is a good approach

[StefanoFioravanzo]

Would it make sense to require unanimous consensus while the group is composed of 3 members, and then switch to rounded half when the group expands to 5?

[andreyvelich]

Might make sense if we agree on 3 members. Another solution could be to ask KSC to participate in TOC decision process until we have 5 members. Any thoughts @jbottum @johnugeorge @thesuperzapper ?

[StefanoFioravanzo]

Asking the KSC to participate may overload the KSC - but hey it would be a KSC decision :)

[juliusvonkohout]

@andreyvelich Regarding "Also, we can think about relaxing rules to be nominated (e.g. 25 contributions rather than 50)." I do not recommend to do that. I would actually require at least a few merged PRs in addition.

[andreyvelich]

@thesuperzapper

1. What actual power does TOC have?

I think, one of the main purpose of TOC is helping WGs with cross-component features. That will help make Kubeflow components much less loosely coupled.

In terms of power, I don't think TOC should endorse WGs roadmaps, but they should provide their vision and collaborate together with all WGs. Also, TOC should be responsible for stable Kubeflow releases and conformance programs.

Isn't the most logical membership of the TOC just the combined chairs of the Working Groups?

We discussed this with @kubeflow/kubeflow-steering-committee during the last call. There are pros and cons for both approaches. For example, for the diversity it is better to have different folks on WG chairs and TOC.
Let's discuss it during one of the upcoming Kubeflow Community calls.

[andreyvelich]

@andreyvelich Regarding "Also, we can think about relaxing rules to be nominated (e.g. 25 contributions rather than 50)." I do not recommend to do that. I would actually require at least a few merged PRs in addition.

That makes sense @juliusvonkohout. Let's discuss it tomorrow.