doc: copy governance docs from subproject notary to .github

Signed-off-by: Yi Zha <[email protected]>

CODE_OF_CONDUCT.md

@@ -0,0 +1,43 @@
+## CNCF Community Code of Conduct v1.0
+
+### Contributor Code of Conduct
+
+As contributors and maintainers of this project, and in the interest of fostering
+an open and welcoming community, we pledge to respect all people who contribute
+through reporting issues, posting feature requests, updating documentation,
+submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for
+everyone, regardless of level of experience, gender, gender identity and expression,
+sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
+religion, or nationality.
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery
+* Personal attacks
+* Trolling or insulting/derogatory comments
+* Public or private harassment
+* Publishing other's private information, such as physical or electronic addresses,
+ without explicit permission
+* Other unethical or unprofessional conduct.
+
+Project maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are not
+aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
+commit themselves to fairly and consistently applying these principles to every aspect
+of managing this project. Project maintainers who do not follow or enforce the Code of
+Conduct may be permanently removed from the project team.
+
+This code of conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a CNCF project maintainer, Sarah Novotny <[email protected]>, and/or Dan Kohn <[email protected]>.
+
+This Code of Conduct is adapted from the Contributor Covenant
+(https://contributor-covenant.org), version 1.2.0, available at
+https://contributor-covenant.org/version/1/2/0/
+
+### CNCF Events Code of Conduct
+
+CNCF events are governed by the Linux Foundation [Code of Conduct](https://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.

CONTRIBUTING.md

@@ -0,0 +1,95 @@
+# Contributing to notary
+
+## Before reporting an issue...
+
+### If your problem is with...
+
+ - automated builds
+ - your account on the [Docker Hub](https://hub.docker.com/)
+ - any other [Docker Hub](https://hub.docker.com/) issue
+
+Then please do not report your issue here - you should instead report it to [https://support.docker.com](https://support.docker.com)
+
+### If you...
+
+ - need help setting up notary
+ - can't figure out something
+ - are not sure what's going on or what your problem is
+
+Then please do not open an issue here yet - you should first try one of the following support forums:
+
+ - irc: #docker-trust on freenode
+
+## Reporting an issue properly
+
+By following these simple rules you will get better and faster feedback on your issue.
+
+ - search the bugtracker for an already reported issue
+
+### If you found an issue that describes your problem:
+
+ - please read other user comments first, and confirm this is the same issue: a given error condition might be indicative of different problems - you may also find a workaround in the comments
+ - please refrain from adding "same thing here" or "+1" comments
+ - you don't need to comment on an issue to get notified of updates: just hit the "subscribe" button
+ - comment if you have some new, technical and relevant information to add to the case
+
+### If you have not found an existing issue that describes your problem:
+
+ 1. create a new issue, with a succinct title that describes your issue:
+   - bad title: "It doesn't work with my docker"
+   - good title: "Publish fail: 400 error with E_INVALID_DIGEST"
+ 2. copy the output of:
+   - `notary version` or `docker version`
+ 3. Run `notary` or `docker` with the `-D` option for debug output, and please include a copy of the command and the output.
+ 4. If relevant, copy your `notaryserver` and `notarysigner` logs that show the error (this is likely the output from running `docker-compose up`)
+
+## Contributing a patch for a known bug, or a small correction
+
+You should follow the basic GitHub workflow:
+
+ 1. fork
+ 2. commit a change
+ 3. make sure the tests pass
+ 4. PR
+
+Additionally, you must [sign your commits](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work). It's very simple:
+
+ - configure your name with git: `git config user.name "Real Name" && git config user.email [email protected]`
+ - sign your commits using `-s`: `git commit -s -m "My commit"`
+
+Some simple rules to ensure quick merge:
+
+ - clearly point to the issue(s) you want to fix in your PR comment (e.g., `closes #12345`)
+ - prefer multiple (smaller) PRs addressing individual issues over a big one trying to address multiple issues at once
+ - if you need to amend your PR following comments, please squash instead of adding more commits
+ - if fixing a bug or adding a feature, please add or update the relevant `CHANGELOG.md` entry with your pull request number
+   and a description of the change
+
+## Contributing new features
+
+You are heavily encouraged to first discuss what you want to do. You can do so on the irc channel, or by opening an issue that clearly describes the use case you want to fulfill, or the problem you are trying to solve.
+
+If this is a major new feature, you should then submit a proposal that describes your technical solution and reasoning.
+If you did discuss it first, this will likely be greenlighted very fast. It's advisable to address all feedback on this proposal before starting actual work
+
+Then you should submit your implementation, clearly linking to the issue (and possible proposal).
+
+Your PR will be reviewed by the community, then ultimately by the project maintainers, before being merged.
+
+It's mandatory to:
+
+ - interact respectfully with other community members and maintainers - more generally, you are expected to abide by the [Docker community rules](https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines)
+ - address maintainers' comments and modify your submission accordingly
+ - write tests for any new code
+
+Complying to these simple rules will greatly accelerate the review process, and will ensure you have a pleasant experience in contributing code to the Registry.
+
+## Review and Development notes
+
+- All merges require LGTMs from any 2 maintainers.
+- We use the git flow model (as best we can) using the `releases` branch as the stable branch, and the `master` branch as the development branch.  When we get near a potential release, a release branch (`release/<semver>`) will be created from `master`.  Any PRs that should go into the release should be made against that branch.  Hotfixes for a minor release will be added to the branch `hotfix/<semver>`.
+
+## Vendoring new dependency versions
+
+We use [VNDR](https://github.com/LK4D4/vndr); please update `vendor.conf` with the new dependency or the new version, and run
+`vndr <top level package name>`.

GOVERNANCE.md

@@ -0,0 +1,107 @@
+# Notary Governance
+
+The following document outlines Notary project governance.
+
+## The Notary Project
+
+The Notary project consists of several repositories known as subprojects that enable community cohorts to experiment and implement solutions across the scope of the project.
+
+## Maintainers Structure
+
+There are two types of maintainers in the Notary project organized hierarchically. Notary org maintainers oversee the overall project and its health. Subproject maintainers focus on a single codebase or a group of related codebases. 
+
+Changes in maintainership have to be announced via an [issue](https://github.com/notaryproject/notaryproject/issues/new).
+
+### Maintainer Responsibility
+Notary maintainers adhere to the requirements and responsibilities set forth in the respective [Notary Org Maintainers](#notary-org-maintainers) and [Subproject Maintainers](#subproject-maintainers). They further pledge the following:
+* To act in the best interest of the project and subprojects at all times.
+* To ensure that project and subproject development and direction is a function of community needs.
+* To never take any action while hesitant that it is the right action to take.
+* To fulfill the responsibilities outlined in this document and its dependents.
+
+### Notary Org Maintainers
+
+The [Notary Org maintainers](MAINTAINERS) are responsible for:
+
+* Maintaining the mission, vision, values, and scope of the project
+* Refining the governance and charter as needed
+* Making project level decisions
+* Resolving escalated project decisions when the subproject maintainers responsible are blocked
+* Managing the Notary brand
+* Controlling access to Notary assets such as source repositories, hosting, project calendars
+* Deciding what subprojects are part of the Notary project
+* Deciding on the creation of new subprojects
+* Overseeing the resolution and disclosure of security issues
+* Managing financial decisions related to the project
+
+Changes to org maintainers use the following:
+
+* Any subproject maintainer is eligible for a position as an org maintainer
+* No one company or organization can employ a simple majority of the org maintainers
+* An org maintainer may step down by submitting an [issue](https://github.com/notaryproject/notaryproject/issues/new) stating their intent and they will be moved to emeritus.
+* Org maintainers MUST remain active on the project. If they are unresponsive for > 3 months they will lose org maintainership unless a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) of the other org maintainers agrees to extend the period to be greater than 3 months
+* Any eligible person may stand as an org maintainer by opening a [PR](https://github.com/notaryproject/notaryproject/pulls).
+* When a PR is opened the project maintainers may vote
+  * The voting period will be open for a minimum of three business days and will remain open until a super-majority of project maintainers has voted
+  * Only current org maintainers are eligible to vote via casting a single vote each via a -1/+1 comment on the nomination issue or approving in GitHub.
+  * Once a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) has been reached the maintainer elect must complete [onboarding](#onboarding-a-new-maintainer) prior to becoming an official Notary maintainer.
+  * Once the maintainer onboarding has been completed a pull request is made on the repo adding the new maintainer to the [MAINTAINERS](MAINTAINERS) file.
+* When an org maintainer steps down, they become an emeritus maintainer
+
+### Subproject Maintainers
+
+Subproject maintainers are responsible for activities surrounding the development and release of content (eg. code, specifications, documentation) or the tasks needed to execute their subproject (e.g., community management) within the designated repository, or repositories associated with the subproject (e.g., community management). Technical decisions for code resides with the subproject maintainers unless there is a decision related to cross maintainer groups that cannot be resolved by those groups. Those cases can be escalated to the org maintainers.
+
+Subprojects may be responsible for one or many repositories.
+
+Subproject maintainers do not need to be software developers. No explicit role is placed upon them and they can be anyone appropriate for the work being produced. For example, if a repository is for documentation it would be appropriate for maintainers to be technical writers.
+
+Changes to maintainers use the following:
+
+* A subproject maintainer may step down by submitting an [issue](https://github.com/notaryproject/notaryproject/issues/new) stating their intent and they will be moved to emeritus.
+* Maintainers MUST remain active. If they are unresponsive for > 6 months they will be automatically removed unless a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) of the other subproject maintainers agrees to extend the period to be greater than 6 months
+* Potential new maintainers should be ongoing active participants in the project
+* New maintainers can be added to a subproject by a [super-majority](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote) vote of the existing subproject maintainers
+* When a subproject has no maintainers the Notary org maintainers become responsible for it and may archive the subproject or find new maintainers
+
+### Onboarding a New Maintainer
+New Notary maintainers participate in an onboarding period during which they fulfill all code review and issue management responsibilities that are required for their role. The length of this onboarding period is variable, and is considered complete once both the existing maintainers and the candidate maintainer are comfortable with the candidate's competency in the responsibilities of maintainership. This process MUST be completed prior to the candidate being named an official Notary maintainer.
+
+The onboarding period is intended to ensure that the to-be-appointed maintainer is able/willing to take on the time requirements, familiar with core logic and concepts, understands the overall system architecture and interactions that comprise it, and is able to work well with both the existing maintainers and the community.
+
+## Decision Making at the Notary org level
+
+When maintainers need to make decisions there are two ways decisions are made, unless described elsewhere.
+
+The default decision making process is [lazy-consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus). This means that any decision is considered supported by the team making it as long as no one objects. Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. In the case of security critical decisions more explicit consensus may be needed.
+
+When a consensus cannot be found a maintainer can call for a [majority](https://en.wikipedia.org/wiki/Majority) vote on a decision.
+
+Many of the day-to-day project maintenance can be done by a lazy consensus model. But the following items must be called to vote:
+
+* Removing a maintainer for any reason other than inactivity (super majority)
+* Changing the governance rules (this document) (super majority)
+* Licensing and intellectual property changes (including new logos, wordmarks) (simple majority)
+* Adding, archiving, or removing subprojects (simple majority)
+* Utilizing Notary/CNCF money for anything CNCF deems "not cheap and easy" (simple majority)
+
+New subprojects should be created (or added) with a well defined mission and goals, and significant changes should be voted on by both the subproject maintainers and the org maintainers.
+
+Other decisions may, but do not need to be, called out and put up for decision via creating an [issue](https://github.com/notaryproject/notaryproject/issues/new) at any time and by anyone. By default, any decisions called to a vote will be for a _simple majority_ vote.
+
+Meetings should be publically documented (Slack, CNCF calendar etc), and recorded and notes kept. Meetings should have a chair, this is a rotating role not restricted to maintainers.
+
+## Code of Conduct
+
+This Notary project has adopted the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
+
+## Attributions
+
+* This governance model was created using both the [SPIFFE](https://github.com/spiffe/spire/blob/main/MAINTAINERS.md) and [Helm](https://github.com/helm/community/blob/main/governance/governance.md) governance documents.
+
+## DCO and Licenses
+
+The following licenses and contributor agreements will be used for Notary projects:
+
+* [Apache 2.0](https://opensource.org/licenses/Apache-2.0) for code
+* [Developer Certificate of Origin](https://developercertificate.org/) for new contributions

PROJECTS

@@ -0,0 +1,23 @@
+# These are the current projects under the overall Notary project umbrella
+
+## Notary
+
+Notary is the original project. It is an implementation of TUF that runs next to a container
+registry and adds the ability to sign and verify content in the registry. By default it makes
+some different security choices, such as using TOFU by default. As it runs next to a registry
+it is not a standard part of the registry protocol and requires independent storage and for
+clients to have different code to handle signed content.
+
+## Notation
+
+Notation is a project to add signatures as standard items in the registry ecosystem, and to
+build a set of simple tooling for signing and verifying these signatures. This should be
+viewed as similar in security to checking git commit signatures, although the signatures are
+generic and can be used for additional purposes.
+
+## TUF
+
+TUF is a project to implement the full TUF specification in a registry native way. This may
+require upstream TUF spec changes or extensions, as there are some differences between the
+registry model and common usage to other TUF use cases. This project will use existing
+registry extensions where available but may need its own document types in addition.