incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r536334 - in /incubator/public/trunk: site-author/guides/graduation.xml site-publish/guides/graduation.html
Date Tue, 08 May 2007 21:22:43 GMT
Author: rdonkin
Date: Tue May  8 14:22:42 2007
New Revision: 536334

URL: http://svn.apache.org/viewvc?view=rev&rev=536334
Log:
Filled in missing content. Haven't checked spelling or proof-read yet. If anyone knows a good
xml-aware spell checker that will run on Linux let me know.

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=536334&r1=536333&r2=536334
==============================================================================
--- incubator/public/trunk/site-author/guides/graduation.xml (original)
+++ incubator/public/trunk/site-author/guides/graduation.xml Tue May  8 14:22:42 2007
@@ -298,6 +298,24 @@
             </section>
             <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:
+                </p>
+                <ul>
+                	<li>
+recruit users, developers, committers and PMCers
+                	</li>
+                	<li>
+take responsible collective action
+					</li>
+					<li>
+disagree on technical matters without destroying personal relationships
+					</li>
+					<li>
+create a 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. 
@@ -313,16 +331,6 @@
 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.
 				</p>
-<!--
-                <p>TODO: content on self sustaining communities; 
-                learn how to recruit developers, committers and PMCers;
-                diversity; capability to self govern 
-                and ability to take responsibility for collective actions;
-                learn how to disagree on technical matters 
-                without destroying personal relationship; 
-                links to community building; positive process of introspection
-                </p>
--->
                 <section id='community-vote'>
                     <title>Community Graduation Vote</title>
                         <p>
@@ -346,7 +354,112 @@
             </section>
             <section id='notes-issues'>
                 <title>On Remaining Obstacles</title>
-                <p>TODO: content</p>
+                <p>
+How to resolve remaining obstacles preventing graduation depends on the nature
+of these obstacles. Notes on a few follow. Mentors should be able to answer
+other questions (or point out those people who can).
+                </p>
+                <section id='notes-releases'><title>Creating A Release</title>
+                	<p>
+The easiest way for a podling to demonstrate the ability to create Apache releases is
+to create one. The 
+<a href='/incubation/Incubation_Policy.html#Incubator+Project+Management+Committee+%28PMC%29'>IPMC</a>

+checks form and not function. It is occasionally convenient to 
+cut a release for verification where the form is correct but the actual code function is
not 
+entirely suitable for users and this is fine.
+					</p><p>
+See (for technical details): 
+                	</p>
+                	<ul>
+						<li>
+<a href='http://www.apache.org/dev/index.html#releases'>Apache Release Documentation</a>
+						</li>
+						<li>
+<a href='releasemanagement.html'>Incubator Release Guide</a>
+						</li>
+                	</ul>
+                </section>
+                <section id='notes-community'><title>Community Building</title>
+                	<p>
+Before a podling graduates, it must create a diverse and self-sustaining community.
+Community building is tough: it takes time, effort and more than a little magic. 
+There is no secret recipe, just hard work. In order to overcome this obstacle, 
+committers may need to devote more time to community building and less to development.
+                	</p>
+                	<p>
+The community mailing list is open to all Apache committers. This is the right list for 
+questions about community and on community building.
+Subscriptions should be from an Apache email address.
+                	</p>
+                	<section id='notes-profile'><title>Rising The Profile</title>
+					<p>
+Sometimes, a podling is just not well enough known. There are simply not enough users
+to allow new developers to be recruited. Overcoming this means finding ways to rise 
+the profile of the podling. Some ideas:
+					</p>
+					<ul>
+						<li>
+Improve the website
+						</li>
+						<li>
+Improve the information provided within each release and release more often
+						</li>
+						<li>
+Committers who blog should join 
+<a href='http://www.apache.org/dev/committers.html#planetapache'>PlanetApache</a>
+						</li>
+						<li>
+Use grassroots media
+						</li>
+						<li>
+Encourage downstream distributions to include a packaged version
+						</li>
+						<li>
+Submit talks to conferences
+						</li>
+						<li>
+<a href='http://www.feathercast.org'>Feathercast</a>
+						</li>
+						<li>
+Write articles
+						</li>
+					</ul>
+					</section>
+					<section id='notes-recruitment'><title>Recruiting New Developers</title>
+					<p>
+If the podling has lots of users but very few new developers then this means that more
+work is required to encourage users to become developers. A common cause of this is 
+that committers are too quick to create code to solve user problems. It's good to respond

