The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: listitem/para
Context English State
I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document.
Andrey A. Chernov <email></email>
Bruce A. Mah <email></email>
Dag-Erling Smørgrav <email></email>
Giorgos Keramidas<email></email>
Ingvil Hovig <email></email>
Jesper Holck<email></email>
John Baldwin <email></email>
John Polstra <email></email>
Kirk McKusick <email></email>
Mark Linimon <email></email>
Marleen Devos
Niels Jørgenssen<email></email>
Nik Clayton <email></email>
Poul-Henning Kamp <email></email>
Simon L. Nielsen <email></email>
A project model is a means to reduce the communications overhead in a project. As shown by <citation><xref linkend="brooks"/></citation>, increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project.
During the Core elections in 2002, Mark Murray stated <quote>I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs.</quote> <citation><xref linkend="bsd-election2002"/></citation>. This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works.
The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper <citation><xref linkend="jorgensen2001"/></citation>, FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers.
After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project.
<citation><xref linkend="freebsd-developer-handbook"/>, Section 1.2 and 1.3</citation> give the vision and the architectural guidelines for the project. The vision is <quote>To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability.</quote> The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project
An <quote>activity</quote> is an element of work performed during the course of a project <citation><xref linkend="ref-pmbok"/></citation>. It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery.
A <quote>process</quote> is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design.
A <quote>hat</quote> is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project.
An <quote>outcome</quote> is the final output of the process. This is synonymous with deliverable, that is defined as <quote>any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer</quote> by <citation><xref linkend="ref-pmbok"/></citation>. Examples of outcomes are a piece of software, a decision made or a report written.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: listitem/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/dev-model.pot, string 34