os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update somewhat stale and occasionally over-colloquial website guidance on

Browse source 
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 2014-08-11 10:53:51 +00:00
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
Download patch file Download diff file Expand all files Collapse all files

93
en_US.ISO8859-1/htdocs/internal/proposing-committers.xml
View file

@ -13,44 +13,67 @@
<body class="navinclude.docs"> <body class="navinclude.docs">
<p>The following paragraphs contain an advice from &a.kib;, member of <p>The following advice is intended for potential mentors in deciding
the Core Team, who summarizes what constitutes a good proposal, how whether a candidate might be suitable to propose for a commit bit, and
you as potential mentor, could increase your chances to have your in preparing a commit-bit proposal for consideration by the Core Team or
mentee granted a commit bit.</p> 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 <p>Commit-bit proposal reviewers will look for several key attributes from
know the candidate personally. After that, look unprejudiced on the potential developers: strong technical abilities, a track record of
person's activity on the mailing lists, and evaluate the patches contributions to the &os; Project, evidence of their ability to work
submitted.</p> 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 <p>Potential mentors are reminded that it is far easier to grant commit
abilities and the social behavior of the candidate, from what you see access than revoke it, and hence significant weight is given to
only on the media? If you do, then write down the reasons why are constructive interaction with the community, rather than simply
you sure, using the said list of the contributions as the evidence, technical contributions. If a mentor is uncertain as to whether a
and do include the reasoning in the commit bit application.</p> 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 <p>In some cases, 'vendor commit bits' may be granted to allow direct
Core Team became quite sensitive to these criteria. Most of the commits to device drivers (or potentially other components) maintained
members only see the activity of applicants on the lists, and not by, for example, a device vendor. These may be held to a lower standard
seeing much there causes the cautious choice.</p> 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
<p>The Core Team wants to see a good list of the work already done for the system independently. It is extremely important that such commit
&os; (e.g., the long list of the commits, submitted by the applicant, bits be used with suitable discretion and awareness of community
the list of PRs opened etc.), which can make us confident that the concerns; it is the responsibility of the mentor to ensure that no
person has an established interest in the project, backed by the undesirable tension arises, and that changes are in keeping with project
technical ability and work done.</p> procedures and community expectations. If a commit bit is granted in
this context, it may be revoked when the individual leaves their
<p>Also, the history of the good engagement with the community on the employer; however, there is also a substantial history of individuals
public media, such as mailing list, is a deciding factor too. The with 'vendor commit bits' making more broad contributions and this is
Core Team wants to filter out the controversial personalities, since the hoped for outcome! Mentors proposing vendor commit bits should take
it is almost impossible and highly undesirable to revoke the commit all steps necessary to ensure that commit bits are granted only to
bit, once granted.</p> individuals who can take responsibility for the quality and testing of
contributions they make on behalf of the vendor, and have the necessary
<p>Vendor-proposed maintainers for the hardware drivers usually approved technical and social skills to engage constructively with the community.
without applying the listed criteria. Still, the Core Team requires It is recommended that proposals for such bits contain to the greatest
an experienced mentor for a vendor committer to avoid unwanted tension extent the same content as expected of ordinary commit bits, with a
and to make sure that vendor commits follow the Project procedures and particular focus on quality of technical contribution.</p>
community expectations.</p>
</body> </body>
</html> </html>