address updated, html syntax replaced by doxygen syntax

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@38078 15284696-431f-4ddb-bdfa-cd5b030d7da7

rfc/RFC1_PSC.dox

@@ -1,9 +1,11 @@
 /*!
 \page rfc1_psc RFC 1: Project Steering Committee Guidelines
 
-Author: GRASS PSC<br>
-Contact: <a href="http://lists.osgeo.org/mailman/listinfo/grass-psc">grass-psc AT lists.osgeo.org</a><br>
-Status: Adopted (6 April 2007)<br>
+Author: GRASS PSC
+
+Contact: <a href="http://lists.osgeo.org/mailman/listinfo/grass-psc">grass-psc AT lists.osgeo.org</a>
+
+Status: Adopted (6 April 2007)
 
 \section summary Summary
 
@@ -17,21 +19,18 @@ 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.
+at OSGeo.
 
 \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>     
+
+-# To enforce control over the GRASS codebase. This can be summarised as:
+ - Enforce mechanisms to ensure quality control.</li>
+ - Ensure compliance with all required legal measures.</li>
+-# 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.
 
@@ -41,15 +40,14 @@ project.
 
 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 
+
+- 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.</li>
-</ul>
+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 
@@ -83,13 +81,12 @@ This document will be updated and revised by the PSC as required.
 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>
+
+- 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 
@@ -111,12 +108,11 @@ procedure is outlined in a separate document:
 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 
+The following issue(s) <b>must</b> 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>
+
+- Granting source code repository write access for new developers
+- Selection of a committee Chair
 
 \section composition Composition of the Committee
 
@@ -133,4 +129,3 @@ The Chair is responsible for keeping track of the membership of the PSC.
 
 
 */
-

rfc/RFC2_PSC.dox

@@ -1,9 +1,11 @@
 /*!
 \page rfc2_psc RFC 2: Legal aspects of code contributions
 
-Author: Markus Neteler (based on GDAL.org/RFC3)<br>
-Contact: neteler AT osgeo.org<br>
-Status: Adopted (8 Dec 2006)<br>
+Author: Markus Neteler (based on GDAL.org/RFC3)
+
+Contact: neteler AT osgeo.org
+
+Status: Adopted (8 Dec 2006)
 
 \section legal Legal aspects
 
@@ -41,32 +43,30 @@ Committers should adhere to the following guidelines, and may be
 personally legally liable for improperly contributing code to the
 source repository:
 
-<ul>
-<li> Make sure the contributor (and possibly employer) is aware of the
-  contribution terms.</li>
+- Make sure the contributor (and possibly employer) is aware of the
+  contribution terms.
 
-<li> Code coming from a source other than the contributor (such as
+- Code coming from a source other than the contributor (such as
   adapted from another project) should be clearly marked as to the
   original source, copyright holders, license terms and so forth. This
   information can be in the file headers, but should also be added to
   the project licensing file if not exactly matching normal project
-  licensing (grass/COPYRIGHT.txt).</li>
+  licensing (grass/COPYRIGHT.txt).
 
-<li> Existing copyright headers and license text should never be stripped
+- Existing copyright headers and license text should never be stripped
   from a file. If a copyright holder wishes to give up copyright they
   must do so in writing to the GRASS-PSC before copyright messages
   are removed. If license terms are changed, it has to be by agreement
-  (written in email is ok) of the copyright holders.</li>
+  (written in email is ok) of the copyright holders.
 
-<li> When substantial contributions are added to a file (such as
+- When substantial contributions are added to a file (such as
   substantial patches) the author/contributor should be added to the
-  list of copyright holders for the file in the file header.</li>
+  list of copyright holders for the file in the file header.
 
-<li> If there is uncertainty about whether a change is proper to
+- If there is uncertainty about whether a change is proper to
   contribute to the code base, please seek more information from the
   project steering committee, other GRASS developers or the OSGeo
-  foundation legal counsel.</li>
-</ul>
+  foundation legal counsel.
 
 Questions regarding GRASS GIS should be directed to the
 GRASS Development Team at the following address:
@@ -76,14 +76,13 @@ Internet:
   http://grass.osgeo.org
 
 Postal address:
-<pre>
+
+\verbatim
  GRASS Development Team
- ITC-Irst
  c/o M. Neteler
- SSI/MPA
- Via Sommarive, 18
- 38050 Trento (Povo), Italy
- neteler * osgeo.org
-</pre>
+ Fondazione Mach - Centre for Alpine Ecology
+ 38100 Viote del Monte Bondone (Trento)
+ Italy
+ email: neteler AT cealp.it
+\endverbatim
 */
