incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@apache.org
Subject cvs commit: incubator-site/src/documentation/content/xdocs/drafts mailing-lists.xml glossary.xml voting.xml
Date Fri, 08 Nov 2002 20:36:11 GMT
coar        2002/11/08 12:36:11

  Modified:    build/site process.html process.pdf
               build/site/drafts glossary.html glossary.pdf voting.html
                        voting.pdf
               src/documentation/content/xdocs process.xml
               src/documentation/content/xdocs/drafts glossary.xml
                        voting.xml
  Added:       src/documentation/content/xdocs/drafts mailing-lists.xml
  Log:
  add some clarifications and some new terminology
  
  Revision  Changes    Path
  1.4       +35 -23    incubator-site/build/site/process.html
  
  Index: process.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/process.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- process.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ process.html	8 Nov 2002 20:36:10 -0000	1.4
  @@ -202,7 +202,7 @@
   <a href="#N10016">Entry to/Exit from the Incubator</a>
   </li>
   <li>
  -<a href="#N10052">The Process of Incubation</a>
  +<a href="#N10056">The Process of Incubation</a>
   </li>
   </ul>
       
  @@ -214,9 +214,19 @@
         and even so it will be refined by experience.  So don't take
         anything here as either complete or completely authoritative.</div>
   </div>
  -<p>A project (or <em>codebase</em>, since 'project' has a specific
  -      meaning in Apache-land) might reach the Incubator by referral,
  -      or be born there.  Here are some of the ways a codebase might
  +<div class="frame note">
  +<div class="label">Note</div>
  +<div class="content">Things in the Incubator may end up
  +      being new ASF projects,
  +      or they may end up being incorporated into some existing
  +      project (sometimes called a 'subproject').  But while they're
  +      in the Incubator, they're neither -- so they need to be called
  +      something else.  The term tentatively chosen by one of
  +      the Incubator team (the one writing these words ;-) is
  +      <strong>podling</strong>.</div>
  +</div>
  +<p>A podling might reach the Incubator by referral,
  +      or be born there.  Here are some of the ways a podling might
         get here:</p>
   <ul>
           
  @@ -236,7 +246,7 @@
         has a number of different options:</p>
   <ul>
           
  -<li>The codebase may be declared non-viable ('dead'), and may
  +<li>The podling's codebase may be declared non-viable ('dead'), and may
           either languish in the Incubator or be relocated to a
           software cemetery;</li>
           
  @@ -245,25 +255,25 @@
           foundation may return title to the code and wave
           <em>sayonara</em>;</li>
           
  -<li>The codebase may fit best within one of the existing
  +<li>The podling may fit best within one of the existing
           ASF projects, and negociations between the Incubator and that
  -        project result in the codebase moving there;</li>
  +        project result in the podling moving there;</li>
           
  -<li>The codebase may seem to belong with an existing project,
  +<li>The podling may seem to belong with an existing project,
           but the project in question refuses to accept it [what happens?];</li>
           
  -<li>The codebase and community represent something sufficiently
  +<li>The podling represents something sufficiently
           unique as to warrant the creation of a completely new ASF
           project.</li>
         
   </ul>
   <p>Those are essentially the ins and outs of the Incubator
         project.  The remaining piece is, of course, what goes on
  -      <em>inside</em> the Incubator with a codebase that hasn't
  +      <em>inside</em> the Incubator with a podling that hasn't
         graduated/matured yet?</p>
   
       
  -<a name="N10052"></a>
  +<a name="N10056"></a>
   <h3>The Process of Incubation</h3>
   <div class="frame warning">
   <div class="label">Warning</div>
  @@ -272,7 +282,7 @@
         anything here as either complete or completely authoritative.</div>
   </div>
   <p>From the standpoint of a codebase being incubated, there are
  -      a couple of things that will need to happen before it will even
  +      some things that will need to happen before it will even
         be possible for it to exit from the Incubator:</p>
   <ol>
           
  @@ -288,7 +298,7 @@
         that, if and when the Foundation begins distributing it, it has
         clear title to do so and isn't infringing on anyone's rights.</p>
   <p>The process of incubation of the codebase's community is
  -      a little different, and consists primarily of assuring that
  +      a little different, and consists primarily of ensuring that
         the community has adopted the Apache methodologies and guidelines,
         and all legal concerns have been addressed.  This means the
         following (among others):</p>
  @@ -303,21 +313,23 @@
   <li>The community has decided on a policy for the
           composition of its 'steering committee';</li>
           
  -<li>The exit strategy for the codebase must be defined up front.
  -        In particular, the incubated codebase needs to know:
  +<li>The exit strategy for the podling has defined up front.
  +        In particular, the incubated podling needs to know:
           <ol>
             
  -<li>What ASF PMC it will be graduating to. This implies
  -          that the PMC is question is sponsoring, at least in part,
  -          the incubated codebase.</li>
  +<li>To which ASF project (if any) it will be graduating. This implies
  +          that the project is question is sponsoring the podling, at least
  +          in part.</li>
             
  -<li>The expected timeframe that the incubated project will
  +<li>The expected timeframe that the podling will
             stay in the incubator. This is determined by mutual consent
  -          among the codebase, the graduation PMC and the Incubator.</li>
  +          among the community of the podling, the graduation
  +          PMC of the project to which the codebase and community will
  +          move at the end of incubation (if any), and the Incubator PMC.</li>
             
  -<li>The "graduation requirements" before the codebase can
  -          leave the Incubator. Basically, what are the pre-defined goals
  -          that must be met before the codebase can leave the Incubator</li>
  +<li>The "graduation requirements" for leaving the Incubator.
  +          Basically, what are the pre-defined goals
  +          that must be met before the podling can leave the Incubator?</li>
            
   </ol>
           
  
  
  
  1.3       +54 -81    incubator-site/build/site/process.pdf
  
  	<<Binary file>>
  
  
  1.4       +114 -22   incubator-site/build/site/drafts/glossary.html
  
  Index: glossary.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/drafts/glossary.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- glossary.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ glossary.html	8 Nov 2002 20:36:10 -0000	1.4
  @@ -270,7 +270,7 @@
           The ability to make direct changes to the code that exists under
           CVS control is called
           <a href="#CommitAccess">commit access</a>
  -        (from the <span class="codefrag">cvs commit</span> command) This process
  +        (from the <span class="codefrag">cvs commit</span> command). This process
           patches the actual offical code.
           Also see <em><a href="#Karma">Karma</a></em>.</dd>
   
  @@ -285,16 +285,28 @@
   
           
   <dt>
  -<strong><a name="CommitThenReview"></a>Commit-then-Review</strong>
  +          
  +<strong>
  +            <a name="CommitThenReview"></a>Commit-then-Review
  +          </strong>
  +        
   </dt>
           
   <dd>(Often abbreviated 'CTR' or 'C-T-R'.)  A policy governing
           code changes which permits developers to make changes at will,
           with the possibility of being retroactively
  -        <a href="#Veto">vetoed</a>.  The C-T-R model is
  +        <a href="#Veto">vetoed</a>.  C-T-R is an application of
  +        decision making through
  +        <a href="#LazyConsensus">lazy consensus</a>.
  +        The C-T-R model is
           useful in rapid-prototyping environments, but because of the
  -        lack of mandatory review it may permit more bugs through.  Compare
  -        <em><a href="#ReviewThenCommit">Review-Then-Commit</a></em>.</dd>
  +        lack of mandatory review it may permit more bugs through
  +        than the
  +        <a href="#ReviewThenCommit">R-T-C</a> alternative.  Compare
  +        <em><a href="#ReviewThenCommit">Review-Then-Commit</a></em>,
  +        and see the description of the
  +        <a href="voting.html">voting process</a>
  +</dd>
   
           
   <dt>
  @@ -305,6 +317,24 @@
   
           
   <dt>
  +          
  +<strong>
  +            <a name="ConsensusApproval"></a>Consensus Approval
  +          </strong>
  +        
  +</dt>
  +        
  +<dd>
  +          'Consensus approval' refers to a
  +          <a href="#Vote">vote</a>
  +          (sense 1) which has completed with
  +          <strong>at least three binding +1 votes</strong> and
  +          <strong>no <a href="#Veto">vetos</a></strong>.  Compare
  +          <em><a href="#MajorityApproval">majority approval</a></em>.
  +        </dd>
  +
  +        
  +<dt>
   <strong><a name="Contributor"></a>Contributor</strong>
   </dt>
           
  @@ -315,8 +345,9 @@
           either code or documentation or otherwise.
           This does not, in and of itself, imply
           <a href="#CommitAccess">commit access</a>, though
  -        frequent and valued contributors are readily voted on for
  -        such access.</dd>
  +        frequent and valued contributors are readily
  +        <a href="#Vote">voted</a>
  +        on for such access.</dd>
   
           
   <dt>
  @@ -419,18 +450,48 @@
   
           
   <dt>
  -<strong><a name="Lazy consensus"></a>Lazy consensus</strong>
  +          
  +<strong>
  +            <a name="LazyConsensus"></a>
  +            <a name="LazyApproval"></a>
  +            Lazy consensus
  +          </strong>
  +        
   </dt>
           
  -<dd>A feature of the
  -        <a href="#CommitThenReview">C-T-R</a>
  -        commit model that assumes general consent if no responses are
  +<dd>(Also called 'lazy approval'.)  A decision-making policy
  +        which assumes general consent if no responses are
           posted within a defined period.  For example, "I'm going to
           commit this by lazy consensus if no-one objects within the
           next three days."  Also see
  -        <em><a href="#CommitThenReview">Commit-Then-Review</a></em>
  -        and
  -        <em><a href="#ReviewThenCommit">Review-Then-Commit</a></em>.</dd>
  +        <em><a href="#ConsensusApproval">consensus approval</a></em>,
  +        <em><a href="#MajorityApproval">majority approval</a></em>,
  +        and the description of the
  +        <a href="voting.html">voting process</a>.</dd>
  +
  +        
  +<dt>
  +          
  +<strong>
  +            <a name="MajorityApproval"></a>Majority Approval
  +          </strong>
  +        
  +</dt>
  +        
  +<dd>
  +          Refers to a
  +          <a href="#Vote">vote</a> (sense 1) which has completed with
  +          <strong>at least three binding +1 votes</strong>
  +          and more +1 votes than -1 votes.  (<em>I.e.</em>,
  +          a simple majority with a minimum quorum of three positive
  +          votes.)  Note that in votes requiring majority approval
  +          a -1 vote is simply a vote against, <strong>not</strong> a
  +          <a href="#Veto">veto</a>.
  +          Compare
  +          <em><a href="#ConsensusApproval">consensus approval</a></em>.
  +          See also the description of the
  +          <a href="voting.html">voting process</a>.
  +        </dd>
   
           
   <dt>
  @@ -548,6 +609,15 @@
   
           
   <dt>
  +<strong><a name="Podling"></a>Podling</strong>
  +</dt>
  +        
  +<dd>A codebase and its community while in the process of being
  +        incubated.  See the description of the
  +        <a href="../process.html#Podling">incubation process</a>.</dd>
  +
  +        
  +<dt>
   <strong><a name="President"></a>President</strong>
   </dt>
           
  @@ -567,16 +637,20 @@
   
           
   <dt>
  -<strong><a name="ReviewThenCommit"></a>Review-Then-Commit</strong>
  +          
  +<strong>
  +            <a name="ReviewThenCommit"></a>Review-Then-Commit
  +          </strong>
  +        
   </dt>
           
   <dd>(Often referenced as 'RTC' or 'R-T-C'.)  Commit policy which
  -        requires that all changes be reviewed and receive at least three +1
  -        <a href="#Vote">votes</a>
  -        -- and no
  -        <a href="#Veto">vetos</a>
  -        -- in order to be committed.  Compare
  -        <em><a href="#CommitThenReview">Commit-Then-Review</a></em>.</dd>
  +        requires that all changes receive
  +        <a href="#ConsensusApproval">consensus approval</a>
  +        in order to be committed.  Compare
  +        <em><a href="#CommitThenReview">Commit-Then-Review</a></em>,
  +        and see the description of the
  +        <a href="voting.html">voting process</a>.</dd>
   
           
   <dt>
  @@ -660,7 +734,25 @@
   <strong><a name="Vote"></a>Vote</strong>
   </dt>
           
  -<dd>TBD.</dd>
  +<dd>
  +          
  +<strong>1.</strong> The process of making a formal decision.  ('The
  +          vote for foo will close in three days.')
  +          <strong>2.</strong> The expression of a positive or negative opinion,
  +          or a veto, as part of a formal decision.  ('My vote
  +          is -1 because foo smells bad.')
  +          <p>
  +<strong>Binding votes</strong> are those cast by
  +          committers in the project or on the codebase to which
  +          the decision applies.  Votes cast by others are
  +          advisory or indicative only.</p>
  +          See also
  +          <em><a href="#ConsensusApproval">consensus approval</a></em>,
  +          <em><a href="#MajorityApproval">majority approval</a></em>,
  +          <em><a href="#LazyConsensus">lazy consensus</a></em>,
  +          and the description of the
  +          <a href="voting.html">voting process</a>.
  +        </dd>
   
         
   </dl>
  
  
  
  1.3       +798 -320  incubator-site/build/site/drafts/glossary.pdf
  
  	<<Binary file>>
  
  
  1.4       +25 -19    incubator-site/build/site/drafts/voting.html
  
  Index: voting.html
  ===================================================================
  RCS file: /home/cvs/incubator-site/build/site/drafts/voting.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -u -r1.3 -r1.4
  --- voting.html	6 Nov 2002 17:28:18 -0000	1.3
  +++ voting.html	8 Nov 2002 20:36:11 -0000	1.4
  @@ -161,30 +161,38 @@
   </p>
   <ul class="minitoc">
   <li>
  -<a href="#N10019">Consensus Gauging through Voting</a>
  +<a href="#N1001B">Consensus Gauging through Voting</a>
   <ul class="minitoc">
   <li>
  -<a href="#N10043">Binding Votes</a>
  +<a href="#N10045">Binding Votes</a>
   </li>
   <li>
  -<a href="#N1004F">Implications of Voting</a>
  +<a href="#N10051">Implications of Voting</a>
   </li>
   <li>
  -<a href="#N1006E">Expressing Votes: +1, 0, -1, and Fractions</a>
  +<a href="#N10070">Expressing Votes: +1, 0, -1, and Fractions</a>
   </li>
   <li>
  -<a href="#N10099">Vetos</a>
  +<a href="#N1009B">Vetos</a>
   </li>
   </ul>
   </li>
   <li>
  -<a href="#N100AB">
  -        Consensus Gauging through Silence
  -      </a>
  +<a href="#N100AC">Consensus Gauging through Silence</a>
   </li>
   </ul>
  +    <!--
  +         <section>
  +           <title>Reasons for Votes</title>
  +           <p>People tend to avoid conflict and thrash around looking for
  +           something to substitute - somebody in charge, a rule, a process,
  +           stagnation.  None of these tend to be very good substitutes
  +           for doing the hard work of resolving the conflict.</p>
  +         </section>
  +         -->
  +
       
  -<a name="N10019"></a>
  +<a name="N1001B"></a>
   <h3>Consensus Gauging through Voting</h3>
   <p>Because one of the fundamental aspects of accomplishing things
         within the Apache framework is doing so by consensus, there obviously
  @@ -223,7 +231,7 @@
         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>
  -<a name="N10043"></a>
  +<a name="N10045"></a>
   <h4>Binding Votes</h4>
   <p>Who is permitted to vote is, to some extent, a
           community-specific thing.  However, the basic rule is
  @@ -237,7 +245,7 @@
           acquired enough merit and respect in the community.
           Only votes by committers are considered binding on
           code-modification issues, however.</p>
  -<a name="N1004F"></a>
  +<a name="N10051"></a>
   <h4>Implications of Voting</h4>
   <p>In some cases and communities, the exercise of a vote carries
           some responsibilities that may not be immediately obvious.  For
  @@ -258,7 +266,7 @@
           the patch was tested and found to be <em>not</em>-good, although
           the veto (for such it is in this case) may be based on other
           technical grounds.</p>
  -<a name="N1006E"></a>
  +<a name="N10070"></a>
   <h4>Expressing Votes: +1, 0, -1, and Fractions</h4>
   <p>The voting process in Apache may seem more than a little
           weird if you've never enountered it before.  Votes are represented
  @@ -267,7 +275,7 @@
   <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>
  -<a name="N10079"></a>
  +<a name="N1007B"></a>
   <h4>Votes on Code Modification</h4>
   <p>For code-modification votes, +1 votes are in favour of
             the proposal, but -1 votes are
  @@ -281,10 +289,10 @@
   <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>
  -<a name="N10090"></a>
  +<a name="N10092"></a>
   <h4>Procedural Votes or Opinion Polls</h4>
   <p></p>
  -<a name="N10099"></a>
  +<a name="N1009B"></a><a name="Veto"></a>
   <h4>Vetos</h4>
   <p>A code-modification proposal may be stopped dead in
           its tracks by a -1 vote by a qualified voter.  This constitutes
  @@ -297,10 +305,8 @@
           justification is invalid and has no weight.</p>
   
       
  -<a name="N100AB"></a>
  -<h3>
  -        Consensus Gauging through Silence
  -      </h3>
  +<a name="N100AC"></a><a name="LazyConsensus"></a>
  +<h3>Consensus Gauging through Silence</h3>
   <p>An alternative to voting that is sometimes used to measure
         the acceptability of something is the concept of
         <em>lazy consensus</em>.</p>
  
  
  
  1.3       +40 -53    incubator-site/build/site/drafts/voting.pdf
  
  	<<Binary file>>
  
  
  1.7       +31 -21    incubator-site/src/documentation/content/xdocs/process.xml
  
  Index: process.xml
  ===================================================================
  RCS file: /home/cvs/incubator-site/src/documentation/content/xdocs/process.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -u -r1.6 -r1.7
  --- process.xml	6 Nov 2002 17:28:19 -0000	1.6
  +++ process.xml	8 Nov 2002 20:36:11 -0000	1.7
  @@ -20,9 +20,17 @@
         and even so it will be refined by experience.  So don't take
         anything here as either complete or completely authoritative.</warning>
   
  -      <p>A project (or <em>codebase</em>, since 'project' has a specific
  -      meaning in Apache-land) might reach the Incubator by referral,
  -      or be born there.  Here are some of the ways a codebase might
  +      <note id="Podling">Things in the Incubator may end up
  +      being new ASF projects,
  +      or they may end up being incorporated into some existing
  +      project (sometimes called a 'subproject').  But while they're
  +      in the Incubator, they're neither -- so they need to be called
  +      something else.  The term tentatively chosen by one of
  +      the Incubator team (the one writing these words ;-) is
  +      <strong>podling</strong>.</note>
  +
  +      <p>A podling might reach the Incubator by referral,
  +      or be born there.  Here are some of the ways a podling might
         get here:</p>
         <ul>
           <li>Some group external to the Foundation wants to donate an
  @@ -36,25 +44,25 @@
         <p>That's the entry to the Incubator.  The exit path similarly
         has a number of different options:</p>
         <ul>
  -        <li>The codebase may be declared non-viable ('dead'), and may
  +        <li>The podling's codebase may be declared non-viable ('dead'), and may
           either languish in the Incubator or be relocated to a
           software cemetery;</li>
           <li>The community around the codebase may decide that the
           Apache Software Foundation isn't the right place, and so the
           foundation may return title to the code and wave
           <em>sayonara</em>;</li>
  -        <li>The codebase may fit best within one of the existing
  +        <li>The podling may fit best within one of the existing
           ASF projects, and negociations between the Incubator and that
  -        project result in the codebase moving there;</li>
  -        <li>The codebase may seem to belong with an existing project,
  +        project result in the podling moving there;</li>
  +        <li>The podling may seem to belong with an existing project,
           but the project in question refuses to accept it [what happens?];</li>
  -        <li>The codebase and community represent something sufficiently
  +        <li>The podling represents something sufficiently
           unique as to warrant the creation of a completely new ASF
           project.</li>
         </ul>
         <p>Those are essentially the ins and outs of the Incubator
         project.  The remaining piece is, of course, what goes on
  -      <em>inside</em> the Incubator with a codebase that hasn't
  +      <em>inside</em> the Incubator with a podling that hasn't
         graduated/matured yet?</p>
       </section>
   
  @@ -66,7 +74,7 @@
         anything here as either complete or completely authoritative.</warning>
   
         <p>From the standpoint of a codebase being incubated, there are
  -      a couple of things that will need to happen before it will even
  +      some things that will need to happen before it will even
         be possible for it to exit from the Incubator:</p>
         <ol>
           <li>All software in the codebase will need to have its copyright
  @@ -80,7 +88,7 @@
         clear title to do so and isn't infringing on anyone's rights.</p>
   
         <p>The process of incubation of the codebase's community is
  -      a little different, and consists primarily of assuring that
  +      a little different, and consists primarily of ensuring that
         the community has adopted the Apache methodologies and guidelines,
         and all legal concerns have been addressed.  This means the
         following (among others):</p>
  @@ -92,18 +100,20 @@
           is otherwise following the Apache guidelines;</li>
           <li>The community has decided on a policy for the
           composition of its 'steering committee';</li>
  -        <li>The exit strategy for the codebase must be defined up front.
  -        In particular, the incubated codebase needs to know:
  +        <li>The exit strategy for the podling has defined up front.
  +        In particular, the incubated podling needs to know:
           <ol>
  -          <li>What ASF PMC it will be graduating to. This implies
  -          that the PMC is question is sponsoring, at least in part,
  -          the incubated codebase.</li>
  -          <li>The expected timeframe that the incubated project will
  +          <li>To which ASF project (if any) it will be graduating. This implies
  +          that the project is question is sponsoring the podling, at least
  +          in part.</li>
  +          <li>The expected timeframe that the podling will
             stay in the incubator. This is determined by mutual consent
  -          among the codebase, the graduation PMC and the Incubator.</li>
  -          <li>The "graduation requirements" before the codebase can
  -          leave the Incubator. Basically, what are the pre-defined goals
  -          that must be met before the codebase can leave the Incubator</li>
  +          among the community of the podling, the graduation
  +          PMC of the project to which the codebase and community will
  +          move at the end of incubation (if any), and the Incubator PMC.</li>
  +          <li>The "graduation requirements" for leaving the Incubator.
  +          Basically, what are the pre-defined goals
  +          that must be met before the podling can leave the Incubator?</li>
            </ol>
           </li>
           <li>[what else?]</li>
  
  
  
  1.9       +99 -22    incubator-site/src/documentation/content/xdocs/drafts/glossary.xml
  
  Index: glossary.xml
  ===================================================================
  RCS file: /home/cvs/incubator-site/src/documentation/content/xdocs/drafts/glossary.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -u -r1.8 -r1.9
  --- glossary.xml	6 Nov 2002 17:28:20 -0000	1.8
  +++ glossary.xml	8 Nov 2002 20:36:11 -0000	1.9
  @@ -85,7 +85,7 @@
           The ability to make direct changes to the code that exists under
           CVS control is called
           <link href="#CommitAccess">commit access</link>
  -        (from the <code>cvs commit</code> command) This process
  +        (from the <code>cvs commit</code> command). This process
           patches the actual offical code.
           Also see <em><link href="#Karma">Karma</link></em>.</dd>
   
  @@ -94,18 +94,43 @@
           able to directly commit changes to an Apache codebase
           (<link href="#CommitAccess">commit access</link>).</dd>
   
  -        <dt><strong><anchor id="CommitThenReview"/>Commit-then-Review</strong></dt>
  +        <dt>
  +          <strong>
  +            <anchor id="CommitThenReview"/>Commit-then-Review
  +          </strong>
  +        </dt>
           <dd>(Often abbreviated 'CTR' or 'C-T-R'.)  A policy governing
           code changes which permits developers to make changes at will,
           with the possibility of being retroactively
  -        <link href="#Veto">vetoed</link>.  The C-T-R model is
  +        <link href="#Veto">vetoed</link>.  C-T-R is an application of
  +        decision making through
  +        <link href="#LazyConsensus">lazy consensus</link>.
  +        The C-T-R model is
           useful in rapid-prototyping environments, but because of the
  -        lack of mandatory review it may permit more bugs through.  Compare
  -        <em><link href="#ReviewThenCommit">Review-Then-Commit</link></em>.</dd>
  +        lack of mandatory review it may permit more bugs through
  +        than the
  +        <link href="#ReviewThenCommit">R-T-C</link> alternative.  Compare
  +        <em><link href="#ReviewThenCommit">Review-Then-Commit</link></em>,
  +        and see the description of the
  +        <link href="voting.html">voting process</link></dd>
   
           <dt><strong><anchor id="Community"/>Community</strong></dt>
           <dd>TBD</dd>
   
  +        <dt>
  +          <strong>
  +            <anchor id="ConsensusApproval"/>Consensus Approval
  +          </strong>
  +        </dt>
  +        <dd>
  +          'Consensus approval' refers to a
  +          <link href="#Vote">vote</link>
  +          (sense 1) which has completed with
  +          <strong>at least three binding +1 votes</strong> and
  +          <strong>no <link href="#Veto">vetos</link></strong>.
 Compare
  +          <em><link href="#MajorityApproval">majority approval</link></em>.
  +        </dd>
  +
           <dt><strong><anchor id="Contributor"/>Contributor</strong></dt>
           <dd>Someone who makes consistent improvements to the entities
           under an
  @@ -114,8 +139,9 @@
           either code or documentation or otherwise.
           This does not, in and of itself, imply
           <link href="#CommitAccess">commit access</link>, though
  -        frequent and valued contributors are readily voted on for
  -        such access.</dd>
  +        frequent and valued contributors are readily
  +        <link href="#Vote">voted</link>
  +        on for such access.</dd>
   
           <dt><strong><anchor id="CVS"/>CVS</strong></dt>
           <dd>The Concurrent Versioning System, a code management system
  @@ -179,16 +205,42 @@
           <strong>3.</strong> Any combination of senses 1 and two; they are
           indirectly related.</dd>
   
  -        <dt><strong><anchor id="Lazy consensus"/>Lazy consensus</strong></dt>
  -        <dd>A feature of the
  -        <link href="#CommitThenReview">C-T-R</link>
  -        commit model that assumes general consent if no responses are
  +        <dt>
  +          <strong>
  +            <anchor id="LazyConsensus"/>
  +            <anchor id="LazyApproval"/>
  +            Lazy consensus
  +          </strong>
  +        </dt>
  +        <dd>(Also called 'lazy approval'.)  A decision-making policy
  +        which assumes general consent if no responses are
           posted within a defined period.  For example, "I'm going to
           commit this by lazy consensus if no-one objects within the
           next three days."  Also see
  -        <em><link href="#CommitThenReview">Commit-Then-Review</link></em>
  -        and
  -        <em><link href="#ReviewThenCommit">Review-Then-Commit</link></em>.</dd>
  +        <em><link href="#ConsensusApproval">consensus approval</link></em>,
  +        <em><link href="#MajorityApproval">majority approval</link></em>,
  +        and the description of the
  +        <link href="voting.html">voting process</link>.</dd>
  +
  +        <dt>
  +          <strong>
  +            <anchor id="MajorityApproval"/>Majority Approval
  +          </strong>
  +        </dt>
  +        <dd>
  +          Refers to a
  +          <link href="#Vote">vote</link> (sense 1) which has completed with
  +          <strong>at least three binding +1 votes</strong>
  +          and more +1 votes than -1 votes.  (<em>I.e.</em>,
  +          a simple majority with a minimum quorum of three positive
  +          votes.)  Note that in votes requiring majority approval
  +          a -1 vote is simply a vote against, <strong>not</strong> a
  +          <link href="#Veto">veto</link>.
  +          Compare
  +          <em><link href="#ConsensusApproval">consensus approval</link></em>.
  +          See also the description of the
  +          <link href="voting.html">voting process</link>.
  +        </dd>
   
           <dt><strong><anchor id="Member"/>Member</strong></dt>
           <dd>An individual who has been elected to membership in
  @@ -268,6 +320,11 @@
           responsibilities implied.  See
           <em><link href="#Indemnification">Indemnification</link></em>.</dd>
   
  +        <dt><strong><anchor id="Podling"/>Podling</strong></dt>
  +        <dd>A codebase and its community while in the process of being
  +        incubated.  See the description of the
  +        <link href="../process.html#Podling">incubation process</link>.</dd>
  +
           <dt><strong><anchor id="President"/>President</strong></dt>
           <dd>Primary executive officer of the
           <link href="#ASF">ASF</link>, seriving at the direction of the
  @@ -279,14 +336,18 @@
           <link href="#Codebase">codebases</link>, overseen by
           a <link href="#PMC">PMC</link>.</dd>
   
  -        <dt><strong><anchor id="ReviewThenCommit"/>Review-Then-Commit</strong></dt>
  +        <dt>
  +          <strong>
  +            <anchor id="ReviewThenCommit"/>Review-Then-Commit
  +          </strong>
  +        </dt>
           <dd>(Often referenced as 'RTC' or 'R-T-C'.)  Commit policy which
  -        requires that all changes be reviewed and receive at least three +1
  -        <link href="#Vote">votes</link>
  -        -- and no
  -        <link href="#Veto">vetos</link>
  -        -- in order to be committed.  Compare
  -        <em><link href="#CommitThenReview">Commit-Then-Review</link></em>.</dd>
  +        requires that all changes receive
  +        <link href="#ConsensusApproval">consensus approval</link>
  +        in order to be committed.  Compare
  +        <em><link href="#CommitThenReview">Commit-Then-Review</link></em>,
  +        and see the description of the
  +        <link href="voting.html">voting process</link>.</dd>
   
           <dt><strong><anchor id="Subversion"/>Subversion</strong></dt>
           <dd>TBD</dd>
  @@ -341,7 +402,23 @@
           of their projects.</dd>
   
           <dt><strong><anchor id="Vote"/>Vote</strong></dt>
  -        <dd>TBD.</dd>
  +        <dd>
  +          <strong>1.</strong> The process of making a formal decision.  ('The
  +          vote for foo will close in three days.')
  +          <strong>2.</strong> The expression of a positive or negative opinion,
  +          or a veto, as part of a formal decision.  ('My vote
  +          is -1 because foo smells bad.')
  +          <p><strong>Binding votes</strong> are those cast by
  +          committers in the project or on the codebase to which
  +          the decision applies.  Votes cast by others are
  +          advisory or indicative only.</p>
  +          See also
  +          <em><link href="#ConsensusApproval">consensus approval</link></em>,
  +          <em><link href="#MajorityApproval">majority approval</link></em>,
  +          <em><link href="#LazyConsensus">lazy consensus</link></em>,
  +          and the description of the
  +          <link href="voting.html">voting process</link>.
  +        </dd>
   
         </dl>
   
  
  
  
  1.5       +14 -6     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.4
  retrieving revision 1.5
  diff -u -u -r1.4 -r1.5
  --- voting.xml	6 Nov 2002 17:28:20 -0000	1.4
  +++ voting.xml	8 Nov 2002 20:36:11 -0000	1.5
  @@ -15,6 +15,16 @@
     </header>
   
     <body>
  +    <!--
  +         <section>
  +           <title>Reasons for Votes</title>
  +           <p>People tend to avoid conflict and thrash around looking for
  +           something to substitute - somebody in charge, a rule, a process,
  +           stagnation.  None of these tend to be very good substitutes
  +           for doing the hard work of resolving the conflict.</p>
  +         </section>
  +         -->
  +
       <section>
         <title>Consensus Gauging through Voting</title>
         <p>Because one of the fundamental aspects of accomplishing things
  @@ -123,8 +133,8 @@
           </section>
         </section>
   
  -      <section>
  -        <title><anchor id="Veto"/>Vetos</title>
  +      <section id="Veto">
  +        <title>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.
  @@ -138,10 +148,8 @@
   
       </section>
   
  -    <section>
  -      <title>
  -        <anchor id="LazyConsensus"/>Consensus Gauging through Silence
  -      </title>
  +    <section id="LazyConsensus">
  +      <title>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>
  
  
  
  1.1                  incubator-site/src/documentation/content/xdocs/drafts/mailing-lists.xml
  
  Index: mailing-lists.xml
  ===================================================================
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
  <document>
    <header>
      <title>Apache Mailing Lists</title>
  
      <authors>
        <person name="The Apache Incubator Project"
          email="general@incubator.apache.org" />
      </authors>
  
      <notice>This document is a WIP (Work In Progress).</notice>
  
      <abstract>
        Description of the various community-wide Apache mailing lists.
      </abstract>
    </header>
  
    <body>
      <section>
        <title>Apache-Wide Mailing Lists</title>
        <p>Everything -- but <em>everything</em> -- inside the Apache
        world occurs or is reflected in email.  As some people say,
        'If it isn't in my email, it didn't happen.'  In addition to
        the <em>per</em>-project and special-group mailing lists,
        there are a few that cross all boundaries:</p>
        <dl>
          <dt><strong>committers</strong></dt>
          <dd/>
          <dt><strong>community</strong></dt>
          <dd/>
          <dt><strong>infrastucture</strong></dt>
          <dd/>
          <dt><strong>party</strong></dt>
          <dd/>
        </dl>
      </section>
    </body>
  </document>
  
  
  

Mime
View raw message