353f760ff7
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
79 lines
4.5 KiB
XML
79 lines
4.5 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
|
|
"http://www.FreeBSD.org/XML/share/xml/xhtml10-freebsd.dtd" [
|
|
<!ENTITY title "Proposing Committers">
|
|
]>
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<title>&title;</title>
|
|
|
|
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
|
|
</head>
|
|
|
|
<body class="navinclude.docs">
|
|
|
|
<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>
|