Noosfero development policy

Antonio Terceiro
1 parent 46f264fa
Showing 1 changed file with 101 additions and 0 deletions Show diff stats
DEVELOPMENT.md
@@ -0,0 +1,101 @@
+# Noosfero Development Policy
+
+## Developer Roles
+
+* *Developers* are everyone that are contributing code to Noosfero.
+* *Committers* are the people with direct commit access to the Noosfero source
+  code. They are responsible for reviewing contributions from other developers
+  and integrating them in the Noosfero code base. They are the members of the
+  [Noosfero group on Gitlab](https://gitlab.com/groups/noosfero/members).
+* *Release managers* are the people that are managing the release of a new
+  Noosfero version and/or the maintainance work of an existing Noosfero stable
+  branch. See MAINTAINANCE.md for details on the maintaince policy.
+
+## Development process
+
+* Every new feature or non-trivial bugfix should be reviewed by at least one
+  committer. This must be the case even if the original author is a committer.
+
+  * In the case the original author is a committer, he/she should feel free to
+    commit directly if after 1 week nobody has provided any kind of feedback.
+
+* Committers should feel free to push trivial (or urgent) changes directly.
+  There are no strict rule on what makes a change trivial or urgent; committers
+  are expected to exercise good judgement on a case by case basis.
+
+* In the case of unsolvable conflict between commiters regarding any change to
+  the code, the current release manager(s) will have the final say in the
+  matter.
+
+* Release managers are responsible for stablishing a release schedule, and
+  about deciding when and what to release.
+
+  * Release managers should announce release schedules to the project mailing
+    lists in advance.
+
+  * The release schedule may include a period of feature freeze, during which
+    no new features or any other changes that are not pre-approved by the
+    release manager must be committed to the repository. Committers must
+    respect the feature freezes.
+
+## Maintainance process
+
+### Not all feature releases will be maintained as a stable release
+
+We will be choosing specific release series to be maintained as stable
+releases.
+
+This means that a given release is not guaranteed to be maintained as a stable
+release, but does *not* mean it won't be. Any committer (or anyone, really) can
+decide to maintain a given release as stable and seek help from others to do
+so.
+
+### No merges from stable branches to master
+
+*All* changes must be submitted against the master branch first, and when
+applicable, backported to the desired stable releases. Exceptions to this rules
+are bug fixes that only apply to a given stable branch and not to master.
+
+In the past we had non-trivial changes accepted into stable releases while
+master was way ahead (e.g. during the rails3 migration period), that made the
+merge back into master very painful.  By eliminating the need to do these
+merges, we save time for the people responsible for the release, and eliminate
+the possibility of human errors or oversights causing changes to be accepted
+into stable that will be a problem to merge back into master.
+
+By getting all fixes in master first, we improve the chances that  a future
+release will not present regressions against bugs that should already be fixed,
+but the fixes got lost in a big, complicated merge (and those won't exist
+anymore, at least not from stable branches to master).
+
+After a fix gets into master, backporting changes into a stable release branch
+is the responsibility of whoever is maintaing that branch, and those interested
+in it. The stable branch release manager(s) are entitled the final say on any
+matters related to that branch.
+
+## Apendix A: how to become a committer
+
+Every developer that wants to be a committer should create [an issue on
+Gitlab](https://gitlab.com/noosfero/noosfero/issues) requesting to be added as
+a committer. This request must include information the requestor's previous
+contributions to the project.
+
+If 2 or more commiters consider second the request, the requestor is accepted
+as new commiter and added to the Noosfero group.
+
+The existing committers are free to choose whatever criteria they want to
+second the request, but they must be sure that the new committer is a
+responsible developer and knows what she/he is doing. They must be aware that
+seconding these requests means seconding the actions of the new committer: if
+the new committer screw up, her/his seconds screwed up.
+
+## Apendix B: how to become a release manager
+
+A new release manager for the development version of Noosfero (i.e. the one
+that includes new features, a.k.a. the master branch) is apointed by the
+current release manager, and must be a committer first.
+
+Release managers for stable branches are self-appointed, i.e. whoever takes the
+work takes the role. In case of a conflict (e.g. 2+ different people want to
+the work but can't agree on working together), the development release manager
+decides.
@@ -0,0 +1,101 @@		@@ -0,0 +1,101 @@
	1	+# Noosfero Development Policy
	2	+
	3	+## Developer Roles
	4	+
	5	+* Developers are everyone that are contributing code to Noosfero.
	6	+* Committers are the people with direct commit access to the Noosfero source
	7	+ code. They are responsible for reviewing contributions from other developers
	8	+ and integrating them in the Noosfero code base. They are the members of the
	9	+ [Noosfero group on Gitlab](https://gitlab.com/groups/noosfero/members).
	10	+* Release managers are the people that are managing the release of a new
	11	+ Noosfero version and/or the maintainance work of an existing Noosfero stable
	12	+ branch. See MAINTAINANCE.md for details on the maintaince policy.
	13	+
	14	+## Development process
	15	+
	16	+* Every new feature or non-trivial bugfix should be reviewed by at least one
	17	+ committer. This must be the case even if the original author is a committer.
	18	+
	19	+ * In the case the original author is a committer, he/she should feel free to
	20	+ commit directly if after 1 week nobody has provided any kind of feedback.
	21	+
	22	+* Committers should feel free to push trivial (or urgent) changes directly.
	23	+ There are no strict rule on what makes a change trivial or urgent; committers
	24	+ are expected to exercise good judgement on a case by case basis.
	25	+
	26	+* In the case of unsolvable conflict between commiters regarding any change to
	27	+ the code, the current release manager(s) will have the final say in the
	28	+ matter.
	29	+
	30	+* Release managers are responsible for stablishing a release schedule, and
	31	+ about deciding when and what to release.
	32	+
	33	+ * Release managers should announce release schedules to the project mailing
	34	+ lists in advance.
	35	+
	36	+ * The release schedule may include a period of feature freeze, during which
	37	+ no new features or any other changes that are not pre-approved by the
	38	+ release manager must be committed to the repository. Committers must
	39	+ respect the feature freezes.
	40	+
	41	+## Maintainance process
	42	+
	43	+### Not all feature releases will be maintained as a stable release
	44	+
	45	+We will be choosing specific release series to be maintained as stable
	46	+releases.
	47	+
	48	+This means that a given release is not guaranteed to be maintained as a stable
	49	+release, but does not mean it won't be. Any committer (or anyone, really) can
	50	+decide to maintain a given release as stable and seek help from others to do
	51	+so.
	52	+
	53	+### No merges from stable branches to master
	54	+
	55	+All changes must be submitted against the master branch first, and when
	56	+applicable, backported to the desired stable releases. Exceptions to this rules
	57	+are bug fixes that only apply to a given stable branch and not to master.
	58	+
	59	+In the past we had non-trivial changes accepted into stable releases while
	60	+master was way ahead (e.g. during the rails3 migration period), that made the
	61	+merge back into master very painful. By eliminating the need to do these
	62	+merges, we save time for the people responsible for the release, and eliminate
	63	+the possibility of human errors or oversights causing changes to be accepted
	64	+into stable that will be a problem to merge back into master.
	65	+
	66	+By getting all fixes in master first, we improve the chances that a future
	67	+release will not present regressions against bugs that should already be fixed,
	68	+but the fixes got lost in a big, complicated merge (and those won't exist
	69	+anymore, at least not from stable branches to master).
	70	+
	71	+After a fix gets into master, backporting changes into a stable release branch
	72	+is the responsibility of whoever is maintaing that branch, and those interested
	73	+in it. The stable branch release manager(s) are entitled the final say on any
	74	+matters related to that branch.
	75	+
	76	+## Apendix A: how to become a committer
	77	+
	78	+Every developer that wants to be a committer should create [an issue on
	79	+Gitlab](https://gitlab.com/noosfero/noosfero/issues) requesting to be added as
	80	+a committer. This request must include information the requestor's previous
	81	+contributions to the project.
	82	+
	83	+If 2 or more commiters consider second the request, the requestor is accepted
	84	+as new commiter and added to the Noosfero group.
	85	+
	86	+The existing committers are free to choose whatever criteria they want to
	87	+second the request, but they must be sure that the new committer is a
	88	+responsible developer and knows what she/he is doing. They must be aware that
	89	+seconding these requests means seconding the actions of the new committer: if
	90	+the new committer screw up, her/his seconds screwed up.
	91	+
	92	+## Apendix B: how to become a release manager
	93	+
	94	+A new release manager for the development version of Noosfero (i.e. the one
	95	+that includes new features, a.k.a. the master branch) is apointed by the
	96	+current release manager, and must be a committer first.
	97	+
	98	+Release managers for stable branches are self-appointed, i.e. whoever takes the
	99	+work takes the role. In case of a conflict (e.g. 2+ different people want to
	100	+the work but can't agree on working together), the development release manager
	101	+decides.