incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r537366 - in /incubator/public/trunk: site-author/guides/graduation.xml site-publish/guides/graduation.html
Date Sat, 12 May 2007 09:29:57 GMT
Author: rdonkin
Date: Sat May 12 02:29:56 2007
New Revision: 537366

URL: http://svn.apache.org/viewvc?view=rev&rev=537366
Log:
Improved content based on responses to first draft.

Modified:
    incubator/public/trunk/site-author/guides/graduation.xml
    incubator/public/trunk/site-publish/guides/graduation.html

Modified: incubator/public/trunk/site-author/guides/graduation.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/graduation.xml?view=diff&rev=537366&r1=537365&r2=537366
==============================================================================
--- incubator/public/trunk/site-author/guides/graduation.xml (original)
+++ incubator/public/trunk/site-author/guides/graduation.xml Sat May 12 02:29:56 2007
@@ -305,8 +305,8 @@
             <section id='notes-community'>
                 <title>On Community</title>
                 <p>
-Apache projects should be self-sustain and self-governing communities.
-The long term health of a project requires that a podling learns how to:
+Apache projects are self-sustain and self-governing communities.
+Long term success and health requires that these communities understand how to:
                 </p>
                 <ul>
                 	<li>
@@ -316,28 +316,80 @@
 take responsible collective action
 					</li>
 					<li>
-disagree on technical matters without destroying personal relationships
+disagree in public on technical matters without destroying personal relationships
 					</li>
 					<li>
-create a positive and inclusive atmosphere on the mailing lists
+create an open, positive and inclusive atmosphere on the mailing lists
 					</li>
 				</ul>
 				<p>
-One of the exit criteria is that the podling needs to have an open and diverse
-<a href="http://www.apache.org/foundation/glossary.html#Meritocracy">meritocratic</a>
community. 
-To show this to the <a href='/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29'>IPMC</a>,

-it can be beneficial to vote and accept a couple of 
-new contributors during incubation: this shows that you are open to accept new 
-developers and grow your community (note: this is not a requirement, but will help
-the graduation process). It will also allow you to diversify
-your community (which <em>is</em> a requirement for graduation).
+Graduation tests whether (in the opinion of the 
+<a href='/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29'>IPMC</a>)
+a podling has learnt enough and is responsible enough to sustain itself as such a community.
 				</p>
+				<section id='notes-open-and-diverse'><title>An Open And Diverse Community</title>
 				<p>
-The openness of your community is not only measured by the number of accepted contributors.

-You will need to have open and respectful discussions on the open mailing list(s). You need
to
-show that you can resolve technical conflict without destroying personal relationships. If
-you can manage this, then you have shown to be a lively, active and successful community.
+A major criteria for graduation is to have developed an open and diverse
+<a href="http://www.apache.org/foundation/glossary.html#Meritocracy">meritocratic</a>
community.
+Time has demonstrated that these kinds of community are more robust and productive than more
+closed ones.
+				</p> 
+				<p>
+As a project grows, it need to renew itself by accepting new committers.
+A project needs to learn how it can recruit new developers and committers into the community.
+Accepting new committers usually increases the diversity the project.
+So, this process is very beneficial. <a href='#notes-community'>Community building</a>

+requires energy which could have been spent on code development 
+but this spending is an important investment for the future of the project.
+				</p><p>
+The openness of the community is not only measured by the number of contributors. 
+Open and respectful discussions on the mailing lists are vital. Ways to resolve technical
conflict 
+without destroying personal relationships must be learn.
+				</p><p>
+Mailing lists are the lifeblood of Apache communities. They are the primary mode of discourse
+and constitute a public and historic record of the project. Other forms of communication

+(P2P, F2F, personal emails and so on) are secondary. There are well founded fears about 
+use of these media for project communication. Though many projects successfully blend other

+forms of communications, care needs to taken since out-of-band communications have lead
+to difficulties in the past. 
+				</p><p>
+Apache project mailing lists are public, well indexed and well archived. This allows anyone

+to monitor (both in real time and by browsing the archives) what's happening. Opinions expressed
+are public and poor behaviour risks a poster's reputation. 
+				</p><p>
+Private communications tend to be more candid but also more likely to be ill-judged.
+Back channel communication tend to be divisive: excluding some members of the group.
+This tends to have a corrosive effect on the collective spirit of the community. 
+Mistrust builds when opinions backed by blocks of developers arise fully formed on 
+list.
+				</p><p>
+Communication through other channels also reduces the chance of serendipity.
+As with most social networks, most subscribers to a mailing list never post 
+and most posts come from a tiny minority of subscribers. Some passive subscribers are
+just interested in where the project is going but others understand related fields
+and have a limited intersection of interest. This second group will often post when this

+topic arises on list. Using public mailing lists to develop designs allows the 
+chance encounter of ideas which often results in innovation.
+				</p><p>
+If alternative forums are used by a project, it is important to try to minimise the 
+chances of problems arising. All matters of substance need to be 
+moved back to the mailing lists. Public records should be kept and posted back to
+the list. Regular reminders should be posted to remind people that these other 
+secondary forms of communication exist.
+				</p><p>
+There are a limited number of topics such as security issues and discussions about people

+which are best handled in private. As much business of the project as possible should take
+place on public lists but the private list is available for those matters of a sensitive
nature.
+Good netiquette requires that permission from the poster should be sort before 
+making public posts made to a private list. 
+Try to avoid cross-posting between public and private forums.
+Take care not to post a reply to a private post to a public forum without permission.
+				</p><p>
+Learning to use mailing lists effectively is very important. If this can be achieved, 
+then you have shown to be a lively, active and successful community.
+The future looks bright.
 				</p>
