# Response to Notary v2 Issue

--- tags: CNCF TOC --- Response to: https://github.com/cncf/toc/issues/981#issuecomment-1424749399 There are a few reasons I see the need to respond to this in order to provide clarification. (1) There is a proposal and it's fair to respond to it, (2) I think it's important to provide context for those who are reading this, and (3) people will find this in the future looking for TOC patterns to follow and I would like to be clear. > We are talking the equivalence of a set of individuals rebooting the TOC and starting a TOCv2 without the consensus of seating members If we look at the listed maintainers of the Notary project when changes occurred or at any other time they are not the signitories on the letter above or those that have raised issues here. If those who were previously maintainers would like to step forward and discuss the issues with us we would be happy to listen. If someone has a case that maintainers were "rebooted" please contact us with details rather than general accusations. Notary has tracked their maintainers since prior to it being a CNCF project. The concern in the quote above does not appear to be valid. > Due to the disconnect and failings in reparation, those members eventually gave up on recourse and started a new project outside of the CNCF which give birth to a separate foundation as they found the committee chartered with technical oversight wasn't willing to step in and exert technical oversight. This is one description of the history that not everyone shares. First, it's important to note the TOC's role. Projects are independently governed. It is not the place of the TOC to step into a project to direct how it should build or design something. When those in the community around a project have disagreements on how to proceed in design and development, it is up to the project maintainers to navigate the situation. The project maintainers are the one empowered here. The community was not in agreement around how to proceed - and we now have multiple projects that handle overlapping aspects while targeting use cases that are a little different and did things using a slightly different methodology. There is a rich history there that I'm not going to try to sum up in this comment. It's important to note that if the other project(s) had been well suited for all the needed use cases, than the work in the notary project would not be active today for lack of a need for it. This isn't to diminish either project. It's to highlight that a diversity of use cases exist. The other project could have come to the CNCF. A separate foundation, under the Linux Foundation, was a choice folks made. Competing projects in the CNCF already occur. The other project was not proposed to the CNCF. I say these things to add context. I would be delighted if both projects were successful or if only one is. Problems being solved in ways that satisfy those with the problems is what I hope for. It's a market driven approach and there are some sub-markets there. > Said project has since superseded notation in traction, growth, and maturity. This seems like a good time to note that the TOC does not crown kings. [This is one of the TOC Principles](https://github.com/cncf/toc/blob/main/PRINCIPLES.md#no-kingmakers--one-size-does-not-fit-all). By not crowning kings the TOC enables innovation and a wide variety of use cases to be targeted. In the CNCF there are many competing projects today (e.g., containerd and CRI-O). Since we are on the topic of the other project, it has not gone un-noticed that many of those related to the other project are the ones raising issues here. I would ask that those competing in this space be professional with each other. Even to the point of collaborating on shared libraries and specifications where it makes sense. > As such, I propose the following course of prompt action: There are a couple concerns I have with the proposed actions: 1. They do not appear to take into account how the work on notary is being designed and proceeding. The separation between a specification and reference implementation where other implementations of the specification are being done. The suggestions appear to be lacking in context. 2. The actions also ask the TOC to step in and take the project in a different direction from the maintainers. The ask is for the TOC to not allow the project to be self governing. This would set a precidence for other CNCF projects as it would mean that projects are no longer self governing. And, to do all of this for something other projects have already done. I understand there is a fair amount of passion around this topic. Using processes, precidents, and making decisions based around handling decisions in common ways helps the TOC to guide projects while enabling them to be self governing without passion around a single issue on a project causing the TOC to act inconsistently. If I put my project maintainer hat on, I appreciate this because I know what to expect.