rfc moved to Trac (http://trac.osgeo.org/grass/wiki/RFC)

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

rfc/Makefile

@@ -1,19 +0,0 @@
-MODULE_TOPDIR = ..
-
-include $(MODULE_TOPDIR)/include/Make/Vars.make
-include $(MODULE_TOPDIR)/include/Make/Doxygen.make
-
-all:
-	doxygen $(MODULE_TOPDIR)/include/Make/Doxyfile_arch_html
-	@echo ""
-	@echo "RFC list generated: html/index.html"
-
-htmldocs-single: all
-
-clean:
-	rm -fr latex/ html/
-cleandocs: clean
-
-DOXNAME=rfc_list
-DOXINPUT=$(DOXNAME).dox
-DOXOUTPUT=$(DOXNAME)

rfc/RFC1_PSC.dox

@@ -1,131 +0,0 @@
-/*!
-\page rfc1_psc RFC 1: Project Steering Committee Guidelines
-
-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
-
-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 OSGeo.
-
-\section tor Terms of Reference
-
-The two primary functions of the PSC are:
-
--# To enforce control over the GRASS codebase. This can be summarised as:
- - Enforce mechanisms to ensure quality control.
- - Ensure compliance with all required legal measures.
--# 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.
-
-\subsection control Codebase Control
-
-\subsubsection quality 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 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:
-
-- 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.
-
-\section operation Operation of the PSC
-
-A dedicated <a href="http://grass.osgeo.org/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) <b>must</b> have a vote called before a 
-decision is reached:
-
-- Granting source code repository write access for new developers
-- Selection of a committee Chair
-
-\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.
-
-
-*/

rfc/RFC2_PSC.dox

@@ -1,88 +0,0 @@
-/*!
-\page rfc2_psc RFC 2: Legal aspects of code contributions
-
-Author: Markus Neteler (based on GDAL.org/RFC3)
-
-Contact: neteler AT osgeo.org
-
-Status: Adopted (8 Dec 2006)
-
-\section legal Legal aspects
-
-GRASS developers have to keep the code base clear of improperly
-contributed code. It is important to the GRASS users, developers and
-the OSGeo foundation to avoid contributing any code to the project
-without it being clearly licensed under the project license or a
-compliant license. In this document, a "committer" is understood to be
-a developer with write access to the GRASS source code repository.
-
-Generally speaking, the key issues are that those individuals
-providing code to be included in the GRASS repository understand that
-the code will be released under the GPL >=2 license, and that the
-person providing the code has the right to contribute the code.  In
-order to verify this, the committer must have a clear understanding of
-the license themselves. When committing 3rd party contributions, the
-committer should verify the understanding unless the committer is very
-comfortable that the contributor understands the license (for instance
-frequent contributors).
-
-If the contribution was developed on behalf of an employer (on work
-time, as part of a work project, etc) then it is important that an
-appropriate representative of the employer understand that the code
-will be contributed under the GPL license. The arrangement should be
-cleared with an authorized supervisor/manager, etc.
-
-The code should be developed by the contributor, or the code should be
-from a source which can be rightfully contributed such as from the
-public domain, or from an open source project under a compatible
-license.
-
-All unusual situations need to be discussed and/or documented.
-
-Committers should adhere to the following guidelines, and may be
-personally legally liable for improperly contributing code to the
-source repository:
-
-- Make sure the contributor (and possibly employer) is aware of the
-  contribution terms.
-
-- 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).
-
-- 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.
-
-- 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.
-
-- 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.
-
-Questions regarding GRASS GIS should be directed to the
-GRASS Development Team at the following address:
-
-Internet:
-  http://grass.osgeo.org/impressum.html and
-  http://grass.osgeo.org
-
-Postal address:
-
-\verbatim
- GRASS Development Team
- c/o M. Neteler
- Fondazione Mach - Centre for Alpine Ecology
- 38100 Viote del Monte Bondone (Trento)
- Italy
- email: neteler AT cealp.it
-\endverbatim
-*/

rfc/RFC3_PSC.dox

@@ -1,51 +0,0 @@
-/*!
-\page rfc3_psc RFC 3: PSC Voting Procedures
-
-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
-
-In brief, the PSC votes on proposals on the dedicated PSC mailing list.
-Proposals are available for review for at least four business days, and a 
-single veto is sufficient to delay progress although ultimately a majority 
-of committee members can pass a proposal.
-
-\section detailed_process Detailed Process
-
--# 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.
--# 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).
--# 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.
--# 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.
--# 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.
-
-*/

rfc/psc_motions.dox

@@ -1,62 +0,0 @@
-/*!
-\page psc_motions Motions of the GRASS Project Steering Committee
-
-See also: <a href="http://grasswiki.osgeo.org/wiki/PSC_Agenda">PSC Agenda</a>.
-
-\section motions2014 Motions of 2014
-
-- SVN write access to Margherita Di Leo (granted, 6 Apr 2014)
-
-\section motions2013 Motions of 2013
-
-- SVN write access to Štěpán Turek (granted, 14 Feb 2013)
-
-\section motions2012 Motions of 2012
-
-- SVN write access to Pietro Zambelli (granted, 9 Oct 2012)
-- SVN write access to Václav Petráš (granted, 6 Apr 2012)
-
-\section motions2011 Motions of 2011
-
-- SVN write access to Luca Delucchi (granted, 28 Jun 2011)
-- SVN write access to Anna Kratochvílová (granted, 1 Jun 2011)
-
-\section motions2010 Motions of 2010
-
-- SVN write access to Helmut Kudrnovsky (granted, 23 Jan 2010)
-- SVN write access to Anne Ghisla (granted, 5 Jan 2010)
-<!--
-<li> \link rfc3_psc RFC 3: PSC Voting Procedures
-</ul>
--->
-
-\section motions2009 Motions of 2009
-
-- SVN write access to Colin Nielsen (3 Sep 2009)
-- SVN write access to Markus Metz (14 Jan 2009)
-
-\section motions2008 Motions of 2008
-
-- SVN write access to Yann Chemin (granted, 12 Sep 2008)
-- 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)
-
-\section motions2007 Motions of 2007
-
-- 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
-
-- 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>)
-- 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

@@ -1,13 +0,0 @@
-/*!
-\page RFC List of the GRASS Project Steering Committee
-
-List of \link psc_motions Motions of the GRASS Project Steering Committee\endlink
-
-A list of all GRASS RFC documents, with status. 
-
-- \subpage rfc1_psc (Adopted)
-- \subpage rfc2_psc (Adopted)
-- \subpage rfc3_psc (Proposed)
-
-<a href="http://grass.osgeo.org/">GRASS GIS</a>
-*/