cncf
/
toc
mirror of https://github.com/cncf/toc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

What: Initiate the TOC Operations folder 

Why:
 * The TOC has a variety of operations and processes that dont exist as content in this repo. this PR begins populating those into the repo.

This change address the need by:
 * Creation of an operations folder
 * moving the toc-decision-process.md into the operations folder
 * create the README.md that discusses the contents of the folder
 * create an onboarding doc
 * create a toc-chair doc

Signed-off-by: Emily Fox <themoxiefoxatwork@gmail.com>
This commit is contained in:
Emily Fox 2024-01-03 16:44:32 -05:00
parent 85d21552f4
commit beeef4c7b7
Failed to extract signature
4 changed files with 158 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
operations/README.md Normal file
View File

@ -0,0 +1,9 @@
# TOC Operations
This directory contains various files, procedures, responsibilties, and expectations of TOC members. Within this folder, TOC members and the community can understand more about how the TOC conducts themselves, what work they perform and how. As the TOC continues to refine and improve its processes, this directory will be updated.
## Operations structure
* [TOC Onboarding](onboarding.md) - a collection of materials, general information, and other relevant details to support new and returning TOC members in getting up to speed.
* [Decision Process](toc-decision-process.md) - General information on how we make decisions.
* [TOC Chair](toc-chair.md) - Addition onboarding, responsibilities, expectations of the TOC Chair.

99
operations/onboarding.md Normal file
View File

