Difference between revisions of "RFC1"

From GRASS-Wiki
Jump to: navigation, search
(Category: PSC)
(updated to match RFC1 adopted April 5 (CVS ver 1.11))
Line 1: Line 1:
''This is a working document with a preliminary proposal, and has not been approved.''
 
 
 
== RFC 1: Project Steering Committee Guidelines ==
 
== RFC 1: Project Steering Committee Guidelines ==
 
: '''Author:''' GRASS Founding PSC
 
: '''Author:''' GRASS Founding PSC
: '''Status:''' Proposed
+
: '''Status:''' Adopted
  
The GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control  
+
A GRASS Project Steering Committee ([[PSC]]) is proposed to formalize control  
 
over the GRASS codebase and to facilitate GRASS project management issues.  
 
over the GRASS codebase and to facilitate GRASS project management issues.  
 
It is desired to keep the administrative overhead as low as possible.
 
It is desired to keep the administrative overhead as low as possible.
Line 12: Line 10:
 
determines membership and makes decisions on GRASS project issues.
 
determines membership and makes decisions on GRASS project issues.
  
The Geographic Resources Analysis Support System, commonly referred to as GRASS, is a Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modelling, and visualization.  "The GRASS Project" is defined as the collection of community-managed source code, documentation, sample data sets, and related intellectual property which has been submitted under the terms of the project's license(s) (see [[Project:Copyrights]] for details) for shared use.
+
"The GRASS Project" is defined as the GPL-licenced GIS software known as the
 +
Geographic Resources Analysis Support System, together with the surrounding
 +
development, distribution and promotion infrastructure currently headquarted
 +
at FBK-irst (formerly ITC-irst), Trento, Italy.
  
 
= Terms of Reference =
 
= Terms of Reference =
Line 44: Line 45:
 
impose technical solutions. Its role is limited to enforcing the quality  
 
impose technical solutions. Its role is limited to enforcing the quality  
 
control mechanisms outlined above.
 
control mechanisms outlined above.
 +
 +
However, if consensus fails to emerge naturally, an issue can be
 +
referred to the PSC for more structured efforts to build consensus. 
 +
As a last resort, if lack of consensus continues, the developer 
 +
community can request the PSC to choose options best preserving the 
 +
quality of the GRASS project.
 +
 +
Removal of write access to the source code repository is handled as a
 +
proposal to the committee as described below in the \ref operation section.
 +
  
 
=== Compliance with Legal Measures ===
 
=== Compliance with Legal Measures ===
Line 70: Line 81:
  
 
= Operation of the PSC =
 
= Operation of the PSC =
 
The PSC has its own public [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List].
 
  
 
A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a  
 
A dedicated [http://grass.itc.it/mailman/listinfo/grass-psc Mailing List] exists for the purpose of PSC discussions. When a  
Line 80: Line 89:
 
to reach a consensus or, only in case of extreme cases of disagreement, to  
 
to reach a consensus or, only in case of extreme cases of disagreement, to  
 
force a decision. The [[PSC Agenda]] lists all open motions.  
 
force a decision. The [[PSC Agenda]] lists all open motions.  
Any member may call a vote on any proposal. That member
+
Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, [[RFC3 | RFC3 - PSC Voting Procedures]].
is then responsible for collating votes and presenting the result to the
 
PSC. The voting procedure is outlined in a separate document: XXXXXXX
 
  
(Copy all the +1/0- stuff in there). -> Can somebody please do that, potentially a link to the document is enough.
+
The Chair is the ultimate adjudicator in case of deadlock or irretrievable
 
+
break down of decision-making, or in case of disputes over voting.
== Issues that must be voted by the PSC ==
 
  
 
The following issue(s) *must* have a vote called before a decision is reached:
 
The following issue(s) *must* have a vote called before a decision is reached:
Line 92: Line 98:
 
* Selection of a committee Chair
 
* Selection of a committee Chair
  
== Prevent Consensus Process from Stalement ==
+
= Composition of the Committee =
  
It is recognised that the ultimate arbitration on technical issues 
+
Initial PSC membership was decided based on a nomination and informal voting
should always lie with consensus on the developers' mailing list.   
+
period on the community's mailing listsMichael Barton, Dylan Beaudette,
Specifically, it is not the role of the [[PSC]] to impose technical 
+
Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova,
solutions. Its role is limited to enforcing the quality control 
+
Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the  
mechanisms outlined above. In general, once write access has been 
+
founding Project Steering Committee.
granted, developers are allowed to make changes to the codebase as 
 
they see fit. For controversial or complicated changes consensus must 
 
be obtained on the developers' mailing list as far as reasonably 
 
practicable. If consensus fails to emerge naturally, issues can be 
 
referred to the PSC for more structured efforts to build consensus. 
 
As a last resort, if lack of consensus continues, the developer 
 
community can request the PSC to choose options best preserving the
 
quality of the GRASS project.
 
  
== Resolving Deadlock or Break Down ==
+
Addition and removal of members from the committee, as well as selection
The Chair is the ultimate adjudicator in case of deadlock or irretrievable
+
of Chair is handled as a proposal to the committee as described above.
break down of decision-making, or in case of disputes over voting.
 
  
= Composition of the Committee =
+
The Chair is responsible for keeping track of the [[PSC | membership of the PSC]].
Founding members of the Project Steering Committee have been declared to be
 
Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad
 
Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and
 
Maciej Sieczka.
 
 
 
Addition and removal of members from the committee, as well as selection
 
of a Chair is handled as a proposal to the committee as described above.
 
  
The Chair is responsible for keeping track of the membership and update the [[PSC | PSC Member List]] accordingly.
 
  
 
[[Category: PSC]]
 
[[Category: PSC]]

Revision as of 09:59, 7 April 2007

RFC 1: Project Steering Committee Guidelines

Author: GRASS Founding PSC
Status: Adopted

A GRASS Project Steering Committee (PSC) is proposed to formalize control over the GRASS codebase and to facilitate GRASS project management issues. It is desired to keep the administrative overhead as low as possible.

This document describes how the GRASS Project Steering Committee determines membership and makes decisions on GRASS project issues.

"The GRASS Project" is defined as the GPL-licenced GIS software known as the Geographic Resources Analysis Support System, together with the surrounding development, distribution and promotion infrastructure currently headquarted at FBK-irst (formerly ITC-irst), Trento, Italy.

Terms of Reference

The two primary functions of the PSC are:

1) To enforce control over the GRASS codebase. This can be summarised as:

