Add Kubeflow TOC Charter #701
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,188 @@ | ||
| # Kubeflow Technical Oversight Committee | ||
|
|
||
| The Kubeflow Technical Oversight Committee (TODO: TOC or KTOC ?) is responsible for | ||
| cross-cutting product and design decisions. | ||
|
|
||
| The governance of Kubeflow is an open, living document, and will continue to evolve as the | ||
| community and project change. | ||
|
|
||
| ## Charter | ||
|
|
||
| - Project direction and roadmap: | ||
|
|
||
| - Consolidate together with WGs the overall technical direction and Kubeflow roadmap. | ||
|
|
||
| - Suggest cross-WGs features like LLMOps and work with stakeholders to address it. | ||
|
|
||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. 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 There was a problem hiding this comment. Perhaps the words are "Consolidate and Validate" There was a problem hiding this comment. 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. There was a problem hiding this comment. I agree with you @jbottum, that was my initial thinking. Let me re-word it. There was a problem hiding this comment. @jbottum @StefanoFioravanzo @johnugeorge Added the following statements: |
||
| - Create proposals based on TOC discussions and bring them to the relevant working groups for discussion. | ||
|
|
||
| - Working with working groups on Kubeflow cross-component integrations. | ||
|
|
||
| - Resolving issues that, despite best efforts, a working group has been unable to resolve. | ||
|
|
||
| - Project releases, security, and stability: | ||
|
|
||
| - Ensure the stability of Kubeflow releases. | ||
|
|
||
|
There was a problem hiding this comment. 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 There was a problem hiding this comment. 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 There was a problem hiding this comment. I think, stability covers all of this @StefanoFioravanzo. Also, we can say about Kubeflow LTS. Should we explicitly add it to charter ? There was a problem hiding this comment. 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" |
||
| - Set the priorities of individual releases to ensure coherency and proper sequencing. | ||
|
|
||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. +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 There was a problem hiding this comment. @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 ? There was a problem hiding this comment. 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. There was a problem hiding this comment. Maybe let's look at how other communities are doing this |
||
| - Working together with Security WG to establish security guidelines to ensure Kubeflow follows | ||
| the CNCF security best practices. | ||
|
|
||
| - Advise the Conformance Committee on conformance rules and tests. | ||
|
|
||
| - Project oversight and scope: | ||
|
|
||
| - Working together with Kubeflow Steering Committee (KSC) to establish guidelines for | ||
| Kubeflow distributions and third-party applications. | ||
|
|
||
| - Advise the KSC on creation and deletion Kubeflow working groups. | ||
|
|
||
| - Advise the KSC on accepting new Kubeflow components and archiving existing | ||
| Kubeflow components. | ||
|
|
||
| - Advise the KSC on changes for Kubeflow distributions and third-party applications. | ||
|
|
||
| ## Delegated Authority | ||
|
|
||
| TOC may choose to delegate its authority to other committees as-needed. | ||
|
|
||
| The committee currently recognizes this delegated authority for [To be set up]: | ||
|
|
||
| - Kubeflow components guidance is delegated to the appropriate [Working Groups](../wgs/wg-governance.md). | ||
|
|
||
| - Enforcing Kubeflow conformance program rules created by TOC and KSC is delegated to the | ||
| [Conformance Committee](CONFORMANCE-COMMITTEE.md). | ||
|
|
||
| ## Committee Meetings | ||
|
|
||
| TOC currently meets at least bi-weekly, or as-needed. Meetings are open to the public and held online, | ||
| unless they pertain to sensitive or privileged matters. Examples of such matters are: | ||
|
|
||
| - Private emails to the committee | ||
| - Certain Escalations | ||
| - Disputes between members | ||
| - Security reports | ||
|
|
||
| Meeting notes are available to members of the | ||
| [kubeflow-discuss mailing](https://www.kubeflow.org/docs/about/community/#kubeflow-mailing-list) | ||
| list, unless community member privacy requires otherwise. | ||
| Public meetings will be recorded and the recordings made available publicly. | ||
|
|
||
| Questions and proposals for changes to governance are posted as issues in the | ||
| [kubeflow/community](https://github.com/kubeflow/community) repository, and the TOC invites community | ||
| feedback there. | ||
|
|
||
| ## Committee members | ||
|
|
||
| TOC is composed of 3 (three) members. They are elected according | ||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. I propose that we should initially have 5 TOC members. Perhaps 2 members will be initially for 1 year terms. There was a problem hiding this comment. 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 There was a problem hiding this comment. I agree with @jbottum and @StefanoFioravanzo |
||
| to the election policy [TODO: add link]. | ||
| No more than two seats may be held by employees of the same organization | ||
| (or conglomerate, in the case of companies owning each other). | ||
| Seats on the TOC are held by an individual, not by their employer. | ||
|
There was a problem hiding this comment. Do we need to control max number of people from each organization similar to what we do for KSC? There was a problem hiding this comment. @terrytangyuan Sure, let me add this point. |
||
|
|
||
| The current membership of the committee is (listed alphabetically by first name): | ||
|
|
||
| <table> | ||
| <thead> | ||
| <tr> | ||
| <th><br> | ||
| Member</th> | ||
| <th><br> | ||
| Organization</th> | ||
| <th><br> | ||
| Github Profile</th> | ||
| <th><br> | ||
| Term Start</th> | ||
| <th><br> | ||
| Term End</th> | ||
| </tr> | ||
| </thead> | ||
| <tbody> | ||
| <tr> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| </tr> | ||
| <tr> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| </tr> | ||
| <tr> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| <td></td> | ||
| </tr> | ||
| </tbody> | ||
| </table> | ||
|
|
||
| ## Emeritus Committee Members | ||
|
|
||
| [This section will be populated when there are retired committee members.] | ||
|
|
||
| ## Decision process | ||
|
|
||
| The TOC desires to always reach consensus. | ||
|
|
||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. I agree with you @jbottum, any suggestions on how we can express it in the charter ? There was a problem hiding this comment. 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. There was a problem hiding this comment. Sounds good. I added it @jbottum |
||
| ### Normal decision process | ||
|
|
||
| Decisions requiring a vote include: | ||
|
|
||
| - Issuing written policy. | ||
| - Amending existing written policy. | ||
| - Creating, removing, or modifying a working group. | ||
| - Accepting or removing Kubeflow components. | ||
| - Official responses to publicly raised issues. | ||
| - Any other decisions that at least half of the members (rounded down) present decide require a vote | ||
|
|
||
| Decisions are made in meetings when a quorum of the members are present and may pass with at | ||
| least half the members (rounded up) of the committee supporting it. | ||
|
|
||
| Quorum is considered reached when at least half of the members (rounded up) are present. | ||
|
There was a problem hiding this comment. 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? There was a problem hiding this comment. 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 ? There was a problem hiding this comment. Asking the KSC to participate may overload the KSC - but hey it would be a KSC decision :) |
||
| Members of TOC may abstain from a vote. Abstaining members will only be considered as | ||
| contributing to quorum, in the event that a vote is called in a meeting. | ||
|
|
||
| ### Special decision process | ||
|
|
||
| Issues that impact the TOC governance require a special decision process. Issues include: | ||
|
|
||
| - Changes to the TOC charter | ||
| - TOC voting rules | ||
|
|
||
| The issue may pass with 70% of the members (rounded up) of the committee supporting it. | ||
|
|
||
| ### Results | ||
|
|
||
| The results of the decision process are recorded and made publicly available, | ||
| unless they pertain to sensitive or privileged matters. The results will include: | ||
|
|
||
| - Description of the issue | ||
| - Names of members who supported, opposed, and abstained from the vote. | ||
| - | ||
|
|
||
| ## Getting in Touch | ||
|
|
||
| There are two ways to raise issues to the steering committee for decision: | ||
|
|
||
| 1. Emailing the steering committee at [TODO: add email]. This is a private discussion list to which | ||
| all members of the committee have access. | ||
|
|
||
| 1. Open an issue in the [kubeflow/community](https://github.com/kubeflow/community) repository and | ||
| indicate that you would like attention from the TOC using GitHub label [TODO: add label]. | ||
|
|
||
| ## Changes to the charter | ||
|
|
||
| Changes to the TOC charter may be proposed via a PR on the charter itself. Amendments are accepted | ||
| following the [Special Decision Process](#special-decision-process) detailed above. | ||
|
|
||
| Kubeflow community members can propose changes and improvements to the existing TOC charter. | ||
|
|
||
| Proposals and amendments to the charter are available for at least a period of one week for | ||
| comments and questions before a vote will occur. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.