Source string Read only

(itstool) path: section/para
89/890
Context English State
Donations Liaison Officer
The task of the donations liaison officer is to match the developers with needs with people or organisations willing to make a donation.
Hat held by: the Donations Liaison Office <email>donations@FreeBSD.org</email>. The <link xlink:href="https://www.freebsd.org/donations/"> Donations Liaison Charter</link>.
Admin
(Also called <quote>FreeBSD Cluster Admin</quote>)
The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers.
Hat held by: the Admin team <email>admin@FreeBSD.org</email>.
Process dependent hats
Report originator
The person originally responsible for filing a Problem Report.
Bugbuster
A person who will either find the right person to solve the problem, or close the PR if it is a duplicate or otherwise not an interesting one.
Mentor
A mentor is a committer who takes it upon them to introduce a new committer to the project, both in terms of ensuring the new committer's setup is valid, that the new committer knows the available tools required in their work, and that the new committer knows what is expected of them in terms of behavior.
Vendor
The person(s) or organisation whom external code comes from and whom patches are sent to.
Reviewers
People on the mailing list where the request for review is posted.
Processes
The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases.
Adding new and removing old committers
The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges.
Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected.
If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer.
When a contributor is given committer status, they are assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon themselves to be the new committers mentor.
When a contributor is given their commit bit, a <xref linkend="tool-pgp"/>-signed email is sent from either <xref linkend="role-core-secretary"/>, <xref linkend="role-ports-manager"/>, or nik@freebsd.org to both admins@freebsd.org, the assigned mentor, the new committer, and core confirming the approval of a new account. The mentor then gathers a password line, <xref linkend="tool-ssh2"/> public key, and PGP key from the new committer and sends them to <xref linkend="role-admin"/>. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process.
Process summary: adding a new committer
_ external ref='proc-add-committer' md5='__failed__'
<imageobject><imagedata fileref="proc-add-committer"/></imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject><phrase>Refer to paragraph below for a screen-reader friendly version.</phrase> </textobject>
When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If they recommend this to core, core will vote on this recommendation. If the vote is in favour, a mentor is assigned the new committer and the new committer has to email their details to the administrators for an account to be created. After this, the new committer is all set to make their first commit. By tradition, this is by adding their name to the committers list.
Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. <citation><xref linkend="freebsd-expiration-policy"/></citation> There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see <link linkend="process-reactions">section 1.5.8</link>.

Loading…

No matching activity found.

Browse all component changes

Things to check

Unpluralised

The string is used as plural, but not using plural forms

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: section/para
Flags
read-only
Source string location
book.translate.xml:1400
String age
a year ago
Source string age
a year ago
Translation file
books/dev-model.pot, string 224