github.com/SagerNet/gvisor@v0.0.0-20210707092255-7731c139d75c/GOVERNANCE.md (about)

     1  # Governance
     2  
     3  ## Projects
     4  
     5  A *project* is the primary unit of collaboration. Each project may have its own
     6  repository and contribution process.
     7  
     8  All projects are covered by the [Code of Conduct](CODE_OF_CONDUCT.md), and
     9  should include an up-to-date copy in the project repository or a link here.
    10  
    11  ## Contributors
    12  
    13  Anyone can be a *contributor* to a project, provided they have signed relevant
    14  Contributor License Agreements (CLAs) and follow the project's contribution
    15  guidelines. Contributions will be reviewed by a maintainer, and must pass all
    16  applicable tests.
    17  
    18  Reviews check for code quality and style, including documentation, and enforce
    19  other policies. Contributions may be rejected for reasons unrelated to the code
    20  in question. For example, a change may be too complex to maintain or duplicate
    21  existing functionality.
    22  
    23  Note that contributions are not limited to code alone. Bugs, documentation,
    24  experience reports or public advocacy are all valuable ways to contribute to a
    25  project and build trust in the community.
    26  
    27  ## Maintainers
    28  
    29  Each project has one or more *maintainers*. Maintainers set technical direction,
    30  facilitate contributions and exercise overall stewardship.
    31  
    32  Maintainers have write access to the project repository. Maintainers review and
    33  approve changes. They can also assign issues and add additional reviewers.
    34  
    35  Note that some repositories may not allow direct commit access, which is
    36  reserved for administrators or automated processes. In this case, maintainers
    37  have approval rights, and a separate process exists for merging a change.
    38  
    39  Maintainers are responsible for upholding the code of conduct in interactions
    40  via project communication channels. If comments or exchanges are in violation,
    41  they may remove them at their discretion.
    42  
    43  ### Repositories requiring synchronization
    44  
    45  For some projects initiated by Google, the infrastructure which synchronizes and
    46  merges internal and external changes requires that merges are performed by a
    47  Google employee. In such cases, Google will initiate a rotation to merge changes
    48  once they pass tests and are approved by a maintainer. This does not preclude
    49  non-Google contributors from becoming maintainers, in which case the maintainer
    50  holds approval rights and the merge is an automated process. In some cases,
    51  Google-internal tests may fail and have to be fixed: the Google employee will
    52  work with the submitter to achieve this.
    53  
    54  ### Becoming a maintainer
    55  
    56  The list of maintainers is defined by the list of people with commit access or
    57  approval authority on a repository, typically via a Gerrit group or a GitHub
    58  team.
    59  
    60  Existing maintainers may elevate a contributor to maintainer status on evidence
    61  of previous contributions and established trust. This decision is based on lazy
    62  consensus from existing maintainers. While contributors may ask maintainers to
    63  make this decision, existing maintainers will also pro-actively identify
    64  contributors who have demonstrated a sustained track record of technical
    65  leadership and direct contributions.
    66  
    67  ## Special Interest Groups (SIGs)
    68  
    69  From time-to-time, a SIG may be formed in order to solve larger, more complex
    70  problems across one or more projects. There are many avenues for collaboration
    71  outside a SIG, but a SIG can provide structure for collaboration on a single
    72  topic.
    73  
    74  Each group will be established by a charter, and governed by the Code of
    75  Conduct. Some resources may be provided to the group, such as mailing lists or
    76  meeting space, and archives will be public.
    77  
    78  ## Security disclosure
    79  
    80  Projects may maintain security mailing lists for vulnerability reports and
    81  internal project audits may occasionally reveal security issues. Access to these
    82  lists and audits will be limited to project *maintainers*; individual
    83  maintainers should opt to participate in these lists based on need and
    84  expertise. Once maintainers become aware of a potential security issue, they
    85  will assess the scope and potential impact. If reported externally, maintainers
    86  will determine a reasonable embargo period with the reporter.
    87  
    88  During the embargo period, the maintainers will prioritize a fix for the
    89  security issue. They may choose to disclose the issue to additional trusted
    90  contributors in order to facilitate a fix, subjecting them to the embargo, or
    91  notify affected users in order to give them an advanced opportunity to mitigate
    92  the issue. The inclusion of specific users in this disclosure is left to the
    93  discretion of the maintainers and contributors involved, and depends on the
    94  scale of known project use and exposure.
    95  
    96  Once a fix is widely available or the embargo period ends, the maintainers will
    97  make technical details about the vulnerability and associated fixes available.
    98  
    99  ## Mailing lists
   100  
   101  There are four key mailing lists that span projects.
   102  
   103  *   [gvisor-users](mailto:gvisor-users@googlegroups.com): general purpose user
   104      list.
   105  *   [gvisor-dev](mailto:gvisor-dev@googlegroups.com): general purpose
   106      development list.
   107  *   [gvisor-security](mailto:gvisor-security@googlegroups.com): private security
   108      list. Access to this list is restricted to maintainers of the core gVisor
   109      project, subject to the security disclosure policy described above.
   110  *   [gvisor-syzkaller](mailto:gvisor-syzkaller@googlegroups.com): private
   111      syzkaller bug tracking list. Access to this list is not limited to
   112      maintainers, but will be granted to those who can credibly contribute to
   113      fixes.