Development Team/policy

This document describes how DareNET's Development Team should function. The formal procedures it uses, the positions of the people it is composed of and the tasks it should accomplish. Once approved, it will become the reference set of rules used by the team.

Tasks

The DareNET Development Team (hereafter called dev-team or simply 'the team') is in charge of maintaining, debugging, upgrading and improving the code for its various projects, which presently include: ircd-darenet, services-darenet, plugins-darenet, website-darenet and webchat-darenet. The team may also oversee additional projects where considered desirable by DareNET's Executive Board.

It is formally accepted that any material (code and documentation) produced by the team is considered to be closed source, and is not to be distributed outside of DareNET. Should a decision be made to release any said material, it must be released under the GNU General Public License (GPL). What is not GPL is beyond the scope of the team and is released and maintained elsewhere.

Similarly, it must be clear, and understood by all team members, that the main scope of the team is to develop the code for use by DareNET, so only those changes, features or services used by DareNET are part of the work of the team.

Goals

The major goals of the team are (in descending order of priority):

• Diagnosing and removing bugs in the current code.
• Improving the performance of the code used for DareNET.
• Making the code base more stable, more consistent and likewise, more maintainable.
• Documenting both existing and newly written code (e.g. using Doxygen-compatible comments).
• Adding services and features while keeping backwards compatibility with existing servers, clients and formal or informal standards.
• Developing new features for client use in cooperation with the developers of the major clients.

Members

The team has different kinds of members with distinct roles: a manager, project maintainers, a small group of senior coders and a group of contributors (hopefully/eventually).

Development Manager

The manager oversees the entire team, including its various projects and members. While it is mostly an administrative position, he or she (hereafter labeled "he" for brevity, not sexism) must be at least a project maintainer. The manager ensures projects meet any established deadlines, and handles any disciplinary issues that may arise.

Project Maintainers

Each project is lead by a maintainer. It is the maintainer's responsibility to ensure the integrity of the code base. He must be an experienced coder and know the internals of the project in detail.

The maintainer is responsible for maintaining and administering the SVN repository. It is one of his major duties to keep things synced, and to verify that any change doesn't break the code or protocol. The maintainer, of course, may attempt to reduce his workload by distributing what can be delegated to other coders.

The maintainer's decisions about actual coding matters take place with a "silent agreement" procedure, provided there are no objections, and temporarily hold if a form vote is later held.

Senior Coders

Each project may have a group of senior coders. These individuals are the most experienced and trusted coders that put forward the biggest effort into the project. They are the only other members of the project that may have commit access to the SVN repository. The manager and project maintainers are implicitly senior coders.

Contributors

Everyone willing to contribute to the work of the team can be a contributor.

Contributors do not have commit access to the repositories, and they can't submit patches directly to the project maintainers (if there are other senior coders on the project). Instead, they must follow the specific procedure for submitting patches, described below, in order to save some of the maintainer's time when checking patches.

Tasks of the contributors include:

• Trying to help those who have trouble running or compiling the daemon, or answering the easier questions asked on the forums.
• Replying to those who make fuzzy feature requests on the forums, and eventually trying to interpret such requests and finding out if/how they can become realistic proposals.
• Working on documentation.
• Submitting patches.

Communication

Each project may devise its own means of communicating with each other; however, a development forum and channel are provided for all team members to keep informed.

Development Forum

All team members have access to the development forum, located on the DareNET web site. Anything may be discussed here, and is also where informal votes may be held.

A contributor can be given access to the development forum, after recommendation by a senior coder, and that would happen after an informal vote, pending no objections by other senior coders.

#Dev

#Dev will be the team's official IRC channel. It is recommended that members of all projects join the channel to allow for easy cross-project discussion and interaction.

Procedures

Procedures for the tasks of the team should be kept as simple and informal as possible, leaving projects to devise their own; however, a minimum number of organizational details and formalities are needed to keep control.

Any decision taken by the team follows one of these three paths:

• silent agreement
• informal voting
• formal voting

The idea is that if there are no severe objections for something, it can be decided with silent agreement (that is, agreement is not reached if there are any objections). If some objection arises, an informal vote is asked by the maintainer on the forums, and only as a last resort and/or for really major decisions the manager may issue a formal cfv.

Moreover, most common actions of the team should follow a defined procedural path, thought to simplify things and improve the stability of the code produced, its consistency and the cooperation within the group.

The procedures for common tasks are described below, and following that are the descriptions of the procedures and exact definitions of "silent agreement," "formal voting," and "informal voting."

Nomination of Senior Coders

Senior coders are those who are extremely confident with the code base internals for their project, have proven to be productive in terms of patches and actual contributions to the code, are trusted by the project's maintainer, and have proven to be capable of cooperatively working together with the rest of the group.

The core group constituted by the senior coders must be kept small, and the only thing that any contributor cannot do is vote on the critical decisions of the Development Team, thus someone definitely does not need to be a senior coder to contribute to DareNET's various projects.

If one of the contributors has been contributing so effectively to one of the team's projects to be considered eligible to become a part of this core group, then one of the senior coders should submit a proposal nominating this person. Thereafter a formal vote takes place among senior coders. If the result of this CFV is positive then the individual may be added as a senior coder.

Senior coders can only be removed by the decision of the Development Manager, or Executive Board. Any senior coder can send a request to remove another trusted coder (with just cause, of course) to the Development Manager. His decision is final.

Nomination of the Project Maintainer

The maintainer is appointed by the Development Manager, with input from the team as a whole, for a one year term. There are no restrictions on how many terms an individual may hold. When a new maintainer is to be elected, any of the senior coders can volunteer himself for the task.