Log in | Back to darenet.org

Development Team

(Goals)
Line 22: Line 22:
* Adding services and features while keeping backwards compatibility with existing servers, clients and formal or informal standards.  
* 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 IRC clients.
* Developing new features for client use in cooperation with the developers of the major IRC clients.
 +
 +
== Members ==
 +
 +
The team has different kinds of members with different roles: a manager, a small group of senior coders, and a group of helpers (hopefully ;p ).
 +
 +
=== Development Manager ===
 +
 +
The Development Manager shall oversee the Development Team and its three (3) sub-teams: IRCd, Services and Web. For the purpose of this document, we are only concerned with IRCd and Services.
 +
 +
The manager is the one responsible for keeping the integrity of the codebase. He or she (hereafter labeled "he" for brevity, not sexism) must be a experienced coder and know the internals of the server in detail.
 +
 +
The manager is the only one who has direct shell access to SVN (minus Executive Board members) and is responsible for maintaining and administering the repository. It is one of his major duties to keep things sync'd and verify that any change doesn't break the code or protocol. The manager, of course, may attempt to reduce his workload by distributing what can be delegated to others.
 +
 +
The manager's decisions about actual coding matters take place with a "silent agreement" procedure.

Revision as of 01:23, 18 September 2008


This document gives a brief breakdown on how DareNET's development team, in regards to IRCd & Services, should work. It shall be the reference set of rules used by the team.

In This Guide:

Tasks

The DareNET Development Team (hereafter called dev-team or simply 'the team') is in charge of maintaining, debugging, upgrading and improving the code of ircd-darenet, including protocol used for server<>server communication and for client<>server communication, the code related to additional services linked as different daemons (such as services-darenet) where it is considered desirable by the Executive Board, and the documentation of all the above.

It is formally accepted that code produced by the team is to be considered closed source, and is not to be distributed outside of DareNET's Operations Department.

Similarly, it must be clear that the main scope of the team is to develop the code for 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 server code used for DareNET.
  • Making the codebase more stable, more consistent, and likewise, more maintainable.
  • Documenting both existing and newly written code.
  • 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 IRC clients.

Members

The team has different kinds of members with different roles: a manager, a small group of senior coders, and a group of helpers (hopefully ;p ).

Development Manager

The Development Manager shall oversee the Development Team and its three (3) sub-teams: IRCd, Services and Web. For the purpose of this document, we are only concerned with IRCd and Services.

The manager is the one responsible for keeping the integrity of the codebase. He or she (hereafter labeled "he" for brevity, not sexism) must be a experienced coder and know the internals of the server in detail.

The manager is the only one who has direct shell access to SVN (minus Executive Board members) and is responsible for maintaining and administering the repository. It is one of his major duties to keep things sync'd and verify that any change doesn't break the code or protocol. The manager, of course, may attempt to reduce his workload by distributing what can be delegated to others.

The manager's decisions about actual coding matters take place with a "silent agreement" procedure.