Development Team/policy - Revision history

Admin: /* #Dev */

2013-10-12T07:23:06Z

#Dev

← Older revision		Revision as of 07:23, 12 October 2013
Line 56:		Line 56:
	<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.	+	A private team channel is also provided.

	== Procedures ==		== Procedures ==

Admin: /* Contributors */

2013-10-12T07:18:12Z

Contributors

← Older revision		Revision as of 07:18, 12 October 2013
Line 39:		Line 39:
	Anyone 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, or read access to private repositories without manager approval.	+	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:		Tasks of the contributors include:

Admin: /* Project Maintainers */ typo

2013-10-12T07:17:09Z

Project Maintainers: typo

← Older revision		Revision as of 07:17, 12 October 2013
Line 27:		Line 27:
	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.		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 is workload by distributing what can be delegated to other developers.	+	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.		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.

Admin: /* Project Maintainers */

2013-10-12T07:13:38Z

Project Maintainers

← Older revision		Revision as of 07:13, 12 October 2013
Line 25:		Line 25:
	=== 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 developer 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 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 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.

Admin at 07:10, 12 October 2013

2013-10-12T07:10:54Z

Show changes

Admin at 20:24, 28 May 2009

2009-05-28T20:24:36Z

Show changes

Admin: /* Procedures */

2009-05-28T19:38:03Z

Procedures

← Older revision		Revision as of 19:38, 28 May 2009
Line 83:		Line 83:
	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 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.

-	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.	+	Any decision taken by the team follows one of these three paths:

-	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.	+	* 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."

	=== Approval of patches ===		=== Approval of patches ===

Admin at 19:32, 28 May 2009

2009-05-28T19:32:15Z

← Older revision		Revision as of 19:32, 28 May 2009
Line 22:		Line 22:
	== Members ==		== 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 ).	+	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!).

	=== Development Manager ===		=== 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 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 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.	+	=== Maintainers ===

-	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~~.	+	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.

-	The ~~manager~~'s decisions about actual coding matters take place with a "silent agreement" procedure.	+	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'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.

	=== Senior Coders ===		=== Senior Coders ===

-	Senior coders are the most experienced and trusted coders that put the biggest effort into ~~ircd-darenet and services-darenet development~~. They are the only other members of the team that have commit access to the svn repository. The manager is implicitly a senior coder.	+	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.
		+
		+	=== Helpers / 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 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.
		+
		+	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.
		+
		+	== Forums & IRC Channel ==
		+
		+	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===

-	~~=== Helpers ===~~	+	<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.

-	~~Everyone willing to contribute to the work of the team can be a helper simply by creating a~~ dev.* account, and pariticipating on the forums.	+	===dev@darenet.org===

-	~~Helpers do not have commit access to~~ the ~~svn repository, and they can't submit patches directly~~ to the ~~manager (if their are other~~ senior coders ~~on the team). Instead, they must follow the specific procedure described below to do it, in order to save some of~~ the ~~manager's time when checking in patches~~.	+	This list is the place for users to report bugs. Here the senior coders might also discuss how deal with the most critical bugs.

-	~~Tasks of~~ the ~~helpers include:~~	+	The list is directly managed by the Development Team Manager.

-	* Trying to ~~help those who have trouble running or compiling~~ the ~~daemon and answering the easier questions asked on the forums.~~	+	Only senior coders may be subscribed to this list; however, the list is open for posting by anyone.
-	* Replying to those who make fuzzy feature-requests on the forums and eventually trying to interpret such requests and find out if/how they can become realistic proposals for ~~code changes.~~	+
-	* Working on the documentation of the code.	+

	== Procedures ==		== Procedures ==

-	Procedures for the tasks of ~~the~~ 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 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.

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

Admin: /* Goals */

2009-05-28T18:56:57Z

Goals

← Older revision		Revision as of 18:56, 28 May 2009
Line 13:		Line 13:
	The major goals of the team are (in descending order of priority):		The major goals of the team are (in descending order of priority):

-	* Diagnosing and removing bugs in the current code.	+	* Diagnosing and removing bugs in the current code.
-	* Improving the performance of the ~~server~~ code used for DareNET.	+	* Improving the performance of the code used for DareNET.
-	* Making the ~~codebase~~ 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.	+	* 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 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 clients.

	== Members ==		== Members ==

Admin at 18:52, 28 May 2009

2009-05-28T18:52:38Z

← Older revision		Revision as of 18:52, 28 May 2009
Line 1:		Line 1:
-	This document ~~gives a brief breakdown on~~ how DareNET's ~~IRCd and Services~~ Development ~~(sub)team~~ should ~~work~~. It ~~shall~~ be the reference set of rules ~~used~~ by the team.	+	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.
-		+
-		+

	== Tasks ==		== Tasks ==

-	The ~~IRCd and Services~~ Development ~~(sub)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 considered desirable by ~~the~~ Executive Board~~, and the documentation of all the above~~.	+	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.

-	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~~.	+	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 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.	+	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 ==		== Goals ==