-

rfc/RFC3_PSC.dox

@@ -1,9 +1,11 @@
 /*!
 \page rfc3_psc RFC 3: PSC Voting Procedures
 
-Author: GRASS PSC<br>
-Contact: <a href="http://lists.osgeo.org/mailman/listinfo/grass-psc">grass-psc AT lists.osgeo.org</a><br>
-Status: Proposed<br>
+Author: GRASS PSC
+
+Contact: <a href="http://lists.osgeo.org/mailman/listinfo/grass-psc">grass-psc AT lists.osgeo.org</a>
+
+Status: Proposed
 
 \section introduction Introduction
 
@@ -14,48 +16,36 @@ of committee members can pass a proposal.
 
 \section detailed_process Detailed Process
 
-<ol>
-
-<li>Proposals are written up and submitted on the mailing list for 
+-# Proposals are written up and submitted on the mailing list for 
 discussion. Any committee member may call a vote on any proposal, although
 it is normal practice for the proposer to call the vote. Any interested 
 party may subscribe to the list and join the discussion, but only committee 
-members may vote. The PSC Chair gets a vote.</li>
-
-<li>Proposals need to be available for review for at least four business
+members may vote. The PSC Chair gets a vote.
+-# Proposals need to be available for review for at least four business
 days before a vote can be closed. It is recognized that some more complex 
 issues may require longer for discussion and deliberation: a vote should 
 only be closed after the minimum time period has passed and sufficient 
 discussion has taken place or no more progress is being made. The Chair 
 may override this and prolong the discussion period or close a vote straight 
 away if necessary (although the minimum time period for discussion/voting 
-always applies).</li>
-
-<li>Respondents may vote "+1" to indicate support for the proposal and a 
-willingness to support implementation.</li>
-
-<li>Respondents may vote "-1" to veto a proposal, but must provide clear
+always applies).
+-# 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 alternative approaches to resolving the problem within the
 period the issue is open for discussion/voting. Otherwise the veto will be
-considered invalid.</li>
-
-<li>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.</li>
-
-<li>A proposal will be accepted if it receives +2 (including the proposer)
-and no vetoes (-1).</li>
-
-<li>The member who called the vote (normally the proposer) is responsible 
+considered invalid.
+-# 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.
+-# A proposal will be accepted if it receives +2 (including the proposer)
+and no vetoes (-1).
+-# The member who called the vote (normally the proposer) is responsible 
 for collating votes and presenting the result to the PSC after closing the
-vote.</li>
-
-<li>The Chair adjudicates in cases of disputes over voting.</li>
-
-<li>If a proposal is vetoed, and it cannot be revised to satisfy all parties, 
+vote.
+-# The Chair adjudicates in cases of disputes over voting.
+-# 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.</li>
-
-</ol>
+a majority of all committee members, not just those who actively vote.
 
 */

rfc/psc_motions.dox

@@ -5,14 +5,13 @@ See also: <a href="http://grass.osgeo.org/wiki/PSC_Agenda">PSC Agenda</a>.
 
 \section motions2008 Motions of 2008
 
