Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
查找文件 普通视图历史永久链接Permalink
governance.html.in 14.1 KB
Newer Older
D
Write up the project governance process  
Daniel P. Berrange 已提交
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 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <body>
    <h1>Project governance</h1>

    <ul id="toc"></ul>

    <p>
      The libvirt project operates as a meritocratic, consensus-based community.
      Anyone with an interest in the project can join the community, contributing
      to the ongoing development of the project's work. This pages describes how
      that participation takes place and how contributors earn merit, and thus
      influence, within the community.
    </p>

    <h2><a name="codeofconduct">Code of conduct</a></h2>

    <p>
      The libvirt project community covers people from a wide variety of
      countries, backgrounds and positions. This global diversity is a great
      strength of the project, but can also lead to communication issues,
      which may in turn cause unhappiness. To maximise happiness of the
      project community taken as a whole, all members (whether users,
      contributors or committers) are expected to abide by the project's
      code of conduct. At a high level the code can be summarized as
      <em>"be excellant to each other"</em>. Expanding on this:
    </p>

    <ul>
      <li><strong>Be respectful:</strong> disagreements between people are to
        be expected and are usually the sign of healthy debate and engagement.
        Disagreements can lead to frustration and even anger for some members.
        Turning to personal insults, intimidation or threatening behaviour does
        not improve the situation though. Participants should thus take care to
        ensure all communications / interactions stay professional at all times.</li>

      <li><strong>Be considerate:</strong> remember that the community has members
        with a diverse background many of whom have English as a second language.
        What might appear impolite, may simply be a result of a lack of knowledge
        of the English language. Bear in mind that actions will have an impact
        on other community members and the project as a whole, so take potential
        consequences into account before pursuing a course of action.</li>

      <li><strong>Be forgiving:</strong> humans are fallible and as such prone
        to make mistakes and inexplicably change their positions at times. Don't
        assume that other members are acting with malicious intent. Be prepared
        to forgive people who make mistakes and assist each other in learning
        from them. Playing a blame game doesn't help anyone.</li>
    </ul>

    <h2><a name="roles">Roles and responsibilities</a></h2>

    <h3><a href="users">Users</a></h3>

    <p>
      The users are anyone who has a need for the output of the project.
      There are no rules or requirements to become a user of libvirt. Even
      if the software does not yet work on their OS platform, a person can
      be considered a potential future user and welcomed to participate.
    </p>

    <p>
      Participation by users is key to ensuring the project moves in the
      right direction, satisfying their real world needs. Users are
      encouraged to participate in the broader libvirt community in any
      number of ways:
    </p>

    <ul>
      <li>Evangelism: spread the word about what libvirt is doing, how it
        helps solve your problems. This can be via blog articles, social
        media postings, video blogs, user group / conference presentations
        and any other method of disseminating information</li>
      <li>Feedback: let the developers know about what does and does not
        work with the project. Talk to developers on the project's
        IRC channel and mailing list, or find them at conferences. Tell
        them what gaps the project has or where they should look for
        future development</li>
      <li>Moral support: developers live for recognition of the positive
        impact their work has on users' lives. Give thanks to the developers
        when evangelising the project, or when meeting them at user groups,
        conferences, etc.</li>
    </ul>

    <p>
      The above is not an exhaustive list of things users can do to
      participate in the project. Further ideas and suggestions are
      welcome. Users are encouraged to take their participation
      further and become contributors to the project in any of the
      ways listed in the next section.
    </p>

    <h3><a name="contributors">Contributors</a></h3>

    <p>
      The contributors are community members who have some concrete impact
      to the ongoing development of the project. There are many ways in which
      members can contribute, with no requirement to be a software engineer.
      Many users can in fact consider themselves contributors merely by
      engaging in evangelism for the project.
    </p>

    <ul>
      <li>Bug reporting: improve the quality of the project by reporting
        any problems found either to the project's own bug tracker, or to
        that of the OS vendor shipping the libvirt code.</li>
      <li>User help: join the <a href="contact.html">IRC channel or mailing list</a>
        to assist or advice other users in troubleshooting the problems they face.</li>
      <li>Feature requests: help set the direction for future work by
        reporting details of features which are missing to the project's
        own bug tracker or mailing lists.</li>
      <li>Graphical design: contribute to the development of the project's
        websites / wiki brand with improved graphics, styling or layout.</li>
      <li>Code development: write and submit patches to address bugs or implement
        new features</li>
      <li>Architectural design: improve the usefulness of the project
        by providing feedback on the design of proposed features, to
        ensure they satisfy the broadest applicable needs and survive
        the long term</li>
      <li>Code review: look at patches which are submitted and critique
        the code to identify bugs, potential design problems or other
        issues which should be addressed before the code is accepted</li>
      <li>Documentation: contribute to content on personal blogs, the
        website, wiki, code comments, or any of the formal documentation
        efforts.</li>
      <li>Translation: join the Fedora transifex community to improve the
        quality of translations needed by the libvirt project.</li>
      <li>Testing: try proposed patches or release candidates and report
        whether the build passes and the changes work as expected.</li>
    </ul>

    <p>
      The above is not an exhaustive list of things members can do to
      contribute to the project. Further ideas and suggestions are
      welcome.
    </p>

    <p>
      There are no special requirements to becoming a contributor other
      than having the interest and ability to provide a contribution. The
      libvirt project <strong>does not require</strong> any
      <em>"Contributor License Agreement"</em>
      to be signed prior to engagement with the community.
    </p>

    <p>
      In making a contribution to the project, the community member is
      implicitly stating that they accept the terms of the license under
      which the work they are contributing to is distributed. They are
      also implicitly stating that they have the legal right to make the
      contribution, if doing so on behalf of a broader organization /
      company. Most of the project's code is distributed under the GNU
      Lesser General Public License, version 2 or later. Details of the
      exact license under which contributions will be presumed to be
      covered are found in the source repositories, or website in question.
    </p>

    <h3><a name="committers">Committers</a></h3>

    <p>
      The committers are the subset of contributors who have direct access
      to commit code to the project's primary source code repositories, which
      are currently using the GIT software. The committers are chosen based
      on the quality of their contributions over a period of time. This includes
      both the quality of code they submit, as well as the quality of reviews
      they provide on other contributors' submissions and a demonstration that
      they understand day-to-day operation of the project and its goals. There
      is no minimum level of contribution required in order to become a committer,
      though 2-3 months worth of quality contribution would be a rough guide.
    </p>

    <p>
      There are no special requirements to becoming a committer other than to
      have shown a willingness and ability to contribute to the project over
      an extended period of time. Proposals for elevating contributors to
      committers are typically made by existing committers, though contributors
      are also welcome to make proposals. The decision to approve the elevation
      of a contributor to a committer is made through "rough consensus" between
      the existing committers.
    </p>

    <p>
      The aim in elevating contributors to committers is to ensure that there
      is a broad base of experience and expertize across all areas of the
      project's work. Committers are not required to have knowledge across
      all areas of the project's work. While an approved committer has the
      technical ability to commit code to any area of the project, by convention
      they will only commit to areas they feel themselves to be qualified to
      evaluate the contribution. If in doubt, committers will defer to the
      opinion of other committers with greater expertize in an area.
    </p>

    <p>
      The committers hold the ultimate control over what contributions are
      accepted by the project, however, this does not mean they have the
      right to do whatever they want. Where there is debate and disagreement
      between contributors, committers are expected to look at the issues with
      an unbiased point of view and help achieve a "rough consensus". If the
      committer has a conflict of interest in the discussion, for example due
      to their position of employment, they are expected to put the needs of
      the community project first. If they cannot put the community project
      first, they must declare their conflict of interest, and allow other
      non-conflicted committers to make any final decision.
    </p>

    <p>
      The committers are expected to monitor contributions to areas of the
      project where they have expertize and ensure that either some form of
      feedback is provided to the contributor, or to accept their contribution.
      There is no formal minimum level of approval required to accept a
      contribution. Positive review by any committer experienced in the area
      of work is considered to be enough to justify acceptance in normal
      circumstances. Where one committer explicitly rejects a contribution,
      however, other committers should not override that rejection without
      first establishing a "rough consensus" amongst the broader group of
      committers.
    </p>

    <p>
      Being a committer is a privilege, not a right. In exceptional
      circumstances, the privilege may be removed from an active
      contributor. Such decisions will be taken based on "rough
      consensus" amongst other committers. In the event that a committer
      is no longer able to participate in the project, after some period
      of inactivity passes, they may be asked to confirm that they wish
      to retain their role as a committer.
    </p>

    <h3><a name="secteam">Security team</a></h3>

    <p>
      The security team consists of a subset of the project committers
      along with representatives from vendors shipping the project's
      software. The subset of project committers is chosen to be the
      minimal size necessary to provide expertise spanning most of
      the project's work. Further project committers may be requested
      to engage in resolving specific security issues on a case by
      case basis. Any vendor who is shipping the project's software
      may submit a request for one or more of their representatives
      to join the security team. Such requests must by approved by
      existing members of the team vouching for the integrity of
      the nominated person or organization.
    </p>

    <p>
      Members of the security team are responsible for triaging and
      resolving any security issues that are reported to the project.
      They are expected to abide by the project's documented
      <a href="securityprocess.html">security process</a>. In particular
      they must respect any embargo period agreed amongst the team
      before disclosing a private issue.
    </p>

    <h2><a name="roughconsensus">Rough consensus</a></h2>

    <p>
      A core concept for governance of the project described above is
      that of "rough consensus". To expand on this, it is a process
      of decision making that involves the following steps
    </p>

    <ul>
      <li>Proposal</li>
      <li>Discussion</li>
      <li>Vote (exceptional circumstances only)</li>
      <li>Decision</li>
    </ul>

    <p>
      To put this into words, any contributor is welcome to make a proposal
      for consideration. Any contributor may participate in the discussions
      around the proposal. The discussion will usually result in agreement
      between the interested parties, or at least agreement between the
      committers. Only in the very exceptional circumstance where there
      is disagreement between committers, would a vote be considered.
      Even in these exceptional circumstances, it is usually found to be
      obvious what the majority opinion of the committers is. In the event
      that even a formal vote is tied, the committers will have to hold
      ongoing discussions until the stalemate is resolved or the proposal
      withdrawn.
    </p>

    <p>
      The overall goal of the "rough consensus" process is to ensure that
      decisions can be made within the project, with a minimum level of
      bureaucracy and process. Implicit in this is that any person who does
      not explicitly reject to a proposal is assumed to be supportive, or
      at least agnostic.
    </p>


  </body>
</html>