Development Team/policy

Current revision as of 07:23, 12 October 2013

The DareNET Development team is responsible for maintaining, debugging, upgrading and improving the code for the software running on the network, or creating new services for the network. Such software ranges from IRC server daemons and IRC services to the DareNET website. The team is not responsible for content published by such software, or network maintenance in general.

It is formally accepted that any material (code and documentation) produced by the team is not to be distributed outside of DareNET. Should a decision be made to release any said material, after sign-off from the Executive Board, it must be released under an appropriate open source license, and preferably on the team's Bitbucket account.

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.

In This Guide:

1 Goals
2 Members
3 Communication
- 3.1 #Dev
4 Procedures
- 4.1 Nomination of Core Developers
- 4.2 Nomination of the Project Maintainer

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 (where desirable) with existing servers, clients and formal or informal standards.

Members

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

Manager

The manager is appointed by the Executive Board and oversees the entire team, including its various projects and members. This is mostly an administrative position, ensuring projects meet any established deadlines, and handling any disciplinary issues that may arise. His (used for brevity, not sexism) decisions in both coding and team matters is final.

Project Maintainers

Each project is lead by a maintainer. In the event a maintainer has not been appointed for a project, the manager shall be its acting maintainer. It is the maintainer's responsibility to ensure the integrity of the code base. He must be an experienced developer and know the internals of the project in detail.

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

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 vote is later held.

Core Developers

Each project may have a group of core developers. These individuals are the most experienced and trusted developers 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 repository. The manager and project maintainer are implicitly core developers.

Contributors

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

Contributors do not have commit access to the repositories, or read access to private repositories without manager and maintainer approval.

Tasks of the contributors include:

Helping those who have trouble running or compiling the software, or answering questions asked in #dev or issue trackers.
Replying to those who make fuzzy feature requests, 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 channel is provided for all team members to keep informed.

#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.

A private team channel is also provided.

Procedures

