1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
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.
|
