diff options
| -rw-r--r-- | GOVERNANCE.md | 110 | ||||
| -rw-r--r-- | SECURITY.md | 2 |
2 files changed, 111 insertions, 1 deletions
diff --git a/GOVERNANCE.md b/GOVERNANCE.md new file mode 100644 index 000000000..ce6b2250c --- /dev/null +++ b/GOVERNANCE.md @@ -0,0 +1,110 @@ +# Governance + +## Projects + +A *project* is the primary unit of collaboration. Each project may have its own +repository and contribution process. + +All projects are covered by the [Code of Conduct](CODE_OF_CONDUCT.md), and +should include an up-to-date copy in the project repository or a link here. + +## Contributors + +Anyone can be a *contributor* to a project, provided they have signed relevant +Contributor License Agreements (CLAs) and follow the project's contribution +guidelines. Contributions will be reviewed by a maintainer, and must pass all +applicable tests. + +Reviews check for code quality and style, including documentation, and enforce +other policies. Contributions may be rejected for reasons unrelated to the code +in question. For example, a change may be too complex to maintain or duplicate +existing functionality. + +Note that contributions are not limited to code alone. Bugs, documentation, +experience reports or public advocacy are all valuable ways to contribute to a +project and build trust in the community. + +## Maintainers + +Each project has one or more *maintainers*. Maintainers set technical direction, +facilitate contributions and exercise overall stewardship. + +Maintainers have write access to the project repository. Maintainers review and +approve changes. They can also assign issues and add additional reviewers. + +Note that some repositories may not allow direct commit access, which is +reserved for administrators or automated processes. In this case, maintainers +have approval rights, and a separate process exists for merging a change. + +Maintainers are responsible for upholding the code of conduct in interactions +via project communication channels. If comments or exchanges are in violation, +they may remove them at their discretion. + +### Repositories requiring synchronization + +For some projects initiated by Google, the infrastructure which synchronizes and +merges internal and external changes requires that merges are performed by a +Google employee. In such cases, Google will initiate a rotation to merge changes +once they pass tests and are approved by a maintainer. This does not preclude +non-Google contributors from becoming maintainers, in which case the maintainer +holds approval rights and the merge is an automated process. In some cases, +Google-internal tests may fail and have to be fixed: the Google employee will +work with the submitter to achieve this. + +### Becoming a maintainer + +The list of maintainers is defined by the list of people with commit access or +approval authority on a repository, typically via a Gerrit group or a GitHub +team. + +Existing maintainers may elevate a contributor to maintainer status on evidence +of previous contributions and established trust. This decision is based on lazy +consensus from existing maintainers. While contributors may ask maintainers to +make this decision, existing maintainers will also pro-actively identify +contributors who have demonstrated a sustained track record of technical +leadership and direct contributions. + +## Special Interest Groups (SIGs) + +From time-to-time, a SIG may be formed in order to solve larger, more complex +problems across one or more projects. There are many avenues for collaboration +outside a SIG, but a SIG can provide structure for collaboration on a single +topic. + +Each group will be established by a charter, and governed by the Code of +Conduct. Some resources may be provided to the group, such as mailing lists or +meeting space, and archives will be public. + +## Security disclosure + +Projects may maintain security mailing lists for vulnerability reports and +internal project audits may occasionally reveal security issues. Access to these +lists and audits will be limited to project *maintainers*; individual +maintainers should opt to participate in these lists based on need and +expertise. Once maintainers become aware of a potential security issue, they +will assess the scope and potential impact. If reported externally, maintainers +will determine a reasonable embargo period with the reporter. + +During the embargo period, the maintainers will prioritize a fix for the +security issue. They may choose to disclose the issue to additional trusted +contributors in order to facilitate a fix, subjecting them to the embargo, or +notify affected users in order to give them an advanced opportunity to mitigate +the issue. The inclusion of specific users in this disclosure is left to the +discretion of the maintainers and contributors involved, and depends on the +scale of known project use and exposure. + +Once a fix is widely available or the embargo period ends, the maintainers will +make technical details about the vulnerability and associated fixes available. + +## Mailing lists + +There are four key mailing lists that span projects. + +* [gvisor-users](mailto:gvisor-users@googlegroups.com): general purpose user list. +* [gvisor-dev](mailto:gvisor-dev@googlegroups.com): general purpose development list. +* [gvisor-security](mailto:gvisor-security@googlegroups.com): private security list. + Access to this list is restricted to maintainers of the core gVisor project, + subject to the security disclosure policy described above. +* [gvisor-syzkaller](mailto:gvisor-syzkaller@googlegroups.com): private syzkaller bug + tracking list. Access to this list is not limited to maintainers, but will + be granted to those who can credibly contribute to fixes. diff --git a/SECURITY.md b/SECURITY.md index 154d68cb3..82cd0efb8 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -5,7 +5,7 @@ the [gvisor-security mailing list][gvisor-security-list]. You should receive a prompt response, typically within 48 hours. Policies for security list access, vulnerability embargo, and vulnerability -disclosure are outlined in the [community][community] repository. +disclosure are outlined in the [governance policy](GOVERNANCE.md). [community]: https://gvisor.googlesource.com/community [gvisor-security-list]: https://groups.google.com/forum/#!forum/gvisor-security |