+quickly to requests by users. However, once a project gains momentum, it may be more productive
+for the long term health of a project to encourage users to become more involved at the expense
+of user satisfaction. 
+					</p><p>
+Try to encourage expert users to answer questions. This may mean intentionally
+allowing a time gap before answering user questions. Encourage users to post by taking the
time
+to deal politly and positively with misunderstands 
+and by replying to threads which have been answer well by a user to confirm that they are
right. 
+Avoid engaging in flame wars on user lists. Ignore trolls.
+					</p><p>
+Try to encourage users to become developers. When they give a good answer that isn't covered
+in the documentation, ask them to submit a patch. When users suggest a good design or extension,
+ask for volunteers to help implement rather than just coding it up. 
+					</p>
+					</section>
+					<section id='notes-committers'><title>Helping Developers Become Committers</title>
+						<p>
+If a podling has no trouble attracting developers but trouble retaining them long enough

+for them to become committers then this highlights an issue with the recruitment process.
+To become an Apache committer, a developer needs to hang around long enough to accumulate
+a track record of contributions. This often requires encouragement and help from existing
+committers.
+						</p>
+						<p>
+Promptly reviewing patches is important. The way that patches are applied is also important.
+Provide credit in the commit message and when close with JIRA. It's also good to encourage

+developers by suggesting new related work they may like to volunteer for.
+						</p>
+					</section>
+                </section>
             </section>
             <section id='notes-on-hand-over'><title>On The Handover</title>
                 <p>This is the transfer of virtual resources from the care of the IPMC

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=536334&r1=536333&r2=536334
==============================================================================
--- incubator/public/trunk/site-publish/guides/graduation.html (original)
+++ incubator/public/trunk/site-publish/guides/graduation.html Tue May  8 14:22:42 2007
@@ -215,6 +215,30 @@
 <li><a href='#notes-issues'>
 On Remaining Obstacles
  </a>
+ <ul>
+<li><a href='#notes-releases'>
+Creating A Release
+ </a>
+</li>
+<li><a href='#notes-community'>
+Community Building
+ </a>
+ <ul>
+<li><a href='#notes-profile'>
+Rising The Profile
+ </a>
+</li>
+<li><a href='#notes-recruitment'>
+Recruiting New Developers
+ </a>
+</li>
+<li><a href='#notes-committers'>
+Helping Developers Become Committers
+ </a>
+</li>
+</ul>
+</li>
+</ul>
 </li>
 <li><a href='#notes-on-hand-over'>
 On The Handover
@@ -540,6 +564,24 @@
 </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:
+                </p>
+<ul>
+                	<li>
+recruit users, developers, committers and PMCers
+                	</li>
+                	<li>
+take responsible collective action
+					</li>
+					<li>
+disagree on technical matters without destroying personal relationships
+					</li>
+					<li>
+create a 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 IPMC, it can be beneficial to vote and accept a couple of 
@@ -581,7 +623,130 @@
    <a name="notes-issues">On Remaining Obstacles</a>
 </h3>
 <div class="section-content">
-<p>TODO: content</p>
+<p>
+How to resolve remaining obstacles preventing graduation depends on the nature
+of these obstacles. Notes on a few follow. Mentors should be able to answer
+other questions (or point out those people who can).
+                </p>
+<h4>
+   <a name="notes-releases">Creating A Release</a>
+</h4>
+<div class="section-content">
+<p>
+The easiest way for a podling to demonstrate the ability to create Apache releases is
+to create one. The 
+<a href="/incubation/Incubation_Policy.html#Incubator+Project+Management+Committee+%28PMC%29">IPMC</a>