-<ul>
-<li> SVN write access to Yann Chemin
-<li> Registering GRASS at <a href="http://osor.eu">OSOR.eu</a> portal (approved Aug 2008)
-<li> SVN write access to Laura Toma (granted, 11 Aug 2008)
-<li> SVN write access to Marco Pasetti (granted, 19 May 2008)
-<li> SVN write access to Maris Nartiss (granted, 12 Apr 2008)
-<li> OSGeo incubator graduation of GRASS approved by OSGeo board (8 Feb 2008)
-<li> SVN write access to Ivan Shmakov (granted, 6 Feb 2008)
+- SVN write access to Yann Chemin
+- Registering GRASS at <a href="http://osor.eu">OSOR.eu</a> portal (approved Aug 2008)
+- SVN write access to Laura Toma (granted, 11 Aug 2008)
+- SVN write access to Marco Pasetti (granted, 19 May 2008)
+- SVN write access to Maris Nartiss (granted, 12 Apr 2008)
+- OSGeo incubator graduation of GRASS approved by OSGeo board (8 Feb 2008)
+- SVN write access to Ivan Shmakov (granted, 6 Feb 2008)
 <!--
 <li> \link rfc3_psc RFC 3: PSC Voting Procedures
 -->
@@ -20,21 +19,16 @@ See also: <a href="http://grass.osgeo.org/wiki/PSC_Agenda">PSC Agenda</a>.
 
 \section motions2007 Motions of 2007
 
-<ul>
-<li> SVN write access to Eric Patton as documentation manager (granted, 24 Nov 2007)
-<li> Motion to migrate CVS/bugtracker to OSGeo (passed, 22 Oct 2007)
-<li> CVS write access to P. Marcondes for PT translations (granted, 2 June 2007)
-<li> \link rfc1_psc RFC 1: Project Steering Committee Guidelines\endlink (adopted 6 April 2007)
-</ul>
+- SVN write access to Eric Patton as documentation manager (granted, 24 Nov 2007)
+- Motion to migrate CVS/bugtracker to OSGeo (passed, 22 Oct 2007)
+- CVS write access to P. Marcondes for PT translations (granted, 2 June 2007)
+- \link rfc1_psc RFC 1: Project Steering Committee Guidelines\endlink (adopted 6 April 2007)
 
 \section motions2006 Motions of 2006
 
-<ul>
-<li> CVS write access to S. Pallecchi (granted, 12 Dec 2006)
-<li> PSC Chair motion (chair: M Neteler, 9 Dec 2006, see related 
+- CVS write access to S. Pallecchi (granted, 12 Dec 2006)
+- PSC Chair motion (chair: M Neteler, 9 Dec 2006, see related 
      <a href="http://grass.osgeo.org/pipermail/grass-psc/2006-December/000143.html">email message</a>)
-<li> CVS write access to R. Antolin (granted, 8 Dec 2006)
-<li> \link rfc2_psc RFC 2: Legal aspects of code contributions\endlink (adopted 8 Dec 2006)
-</ul>
-
+- CVS write access to R. Antolin (granted, 8 Dec 2006)
+- \link rfc2_psc RFC 2: Legal aspects of code contributions\endlink (adopted 8 Dec 2006)
 */

rfc/rfc_list.dox

@@ -3,17 +3,11 @@
 
 List of \link psc_motions Motions of the GRASS Project Steering Committee\endlink
 
-<p>
 A list of all GRASS RFC documents, with status. 
 
-<ul>
+- \link rfc1_psc RFC 1: Project Steering Committee Guidelines\endlink (Adopted)
+- \link rfc2_psc RFC 2: Legal aspects of code contributions\endlink (Adopted)
+- \link rfc3_psc RFC 3: PSC Voting Procedures\endlink (Proposed)
 
-<li> \link rfc1_psc RFC 1: Project Steering Committee Guidelines\endlink (Adopted)
-<li> \link rfc2_psc RFC 2: Legal aspects of code contributions\endlink (Adopted)
-<li> \link rfc3_psc RFC 3: PSC Voting Procedures\endlink (Proposed)
-</ul>
-
-<hr>
 <a href="http://grass.osgeo.org/">GRASS GIS</a>
 */
-