svn commit: r45435 - head/en_US.ISO8859-1/htdocs/internal

Mon Aug 11 10:53:52 UTC 2014

Author: rwatson
Date: Mon Aug 11 10:53:51 2014
New Revision: 45435
URL: http://svnweb.freebsd.org/changeset/doc/45435

Log:
  Update somewhat stale and occasionally over-colloquial website guidance on
  new committer proposals to:
  
  - Provide more details on the contents of a suitable proposal, including
    a request for evidence of constructive engagement with the mentor (e.g.,
    through successfully completed patch cycles).
  - Be more overt about identifying community participation (but also more
    open about what it means -- mention BSD-conference talks, for example).
  - Suggest contacing core@ informally first if there are worries about
    whether there is sufficient contribution or concern about a proposal
    failing.
  - Expand thinking on 'vendor commit bits' -- both the responsibilities of
    the mentor, and also the hope that such contributors will broaden their
    interests over time.
  
  Approved by:	core

Modified:
  head/en_US.ISO8859-1/htdocs/internal/proposing-committers.xml

Modified: head/en_US.ISO8859-1/htdocs/internal/proposing-committers.xml
==============================================================================

--- head/en_US.ISO8859-1/htdocs/internal/proposing-committers.xml	Mon Aug 11 08:46:13 2014	(r45434)
+++ head/en_US.ISO8859-1/htdocs/internal/proposing-committers.xml	Mon Aug 11 10:53:51 2014	(r45435)
@@ -13,44 +13,67 @@
 
   <body class="navinclude.docs">
 
-<p>The following paragraphs contain an advice from &a.kib;, member of
-  the Core Team, who summarizes what constitutes a good proposal, how
-  you as potential mentor, could increase your chances to have your
-  mentee granted a commit bit.</p>
-
-<p>When proposing somebody, you should just forget for a moment that you
-  know the candidate personally.  After that, look unprejudiced on the
-  person's activity on the mailing lists, and evaluate the patches
-  submitted.</p>
-
-<p>Now, you can ask yourself, is it enough confidence in both technical
-  abilities and the social behavior of the candidate, from what you see
-  only on the media?  If you do, then write down the reasons why are
-  you sure, using the said list of the contributions as the evidence,
-  and do include the reasoning in the commit bit application.</p>
-
-<p>Due to several failures of the premature granting of commit bits, the
-  Core Team became quite sensitive to these criteria.  Most of the
-  members only see the activity of applicants on the lists, and not
-  seeing much there causes the cautious choice.</p>
-
-<p>The Core Team wants to see a good list of the work already done for
-  &os; (e.g., the long list of the commits, submitted by the applicant,
-  the list of PRs opened etc.), which can make us confident that the
-  person has an established interest in the project, backed by the
-  technical ability and work done.</p>
-
-<p>Also, the history of the good engagement with the community on the
-  public media, such as mailing list, is a deciding factor too.  The
-  Core Team wants to filter out the controversial personalities, since
-  it is almost impossible and highly undesirable to revoke the commit
-  bit, once granted.</p>
-
-<p>Vendor-proposed maintainers for the hardware drivers usually approved
-  without applying the listed criteria.  Still, the Core Team requires
-  an experienced mentor for a vendor committer to avoid unwanted tension
-  and to make sure that vendor commits follow the Project procedures and
-  community expectations.</p>
+<p>The following advice is intended for potential mentors in deciding 
+  whether a candidate might be suitable to propose for a commit bit, and 
+  in preparing a commit-bit proposal for consideration by the Core Team or 
+  its delegates. Note that in the case of delegated approval (e.g., to 
+  Portmgr or Doceng), additional procedures or constraints may apply 
+  (e.g., to the nature of the contribution).</p>
+
+<p>Commit-bit proposal reviewers will look for several key attributes from 
+  potential developers: strong technical abilities, a track record of 
+  contributions to the &os; Project, evidence of their ability to work 
+  independently within the community (i.e., that mentoring will not need 
+  to continue indefinitely), evidence of the ability of a developer to 
+  engage constructively with the &os; community (and in particular, 
+  have the social skills to navigate occasionally heated online debate), 
+  and a commitment to contribute to the project in the future. Typically, 
+  supporting material for a commit-bit proposal will include a description 
+  of the candidate's background and training/education, the context for 
+  their contributions to the project (e.g., as a volunteer, employee, 
+  etc), references to patches/PRs/commits justifying their contribution 
+  track record, pointers at mailing-list or other community participation 
+  (e.g., presentations at BSD conferences), a strong indication of 
+  constructive engagement with their mentor to date, and a list of 
+  interests and potential areas of continuing and future contribution.</p>
+
+<p>Potential mentors are reminded that it is far easier to grant commit 
+  access than revoke it, and hence significant weight is given to 
+  constructive interaction with the community, rather than simply 
+  technical contributions. If a mentor is uncertain as to whether a 
+  candidate is suitable, it may be sensible to initially contact the Core 
+  Team via an informal request for guidance rather than a formal proposal 
+  -- this might lead to advice to continue, requests for further 
+  supporting material, or the suggestion that a proposal should be 
+  deferred while further track record is accrued. It is hoped that 
+  requests to gain further experience or to generate additional evidence 
+  of community participation and contribution will be taken in the spirit 
+  that they are intended: granting of a commit bit is a significant action 
+  and based in large part on work performed, rather than simply strong 
+  technical abilities. The project would rather take a conservative 
+  approach in granting commit rights than grant them prematurely.</p>
+
+<p>In some cases, 'vendor commit bits' may be granted to allow direct 
+  commits to device drivers (or potentially other components) maintained 
+  by, for example, a device vendor. These may be held to a lower standard 
+  of past community involvement based on a strong commitment by the vendor 
+  and an experienced mentor, as well as limited charter to make changes in 
+  the system independently. It is extremely important that such commit 
+  bits be used with suitable discretion and awareness of community 
+  concerns; it is the responsibility of the mentor to ensure that no 
+  undesirable tension arises, and that changes are in keeping with project 
+  procedures and community expectations. If a commit bit is granted in 
+  this context, it may be revoked when the individual leaves their 
+  employer; however, there is also a substantial history of individuals 
+  with 'vendor commit bits' making more broad contributions and this is 
+  the hoped for outcome! Mentors proposing vendor commit bits should take 
+  all steps necessary to ensure that commit bits are granted only to 
+  individuals who can take responsibility for the quality and testing of 
+  contributions they make on behalf of the vendor, and have the necessary 
+  technical and social skills to engage constructively with the community. 
+  It is recommended that proposals for such bits contain to the greatest 
+  extent the same content as expected of ordinary commit bits, with a 
+  particular focus on quality of technical contribution.</p>
 
   </body>
 </html>
