Developer policies - Revision history

Lcc at 11:27, 30 March 2010

2010-03-30T11:27:41Z

Lcc: Developer Policies moved to Developer policies

2010-03-30T11:08:59Z

Developer Policies moved to Developer policies

Lcc at 11:08, 30 March 2010

2010-03-30T11:08:44Z

Pez4brian: cleanup

2009-12-13T04:02:02Z

cleanup

Pez4brian: Add reference to source File Headers

2009-12-10T05:19:38Z

Add reference to source File Headers

Pez4brian: /* Coding Policies */

2009-12-10T05:16:36Z

‎Coding Policies

Bmcage at 15:51, 4 March 2009

2009-03-04T15:51:46Z

Bmcage: New page: Category:Developers/General This document collects the different policies the GRAMPS developer community has adopted. == Coding Policies == === Licence === GRAMPS is a GPLv2 applicati...

2009-03-04T15:49:32Z

New page: Category:Developers/General This document collects the different policies the GRAMPS developer community has adopted. == Coding Policies == === Licence === GRAMPS is a GPLv2 applicati...

New page

[[Category:Developers/General]]
This document collects the different policies the GRAMPS developer community has adopted.

== Coding Policies ==
=== Licence ===
GRAMPS is a GPLv2 application with possibility to use a later version of the GPL (GPLv3). There are no plans at the moment to move to GPLv3 and drop GPLv2.

=== Coding style ==
GRAMPS follows PEP 8. More info and general policy: [[Programming Guidelines]]. Starting from 3.2 minimal pylint scores will probably be enforced.

Concerning the visual elements, a general UI style is agreed upon: [[UI Style]]

=== Acceptable changes ===
You should follow the roadmap set out for the next release. Only minor features or new reports/gramplets/... can still be added to the roadmap after it has been made official. Add your changes to the roadmap (on this wiki and in the bug tracker) so others are notified what you work on. Seek approval for your changes via the devel mailing list.

== Commit Policies ==
=== General ===
Read [[Committing Policies]]

=== Becoming an official developer ===
The road to become an official developer is as follows:
* Fix bug issues on the bug tracker and participate in the devel mailing list.
* Accept the guidance from existing developers. If you do not agree with them, you need to convince them. To do that consider first to code what is asked pointing out the weakness afterward, i.e let the code speak for you.
* Take up a feature request after assuring yourself (eg via the devel mailing list), the feature will probably be accepted by the developers. Let your code be reviewed.

:Once you come to the conclusion your code needs little change before commit, ask one of the admins (Benny, Brian) to add your sourceforge id to the list of developers. If you did not have contact with the admins yet, ask one of the other developers to

@@ Line 6: / Line 6: @@
 === Coding style ===
-Follow the Gramps [[Programming Guidelines]] - which mostly refer to PEP8 with a few additions.
+Follow the Gramps [[Programming guidelines]] - which mostly refer to PEP8 with a few additions.
-All source files shall include conforming [[Source File Headers]].
+All source files shall include conforming [[Source file headers]].
 === GUI design ===
-User interfaces shall conform to the agreed upon: [[UI Style]]
+User interfaces shall conform to the agreed upon: [[UI style]]
 === Acceptable changes ===
@@ Line 18: / Line 18: @@
 == Commit policies ==
 === General ===
-Read [[Committing Policies]]
+Read [[Committing policies]]
 === Becoming an official developer ===

@@ Line 7: / Line 7: @@
 === Coding style ===
-GRAMPS follows PEP 8. More info and general policy: [[Programming Guidelines]]. Starting from 3.2 minimal pylint scores will probably be enforced.
+Follow the Gramps [[Programming Guidelines]] - which mostly refer to PEP8 with a few additions.
-−
-Concerning the visual elements, a general UI style is agreed upon: [[UI Style]]
 All source files shall include conforming [[Source File Headers]].
 === Acceptable changes ===

← Older revision		Revision as of 05:19, 10 December 2009
Line 10:		Line 10:

	Concerning the visual elements, a general UI style is agreed upon: [[UI Style]]		Concerning the visual elements, a general UI style is agreed upon: [[UI Style]]
		+
		+	All source files shall include conforming [[Source File Headers]].

	=== Acceptable changes ===		=== Acceptable changes ===

@@ Line 1: / Line 1: @@
 This document collects the different policies the GRAMPS developer community has adopted.
-== Coding Policies ==
+== Coding policies ==
 === Licence ===
 GRAMPS is a GPLv2 application with possibility to use a later version of the GPL (GPLv3). There are no plans at the moment to move to GPLv3 and drop GPLv2. See [[Project License]] for details.
@@ Line 17: / Line 16: @@
 You should follow the roadmap set out for the next release. Only minor features or new reports/gramplets/... can still be added to the roadmap after it has been made official. Add your changes to the roadmap (on this wiki and in the bug tracker) so others are notified what you work on. Seek approval for your changes via the devel mailing list.
-== Commit Policies ==
+== Commit policies ==
 === General ===
 Read [[Committing Policies]]
@@ Line 30: / Line 29: @@
 * Even after you obtained commit rights, consider a review of your code by other developers using the bug tracker (send reminder) or the devel mailing list.

@@ Line 6: / Line 6: @@
 GRAMPS is a GPLv2 application with possibility to use a later version of the GPL (GPLv3). There are no plans at the moment to move to GPLv3 and drop GPLv2.
-=== Coding style ==
+=== Coding style ===
 GRAMPS follows PEP 8. More info and general policy: [[Programming Guidelines]]. Starting from 3.2 minimal pylint scores will probably be enforced.
@@ Line 22: / Line 22: @@
 * Fix bug issues on the bug tracker and participate in the devel mailing list.
 * Accept the guidance from existing developers. If you do not agree with them, you need to convince them. To do that consider first to code what is asked pointing out the weakness afterward, i.e let the code speak for you.
-* Take up a feature request after assuring yourself (eg via the devel mailing list), the feature will probably be accepted by the developers. Let your code be reviewed.
+* Take up a feature request after assuring yourself (eg via the devel mailing list) the feature will probably be accepted by the developers. Let your code be reviewed.
-:Once you come to the conclusion your code needs little change before commit, ask one of the admins (Benny, Brian) to add your sourceforge id to the list of developers. If you did not have contact with the admins yet, ask one of the other developers to
+* Once you come to the conclusion your code needs little change before commit, ask one of the admins (Benny, Brian) to add your sourceforge id to the list of developers. If you did not have contact with the admins yet, ask one of the other developers to vouch for you.