@ -0,0 +1,99 @@
# Welcome to the TOC!
We are so glad you are here. You have been elected to the Technical Oversight Committee, the body responsible for accepting and overseeing projects in the cloud native ecosystem. This onboarding document and its various files and links are here to help get you up to speed and set you up for success as a TOC member. If you haven't already done so, now is a great time to familiarize yourself with the [Definition of Cloud Native](../DEFINITION.md).
#### About this document
This onboarding document is designed to provide some introductory information to new TOC members. It contains limited information to set expectations and provide a TOC member with generalities about the role and work we do. For specific instructions, guidance, templates, etc. please refer to the various files and content in the [Operations Directory](README.md).
## The Charter
The role of the TOC is defined by the [CNCF Charter](https://github.com/cncf/foundation/blob/main/charter.md). Please take a few moments to familiarize yourself with the charter. The TOC is mandated in section 6(a), however there are many parts of the charter that are relevant to the execution of our work.
Within the scope of the Charter, the TOC is responsible for defining how we achieve that mandate. That means we agree on the structure, processes, and tasks. Everything that follows represents the current way the TOC has been working. It is not set in stone, as it is expected that the TOC will periodically alter, adjust, and change how we conduct our work in response to shifts in the landscape and community as well as proactively, to not only keep pace, but lean into technical innovation for a sustainable cloud native future.
## Accesses, Openness, and Transparency
As TOC members, we manage our repository with the support of CNCF Staff. You will be added to the toc-members group and granted appropriate permissions on the repository so you may create, review, and merge pull requests in accordance with our [PR processes](../toc-decision-process.md). We bear the responsibility of managing our repository equally among the TOC and expect all TOC members to support the collective group in managing the repo.
The TOC maintains both public and private communication mediums. In accordance with the [CNCF values](https://github.com/cncf/foundation/blob/main/charter.md#3-values), we strive for openness and transparency - our technical work must be available to all. Our processes and decisions shall be transparent, visible, and discoverable. The nature of some TOC discussions may be sensitive as they impact individuals, projects, and organizations. Therefore TOC members are expected to use their best judgement in determining if a discussion should be held in private to allow the TOC members to speak their mind or raise doubts fully and frankly without the fear of being misunderstood or revealing their ignorance in front of a wider audience. Once concensus is reached, the rationale and reasoning will be summarized, well documented, and a decision may be put forward for the community publicly, either as informative or for public review and finalization through voting.
You will be added to both public and private slacks, mailing lists, and receive calendar invitations for both public and private meetings.
## Attendence, Availability, and Involvement
The expected time commitment of a TOC member is anywhere from **10-25% of their monthly regular work time** and will vary month to month with surges and slow downs throughout their term. TOC members should also anticipate travel to conferences and offsites at least twice a year, with participation and attendence at various meetings during the CNCF flagship conference: KubeCon+CloudNativeCon (KCCN).
The TOC has four (4) hour-long meetings per month held on Tuesdays at 0800 PST/1100 EST/1700 CET. The first meeting of each month are Technical Advisory Group (TAG) updates and discussion. As a [Liaison](../../tags/cncf-tags.md#toc-liaisons) to one or more TAGs, the content presented and discussed by the TAG should be information you are already aware of. For TAGs that you are not a liaison for, this is your opportunity to become aware of the broader work being done within speciality technical domains and verticals. It allows you to connect various TAGs and projects together, promoting interoperability for the benefit of the technical community and its adopters.
The second and fourth meetings are generally private meetings. During these meetings, the TOC meets to review issues on the repo, conduct vote parties (to ensure outstanding votes are completed), and discuss any open issues, activities, tasks, and other efforts. Periodically, we may invite the Maintainers, projects or other groups to join us to join so we may connect with them, understand any challenges and successes they encounter, and take feedback to improve our engangements.
The third meeting is public and will usually cover public discussion on improvements and activities the TOC is pursuing or community-led topics where the TOC has oversight or is needed to facilitate neutral consensus.
TOC members rotate meeting facilitation as often as we can to ensure the TOC Chair is not always doing it, they already have a lot of tasks, see [TOC Chair](toc-chair.md) for more detail. It is important that the Agenda be set in advance but have the opportunity for flexibility should more pressing issues arise.
### Events and additional meetings
#### Governing Board
The TOC attends Governing Board meetings periodically when invited, our participation is typically limited to 1 hr ([except for the TOC Chair](toc-chair.md#Governing-board-meetings)). The most common of these is the Strategy Meeting typically held during KubeCon+CloudNativeCon (KCCN). As the overseeing technical body, it is anticipated the TOC guides any technical strategy discussions. The TOC collectively crafts the messaging and structure for this.
#### KubeCon+CloudNativeCon (KCCN)
At KCCN, the TOC has three additional engagements; TOC Keynote, TOC Panel, and TOC/TAG Meeting. The TOC keynote is about 15 minutes in length and is delivered by one or more TOC members and may include guests. Common topics are:
* introducing what the TOC is
* conveying changes to the ecosystem/landscapre since the last KCCN
* community oriented topics
The TOC Panel is a panel of the TOC members present at the conference and functions similar to a ask-me-anything session. The CNCF CTO initiates the panel by providing an overview to attendees of who the TOC is and what we do. They will often initiate the first few questions to the panel and facilitate attendee questions to the TOC.
The TOC and TAG meeting may be an open (conference attendees may observe) or closed meeting, depending on the topics. This meeting focuses heavily on the TAGs, their health, and their work. TOC Liaisons are expected to make time to meet with their TAGs as part of that meeting.
There are additional social events at KCCN that TOC members are invited to as a body or as individuals, attendence at these is purely optional.
#### TOC Offsite
The TOC offsite is a relatively new event, happening at least once per year lasting about 1-2 days plus travel. It is focused time, ideally face-to-face but virtual is also an option, for the TOC to come together and perform strategic planning and operational health development of the TOC, community, TAGs, and projects. Many initiatives the TOC has had success in executing are the result of these offsites and thus highlights their importance to the continued growth and sustainment of cloud native.
### Preparedness and communicating availability
TOC members, in accordance with the Charter Section 6(f)iii, are expected to attend and be prepared in-advance of each meeting so that the conversation may be productive and decisions may be reached in a timely manner. TOC members are **not full-time employees of the CNCF**, they are individuals elected to serve the community - many with full-time jobs for which their employers support their activites - *for the benefit of cloud native and open source*. As such, we understand that incidents, pressing issues, and other primary work priorities may occur from time-to-time, particularly as many TOC members hold significant technical leadership roles within their organizations, that may inhibit their ability to make every meeting all the time. Further, we are human with personal lives and responsibilities that may temporarily limit our ability to attend and participate in these meetings, e.g. vacations, personal matters, etc. It is expected that every TOC member *will communicate their absence or limited availability* in advance (when possible), but endevour to be present and prepared for these meetings.
In addition to these meetings, TOC members are expected to meet synchronously or asynchronously with the TAGs for which they liaison, occassionally attending TAG meetings.
### Inactivity of a TOC member
If, for any reason, a TOC member is continuously absent without notice, see 6(f)iii, their voting privileges are *suspended* until such time as their consecutive attendence at two meetings. Due to the nature of our work, the inability of a TOC member to cast an *informed* vote (as occurs by meeting attendence *and* involvement in regular engagement as detailed above) penalizes the entire TOC's ability to regularly achieve quorum. If after the 4th absence the TOC is not notified, the TOC Chair with support of CNCF Staff will make an attempt to address the absence with the TOC member. If the Chair and Staff are unsuccessful, the Chair will bring the issue of absence to TOC vote in accordance with z6(f)ii at the next private meeting and provide notice to the Governing Board of the outcome.
If, for whatever reason, a TOC member feels that cannot sustain the committment required of the role, they may proactively notify the TOC Chair or CNCF Staff of their decision to step down. While uncommon, this is entirely reasonable to have happen, particularly as lives and careers grow and shift. We thank each TOC member for their time of service to the community, however long or brief it may be.
### Communicating effectively for consensus
One of the most critical aspects of the TOC is our ability to facillitate effective communication, particular among ourselves. The TOC holds many discussions over Slack. Members do their best to summarize content and may use emojis to indicate types of information for quick review or action. An effective tactic that is being normalized is:
* `:information_source:` (light blue square with an 'i' in it) This emoji is used to indicate the content is for information only and no action is needed.
* `:reminder_ribbon:` (yellow ribbon shaped like an open bottom figure eight) This emoji is used to indicate the content was previously provided and is providing a courtesy reminder. It usually indicates some task or action needs completed if you havent already done so. It is also used to remind members of upcoming items such as topics on an upcoming Agenda.
* `:exclamation:` (red exclamation point) This emoji is used to indicate an action is needed by the TOC, either for an individual or for the group.
Emojis can be used individually or with other emojis, this usually happens to indicate a reminder has an action with it or a reminder is informational but an update may make it more topical. It is common practice to **bold** the topic immediately following the emoji for longer updates, such as summarization of a meeting.
We operate on lazy consensus, if a TOC member is not participating in a discussion, it is their responsibility to keep themselves informed of the outcome and impetus of these discussion to guide future decision making as part of their participation in the TOC, the use of emojis and summarization of topics is intended to facillitate this in the most effective manner for a group of time-constrained individuals.
### Due Diligence
The primary work a TOC member engages is in conducting the due diligence of cloud native projects as they advance in their maturity, this process is commonly referred to the moving levels or maturation process. After a TOC member steps forward to sponsor a project, it is anticipated that a kick-off meeting is held to set expectations for what the process will be like, provide rough timelines, collect additional information and allow the project to ask any questions. This kick-off is commonly conducted as a virtual meeting, not lasting more than an hour. Additionally, TOC members should anticipate a few hours of concentrated review, analysing the project, its repository(ies), and clarifying the content of the due diligence. Additional time is expected to be spent conducting and summarizing Adopter interviews to ascertain the current usage of the project within industry.
## Voting
The TOC primarily votes in one of two mechanisms, gitvote or on the mailing list. It is our preference that voting occur with gitvote in the repository as this provides better transparency and is easier to verify and track vote execution. Voting conducted over the mailing list is performed by responding with a +1 Binding (+1B), or -1 Binding (-1). TOC members may abstain if they have a conflict of interest. Indication of abstention from voting for any other reason is discouraged and should not be confused with not yet voting as indication of abstention is active, not passive, andresults in no vote being rendered by that individual. In the absence of information, we cannot make an informed decision, so it is imperative that we ask questions openly and provide answers with clarity for our peer TOC members, particularly on topics that may not be their strength. A vote passes with two-thirds vote of votes cast based on the charter (see [6(c)(viii)](https://www.cncf.io/about/charter)).
## Lobbying and Direct Messages
Historically, the TOC has had a problem with “lobbying”, e.g. a project approaching individual TOC members for feedback / comment, often moving on to another TOC member if they didn’t get the answer they wanted. This was particularly true for the old Sandbox model and was a key reason for changing from sponsorship to a voting model. With this in mind, TOC members should disclose to the rest of the TOC if they have been approached by a project or individual within the community. It is acceptable and expected that projects or community members will reach out to the TOC for advice, however to maintain consistency in expectations, *all TOC members should be made aware of those discussions, with the opportunity to provide additional information or recommendations*. This ensures the TOC maintains a strong, clear voice to our technical communtiy, consistent with our processes, [values](https://github.com/cncf/foundation/blob/main/charter.md#3-values), [principles](../PRINCIPLES.md), and the Charter.
As the TOC continues to work through updating our documentation on the repo, older references to "seeking sponsorship" may result in projects reaching out to TOC members directly to "sponsor" their project for moving levels. When this occurs, kindly direct them to the Moving Levels resources which details how projects are recommended for promotion to the next level. The TOC strives to pick up projects from the backlog in the order which they are recommended for promotion, while balancing alignment of TOC member expertise, liaisoning assignment, and availability of our members.
## Public persona and engagement
As a member of the TOC, you may receive requests to speak at conferences, community days or events, or even on podcasts and webcasts and contribute to or participate in panels, blogs, and articles. It is important that you are aware of the capacity that you are participating in these activities in. Depending on the activity, particularly for conferences and community days or events facillitated by the CNCF, support may be available to allow a TOC member to attend and speak. If you are approached to do this for a CNCF facillitated event and interested, reach out to CNCF Staff.
It is important that you conduct yourself in a manner expected of a Technical Leader that aligns, exemplifies, and promotes the [TOC Leadership Principles](../PRINCIPLES.md).

40
operations/toc-chair.md Normal file
View File

@ -0,0 +1,40 @@
# TOC Chair
This document serves to provide the TOC Chair with details on their responsibilities, role, and expectations that are in addition to those of a TOC member.
## Selecting the Chair
The TOC Chair is an member of the TOC that is chosen by each seated TOC to lead and presented the TOC in the execution of it's work.
## Functions of the Chair
The Chair is expected to perform a variety of functions and can often be thought of as a Team Lead, as such their work relies on the input and support of the TOC to be successful. A list of known functions and their details is below:
* Facilitate Initiative Planning
* Coordinate TOC activities
* Ensure Liaisons are assigned and engaged for each TAG
* Coordinate overarching TAG activities
* Represent the TOC to the Governing Board
* Co-present CNCF technical strategy at Governing Board strategy sessions
* Support onboarding new TOC members as needed
* Ensure notes and actions are documented and issued for TOC meetings with follow-up
* Verify appropriate workload distribution among the TOC members
* Ensure TOC meetings have a facilitator and agenda
* Foster discussion - ask questions, even obvious ones to move the conversation forward or to closure.
* Protect TOC time - People like to sign the TOC up for a lot of things, you are responsible for ensuring we’re involved in the things we need to be and which ones are not on us
* Redirect work out of scope of the TOC to the appropriate group (Kubernetes Steering, Governing Board, Code of Conduct Committee, Legal Committee, etc.)
* Bring project and group conflicts that escalate to the TOC level to closure, either through delegation to TOC members and awareness or through direct resolution while keeping the TOC informed
* Meet regularly with CNCF Leadership, CNCF Staff Supporting the TOC, and other Foundations' Technical Leadership to coordinate cross-foundation opportunities and awareness
* Be available to field questions and concerns from community members and redirect as needed
* Coordinate TOC Keynotes at KubeCon + CloudNativeCon (KCCN)
* Participate in meetings, presentations, etc. as needed at KCCN
## Governing Board Meetings
When a new TOC chair is selected, the following governing board meeting the chair provides a brief introduction about themselves, their vision and principles, and provides a "state of the TOC" address. The State of the TOC address identified curent activities, challenges, and work planned or unplanned. It may include a roadmap of what the next year of the TOC looks like.
At subsequent GB meetings, the Chair will provide the GB with a status update of the TOC's work. It is recommended these updates be information with links to where interested GB members may participate or engage.
## Other duties as they occur
This is a short doc, while it does contain a fair amount of information on what goes into being the Chair, there is a lot more that is not documented here due to complexity, sensitivity, sporadic nature of the work, or the number of one-off unrelated things that pop-up time and time again. It is strongly recommended that if you are interested in serving as Chair, reach out to past Chairs and ask their experience. Each Chair's experience is very different, now two are alike. As the community grows and evolves, so too does the functions and responsibilities of the chair.

37
process/toc-decision-process.md → operations/toc-decision-process.md
View File

@ -1,21 +1,14 @@
# TOC Decision Making Process
This document outlines a decision-making structure used by the TOC
that takes into account feedback from members of the community
and strives to find consensus, while avoiding deadlocks.
This document outlines a decision-making structure used by the TOC that takes into account feedback from members of the community and strives to find consensus, while avoiding deadlocks.
All discussions take place based on the Operating Model
defined in the [charter](https://github.com/cncf/foundation/blob/main/charter.md#6-technical-oversight-committee-toc).
All discussions take place based on the Operating Model defined in the [charter](https://github.com/cncf/foundation/blob/main/charter.md#6-technical-oversight-committee-toc).
To ensure that the process is as efficient as possible,
the amount of notice provided and the amount of consensus sought is driven by
the estimation of how complicated an issue or PR is.
To ensure that the process is as efficient as possible, the amount of notice provided and the amount of consensus sought is driven by the estimation of how complicated an issue or PR is.
## Major Changes
To propose any change to the existing governance, principles or processes that
impact the broader CNCF community (including projects, TAGs, etc),
the following process shall be followed:
To propose any change to the existing governance, principles or processes that impact the broader CNCF community (including projects, TAGs, etc), the following process shall be followed:
- Open a GitHub issue in the `cncf/toc` repo describing the change.
- Shepherd a public discussion about the topic in a TOC meeting.
@ -42,18 +35,11 @@ for a _reasonable time_ to allow for any additional comments.
## Minor Changes
The following process shall be followed for changes that are narrowly scoped.
Some examples of these changes are typo fixes or improving the clarity of
existing TOC processes as documented where there is no impact to projects,
the community, the outcome of processes, or any such changes that modify
the intent of their execution.
It is expected these changes are made in good faith to enable velocity for
projects by removing confusion and enable increased transparency.
The following process shall be followed for changes that are narrowly scoped. Some examples of these changes are typo fixes or improving the clarity of existing TOC processes as documented where there is no impact to projects, the community, the outcome of processes, or any such changes that modify the intent of their execution.
It is expected these changes are made in good faith to enable velocity for projects by removing confusion and enable increased transparency.
- Open a GitHub issue or directly create a PR to the `cncf/toc` repo
to propose the change.
- For the PR to be approved, it needs approval from at least one TOC member
_and_ the TOC Chair is to be informed to confirm previous consensus in
- Open a GitHub issue or directly create a PR to the `cncf/toc` repo to propose the change.
- For the PR to be approved, it needs approval from at least one TOC member _and_ the TOC Chair is to be informed to confirm previous consensus in
applying the minor change.
- If the PR is approved as per above, the PR can be merged.
@ -70,8 +56,5 @@ Votes are managed through at least one of the following ways:
- over email on the TOC mailing list
- on call in a public TOC meeting
The specific voting details are mentioned in each process' guidelines
and the requirements laid out in the [charter](https://github.com/cncf/foundation/blob/main/charter.md#6-technical-oversight-committee-toc).
Processes that pass votes do not require additional approvals and
can be directly merged by the CNCF Staff.
The specific voting details are mentioned in each process' guidelines and the requirements laid out in the [charter](https://github.com/cncf/foundation/blob/main/charter.md#6-technical-oversight-committee-toc).
Processes that pass votes do not require additional approvals and can be directly merged by the CNCF Staff.