Proposing Committers

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