incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dasho...@apache.org
Subject svn commit: r543984 - in /incubator/public/trunk: site-author/guides/community.xml site-author/guides/graduation.xml site-publish/guides/community.html site-publish/guides/graduation.html
Date Sun, 03 Jun 2007 20:36:07 GMT
Author: dashorst
Date: Sun Jun  3 13:36:06 2007
New Revision: 543984

URL: http://svn.apache.org/viewvc?view=rev&rev=543984
Log:
INCUBATOR-66 extract community building from graduation guide

Added:
    incubator/public/trunk/site-author/guides/community.xml   (with props)
    incubator/public/trunk/site-publish/guides/community.html   (with props)
Modified:
    incubator/public/trunk/site-author/guides/graduation.xml
    incubator/public/trunk/site-publish/guides/graduation.html

Added: incubator/public/trunk/site-author/guides/community.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/community.xml?view=auto&rev=543984
==============================================================================
--- incubator/public/trunk/site-author/guides/community.xml (added)
+++ incubator/public/trunk/site-author/guides/community.xml Sun Jun  3 13:36:06 2007
@@ -0,0 +1,272 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+	Licensed under the Apache License, Version 2.0 (the "License");
+	you may not use this file except in compliance with the License.
+	You may obtain a copy of the License at
+
+	http://www.apache.org/licenses/LICENSE-2.0
+
+	Unless required by applicable law or agreed to in writing, software
+	distributed under the License is distributed on an "AS IS" BASIS,
+	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+	See the License for the specific language governing permissions and
+	limitations under the License.
+-->
+<document>
+	<properties>
+		<title>Guide to successful community building (DRAFT)</title>
+		<atom url="http://mail-archives.apache.org/mod_mbox/incubator-general/?format=atom">general@incubator.apache.org Archives</atom>
+	</properties>
+	<body>
+		<section id="preamble">
+			<title>Guide to successful community building (DRAFT)</title>
+			<section id="status">
+				<title>Status - DRAFT</title>
+				<p>This document is under development.</p>
+				<p>
+					Help to improve the system by posting a patch for
+					this document to the incubator section of JIRA or a
+					comment to the <a href="lists.html">general</a> list at
+					incubator.
+				</p>
+			</section>
+			<section id='TOC'><title>Contents</title><toc/></section>
+			<section id="abstract">
+				<title>Abstract</title>
+				<p>
+
+					The intent of this document is to help podlings the
+                    importance of building an open and diverse community for
+                    their project. It gives guidelines on how to accept new
+                    committers and PPMC members, and how to enable more
+                    community involvement, taking off the burden of answering
+                    every question yourself.
+
+				</p>
+			</section>
+		</section>
+		<section id="introduction">
+			<title>What is an open and diverse community?</title>
+			<p>
+
+				A major criterion 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
+                communities are more robust and productive than more closed
+                ones.
+
+			</p>
+			<section id="people">
+				<title>People</title>
+				<p>
+
+					As a project grows, it needs 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 of 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 cost
+	                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 learned.
+
+				</p> 
+			</section>
+			<section id="communication">
+				<title>Communication</title>
+				<p>
+
+					Mailing lists are the life blood 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 be taken since
+	                out-of-band communications have led to difficulties in the
+	                past. The reason is that communications on other than the
+	                public mail aliases exclude parts of the community. Even
+	                publicly advertised IRC chats can be exclusionary due to time
+	                zone constraints or conflicting time commitments by community
+	                members who might want to participate.
+
+				</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 behavior 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 <a
+	                href='http://en.wikipedia.org/wiki/Serendipity'>serendipity</a>.
+	                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 minimize 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
+	                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 sought
+	                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>
+		<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 <a href="mailto:community@apache.org">community mailing
+                list</a> 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>Raising 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 raise 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>Building a community by stepping back a little</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 politely and positively with
+                    misunderstandings and by replying to threads which have
+                    been answered 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 closing the JIRA. It's also
+                    good to encourage developers by suggesting new related
+                    work they may like to volunteer for.
+
+				</p>
+			</section>
+		</section>
+	</body>
+</document>
\ No newline at end of file

