MetaCRS PSC - Revision history

Warmerdam: deprecate.

2009-11-14T22:10:55Z

deprecate.

Wiki-Hugueswski: /* Summary */

2008-08-14T18:25:32Z

Summary

Warmerdam: note this is adopted.

2008-07-21T16:30:23Z

note this is adopted.

Arnulf: /* Summary */ added link back to MetaCRS

2008-04-25T21:29:55Z

Summary: added link back to MetaCRS

Warmerdam: /* RFC 1: Project Steering Committee Guidelines */

2008-04-25T18:20:18Z

RFC 1: Project Steering Committee Guidelines

Warmerdam: Preliminary Draft.

2008-04-25T18:17:09Z

Preliminary Draft.

New page

= RFC 1: Project Steering Committee Guidelines =

Author: Frank Warmerdam[[BR]]
Contact: warmerdam@pobox.com[[BR]]
Status: Development

== Summary ==

This document describes governance and decision making for the MetaCRS Project.

The MetaCRS project is a effectively a confederation of projects related to coordinate reference system handling and transformations. As such, it's governance is somewhat decentralized with some component projects operating in a partially autonomous manner. On initiation the sub-projects are CS-MAP, PROJ.4 and PROJ4JS.

Each sub-project has a project lead who is considered primarily responsible for the sub-project. It is anticipated that most technical decisions will be made within the sub-projects on the basis of consensus, and be supervised by the sub-project lead.

However, the MetaCRS Project Steering Committee exists to make decisions on contentious sub-project decisions, matters that cross sub-project boundaries and official matters relating to OSGeo project governance such as committer approval.

== Detailed Process ==

1. Proposals are written up and submitted on the metacrs@lists.osgeo.org mailing list for discussion and voting, by any interested party, not just committee members.
2. Proposals need to be available for review and voting for at least two business days before a final decision can be made.
3. Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation.
4. Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days.
5. A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicate mild support, but has no effect. Not voting is also an acceptable way of indicating no opinion.
6. Anyone may comment on proposals on the list, but only members of the Project Steering Committee's votes will be counted.
7. A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1).
8. If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it. Note that this is a majority of all committee members, not just those who actively vote.
9. Upon completion of discussion and voting the proposer should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed).
10. The Chair gets a vote.
11. The Chair is responsible for keeping track of who is a member of the Project Management Committee.
12. Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee. The selection of a new Chair also requires approval of the OSGeo board.
13. The Chair adjudicates in cases of disputes about voting, or procedure, and can choose to extend the voting period if it is judged helpful to reaching consensus.

== When is Vote Required? ==

Generally speaking, technical decisions should be made by consensus within sub-projects. However, if a decision cannot be decided by consensus of the commiters involved in the sub-project, any commiter can request the decision be brought to a vote of the MetaCRS PSC. Technical decision that would be suitable for such a process include:

* Anything that could cause backward compatibility issues.
* Adding substantial amounts of new code.
* Changing inter-subsystem APIs, or objects.
* When releases should take place.
* Anything that might be controversial.

The MetaCRS PSC will also be directly responsible for some activities, particularly activities that cross sub-project boundaries such as interpreting coordinate system definitions, work on CRS dictionary tools, development of cross project test suites, and establishing best practices for coordinate system interchange and expression.

The MetaCRS PSC will always be responsible for:

* Approval of project commiters.
* Approval of sub-project leads.

== Observations ==

* The Chair is the ultimate adjudicator if things break down.
* The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances vetoers need to be convinced to withdraw their veto. We are trying to reach consensus.
* While it is generally intended that sub-projects operate fairly automously, the MetaCRS PSC always has the ultimate right to impose decisions on sub-projects.

== Bootstrapping ==

Frank Warmerdam is declared initial Chair of the MetaCRS Project Steering Committee.

Hugues Wisniewski, Norm Olson, Frank Warmerdam and Mike Adair are declared to be the
founding Project Steering Committee. The current list will be maintained by the MetaCRS
chair on the MetaCRS web pages.

← Older revision		Revision as of 22:10, 14 November 2009
Line 1:		Line 1:
		+	'''NOTE: This document has migrated to the MetaCRS Trac Wiki, and is now at: http://trac.osgeo.org/metacrs/wiki/PSCGuidelines'''
		+
		+	-----------
		+
	= RFC#1: MetaCRS Project Steering Committee Guidelines =		= RFC#1: MetaCRS Project Steering Committee Guidelines =

@@ Line 11: / Line 11: @@
 This document describes governance and decision making for the [[MetaCRS]] Project.
-The MetaCRS project is a effectively a confederation of projects related to coordinate reference system handling and transformations.  As such, it's governance is somewhat decentralized with some component projects operating in a partially autonomous manner.  On initiation the sub-projects are CS-MAP, PROJ.4 and PROJ4JS.
+The MetaCRS project is a effectively a confederation of projects related to coordinate reference system handling and transformations.  As such, it's governance is somewhat decentralized with some component projects operating in a partially autonomous manner.  On initiation the sub-projects are [http://trac.osgeo.org/csmap CS-MAP], PROJ.4 and PROJ4JS.
 Each sub-project has a project lead who is considered primarily responsible for the sub-project.  It is anticipated that most technical decisions will be made within the sub-projects on the basis of consensus, and be supervised by the sub-project lead.