+				</section>
                 <section id='community-vote'>
                     <title>Community Graduation Vote</title>
                         <p>

Modified: incubator/public/trunk/site-publish/guides/graduation.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/graduation.html?view=diff&rev=537366&r1=537365&r2=537366
==============================================================================
--- incubator/public/trunk/site-publish/guides/graduation.html (original)
+++ incubator/public/trunk/site-publish/guides/graduation.html Sat May 12 02:29:56 2007
@@ -206,6 +206,10 @@
 On Community
  </a>
  <ul>
+<li><a href='#notes-open-and-diverse'>
+An Open And Diverse Community
+ </a>
+</li>
 <li><a href='#community-vote'>
 Community Graduation Vote
  </a>
@@ -580,8 +584,8 @@
 </h3>
 <div class="section-content">
 <p>
-Apache projects should be self-sustain and self-governing communities.
-The long term health of a project requires that a podling learns how to:
+Apache projects are self-sustain and self-governing communities.
+Long term success and health requires that these communities understand how to:
                 </p>
 <ul>
                 	<li>
@@ -591,28 +595,91 @@
 take responsible collective action
 					</li>
 					<li>
-disagree on technical matters without destroying personal relationships
+disagree in public on technical matters without destroying personal relationships
 					</li>
 					<li>
-create a positive and inclusive atmosphere on the mailing lists
+create an open, positive and inclusive atmosphere on the mailing lists
 					</li>
 				</ul>
 <p>
-One of the exit criteria is that the podling needs to have an open and diverse
-<a href="http://www.apache.org/foundation/glossary.html#Meritocracy">meritocratic</a>
community. 
-To show this to the <a href="/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">IPMC</a>,

-it can be beneficial to vote and accept a couple of 
-new contributors during incubation: this shows that you are open to accept new 
-developers and grow your community (note: this is not a requirement, but will help
-the graduation process). It will also allow you to diversify
-your community (which <em>is</em> a requirement for graduation).
+Graduation tests whether (in the opinion of the 
+<a href="/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">IPMC</a>)
+a podling has learnt enough and is responsible enough to sustain itself as such a community.
+				</p>
+<h4>
+   <a name="notes-open-and-diverse">An Open And Diverse Community</a>
+</h4>
+<div class="section-content">
+<p>
+A major criteria for graduation is to have developed an open and diverse
+<a href="http://www.apache.org/foundation/glossary.html#Meritocracy">meritocratic</a>
community.
+Time has demonstrated that these kinds of community are more robust and productive than more
+closed ones.
+				</p>
+<p>
+As a project grows, it need to renew itself by accepting new committers.
+A project needs to learn how it can recruit new developers and committers into the community.
+Accepting new committers usually increases the diversity the project.
+So, this process is very beneficial. <a href="#notes-community">Community building</a>

+requires energy which could have been spent on code development 
+but this spending is an important investment for the future of the project.
+				</p>
+<p>
+The openness of the community is not only measured by the number of contributors. 
+Open and respectful discussions on the mailing lists are vital. Ways to resolve technical
conflict 
+without destroying personal relationships must be learn.
+				</p>
+<p>
+Mailing lists are the lifeblood of Apache communities. They are the primary mode of discourse
+and constitute a public and historic record of the project. Other forms of communication

+(P2P, F2F, personal emails and so on) are secondary. There are well founded fears about 
+use of these media for project communication. Though many projects successfully blend other

+forms of communications, care needs to taken since out-of-band communications have lead
+to difficulties in the past. 
 				</p>
 <p>
-The openness of your community is not only measured by the number of accepted contributors.

-You will need to have open and respectful discussions on the open mailing list(s). You need
to
-show that you can resolve technical conflict without destroying personal relationships. If
-you can manage this, then you have shown to be a lively, active and successful community.
+Apache project mailing lists are public, well indexed and well archived. This allows anyone

+to monitor (both in real time and by browsing the archives) what's happening. Opinions expressed
+are public and poor behaviour risks a poster's reputation. 
 				</p>
+<p>
+Private communications tend to be more candid but also more likely to be ill-judged.
+Back channel communication tend to be divisive: excluding some members of the group.
+This tends to have a corrosive effect on the collective spirit of the community. 
+Mistrust builds when opinions backed by blocks of developers arise fully formed on 
+list.
+				</p>
+<p>
+Communication through other channels also reduces the chance of serendipity.
+As with most social networks, most subscribers to a mailing list never post 
+and most posts come from a tiny minority of subscribers. Some passive subscribers are
+just interested in where the project is going but others understand related fields
+and have a limited intersection of interest. This second group will often post when this

+topic arises on list. Using public mailing lists to develop designs allows the 
+chance encounter of ideas which often results in innovation.
+				</p>
+<p>
+If alternative forums are used by a project, it is important to try to minimise the 
+chances of problems arising. All matters of substance need to be 
+moved back to the mailing lists. Public records should be kept and posted back to
+the list. Regular reminders should be posted to remind people that these other 
+secondary forms of communication exist.
+				</p>
+<p>
+There are a limited number of topics such as security issues and discussions about people

+which are best handled in private. As much business of the project as possible should take
+place on public lists but the private list is available for those matters of a sensitive
nature.
+Good netiquette requires that permission from the poster should be sort before 
+making public posts made to a private list. 
+Try to avoid cross-posting between public and private forums.
+Take care not to post a reply to a private post to a public forum without permission.
+				</p>
+<p>
+Learning to use mailing lists effectively is very important. If this can be achieved, 
+then you have shown to be a lively, active and successful community.
+The future looks bright.
+				</p>
+</div>
 <h4>
    <a name="community-vote">Community Graduation Vote</a>
 </h4>



---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message