a) Enforce mechanisms to ensure quality control.
b) Ensure compliance with all required legal measures.

2) Project Management and responsibility for the "public face" of GRASS. The PSC is expected to be able to speak and act on behalf of the GRASS project.

Codebase Control

Quality Control Mechanisms

The quality control mechanisms, which are the responsibility of the PSC, currently include:

  • Maintaining submitter guidelines and making all developers aware of them.
  • Granting write access to the source code repository for new developers.
  • Enforcing the submitter guidelines, with the ultimate sanction against

non-compliance being removal of write access to the source code repository.

In general, once write access has been granted, developers are allowed to make changes to the codebase as they see fit. For controversial or complicated changes consensus must be obtained on the developers' mailing list as far as reasonably practicable. It is recognised that the ultimate arbitration on technical issues always lies with consensus on the developers' mailing list. Specifically, it is not the role of the PSC to impose technical solutions. Its role is limited to enforcing the quality control mechanisms outlined above.

However, if consensus fails to emerge naturally, an issue can be referred to the PSC for more structured efforts to build consensus. As a last resort, if lack of consensus continues, the developer community can request the PSC to choose options best preserving the quality of the GRASS project.

Removal of write access to the source code repository is handled as a proposal to the committee as described below in the \ref operation section.


Compliance with Legal Measures

Control over the codebase also extends to ensuring that it complies with all relevant legal requirements. This includes copyright and licensing amongst other issues. The PSC is resonsible for developing rules and procedures to cover this. These are outlined in a separate document: "RFC 2: Legal aspects of code contributions". This document will be updated and revised by the PSC as required.

Project Management

The PSC will share responsibility and make decisions over issues related to the management of the overall direction of the GRASS project and external visibility, etc. These include, but are not limited to:

  • Release Cycles
  • Project infrastructure
  • Website Maintenance
  • Promotion and Public Relations
  • Other issues as they become relevant

It is the responsibility of the PSC to ensure that issues critical to the future of the GRASS project are adequately attended to. This may involve delegation to interested helpers.

Operation of the PSC

A dedicated Mailing List exists for the purpose of PSC discussions. When a decision is required of the PSC, it will be presented by any member to the mailing list in the form of a proposal. A decision will then be achieved by discussion of the proposal on the mailing list until a consensus is reached. Voting on issues is also permissable and may be used as a means to reach a consensus or, only in case of extreme cases of disagreement, to force a decision. The PSC Agenda lists all open motions. Any member may call a vote on any proposal. The voting procedure is outlined in a separate document, RFC3 - PSC Voting Procedures.

The Chair is the ultimate adjudicator in case of deadlock or irretrievable break down of decision-making, or in case of disputes over voting.

The following issue(s) *must* have a vote called before a decision is reached:

  • Granting source code repository write access for new developers
  • Selection of a committee Chair

Composition of the Committee

Initial PSC membership was decided based on a nomination and informal voting period on the community's mailing lists. Michael Barton, Dylan Beaudette, Hamish Bowman, Massimiliano Cannata, Brad Douglas, Paul Kelly, Helena Mitasova, Scott Mitchell, Markus Neteler, and Maciej Sieczka are declared to be the founding Project Steering Committee.

Addition and removal of members from the committee, as well as selection of Chair is handled as a proposal to the committee as described above.

The Chair is responsible for keeping track of the membership of the PSC.