Hi Emily,

Thanks for driving a very productive discussion this morning. I’m sorry I couldn’t join. Having watched the video, I wanted to offer some input on a couple of points that were touched on, but not fully explored, in the meeting.

The CNCF must be valuable as-is: look at the queue of people trying to join!

Not all projects join the CNCF because they want more contributors. Many just want more adoption. They join because being a CNCF project is (a) a shorthand that some adopters require, or at least expect (b) the gatekeeper for acceptance into KubeCon.

(I have substantial experience in a Cloud Native open source project that was not part of the CNCF.)

Projects want to join the CNCF. They also want to move levels as quickly as possible, because that is a signal to the marketplace which spurs adoption, and their maintainers’ ability to build a business. As an example for contribution, Boeing announced their staff are able to contribute to CNCF Incubating or Graduating projects. If you are in the aviation or defense space and you want Boeing to support your project, you want to move up the levels quickly. (I’m pretty sure you can consider heavily regulated industries “the late majority”.)

We shouldn’t want every project to join the CNCF; we have more projects than we can logistically handle or support

The charter currently states: “The goal is to have an increasing bazaar of projects related to and that integrate with projects already accepted into the CNCF.” To gain admission to the playing field, you must join, and to gain adoption, you must move up the treadmill.

(See also, the changing opinions on whether or not Istio talks were welcome at past KubeCons).

We are but a few people with hundreds of projects on the landscape

This could be an opportunity to revisit if having 11 people on the TOC is still correct, or if some of the responsibility for vetting projects could be delegated.

The TOC was founded as 9 members when the CNCF had one project, and expanded to 11 at a time when it had 42 projects.  There are 152 projects today.  It is reasonable to think that 11 members can no longer provide the same level of service.

In the past, Chris Aniszczyk has described the TOC as “the Supreme Court” of the CNCF.  The means of selection by different groups suggests it is meant to be representative of the whole CNCF community. Is it time to tweak the process so that the expectation isn’t that “TOC members will do all the level-moving work”, but instead that they are a body that is the final check and balance on work done by other groups?

Moreover, because projects want to move levels, why not have the onus be on them to actually prove they meet all the criteria? Or create a TAG Project Maturity?

There is no shortage of volunteers. There were 18 qualified candidates who put themselves forward for the 5 TOC spaces that were selected in the last 2 months.

We can’t just provide a checklist and then you’re graduated.

Why not? That is true for an OpenSSF Best Practices badge, for example, which is also a signal of maturity (albeit in a different area).

The graduation criteria read as a checklist.  As written, the vote required seems to be does the project meet all the criteria, all of which are individually measurable. 

Vitess graduated in less than a month. I think that's a reasonable expectation for a timeline, given that you should know in advance if you meet the criteria and only apply when you do. Even if there are to be new criteria added, it’s important to decide if there is still a “judgment call” criteria to be made by the Court TOC. 

I don’t think the solution to the current situation is just that the TOC makes small tweaks. If we hypothetically introduced a “Super Graduated” level, then the CNCF’s promotion and event offerings to this level would determine whether a project needed to pursue it.

In closing, I’d like to return to the CNCF charter: “Fast is better than slow. The foundation enables projects to progress at high velocity to support aggressive adoption by users.”

-c

On Wed, Mar 22, 2023 at 10:41 AM Emily Fox <themoxiefoxatwork@...> wrote:

All,

Thanks to everyone who was able to join the TOC call today or had participated in the discussion on the GitHub issues and PRs for the proposed cloud native milestones as well as the open issues on graduation criteria. We had an excellent discussion that surfaced additional challenges and observations in both of these areas from a broad range of stakeholders and interested parties. Below is the top level summary that outlines key points of discussion and next steps. If you were unable to join us, please check out the YouTube recording here: https://youtu.be/WDwvowl9SAs

Regarding Milestones:

• Consensus to rename as “Guide Posts”

• Consensus to remove the maturity structure currently conveyed that aligns with the levels, ordering will remain to show evolution of these

Elevated during discussion of Milestones:

• Need to scale the process for the projects we have before us

• Better alignment or exploration of the value the foundation provides projects at various levels - have we lost or shifted the north star away from the original intent?

Regarding the Criteria: ( Note much of the discussion focused more on the process and logistics of moving levels, not on the specifics of the existing criteria or proposed criteria - this feedback exists on the issues)

• The content in the repo on what the process is and the criteria is misleading and confusing in several key areas

• Consensus that governance review should occur at Incubation or near moving to Incubation and not part of Graduation

• Consensus that guidance and roll out for changes (to be proposed) needs developed for projects mid-application to move levels to ensure equitable evaluation

• Existing confusion or duplication of work between the Google Doc and the PR

• The plethora of project needs and maturity considerations for moving levels varies project to project, however, there is a fundamental core of criteria that are consistent across nearly all projects. There is a significant amount of discretion needed in evaluating projects seeking to move levels that needs to be balanced with maintainers and contributors trying to understand the path forward to move levels

Elevated during discussion of Criteria:

• Update the freeze/modify this time period to better align with what can be accomplished when folks are freed up - 3 months of no progress in moving levels is undesirable.  Worth revisiting now that we’ve tried this a few times.

Actions / Requests from the call:

• Regarding Milestones specifically:

• Emily Fox to provide the summary of today’s meeting - Completed as of this message, will also appear in a thread in #toc slack channel

• Emily Fox will push an update on PR 997 to include the items where we reached consensus (estimated to be completed within the next week or two)

• Regarding criteria and moving levels

• TOC will confer on next steps (community teaming or TOC-driven changes) and provide a decision with engagement and direction for the community to engage on this by April 4th.
  

• Regarding the freeze - the TOC will confer on changing this to rebalance expectations, activities, and timeliness for this. If a community member has a proposal to restructure that freeze that includes considerations from the discussion from the call, we would welcome it, otherwise this requires a TOC member to champion and execute.

Thank you all again!