[prev in list] [next in list] [prev in thread] [next in thread] 

List:       incubator-cvs
Subject:    cvs commit: incubator-site/src/documentation/content/xdocs/drafts voting.xml
From:       coar () apache ! org
Date:       2002-11-05 22:22:44
[Download RAW message or body]

coar        2002/11/05 14:22:44

  Modified:    src/documentation/content/xdocs/drafts voting.xml
  Log:
  more flesh.. more flesh!
  
  Revision  Changes    Path
  1.2       +77 -7     incubator-site/src/documentation/content/xdocs/drafts/voting.xml
  
  Index: voting.xml
  ===================================================================
  RCS file: /home/cvs/incubator-site/src/documentation/content/xdocs/drafts/voting.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -u -r1.1 -r1.2
  --- voting.xml	5 Nov 2002 12:40:02 -0000	1.1
  +++ voting.xml	5 Nov 2002 22:22:43 -0000	1.2
  @@ -23,31 +23,101 @@
         <p>There are essentially two types of voting:</p>
         <p/>
         <ol>
  -        <li>Code inclusion, and</li>
  +        <li>Code modifications, and</li>
           <li>Procedural.</li>
         </ol>
         <p/>
  -      <p></p>
  +      <p>Votes on procedural issues follow the common format of
  +      majority rule unless otherwise stated.  That is, if there
  +      are more favourable votes than unfavourable ones, the
  +      issue is considered to have passed -- regardless of the number
  +      of votes in each category.  (If the number of votes seems
  +      too small to be representative of a community consensus,
  +      the issue is typically not pursued.  However, see
  +      the description of
  +      <link href="#LazyConsensus">lazy consensus</link>
  +      for a modifying factor.)</p>
  +      <p>Votes on code modifications follow a different model.
  +      In this scenario, a negative vote constitutes a
  +      <link href="#Veto">veto</link>, which cannot be overridden.
  +      Again, this model may be modified by a
  +      <link href="#LazyConsensus">lazy consensus</link>
  +      declaration when the request for a vote is raised, but
  +      the full-stop nature of a negative vote is unchanged.
  +      Under normal (non-lazy consensus) conditions, the proposal
  +      requires three positive votes and no negative ones in
  +      order to pass; if it fails to garner the requisite amount of
  +      support, it doesn't -- and typically is either withdrawn,
  +      modified, or simply allowed to languish as an open issue
  +      until someone gets around to removing it.</p>
   
         <section>
           <title>Binding Votes</title>
  -        <p></p>
  +        <p>Who is permitted to vote is, to some extent, a
  +        community-specific thing.  However, the basic rule is
  +        that committers have binding votes, and all others are
  +        either discouraged from voting (to keep the noise down) or
  +        else have their votes considered of an indicative or
  +        advisory nature only.</p>
  +        <p>That's the general rule.  In actual fact, things tend
  +        to be a little looser, and procedural votes from non-committers
  +        are sometimes considered binding if the voter has
  +        acquired enough merit and respect in the community.
  +        Only votes by committers are considered binding on
  +        code-modification issues, however.</p>
         </section>
   
         <section>
           <title>Expressing Votes: +1, 0, -1, and Fractions</title>
  -        <p></p>
  +        <p>The voting process in Apache may seem more than a little
  +        weird if you've never enountered it before.  Votes are represented
  +        as numbers between -1 and +1, with '-1' meaning 'no' and '+1'
  +        meaning 'yes.'</p>
  +        <p>Votes should generally be permitted to run for at least 72
  +        hours to provide an opportunity for all concerned persons
  +        to participate regardless of their geographic locations.</p>
  +
  +        <section>
  +          <title>Votes on Code Modification</title>
  +          <p>For code-modification votes, +1 votes are in favour of
  +          the proposal, but -1 votes are
  +          <link href="#Veto">vetos</link>
  +          and kill the proposal dead until all vetoers withdraw their
  +          -1 votes.</p>
  +          <p>Unless a vote has been declared as using
  +          <link href="#LazyConsensus">lazy consensus</link>,
  +          three +1 votes are required for a code-modification proposal
  +          to pass.</p>
  +          <p>Whole numbers are recommended for this type of vote,
  +          as the opinion being expressed is Boolean: 'I approve/do not approve
  +          of this change.'</p>
  +        </section>
  +
  +        <section>
  +          <title>Procedural Votes or Opinion Polls</title>
  +          <p></p>
  +        </section>
         </section>
   
         <section>
  -        <title>Vetos</title>
  -        <p></p>
  +        <title><anchor id="Veto"/>Vetos</title>
  +        <p>A code-modification proposal may be stopped dead in
  +        its tracks by a -1 vote by a qualified voter.  This constitutes
  +        a veto, and it cannot be overruled nor overridden by anyone.
  +        Vetos stand until and unless withdrawn by their casters.</p>
  +        <p>To prevent vetos from being used capriciously, they
  +        must be accompanied by a technical justification showing
  +        why the change is bad (opens a security exposure, negatively
  +        affects performance, <em>etc.</em>).  A veto without a
  +        justification is invalid and has no weight.</p>
         </section>
   
       </section>
   
       <section>
  -      <title>Consensus Gauging through Silence</title>
  +      <title>
  +        <anchor id="LazyConsensus"/>Consensus Gauging through Silence
  +      </title>
         <p>An alternative to voting that is sometimes used to measure
         the acceptability of something is the concept of
         <em>lazy consensus</em>.</p>
  
  
  

[prev in list] [next in list] [prev in thread] [next in thread]