From owner-svn-doc-all@FreeBSD.ORG Mon Aug 11 10:53:52 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0199A74B for ; Mon, 11 Aug 2014 10:53:52 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DEDB3247D for ; Mon, 11 Aug 2014 10:53:51 +0000 (UTC) Received: from rwatson (uid 520) (envelope-from rwatson@FreeBSD.org) id 2b18 by svn.freebsd.org (DragonFly Mail Agent v0.9+); Mon, 11 Aug 2014 10:53:51 +0000 From: Robert Watson Date: Mon, 11 Aug 2014 10:53:51 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r45435 - head/en_US.ISO8859-1/htdocs/internal X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-Id: <53e8a0bf.2b18.5ab4408f@svn.freebsd.org> X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 10:53:52 -0000 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 @@ -

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.

- -

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.

- -

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.

- -

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.

- -

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.

- -

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.

- -

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.

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).

+ +

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.

+ +

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.

+ +

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.