Propchange: incubator/public/trunk/site-author/guides/community.xml
------------------------------------------------------------------------------
    svn:eol-style = native

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=543984&r1=543983&r2=543984
==============================================================================
--- incubator/public/trunk/site-author/guides/graduation.xml (original)
+++ incubator/public/trunk/site-author/guides/graduation.xml Sun Jun  3 13:36:06 2007
@@ -384,92 +384,20 @@
 Long term success and health requires that these communities understand how to:
                 </p>
                 <ul>
-                	<li>
-recruit users, developers, committers and PMCers
-                	</li>
-                	<li>
-take responsible collective action
-					</li>
-					<li>
-disagree in public on technical matters without destroying personal relationships
-					</li>
-					<li>
-create an open, positive and inclusive atmosphere on the mailing lists
-					</li>
+                	<li>recruit users, developers, committers and PMCers</li>
+                	<li>take responsible collective action</li>
+					<li>disagree in public on technical matters without destroying personal relationships</li>
+					<li>create an open, positive and inclusive atmosphere on the mailing lists</li>
 				</ul>
 				<p>
 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 learned 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>
-A major criterion 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 communities are more robust and productive than more
-closed ones.
-				</p> 
-				<p>
-As a project grows, it needs 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 of 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 cost 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 learned.
-				</p><p>
-Mailing lists are the life blood 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 be taken since out-of-band communications have led
-to difficulties in the past. 
-The reason is that communications on other than the public mail aliases
-exclude parts of the community. Even publicly advertised IRC chats can be
-exclusionary due to time zone constraints or conflicting time commitments
-by community members who might want to participate.
-				</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 behavior 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 
-<a href='http://en.wikipedia.org/wiki/Serendipity'>serendipity</a>.
-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 minimize 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 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 sought 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.
+					Read more on how to successfully build an open and diverse community for your podling in
+					the <a href="community.html">community guide</a>.
 				</p>
-				</section>
                 <section id='community-vote'>
                     <title>Community Graduation Vote</title>
                         <p>
@@ -517,89 +445,6 @@
 <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 
-<a href="mailto:community@apache.org">community mailing list</a> 
-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>Raising 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 raise 
-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 politely and positively with misunderstandings 
-and by replying to threads which have been answered 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 closing the 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>

