--- tags: CNCF TOC --- Response to https://github.com/cncf/toc/issues/981 We want to start by thanking everyone that we, the TOC, spoke with while reviewing this situation. It helped provide some much needed context. We also ask all parties to be empathetic towards one another when facing technical conflict. We want to welcome other perspectives and experiences when evaluating community concerns. The TOC has met numerous times at various intervals with many community members passionate about Notary to understand this issue and have also looked outside of the CNCF to how other foundations or projects have navigated similar concerns. We have heavily considered the charter we have and the goals we maintain for projects and you will see elements of this below. Guidance given to the Notary project in the rest of this response is the type of feedback often given during the due diligence process during an incubation and graduation review. Often changes need to be made during the incubation or graduation review prior to a vote. --- **Action Summary For Notary:** The following is an action based summary for the [Notary project](https://github.com/notaryproject). Context around these and details on reported concerns not addressed here are below the summary. - The TOC expects projects to be self-governing, this means community members abide by their governance or make motions to propose, discuss, decide, and document changes. We expect Notary to adhere to their governance and request the project consult with TAG Contributor Strategy for guidance on this. - Notary needs to refresh the documentation around all its subprojects to eliminate confusion by it’s adopters and contributors (past and present). This may include archiving stale repos but it is up to the project to follow their governance process in executing this. - Notary and its sub-projects will undergo a security audit targeting the v2/notation work. - Suggestions for specific improvements of Notary should be made to Notary in accordance with their contributor guidelines and governance. --- Technical conflict in projects should be documented by the project as part of their self-governance. It should consider all perspectives and move to a vote under the specified governance process at the time the conflict occurs. Should the governance be lacking, the project should remediate the governance first and then return to technical conflict resolution. Should this not solve the issue, the project may escalate to the TOC for technical remediation through a to be determined process. Escalating to the TOC is not a path for community members to have the TOC direct a project to change direction when a reasonable governance was followed. Notary has a [documented governance](https://github.com/notaryproject/notary/blob/master/GOVERNANCE.md) and it, with the process above, should be followed in this technical conflict resolution. Note, after the quoted email above was written the Notary governance was updated to account for sub-projects like Notation (in this thread referred to as Notary v2). Formal governance is designed to introduce structure and consistency. We highly recommend all projects lean towards formal governance with flexibility to adjust. Having and following a governance is a [graduation requirement](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md) and in the graduation process all projects have their governance reviewed. Having a governance reviewed by TAG Contributor Strategy prior to going through the graduation process can help make the graduation process, which often includes changes, easier. --- We fully expect projects to refresh their goals and objectives and to document those proposals and the corresponding decision. Changes in goals and objectives can lead to changes in design. CNCF projects have a rich history with sub-projects. The TOC is not making changes in this area. Sub-projects should have their maturity clearly documented in relation to the primary project, and not be assumed to be at the same maturity level.. The TOC finds no issue with Notary having sub-projects or changes in design. The maturity of sub-projects with relation to Notary does need to be clearly documented. Changes in design have precedent of happening during the Incubation phase. Projects may reasonably expect divergence in naming. When this occurs it is up to the project to make a documented decision with reasoning so that contributors and adopters can easily navigate each element of the project and its use. This includes cleaning up heritage or legacy naming conventions and documentation within the community while also archiving the appropriate repositories. Notary, Notary v2, and Notation are all discussed as part of the project. There is the Notary v1 codebase, the Notary v2 specification, and Notation which is a reference implementation of the v2 specification. Clarification is needed to help contributors and end-users of the project. Questions arise such as: - Is Notary v2 the general Notary specification and Notation a reference implementation? If so, why is the v2 specification versioned as a v1 and versioned like Notation? Or is the Notary v2 specification the specification for the Notation sub-project? - Which of the sub-projects own the Notary v2 specification? Is it Notation, Notary, or an unlisted one? This may help clear up the first question. - How are end-users supposed to view Notary v1 and v2? We appreciate that keeping external documentation clear, consistent, and up to date can, at times, be a challenge. It may be useful to have a community manager to help keep the communication clear and consistent. The documentation for the Notary project needs changes to improve clarity. --- Projects, particularly security projects, should plan to go beyond minimums as a matter of building trust with adopters. For instance, achieving an OpenSSF Best Practices Silver or Gold badge. Moving beyond the passing badge requires documentation of elements such as an [assurance case](https://bestpractices.coreinfrastructure.org/en/criteria/1#1.assurance_case). Given that the specification and Notation are at a major version release candidate stage, this is an ideal time for a 3rd party security audit of the specification and implementation. We will work with the project to get this process started. --- Community members that have issues with the openness and transparency in which the project conducts their collaboration and development activities should discuss these with the project for resolution. Often technical challenges with the tools used may be the cause and this is not immediately apparent to community members. Some ways we observed Notary currently operating with openness and transparency include: - The Notary project currently has a regular public meeting that is documented in the project and listed on the CNCF calendar. An agenda and meeting minutes are captured in a public document. - Development is managed through issues on the GitHub repositories and a project board. - Notary is leveraging CNCF slack to hold online conversations. Suggestions for specific improvements for the Notary project related to openness and transparency should be directed at the Notary project. --- If the Notary project has questions about the guidance from the TOC, we are happy to provide more detail.