Procedures for the tasks of the team have intentionally been 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 list, and only as a last resort and/or for really major decisions the manager may issue a formal Call For Votes (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 Core Developers

Core developers 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 core developers 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 core developer 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 core developers should submit a proposal nominating this person. Thereafter a formal vote takes place among core developers. If the result of this CFV is positive then the individual may be added as a core developer.

Core developers can only be removed by the decision of the Development Manager, or Executive Board. Any core developer can send a request to remove another trusted developer (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 appointed, any of the core developers can volunteer himself for the task.

@@ Line 1: / Line 1: @@
-This document describes how DareNET's Development Team should function. The formal procedures it uses, the position of the people it is composed of, and the tasks it should accomplish. It will be the reference set of rules use by the team.
+The DareNET Development team is responsible for maintaining, debugging, upgrading and improving the code for the software running on the network, or creating new services for the network. Such software ranges from IRC server daemons and IRC services to the DareNET website. The team is not responsible for content published by such software, or network maintenance in general.
-== Tasks ==
+It is formally accepted that any material (code and documentation) produced by the team is not to be distributed outside of DareNET. Should a decision be made to release any said material, after sign-off from the Executive Board, it must be released under an appropriate open source license, and preferably on the team's Bitbucket account.
-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 commication), and other projects such as services-darenet, website-darenet, plugins-darenet and webchat-darenet. The team may also oversee other projects where considered desirable by DareNET's Executive Board.
+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.
-It is formally accepted that any material (code and documentation) produced by the team is to be considered 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 and/or services used by DareNET are part of the work of the team.
 == Goals ==
@@ Line 17: / Line 13: @@
 * 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.
+* Adding services and features while keeping backwards compatibility (where desirable) 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 different roles: a manager, maintainers, a small group of senior coders, and group of helpers/contributors (hopefully!).
+The team has different kinds of members with distinct roles: a manager, project maintainers, a small group of core developers and a group of contributors (hopefully/eventually).
-=== Development Manager ===
+=== Manager ===
-The Development Manager oversees the entire team, including its various projects and members. He or she (hereafter labeled "he" for brevity, not sexism) is mostly concerned with ensuring the team's various projects meet established deadlines, and handling any disciplinary issues that may arise.
+The manager is appointed by the Executive Board and oversees the entire team, including its various projects and members. This is mostly an administrative position, ensuring projects meet any established deadlines, and handling any disciplinary issues that may arise. His (used for brevity, not sexism) decisions in both coding and team matters is final.
-=== Maintainers ===
+=== Project Maintainers ===
-Each project has a maintainer. The maintainer is the one responsible for keeping the integrity of the code base. He must be an experienced coder and know the internals of the project in detail.
+Each project is lead by a maintainer. In the event a maintainer has not been appointed for a project, the manager shall be its acting maintainer. It is the maintainer's responsibility to ensure the integrity of the code base. He must be an experienced developer and know the internals of the project in detail.
-The maintainer is the only one who has direct shell access to SVN (though this may be delegated to others) and is responsible for maintaining and administering the repository. It is one of his major duties to keep things synch'd and 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 others.
+The maintainer is responsible for maintaining and administering the project's repository. It is one of his major duties to verify that any change doesn't break the code base or protocol. The maintainer, of course, may attempt to reduce his workload by distributing what can be delegated to other developers.
-The maintainer's decisions about actual coding matters take place with a "silent agreement" procedure, as long as there are no objections, and temporarily hold if a formal vote is later held.
+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 vote is later held.
-=== Senior Coders ===
+=== Core Developers ===
-Senior coders are the most experienced and trusted coders that put the biggest effort into the team's various projects. They are the only other members of the team that may have commit access to the svn repository. The manager and maintainers are implicitly senior coders.
+Each project may have a group of core developers. These individuals are the most experienced and trusted developers 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 repository. The manager and project maintainer are implicitly core developers.
-=== Helpers / Contributors ===
+=== Contributors ===
-Everyone willing to contribute to the work of the team can be a contributor.
+Anyone 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 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.
+Contributors do not have commit access to the repositories, or read access to private repositories without manager and maintainer approval.
 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.
+* Helping those who have trouble running or compiling the software, or answering questions asked in #dev or issue trackers.
-* 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.
+* Replying to those who make fuzzy feature requests, and eventually trying to interpret such requests and finding out if/how they can become realistic proposals.
 * Working on documentation.
 * Submitting patches.
-A helper can be given access to posting to dev@ and/or the development forum, after recommendation by a senior coder, and that would happen after an informal vote, pending no objections by other senior coders.
+== Communication ==
-== Forums & IRC Channel ==
+Each project may devise its own means of communicating with each other; however, a development channel is provided for all team members to keep informed.
-As a means of communication between the members, the team will use the forums and IRC channel.
-===Development Forum===
-All team members will have access to the development forum located on the DareNET forums website. It is there that senior coders can discuss changes to the project's code base, make informal votes and so on.
-The forum is directly managed by the Development Team Manager.
-Contributors can join the forum provided there are no objections by senior coders.
 ===#Dev===
-<nowiki>#</nowiki>Dev will be the team's official IRC channel. It is recommended that members of all projects join this channel to allow for easy cross-project discussion and interaction.
+<nowiki>#</nowiki>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.
-===dev@darenet.org===
+A private team channel is also provided.
-This list is the place for users to report bugs. Here the senior coders might also discuss how deal with the most critical bugs.
-The list is directly managed by the Development Team Manager.
-Only senior coders may be subscribed to this list; however, the list is open for posting by anyone.
 == Procedures ==
-Procedures for the tasks of them team should be kept as simple and informal as possible; however, a minimum number of organizational details and formalities are needed to keep control.
+Procedures for the tasks of the team have intentionally been 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, or formal voting. The idea is that if there are not 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 voting is asked by the manager on the closed dev@ list, 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.
-=== Approval of patches ===
-Patches can be submitted by anybody, but the path they follow before being approved changes based on who proposes them.
-Patches are those code submissions that don't severely alter the "behavior" of the server but only how it internally works; major changes follow a different procedure described later.
-A patch must be submitted with a separate description section that includes standard header fields, and the actual patch should be in "diff-rc3" format. The manager can ask that the description of the patch and other information are provided in a standard form that can be somehow automatically processed and archived, if he so chooses.
-When a patch is prepared by one of the senior coders or from one of the trusted helpers, he can send it directly to the manager or, preferrably, send it to the dev@ list (and it is advisable that he let the dev@ list know what he is up to before writing the patch). The manager should quickly verify it and then follow one of the following three steps. If the patch seems ok to him, the senior coder puts it in the repository. Otherwise, the manager could have found some problem with the patch, in which case he can either discuss privately the issue with the author until they find an agreement or ask for an informal vote on the list while keeping the patch suspended.
-Finally, when a patch is submitted by a helper he has to contact first one of the senior coders, who will act as a "sponsor" for the patch and has the duty of verifying its behavior, personally testing it, checking for interference with other parts of the code, and fixing problems. If he finds the patch working and helpful, he posts it as "written by x, verified by me." This is to save the manager from the work of checking patches that are broken, unacceptable, or that break the protocol of the choices made by dev-team.
-=== Approval of formal releases ===
+Any decision taken by the team follows one of these three paths:
-The coding tasks of the team move toward two different directions:
+* silent agreement
+* informal voting
+* formal voting
-* Preparation of new releases
+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 list, and only as a last resort and/or for really major decisions the manager may issue a formal Call For Votes (CFV).
-* Bug fixing
-All optimization efforts, addition of new features, and protocol changes should be considered part of the "next major release". Thus the SVN should be divided into two parts: a stable working release (branches) and an "experimental" unstable release (trunk).
+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.
-Most patches should be included only in trunk. When trunk has been found stable it can be formally released as stable.
+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."
-Upon proposal by the manager, a formal vote takes place to make the current trunk version the next stable formal release, and following that the manager prepares a tarball of the release to be submitted to the Server Management team that will become the "required" codebase for DareNET servers. Thus all patches included in the SVN should not be adopted in the network until the next formal release has been produced and approved.
+=== Nomination of Core Developers ===
-An exceptional path is to be adopted for bug fixes considered urgent in the production network. When such a bug is found and a patch is prepared for it, the manager will post two different patches: one for trunk and one for the branch. The patch in branch should be applied as soon as possible by all the servers on the production network to fix the bug while waiting for the next formal release.
+Core developers 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.
-=== Approval of protocol/semantic changes ===
+The core group constituted by the core developers 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 core developer to contribute to DareNET's various projects.
-Some changes in the source tree can't be done with simple patches because they have a major impact on the network, and the following are examples:
+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 core developers should submit a proposal nominating this person. Thereafter a formal vote takes place among core developers. If the result of this CFV is positive then the individual may be added as a core developer.
-* Changes to the server<>server protocol's syntax or semantics.
+Core developers can only be removed by the decision of the Development Manager, or Executive Board. Any core developer can send a request to remove another trusted developer (with just cause, of course) to the Development Manager. His decision is final.
-* Changes in the client<>server protocol that can break existing clients (like the removal of commands or the change of their behavior that cause any command that worked and produced a given effect with some parameters to behave differently or not work anymore with the same parameters and under the same conditions).
-* Addition of commands of features that might somehow violate any of the rules of the network (like allowing people to spam more, to have access to information they couldn't access before, to hide information that they couldn't hide before and so on).
-Such changes need to be approved by a formal vote on dev@ and then forwarded for ratification to the Operations Director, and eventually the Executive Board.
+=== Nomination of the Project Maintainer ===
-Moreover changes in server<>server protocol should always be checked in advance with the coders/manager of the services linked to the network, and as far as possible changes in the client<>server protocol should always be checked in advance with the coders of the major clients and of the daemons of the other major networks. On this last subject DareNET will make any effort to promote cooperation with the coders of other major networks and of the most commonly used clients.
+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 appointed, any of the core developers can volunteer himself for the task.