Development Team/policy
m |
|||
| Line 1: | Line 1: | ||
| - | + | 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. | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | It is formally accepted that any material (code and documentation) produced by the team | + | |
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. | 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. | ||
| Line 17: | Line 13: | ||
* Making the code base more stable, more consistent and likewise, more maintainable. | * 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). | * 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. |
| - | + | ||
== Members == | == Members == | ||
| - | The team has different kinds of members with distinct roles: a manager, project maintainers, a small group of | + | 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 oversees the entire team, including its various projects and members. | + | 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 === | === 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 | + | 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 developer and know the internals of the project in detail. |
| - | The maintainer is responsible for maintaining and administering the | + | 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 is 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 | + | 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 | + | 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 === | === Contributors === | ||
| - | + | Anyone willing to contribute to the work of the team can be a contributor. | |
| - | Contributors do not have commit access to the repositories, | + | Contributors do not have commit access to the repositories, or read access to private repositories without manager approval. |
Tasks of the contributors include: | 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 | + | * 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. | * Working on documentation. | ||
* Submitting patches. | * Submitting patches. | ||
| Line 55: | Line 50: | ||
== Communication == | == Communication == | ||
| - | Each project may devise its own means of communicating with each other; however, a development | + | 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=== | ||
<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. | <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. | ||
| + | |||
| + | A private team channel is provided. | ||
== Procedures == | == Procedures == | ||
| - | Procedures for the tasks of the team | + | 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: | Any decision taken by the team follows one of these three paths: | ||
| Line 77: | Line 68: | ||
* formal 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 | + | 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. | 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. | ||
| Line 83: | Line 74: | ||
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." | 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 | + | === 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 | + | 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 | + | 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 === | === 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 | + | 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. |
Revision as of 07:10, 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: |
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. 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 is 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 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 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.
