Notary and TUF are separate projects, but this is not very clear because the Notary v1 repo currently[1] lives under the TUF organization on GitHub. As a first step the TOC will urge the maintainers to 

- move this project to the Notary organization as soon as possible 
- refresh the maintainers list which is evidently stale
- provide clear guidance to end users as to the status of the project - namely, that v1 is an implementation that can provide signing functionality, but that the project is now focused on a new implementation that does not follow exactly the same specification, but aims to provide a more easily used signing implementation. 

Resolving this would address many of the concerns you raise as it would clarify that the projects are decoupled (and that Notary is not necessarily bound to being compliant with TUF if that no longer meets the goals of the Notary project).

[1] https://github.com/theupdateframework/notary
[2] https://github.com/notaryproject

- We’re aware that the Notary project does have an active community but that it needs to clarify and codify the project governance as a matter of urgency. Our understanding is that this is in progress; we will set a deadline that this should be resolved by the end of August. 

The TOC doesn’t believe it will serve the wider community to follow this recommendation for the following reasons:

- We believe that the Notary name is understood as a project that addresses the need for securely signing artifacts.
- There is precedent for re-implementing projects without requiring them to reset into the Sandbox (for example Fluent / Fluent Bit, Linkerd v1/v2)
- Notary clearly falls into the Cloud Native landscape and has participants from multiple organizations in the CNCF Community, so we want to encourage this collaboration
- A significant proportion of adoption is through other projects like Harbor, which should ease the transition for end users.


The alternative approach would be to archive the Notary project and encourage “Notary v2” to reapply with a different name, but we believe this would create more confusion for end users. 

- Notary is of course subject to the same requirements as any other incubation project. The security requirements at this level require security processes to be in place but we don’t currently have any requirements around threat modelling (though we do encourage projects to collaborate with TAG Security on their security assessment process). 

- We also note the concern raised about development “behind closed doors” and encourage members of the project to make the TOC aware if decision-making happens in a private fashion. However, we also note that collaborating on a project together does not preclude people from having private discussions - for example, it is acceptable to solicit feedback from a smaller group before opening something up for broader input. It is the decision-making that needs to be open. 

- Noting your intention to discuss these concerns at the next Notary meeting, we propose to publish this thread on the TOC mailing list, and add this to the agenda for discussion at an open TOC meeting in August, where we would be delighted to have you join us for the discussion (and this would allow time for the Notary meeting to take place first). Does that seem reasonable to you?