None
As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary, or are funded to do, there is no overall strategy or prioritisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team.
The requirements of the project are given by developer wishes, requests from the community in terms of direct requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer are given to that developer who prioritises histheir time between the request and histheir wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All requests, their distribution and follow-up are handled by the <xref linkend="tool-bugzilla"/> tool.
Core announces the election and selects an election manager. He who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office.
When a committer has written a piece of code and wants to commit it, they first needs to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the maintainer, they should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and then deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, they can choose to implement or ignore the patch.
After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a <quote>Merge From Current</quote> ("MFC") countdown is set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be sent to the committer reminding hithem to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches.
When code is written by the developer that is non-trivial, they should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, they should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called <quote>pre-commit test</quote>. When contributed code is received, it should be reviewed by the committer and tested the same way.
The committing of new or modified code is one of the most frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a <quote>committer</quote>. Committers commit either code written by themselves, code submitted to them, or code submitted through a <link linkend="model-pr">problem report</link>.
When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If they recommends this to core, theycore will vote on this recommendation. If they vote is in favour, a mentor is assigned the new committer and the new committer has to email histheir details to the administrators for an account to be created. After this, the new committer is all set to make histheir first commit. By tradition, this is by adding histheir name to the committers list.
When a contributor is given histheir 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.
A mentor is a committer who takes it upon him/herthem 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 his/their work, and that the new committer knows what is expected of him/herthem in terms of behavior.
The Source Repository Manager is the only one who is allowed to directly modify the repository without using the <xref linkend="tool-svn"/> tool. It is his/their responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is necessary to resolve a SVN technical problem.
The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. They have the authority and responsibility for their area. The following illustrationlist shows the responsibility lines. After this follow and gives a description of each hat, including who it is held by.