Added: incubator/public/trunk/site-publish/guides/community.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/community.html?view=auto&rev=543984
==============================================================================
--- incubator/public/trunk/site-publish/guides/community.html (added)
+++ incubator/public/trunk/site-publish/guides/community.html Sun Jun  3 13:36:06 2007
@@ -0,0 +1,479 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+               "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<html>
+ <head>
+  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
+  <link rel="stylesheet" href="/style/style.css" type="text/css" />
+    <link rel="alternate" title="general@incubator.apache.org Archives" type="application/atom+xml" href="http://mail-archives.apache.org/mod_mbox/incubator-general/?format=atom" />
+    <title>Guide to successful community building (DRAFT) - Apache Incubator</title>
+ </head>
+ <body>        
+  <table border="0" width="100%" cellspacing="0">
+   <tr><!-- SITE BANNER AND PROJECT IMAGE -->
+    <td align="left" valign="top">
+<a href="http://www.apache.org/"><img src="/images/asf_logo_wide.gif" alt="The Apache Software Foundation" border="0"/></a>
+</td>
+<td align="right">
+<a href="http://incubator.apache.org/"><img src="../images/apache-incubator-logo.png" alt="Apache Incubator" border="0"/></a>
+</td>
+   </tr>
+  </table>
+  <table border="0" width="100%" cellspacing="4">
+   <tr><td colspan="3"><hr noshade="noshade" size="1"/></td></tr>
+   <tr>
+    <!-- LEFT SIDE NAVIGATION -->
+    <td valign="top" nowrap="nowrap" class="navleft">
+           <div class="menuheader"><a 
+href="http://www.apache.org/foundation/glossary.html#Podling">Podlings (What's that?)</a></div> 
+    <menu compact="compact">
+          <li><a href="/incubation/Incubation_Policy.html">How? (Policy)</a></li> 
+          <li><a href="/incubation/Roles_and_Responsibilities.html">Who? (Roles)</a></li> 
+          <li><a href="/incubation/Process_Description.html">When? (Process)</a></li> 
+            </menu>
+      <div class="menuheader"><a 
+href="/guides/index.html">Entry Guides</a></div> 
+    <menu compact="compact">
+          <li><a href="/guides/proposal.html">Proposal Guide</a></li> 
+            </menu>
+      <div class="menuheader"><a 
+href="/guides/index.html">Podling Guides</a></div> 
+    <menu compact="compact">
+          <li><a href="/guides/committer.html">Podling Committers</a></li> 
+          <li><a href="/guides/ppmc.html">Podling PMC (PPMC)</a></li> 
+          <li><a href="/guides/projects.html">Podling Mentor</a></li> 
+          <li><a href="/guides/releasemanagement.html">Podling Releases</a></li> 
+          <li><a href="/guides/branding.html">Podling Branding</a></li> 
+          <li><a href="/guides/sites.html">Podling Websites</a></li> 
+            </menu>
+      <div class="menuheader"><a 
+href="/ip-clearance/index.html">IP Clearance</a></div> 
+    <menu compact="compact">
+            </menu>
+      <div class="menuheader"><a 
+href="/whoweare.html">Who We Are</a></div> 
+    <menu compact="compact">
+            </menu>
+      <div class="menuheader"><a 
+href="http://www.apache.org">ASF</a></div> 
+    <menu compact="compact">
+          <li><a href="http://www.apache.org/foundation/how-it-works.html">How Apache Works</a></li> 
+          <li><a href="http://www.apache.org/dev/">Developer Documentation</a></li> 
+          <li><a href="http://www.apache.org/foundation/">Foundation</a></li> 
+            </menu>
+      <div class="menuheader">Other Guides</div>
+    <menu compact="compact">
+          <li><a href="/guides/participation.html">Participation</a></li> 
+          <li><a href="/faq.html">General FAQ</a></li> 
+          <li><a href="/guides/pmc.html">PMC</a> (<a href="/guides/chair.html">Chair</a>)</li> 
+          <li><a href="/guides/lists.html">Mailing Lists</a></li> 
+          <li><a href="/guides/website.html">Incubator Website</a></li> 
+            </menu>
+      <div class="menuheader"><a 
+href="http://wiki.apache.org/incubator">Wiki</a></div> 
+    <menu compact="compact">
+            </menu>
+
+    <!-- start Ads Server -->
+    <iframe src="http://www.apache.org/ads/buttonbar.html"
+        style="border-width:0; float: left" frameborder="0" scrolling="no"
+        width="135" height="265"></iframe>
+    <!-- end Ads Server -->
+    </td>
+    <!-- CONTENT -->
+    <td align="left" valign="top" class="content">
+                <h2><img src="/images/redarrow.gif" />
+   <a name="preamble">Guide to successful community building (DRAFT)</a>
+</h2>
+<div class="section-content">
+<h3>
+   <a name="status">Status - DRAFT</a>
+</h3>
+<div class="section-content">
+<p>This document is under development.</p>
+<p>
+					Help to improve the system by posting a patch for
+					this document to the incubator section of JIRA or a
+					comment to the <a href="lists.html">general</a> list at
+					incubator.
+				</p>
+</div>
+<h3>
+   <a name="TOC">Contents</a>
+</h3>
+<div class="section-content">
+<ul>
+<li><a href='#preamble'>
+Guide to successful community building (DRAFT)
+ </a>
+ <ul>
+<li><a href='#status'>
+Status - DRAFT
+ </a>
+</li>
+<li><a href='#TOC'>
+Contents
+ </a>
+</li>
+<li><a href='#abstract'>
+Abstract
+ </a>
+</li>
+</ul>
+</li>
+<li><a href='#introduction'>
+What is an open and diverse community?
+ </a>
+ <ul>
+<li><a href='#people'>
+People
+ </a>
+</li>
+<li><a href='#communication'>
+Communication
+ </a>
+</li>
+</ul>
+</li>
+<li><a href='#notes-community'>
+Community Building
+ </a>
+ <ul>
+<li><a href='#notes-profile'>
+Raising The Profile
+ </a>
+</li>
+<li><a href='#notes-recruitment'>
+Building a community by stepping back a little
+ </a>
+</li>
+<li><a href='#notes-committers'>
+Helping Developers Become Committers
+ </a>
+</li>
+</ul>
+</li>
+</ul>
+</div>
+<h3>
+   <a name="abstract">Abstract</a>
+</h3>
+<div class="section-content">
+<p>
+
+					The intent of this document is to help podlings the
+                    importance of building an open and diverse community for
+                    their project. It gives guidelines on how to accept new
+                    committers and PPMC members, and how to enable more
+                    community involvement, taking off the burden of answering
+                    every question yourself.
+
+				</p>
+</div>
+</div>
+           <h2><img src="/images/redarrow.gif" />
+   <a name="introduction">What is an open and diverse community?</a>
+</h2>
+<div class="section-content">
+<p>
+
+				A major criterion 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
+                communities are more robust and productive than more closed
+                ones.
+
+			</p>
+<h3>
+   <a name="people">People</a>
+</h3>
+<div class="section-content">
+<p>
+
+					As a project grows, it needs 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 of 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 cost
+	                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 learned.
+
+				</p>
+</div>
+<h3>
+   <a name="communication">Communication</a>
+</h3>
+<div class="section-content">
+<p>
+
+					Mailing lists are the life blood 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 be taken since
+	                out-of-band communications have led to difficulties in the
+	                past. The reason is that communications on other than the
+	                public mail aliases exclude parts of the community. Even
+	                publicly advertised IRC chats can be exclusionary due to time
+	                zone constraints or conflicting time commitments by community
+	                members who might want to participate.
+
+				</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 behavior 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 <a href="http://en.wikipedia.org/wiki/Serendipity">serendipity</a>.
+	                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 minimize 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
+	                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 sought
+	                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>
+</div>
+           <h2><img src="/images/redarrow.gif" />
+   <a name="notes-community">Community Building</a>
+</h2>
+<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 <a href="mailto:community@apache.org">community mailing
+                list</a> 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>
+<h3>
+   <a name="notes-profile">Raising The Profile</a>
+</h3>
+<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 raise 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>
+<h3>
+   <a name="notes-recruitment">Building a community by stepping back a little</a>
+</h3>
+<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 politely and positively with
+                    misunderstandings and by replying to threads which have
+                    been answered 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>
+<h3>
+   <a name="notes-committers">Helping Developers Become Committers</a>
+</h3>
+<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 closing the JIRA. It's also
+                    good to encourage developers by suggesting new related
+                    work they may like to volunteer for.
+
+				</p>
+</div>
+</div>
+         </td>
+    <!-- RIGHT SIDE NAVIGATION -->
+    <td valign="top" nowrap="nowrap" class="navright">
+           <div class="menuheader"><a 
+href="/projects/index.html">Projects</a></div>
+    <menu compact="compact">
+          <li><a href="/projects/abdera.html">Abdera</a></li> 
+          <li><a href="/projects/cxf.html">CXF</a></li> 
+          <li><a href="/projects/felix.html">Felix</a></li> 
+          <li><a href="/projects/ftpserver.html">FtpServer</a></li> 
+          <li><a href="/projects/graffito.html">Graffito</a></li> 
+          <li><a href="/projects/heraldry.html">Heraldry</a></li> 
+          <li><a href="/projects/ivy.html">Ivy</a></li> 
+          <li><a href="/projects/juice.html">JuiCE</a></li> 
+          <li><a href="/projects/lokahi.html">Lokahi</a></li> 
+          <li><a href="/projects/lucene.net.html">Lucene.Net</a></li> 
+          <li><a href="/projects/nmaven.html">NMaven</a></li> 
+          <li><a href="/projects/ode.html">Ode</a></li> 
+          <li><a href="/projects/openejb.html">OpenEJB</a></li> 
+          <li><a href="/projects/openjpa.html">OpenJPA</a></li> 
+          <li><a href="/projects/qpid.html">Qpid</a></li> 
+          <li><a href="/projects/river.html">River</a></li> 
+          <li><a href="/projects/servicemix.html">ServiceMix</a></li> 
+          <li><a href="/projects/stdcxx.html">stdcxx</a></li> 
+          <li><a href="/projects/tika.html">Tika</a></li> 
+          <li><a href="/projects/trinidad.html">Trinidad</a></li> 
+          <li><a href="/projects/triplesoup.html">TripleSoup</a></li> 
+          <li><a href="/projects/tuscany.html">Tuscany</a></li> 
+          <li><a href="/projects/uima.html">UIMA</a></li> 
+          <li><a href="/projects/wadi.html">wadi</a></li> 
+          <li><a href="/projects/wicket.html">Wicket</a></li> 
+          <li><a href="/projects/woden.html">Woden</a></li> 
+          <li><a href="/projects/wsrp4j.html">WSRP4J</a></li> 
+          <li><a href="/projects/xap.html">XAP</a></li> 
+          <li><a href="/projects/yoko.html">Yoko</a></li> 
+        </menu>
+
+<form action="http://www.google.com/search" method="get">
+    <input value="incubator.apache.org" name="sitesearch" type="hidden"/>
+    <input size="8" name="q" id="query" type="text" value="search..."
+        onclick="if(this.value == 'search...') {this.value = ''}"/>
+    <input name="Search" value="Go" type="submit"/>
+</form>
+    </td>     
+   </tr>
+   <!-- FOOTER -->
+   <tr><td colspan="3"><hr noshade="noshade" size="1"/></td></tr>
+   <tr><td colspan="3" class="footer">
+         Copyright &#169; 1999-2007, The Apache Software Foundation<br />
+Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.
+       </td>
+   </tr>
+  </table>
+ </body>
+</html>

Propchange: incubator/public/trunk/site-publish/guides/community.html
------------------------------------------------------------------------------
    svn:eol-style = native

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=543984&r1=543983&r2=543984
==============================================================================
--- incubator/public/trunk/site-publish/guides/graduation.html (original)
+++ incubator/public/trunk/site-publish/guides/graduation.html Sun Jun  3 13:36:06 2007
@@ -211,10 +211,6 @@
 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>
@@ -229,24 +225,6 @@
 Creating A Release
  </a>
 </li>
-<li><a href='#notes-community'>
-Community Building
- </a>
- <ul>
-<li><a href='#notes-profile'>
-Raising 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'>
@@ -674,103 +652,20 @@
 Long term success and health requires that these communities understand how to:
                 </p>
 <ul>
-                	<li>
-recruit users, developers, committers and PMCers
-                	</li>
-                	<li>
-take responsible collective action
-					</li>
-					<li>
-disagree in public on technical matters without destroying personal relationships
-					</li>
-					<li>
-create an open, positive and inclusive atmosphere on the mailing lists
-					</li>
+                	<li>recruit users, developers, committers and PMCers</li>
+                	<li>take responsible collective action</li>
+					<li>disagree in public on technical matters without destroying personal relationships</li>
+					<li>create an open, positive and inclusive atmosphere on the mailing lists</li>
 				</ul>
 <p>
 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 learned 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 criterion 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 communities are more robust and productive than more
-closed ones.
-				</p>
-<p>
-As a project grows, it needs 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 of 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 cost 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 learned.
-				</p>
-<p>
-Mailing lists are the life blood 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 be taken since out-of-band communications have led
-to difficulties in the past. 
-The reason is that communications on other than the public mail aliases
-exclude parts of the community. Even publicly advertised IRC chats can be
-exclusionary due to time zone constraints or conflicting time commitments
-by community members who might want to participate.
-				</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 behavior 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 
-<a href="http://en.wikipedia.org/wiki/Serendipity">serendipity</a>.
-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.
+					Read more on how to successfully build an open and diverse community for your podling in
+					the <a href="community.html">community guide</a>.
 				</p>
-<p>
-If alternative forums are used by a project, it is important to try to minimize 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 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 sought 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>
@@ -826,103 +721,6 @@
 <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 
-<a href="mailto:community@apache.org">community mailing list</a> 
-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">Raising 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 raise 
-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 politely and positively with misunderstandings 
-and by replying to threads which have been answered 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 closing the JIRA. It's also good to encourage 
-developers by suggesting new related work they may like to volunteer for.
-						</p>
-</div>
 </div>
 </div>
 <h3>



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


Mime
View raw message