/*!
\page rfc1_psc RFC 1: Project Steering Committee Guidelines

Author: GRASS PSC<br>
Contact: <a href="http://grass.itc.it/mailman/listinfo/grass-psc">grass-psc AT grass.itc.it</a><br>
Status: Adopted<br>

\section summary Summary

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

\section tor Terms of Reference

The two primary functions of the PSC are:
<ol>
<li>To enforce control over the GRASS codebase. This can be summarised as:
  <ul>
  <li> Enforce mechanisms to ensure quality control.</li>
  <li> Ensure compliance with all required legal measures.</li>
  </ul>
</li>  
<li>Project Management and responsibility for the "public face" of
GRASS.</li>
</ol>     
The PSC is expected to be able to speak and act on behalf of the GRASS 
project.

\subsection control Codebase Control

\subsubsection quality Quality Control Mechanisms

The quality control mechanisms, which are the responsibility of the PSC, 
currently include:
<ul>
<li>Maintaining submitter guidelines and making all developers aware of 
them.</li>
<li>Granting write access to the source code repository for new
developers.</li>
<li>Enforcing the submitter guidelines, with the ultimate sanction against 
non-compliance being removal of write access to the source code
repository.</li>
</ul>

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 should always lie with consensus on the 
developers' mailing list. Specifically, it is not the role of the PSC to 
impose technical solutions. Its role is in general 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.

\subsubsection legal 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 responsible for developing rules and 
procedures to cover this. These are outlined in a separate document: 
\link rfc2_psc "RFC 2: Legal aspects of code contributions".\endlink
This document will be updated and revised by the PSC as required.

\subsection projectman 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:
<ul>
<li>Release Cycles</li>
<li>Project infrastructure</li>
<li>Website Maintenance</li>
<li>Promotion and Public Relations</li>
<li>Other issues as they become relevant</li>
</ul>
	  
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.

\section operation Operation of the PSC

A dedicated <a href="http://grass.itc.it/mailman/listinfo/grass-psc">mailing list</a>
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. Any member may call a vote on any proposal. The voting 
procedure is outlined in a separate document: 
\link rfc3_psc "RFC 3: PSC Voting Procedures".\endlink

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) <strong>must</strong> have a vote called before a 
decision is reached:
<ul>
<li>Granting source code repository write access for new developers</li>
<li>Selection of a committee Chair</li>
</ul>

\section composition 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.


*/