svn commit: r45435 - head/en_US.ISO8859-1/htdocs/internal
Robert Watson <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"