[mapserver-commits] r8140 - trunk/docs/development/rfc

[svn at osgeo.org]

Author: hobu
Date: 2008-11-30 13:56:21 -0500 (Sun, 30 Nov 2008)
New Revision: 8140

Modified:
   trunk/docs/development/rfc/ms-rfc-1.txt
Log:
hard linebreaks at 80

Modified: trunk/docs/development/rfc/ms-rfc-1.txt
===================================================================
--- trunk/docs/development/rfc/ms-rfc-1.txt	2008-11-30 18:54:06 UTC (rev 8139)
+++ trunk/docs/development/rfc/ms-rfc-1.txt	2008-11-30 18:56:21 UTC (rev 8140)
@@ -15,35 +15,54 @@
 This document describes how the MapServer Technical Steering Committee 
 determines membership, and makes decisions on MapServer technical issues.
 
-In brief the technical team votes on proposals on mapserver-dev.  Proposals are available for review for at least two days, and a single veto is sufficient delay progress though ultimately a majority of members can pass a proposal.
+In brief the technical team votes on proposals on mapserver-dev.  Proposals 
+are available for review for at least two days, and a single veto is 
+sufficient delay progress though ultimately a majority of members can 
+pass a proposal.
 
 
 Detailed Process
 ================
 
-1. Proposals are written up and submitted on the mapserver-dev mailing list for discussion and voting, by any interested party, not just committee members.
+1. Proposals are written up and submitted on the mapserver-dev mailing list for 
+   discussion and voting, by any interested party, not just committee members.
 
-2. Proposals need to be available for review for at least two business days before a final decision can be made. 
+2. Proposals need to be available for review 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. 
+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.
+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. 
+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. 
 
-6. Anyone may comment on proposals on the list, but only members of the Technical Steering Committee's votes will be counted. 
+6. Anyone may comment on proposals on the list, but only members of 
+   the Technical Steering Committee's votes will be counted. 
 
-7. A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1). 
+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. 
+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). 
+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 Technical Steering Committee (perhaps as part of a TSC file in CVS). 
+11. The Chair is responsible for keeping track of who is a member of the 
+    Technical Steering Committee (perhaps as part of a TSC file in CVS). 
 
-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. 
+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. 
 
 13. The Chair adjudicates in cases of disputes about voting.
 
@@ -73,8 +92,11 @@
 ==============
 
 * 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.
-* It is anticipated that seperate "committees" will exist to manage conferences, documentation and web sites. 
+* 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.
+* It is anticipated that seperate "committees" will exist to 
+  manage conferences, documentation and web sites. 
 
 
 Bootstrapping
@@ -83,6 +105,7 @@
 Steve Lime is declared initial Chair of the Technical Steering Committee.
 
 Steve Lime, Daniel Morissette, Frank Warmerdam, Sean Gilles, Assefa
-Yewondwossen, Howard Butler and Perry Nacionales are declared to be the founding Technical Steering Committee.
+Yewondwossen, Howard Butler and Perry Nacionales are declared to be the 
+founding Technical Steering Committee.