@@ Line 5: / Line 5: @@
 Contact: warmerdam@pobox.com
-Status: Development
+Status: Adopted
 == Summary ==

@@ Line 9: / Line 9: @@
 == Summary ==
-This document describes governance and decision making for the MetaCRS Project.
+This document describes governance and decision making for the [[MetaCRS]] Project.
 The MetaCRS project is a effectively a confederation of projects related to coordinate reference system handling and transformations.  As such, it's governance is somewhat decentralized with some component projects operating in a partially autonomous manner.  On initiation the sub-projects are CS-MAP, PROJ.4 and PROJ4JS.
@@ Line 15: / Line 15: @@
 Each sub-project has a project lead who is considered primarily responsible for the sub-project.  It is anticipated that most technical decisions will be made within the sub-projects on the basis of consensus, and be supervised by the sub-project lead.
 However, the MetaCRS Project Steering Committee exists to make decisions on contentious sub-project decisions, matters that cross sub-project boundaries and official matters relating to OSGeo project governance such as committer approval.
 == Detailed Process ==

@@ Line 1: / Line 1: @@
-= RFC 1: Project Steering Committee Guidelines =
+= RFC#1: MetaCRS Project Steering Committee Guidelines =
 Status: Development
@@ Line 17: / Line 19: @@
 == Detailed Process ==
-. Proposals are written up and submitted on the metacrs@lists.osgeo.org mailing list for discussion and voting, by any interested party, not just committee members.
+# Proposals are written up and submitted on the metacrs@lists.osgeo.org mailing list for discussion and voting, by any interested party, not just committee members.
-. Proposals need to be available for review and voting for at least two business days before a final decision can be made.
+# Proposals need to be available for review and voting for at least two business days before a final decision can be made.
-. Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation.
+# Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation.
-. Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days.
+# Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days.
-. A vote of -0 indicates mild disagreement, but has no effect.  A 0 indicates no opinion.  A +0 indicate mild support, but has no effect.  Not voting is also an acceptable way of indicating no opinion.
+# A vote of -0 indicates mild disagreement, but has no effect.  A 0 indicates no opinion.  A +0 indicate mild support, but has no effect.  Not voting is also an acceptable way of indicating no opinion.
-. Anyone may comment on proposals on the list, but only members of the Project Steering Committee's votes will be counted.
+# Anyone may comment on proposals on the list, but only members of the Project Steering Committee's votes will be counted.
-. A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1).
+# A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1).
-. If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it.  Note that this is a majority of all committee members, not just those who actively vote.
+# If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it.  Note that this is a majority of all committee members, not just those who actively vote.
-. Upon completion of discussion and voting the proposer should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed).
+# Upon completion of discussion and voting the proposer should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed).
-. The Chair gets a vote.
+# The Chair gets a vote.
-. The Chair is responsible for keeping track of who is a member of the Project Management Committee.
+# The Chair is responsible for keeping track of who is a member of the Project Management Committee.
-. Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee.  The selection of a new Chair also requires approval of the OSGeo board.
+# Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee.  The selection of a new Chair also requires approval of the OSGeo board.
-. The Chair adjudicates in cases of disputes about voting, or procedure, and can choose to extend the voting period if it is judged helpful to reaching consensus.
+# The Chair adjudicates in cases of disputes about voting, or procedure, and can choose to extend the voting period if it is judged helpful to reaching consensus.
 == When is Vote Required? ==
@@ Line 35: / Line 37: @@
 Generally speaking, technical decisions should be made by consensus within sub-projects.  However, if a decision cannot be decided by consensus of the commiters involved in the sub-project, any commiter can request the decision be brought to a vote of the MetaCRS PSC.  Technical decision that would be suitable for such a process include:
- * Anything that could cause backward compatibility issues.
+* Anything that could cause backward compatibility issues.
- * Adding substantial amounts of new code.
+* Adding substantial amounts of new code.
- * Changing inter-subsystem APIs, or objects.
+* Changing inter-subsystem APIs, or objects.
- * When releases should take place.
+* When releases should take place.
- * Anything that might be controversial.
+* Anything that might be controversial.
 The MetaCRS PSC will also be directly responsible for some activities, particularly activities that cross sub-project boundaries such as interpreting coordinate system definitions, work on CRS dictionary tools, development of cross project test suites, and establishing best practices for coordinate system interchange and expression.
@@ Line 45: / Line 47: @@
 The MetaCRS PSC will always be responsible for:
- * Approval of project commiters.
+* Approval of project commiters.
- * Approval of sub-project leads.
+* Approval of sub-project leads.
 == Observations ==
- * The Chair is the ultimate adjudicator if things break down.
+* The Chair is the ultimate adjudicator if things break down.
- * The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances vetoers need to be convinced to withdraw their veto.  We are trying to reach consensus.
+* The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances vetoers need to be convinced to withdraw their veto.  We are trying to reach consensus.
- * While it is generally intended that sub-projects operate fairly automously, the MetaCRS PSC always has the ultimate right to impose decisions on sub-projects.
+* While it is generally intended that sub-projects operate fairly automously, the MetaCRS PSC always has the ultimate right to impose decisions on sub-projects.
 == Bootstrapping ==