+checks form and not function. It is occasionally convenient to 
+cut a release for verification where the form is correct but the actual code function is
not 
+entirely suitable for users and this is fine.
+					</p>
+<p>
+See (for technical details): 
+                	</p>
+<ul>
+						<li>
+<a href="http://www.apache.org/dev/index.html#releases">Apache Release Documentation</a>
+						</li>
+						<li>
+<a href="releasemanagement.html">Incubator Release Guide</a>
+						</li>
+                	</ul>
+</div>
+<h4>
+   <a name="notes-community">Community Building</a>
+</h4>
+<div class="section-content">
+<p>
+Before a podling graduates, it must create a diverse and self-sustaining community.
+Community building is tough: it takes time, effort and more than a little magic. 
+There is no secret recipe, just hard work. In order to overcome this obstacle, 
+committers may need to devote more time to community building and less to development.
+                	</p>
+<p>
+The community mailing list is open to all Apache committers. This is the right list for 
+questions about community and on community building.
+Subscriptions should be from an Apache email address.
+                	</p>
+<h5> 
+   <a name="notes-profile">Rising The Profile</a> 
+</h5> 
+<div class="section-content">
+<p>
+Sometimes, a podling is just not well enough known. There are simply not enough users
+to allow new developers to be recruited. Overcoming this means finding ways to rise 
+the profile of the podling. Some ideas:
+					</p>
+<ul>
+						<li>
+Improve the website
+						</li>
+						<li>
+Improve the information provided within each release and release more often
+						</li>
+						<li>
+Committers who blog should join 
+<a href="http://www.apache.org/dev/committers.html#planetapache">PlanetApache</a>
+						</li>
+						<li>
+Use grassroots media
+						</li>
+						<li>
+Encourage downstream distributions to include a packaged version
+						</li>
+						<li>
+Submit talks to conferences
+						</li>
+						<li>
+<a href="http://www.feathercast.org">Feathercast</a>
+						</li>
+						<li>
+Write articles
+						</li>
+					</ul>
+</div>
+<h5> 
+   <a name="notes-recruitment">Recruiting New Developers</a> 
+</h5> 
+<div class="section-content">
+<p>
+If the podling has lots of users but very few new developers then this means that more
+work is required to encourage users to become developers. A common cause of this is 
+that committers are too quick to create code to solve user problems. It's good to respond

+quickly to requests by users. However, once a project gains momentum, it may be more productive
+for the long term health of a project to encourage users to become more involved at the expense
+of user satisfaction. 
+					</p>
+<p>
+Try to encourage expert users to answer questions. This may mean intentionally
+allowing a time gap before answering user questions. Encourage users to post by taking the
time
+to deal politly and positively with misunderstands 
+and by replying to threads which have been answer well by a user to confirm that they are
right. 
+Avoid engaging in flame wars on user lists. Ignore trolls.
+					</p>
+<p>
+Try to encourage users to become developers. When they give a good answer that isn't covered
+in the documentation, ask them to submit a patch. When users suggest a good design or extension,
+ask for volunteers to help implement rather than just coding it up. 
+					</p>
+</div>
+<h5> 
+   <a name="notes-committers">Helping Developers Become Committers</a> 
+</h5> 
+<div class="section-content">
+<p>
+If a podling has no trouble attracting developers but trouble retaining them long enough

+for them to become committers then this highlights an issue with the recruitment process.
+To become an Apache committer, a developer needs to hang around long enough to accumulate
+a track record of contributions. This often requires encouragement and help from existing
+committers.
+						</p>
+<p>
+Promptly reviewing patches is important. The way that patches are applied is also important.
+Provide credit in the commit message and when close with JIRA. It's also good to encourage

+developers by suggesting new related work they may like to volunteer for.
+						</p>
+</div>
+</div>
 </div>
 <h3>
    <a name="notes-on-hand-over">On The Handover</a>



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


Mime
View raw message