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
This commit is contained in:
Robert Watson
parent
6a06d8bb7c
commit
353f760ff7
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=45435
1 changed files with 58 additions and 35 deletions
|
|
@ -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>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>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>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>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>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>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>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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue