General
Basil server is the open source project through which Basil-project group is releasing the technology for the functionality of web servers. Basil is a new project that was founded on free lance base. Basil is the name of the overall project and is being hosted by BitterNet.

Basil-project's three main features are:

downloadable sources and information
the community and communication mechanisms for the project
the governance body called the Basil-project team.

The Basil-project establishes the necessary facilities to make this open source technology available to the developer community. This project web site currently includes informational resources and discussion forums.

The following chapter describe guidelines regarding technical roles and responsibilities at Basil-project and handling of source code. Substantial enhancements or modifications of these guidelines need approval of 2/3 majority of Project Leads.

Roles and Responsibilities
The roles and responsibilities that people can assume in the project are based on merit. Everybody can help no matter what their role. Those who have been long term and valuable contributors to the project obtain the right to commit directly to the source repository.

Users
Users are the people who use the products of the Project. People in this role aren't contributing code, but they are using the products, reporting bugs, making feature requests, and such. This is by far the most important category of people as, without users, there is no reason for the Project. When a user starts to contribute code or documentation patches, they become a developer.

Developers
Developers are the people who write code or documentation patches or contribute positively to the project in other ways. A developer's contribution is always recognized. In source code, all developers who contribute to a source file may add their name to the list of contributors for that file.

Committers
Developers who give frequent and valuable contributions to a project can have their status promoted to that of a "Committer" for that project. A Committer has write access to the source code repository.

In order for a Developer to become a Committer, another Committer can nominate that Developer. The Project Lead may convert the Developer into a Committer and give write access to the source code repository for his project.

At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose his or her status as a Committer. In this case or if value of contributions of a Committer decreases write access may also be revoked by the responsible Project Lead.

A committed change must be reversed if this is asked by the responsible Project Lead or the majority of all Project Leads and the conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The situation must be rescinded before the change can be included in any public release.

Project Leads
Long term Committers with actual involvement in developing code, deep knowledge in the working area of question and Basil-project as a whole and proven leadership skills can be nominated as Project Lead. A Project Lead is responsible for giving guidance and directions for his project and it's part of the Basil-project effort. He especially should make sure that questions about his project are answered and contributions/issues are handled.

Nominated by Committers a candidate may be approved by 2/3 majority of Project Leads as an Project Lead for a new project or an orphaned, existing project.

Loss of Project Lead status may not only occur due to contribution inactivity (as described for Committers) but also because of missing fulfilment of responsibilities for the project the Project Lead is in charge of. A 2/3 majority of Project Leads may revoke Project Lead status.

A list of our current Project Leads can be found in the list of projects.

Sources
The codebase is maintained in shared information repositories. Only Committers have write access to these repositories. Everyone has read access via Web-interface.

All source code committed to the Project's repositories must be covered by GPL. Developers of source code larger than small changes must have contact for the Project Leads for their contribution can be committed to the repository.

Straightforward patches and feature implementations can be committed without prior notice or discussion. Doubtful changes and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics, function, configuration data or other major areas must receive approval. A Project Lead may informally approve changes within their project.

There are three different types of changes:

info
Informational notice about an API change, no developer action necessary.

recommended
Use the new API as soon as possible. The old API is obsolete and might go away in the near future. New code should always use the new API.

required
Not complying to the new API will break the build or cause runtime failure. Developer action is mandatory.

Proposals for inter-project changes of type "recommended" or "required" must be published with the suggested change date to the interface discussion mailing list. Earliest after one week for review a change announcement must be published to the interface announce mailing list. During this announcement period depending projects have to prepare their projects for the changes so that the following build will not break. They are responsible for reflecting the change in their project, not the requester. Within the two weeks of discussion/announcement Project Leads may raise a flag and Project Leads majority has to decide about cancellation of the change request.

A committed change must be reversed if this is asked by the responsible Project Lead or the majority of all Project Leads and the conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The situation must be rescinded before the change can be included in any public release.