incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r422181 - in /incubator/public/trunk: site-author/guides/proposal.xml site-publish/guides/proposal.html
Date Sat, 15 Jul 2006 08:53:25 GMT
Author: rdonkin
Date: Sat Jul 15 01:53:25 2006
New Revision: 422181

URL: http://svn.apache.org/viewvc?rev=422181&view=rev
Log:
First draft for proposal guide. Intended for public review so please patch the many deficiencies.

Added:
    incubator/public/trunk/site-author/guides/proposal.xml
    incubator/public/trunk/site-publish/guides/proposal.html

Added: incubator/public/trunk/site-author/guides/proposal.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/proposal.xml?rev=422181&view=auto
==============================================================================
--- incubator/public/trunk/site-author/guides/proposal.xml (added)
+++ incubator/public/trunk/site-author/guides/proposal.xml Sat Jul 15 01:53:25 2006
@@ -0,0 +1,547 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <title>A Guide To Proposal Creation (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>A Guide To Proposal Creation (DRAFT)</title>
+        <section id="status">
+          <title>Status - DRAFT</title>
+          <p>
+This document is under <a href='#help-wanted'>development</a>. This is the first 
+draft intended to allow public review. 
+          </p>
+        </section>
+        <section id="abstract">
+          <title>Abstract</title>
+          <p>
+This document is descriptive not normative. It describes ways to go about
+drawing up a proposal for submission. It is not an inflexible standard but
+respresents a consensus condensed from previous discussions on the
+incubator general list.
+          </p>
+        </section>
+        <section id="background">
+          <title>Background</title>
+          <p>
+Entry to the incubator is a democractic process. The incubator pmc votes on
+whether to accept or not. The proposal is the document upon which the pmc
+votes. So, though it's not necessary or sufficient to have a good proposal,
+a good proposal document will increase the chances of a positive result.
+           </p>
+           <p>
+The proposal is (in some ways) a manifesto. It should shape the evolution of
+the product at apache. A lot of the information contained should be included
+in the initial project website.
+           </p>
+        </section>
+        <section id="help-wanted">
+          <title>Help Wanted!</title>
+          <p>
+Help to improve the system by posting a patch for this document to the
+incubator section of JIRA or a comment to the general list at incubator.
+          </p>
+        </section>
+    </section>
+    <section id="formulating">
+      <title>Formulating A Proposal</title>
+      <p>
+Start by RTFM. The Entry To The incubator is a good place to start this
+process.
+       </p>
+       <p>
+Subscribe to general@incubator.apache.org. Spend some time reviewing the 
+mailing lists archives . The mailing lists are the canonical form of
+communication and decision making at Apache. The documentation represents
+an attempt to codify the consensus formed on list.
+       </p>
+       <p>
+Before drawing up a lengthy proposal, recruit a champion. [links to other
+documentation explaning role of champion] The champion knows how Apache work
+and should be able to help navigate the process.
+       </p>
+       <p>
+Review recent proposals [links to the wiki] and how they have been received.
+       </p>
+       <p>
+The incoming community needs to work together before presenting this
+proposal to
+the incubator. Think about goals and about the reasons for coming to apache.
+       </p>
+       <p>
+Once the preparatory work is done, the proposal should be presented to the
+incubator.  This is done by posting the proposal
+in plain text in a email whose subject is prefixed with [PROPOSAL].
+       </p>
+       <p>
+Expect to work on improving the template on list after presenting it. The
+wiki is an excellent way to develop a proposal. Consider creating a wiki
+page containing the same content and supplying a link. Interested parties
+may wish to add themselves to the watch list for the page so that received
+email notifications when the page is changed.
+       </p>
+       <p>
+When the proposal seems finish and some sort of consensus has emerged, the
+proposal can be put to the vote.
+      </p>
+    </section>
+    <section id="proposal-template">
+      <title>Proposal Template</title>
+      <p>
+The aim of presenting a template with examples and comments is educational.
+Proposals are not required to adopt this format. If you can see a better
+way: great - try it. 
+      </p>
+      <p>
+Every proposal is different. There may be sections which don't seem to be
+useful. It's fine to miss them out and to add new ones that the proposal seems
+to need.
+      </p>
+      <p>
+In the following sections:
+      </p>
+      <blockquote>
+      <p>
+Commentary is thus.
+      </p>
+      <p>
+<pre>Examples are thus.</pre>
+      </p>
+      </blockquote>
+      <section id='template'><title>Template</title>
+
+       <section id='template-abstract'><title>Abstract</title>
+       <blockquote>
+<p>
+What is the proposed project? 
+</p><p>
+A short descriptive summary of the
+project. Ideally one sentence in length.
+</p><p>
+The technical vision for an open source project should be communicatable 
+in a short paragraph. This paragraph will most like be used for
+the board resolution used to create the official project upon graduation,
+may be used as the first paragraph on the web site and as the DOAP
+description.
+</p>
+<pre>
+Examples
+       Geronimo will be a J2EE compliant container.
+       
+       Heraldry will develop technologies around the emerging  
+           user-centric identity space.
+           
+       Yoko will be a CORBA server.
+</pre>
+       </blockquote>
+        </section>
+        <section id='template-proposal'><title>Proposal</title>
+        <blockquote>
+<p>
+A lengthier description of the proposal. Should be reasonably declarative.
+More discursive material can be included in later sections.
+</p>
+<pre>
+Examples:
+</pre>
+        </blockquote>
+        </section>
+        <section id='template-background'><title>Background</title>
+        <blockquote>
+<p>
+For some projects, it may be useful to provide context for those unfamiliar
+with the project space and history.
+</p><p>
+If there any likelihood of confusion over the meaning of some terms (for example, 
+if there is not a single widely adopted definition), explain what is meant by them.
+if the problem domain is likely to be unfamiliar to many then please give an outline.
+<p>
+</p>
+This content should be capable of being safely ignored by any domain
+experts.
+<p>
+</p>
+This material should probably find an eventual home on the project website.
+</p>
+<pre>
+Examples:
+</pre>
+        </blockquote>
+        </section>
+        <section id='template-rationale'><title>Rationale</title>
+        <blockquote>
+<p>
+Why does this project need to exist and why should it be adopted by apache?
+<p>
+</p>
+More discursive material is probably better in this section rather than in
+the proposal.
+<p>
+</p>
+This content should be ignorable for those for whom the need is obvious.
+</p>
+<pre>
+Examples:
+</pre>
+        </blockquote>
+        </section>
+        <section id='template-initial-goals'><title>Initial Goals</title>
+        <blockquote>
+<p>
+Only include this section if it is not obvious. If the proposal is complex
+(probably involving multiple code bases) then people may worry about it's
+practicallity and whether it may drag in too much Apache energy. 
+<p>
+</p>
+This is a good place to explain the plan and demonstrate that the proposal
+is feasible and has been thought through.
+</p>
+<pre>
+Example:
+    Initial Goals
+    -------------
+      * Expansion of Yadis and OpenID libraries into additional
+        languages beyond the existing Python, Ruby, Perl, and 
+        PHP libraries
+      * OpenID authentication specification revision to fix known
+        security considerations, investigate compatibility with 
+        the DIX IETF proposal, describe Yadis integration, and 
+        allow either an URL or XRI be used as the End User's 
+        Identifier
+      ...
+</pre>
+        </blockquote>
+        </section>
+        <section id='template-current-status'><title>Current Status</title>
+        <blockquote>
+<p>
+Questions are often asked about the current status of the constituent codebases
+and current development practices.
+It is sometimes useful to prempt these questions by stating honestly
+where how these balance up against principles and ideals. 
+Some proposals describe this section as criteria.
+</p><p>
+A few possible topics:
+</p>
+        </blockquote>
+        <section id='template-meritocracy'><title>Meritocracy</title>
+        <p>
+        [need more content describing these attributes]
+        </p>
+        </section>
+        <section id='template-community'><title>Community</title>
+        <p>
+        [need more content describing these attributes]
+        </p>
+        </section>
+        <section id='template-core-developers'><title>Core Developers</title>
+        <p>
+        [need more content describing these attributes]
+        </p>
+        </section>
+        <section id='template-alignment'><title>Alignment</title>
+        <p>
+[need more content describing these attributes]
+        </p>
+        </section>
+<pre>
+Examples:
+</pre>
+        </section>
+        <section id='template-known-risks'><title>Known Risks</title>
+        <blockquote>
+<p>
+An exercise in self-knowledge.
+Risks don't mean that a project is unacceptable.
+It is useful to collect together material prempting questions about possible risks.
+</p>
+        </blockquote>
+        <section id='template-orphaned-products'><title>Orphaned products</title>
+        <blockquote>
+            <p>
+              [needs improvements?] This is the right place for the
+proposers to publically state their commitment to future development. It
+takes quite a while to recruit a diverse development community. So Apache
+needs to be confident that those already working on the product are still
+committed.
+            </p>
+<pre>
+Example (Yoko):
+    The contributors are leading vendors in this space.
+There is no risk of any of the usual warning signs of orphaned 
+or abandoned code.
+</pre>
+        </blockquote>
+        </section>
+        <section id='template-inexperience-with-open-source'><title>Inexperience with Open Source</title>
+        <blockquote>
+        <p>
+               [needs improvements?] One of the reasons why many closed
+project choose to move to here is the experience of Apache in the open
+source space. But this means an invest of energy by Apache so many people
+look for an indications of a willingness to learn and to give back to the community.
+        </p>
+        </blockquote>
+        </section>
+        <section id='template-homogenuous-developers'><title>Homogenous Developers</title>
+            <blockquote>
+                <p>
+               [needs improvements?] Healthy projects need a mix of
+developers. Open development means a commitment to encouraging a diverse mix
+of developers.
+                </p>
+            </blockquote>
+        </section>
+        <section id='template-reliance-on-salaired-developers'><title>Reliance on Salaried Developers</title>            
+            <blockquote>
+                <p> 
+               [needs improvements?] People worry about salaried developers
+who are interested in working on this project only whilst they are employed
+to do so. Apache focusses on people, not corporations. We'd like developers
+to continue to be involved with Apache no matter who their current employer
+happens to be.
+                </p>
+            </blockquote>
+        </section>
+        <section id='template-other-producrs'><title>Relationships with Other Apache Products</title>  
+            <blockquote>
+                <p>
+               [needs improvements?]
+               People are concerned about projects that work just inside
+their own little bubble. Apache encourages projects to open to collaboration
+with other open source projects both within apache and without. This may be
+existing links but is also a good place to talk about potential future links
+and plans.
+                </p><p>
+               Apache allows different projects to have competing or
+overlapping goals. However, this should mean friendly competition with
+coorporation whenever this makes sense.
+                </p><p>
+It is not always obvious to all
+whether the proposers see themselves as direct competitors with an existing
+project, indirect competitors (same problem space, different ecological
+niche) or just peers with some overlap. So, it's best to note this. 
+It is polite to inform the the projects.
+In the case of indirect competition, it may be important that the abstract 
+describe accurately the niche.
+                </p>
+            </blockquote>
+        </section>
+        <section id='template-brand-fascination'><title>A Fascination with the Apache Brand</title>  
+            <blockquote>
+                <p>
+               [needs improvements?] Concerns have been raised in the past
+that some projects are proposed just to generate positive publicity for
+themselves. This is a chance to build bridges with the community after past
+misdemeanors (for example, if any of those associated with the proposal have
+- in the past - sort to associate themselves with the Apache brand in
+factually incorrect ways) and promise good conduct for the future.
+                </p>
+            </blockquote>
+        </section>
+<pre>
+Examples:
+</pre>
+        </section>
+        <section id='template-documentation'><title>Documentation</title>
+            <blockquote>
+                <p>
+References to further reading material.
+                </p>
+            </blockquote>
+<pre>
+Examples:
+</pre>
+        </section>
+        <section id='template-initial-source'><title>Initial Source</title>
+            <blockquote>
+<p>
+Describes the origin of the proposed code base. If there is no initial source,
+note that here.
+</p>
+            </blockquote>
+<pre>
+Examples:
+</pre>
+        </section>
+        <section id='template-ip'><title>Source and Intellectual Property Submission Plan</title>
+            <blockquote>
+<p>
+More complex proposals (typically involving mutliple code bases) may find it useful
+to draw up an initial plan for the submission of the code here in a separate
+section. Demonstrates that the proposal is practical.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+        </section>
+        <section id='template-external-dependencies'><title>External Dependencies</title>
+            <blockquote>
+<p>
+External dependencies for the initial source is important. Apache has policy
+about dependencies allowed for projects. These are (to some extent) relaxed
+for projects under incubation. Listing dependencies and licenses allows any
+possible problems to be highlighted and the appropriate actions planned.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+        </section>
+        <section id='template-cryptography'><title>Cryptography</title>
+            <blockquote>
+<p>
+If the proposal involves cryptographic code either directly or indirectly,
+Apache needs to know so that the relevant export documentation can be
+obtained.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+        </section>
+        <section id='template-required-resources'><title>Required Resources</title>
+            <blockquote>
+<p>
+       Create a list of resources that the Apache infrastructure will be asked
+supply for this project. Note that the contents of this list may need to be developed.
+</p>
+            </blockquote>
+        <section id='template-mailing-lists'><title>Mailing lists</title>
+            <blockquote>
+                <p>
+             Minimum project-private (for pmc) project-dev listing
+                </p><p>
+If this project is new to open source, it is often best to start with 
+these minimum lists. The initial focus needs to be on recruiting new developers. 
+Developers need to get into the habit of reading and checking commit messages.  
+As momentum is gained, the community may decide that to create commit 
+and user lists in the usual way.
+                </p><p>
+Existing open source projects moving to Apache will probably want to adopt the
+same mailing list set up here as they have already.
+                </p>
+            </blockquote>
+        </section>
+        <section id='template-subversion-directory'><title>Subversion Directory</title>
+        </section>
+        <section id='template-issue-tracking'><title>Issue Tracking</title>
+            <blockquote>
+                <p>
+Apache runs JIRA and Bugzilla.
+                </p>
+            </blockquote>
+        </section>
+        <section id='template-other-resources'><title>Other Resources</title>
+            <blockquote>
+                <p>
+        Other resources such as continuous integration and so on should be
+added by the Podling later in the usual way (votes on list) as momentum is gained. 
+The infrastructure documentation should explain the process.
+                </p><p>
+        If the proposal requires other special infrastructure, it is best to
+give an explaination. The Apache infrastructure team usually take some
+convincing before allowing new services on core Apache hardware.
+                </p>
+<pre>
+Examples:
+</pre>
+                </blockquote>
+            </section>
+        </section>
+        <section id='template-initial-committers'><title>Initial Committers</title>
+            <blockquote>
+<p>
+        List of committers used to bootstrap the community. Note which have
+submitted CLAs.
+</p>
+<p>
+        It is a good idea to submit CLAs at the same time as proposal and
+before acceptance. There is nothing lost by having a CLA on file at Apache
+but they do take some time to process.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+        </section>
+        <section id='template-affiliations'><title>Affiliations</title>
+            <blockquote>
+                <p>
+Little bit of a controversial subject. [link to mailing list discussions] 
+Committers at Apache are individuals
+and work here on their own behalf. They are judged on their merits not their
+affiliations. However, in the spirit of full disclosure, it is useful for
+any current affiliations which may effect their perceived independence to be 
+listed openly at the start.
+                </p><p>
+For example, those in a salaried positions whose job is to work on the
+project should list their affiliation. Having this list helps to judge how
+much diversity exists in the initial list and so how much work there is to
+do.
+                </p>
+                <p>
+It's probably best to do this in a separate section away from the committers
+list. This list is only for initial committers and drafted into the Podling.
+It does not need to be maintained and affiliations of new committers elected 
+after the bootstrap do not need to be listed.
+                </p>
+<pre>
+Examples:
+</pre>
+                </blockquote>
+        </section>
+        <section id='template-sponsors'><title>Sponsors</title>
+            <section id='template-champion'><title>Champion</title>
+                <blockquote>
+                <p>
+[needs improvements?] A champion should be found before the proposal is
+submitted.
+                </p>
+                </blockquote>
+            </section>
+            <section id='template-mentors'><title>Mentors</title>
+                <blockquote>
+                    <p>
+[needs improvements?]
+            The list of mentors may well be established during development
+of the proposal. The absolute minimum is a single mentor but the current
+consensus is that (at least) three mentors will make things go more
+smoothly. Three mentors gives a quorum and allows the project more autonomy.
+                </p>
+                <p>
+The number of mentors a podling can have is limited only by the
+energy and interest of those eligable to mentor.
+                </p>
+                </blockquote>
+            </section>
+            <section id='template-sponsoring-entity'><title>Sponsoring Entity</title>
+                <blockquote>
+                        <p>
+This is the organisational unit within Apache taking resposibility for this
+proposal.
+The sponsoring entity can be:
+</p>
+<ul>
+        <li>Apache Board</li>
+        <li>Incubator PMC</li>
+        <li>Another Apache project</li>
+</ul>
+                <p>
+Unless there are strong links to an existing pmc, it is recommended that the
+proposal asked that the incubator pmc to act as sponsor.
+                </p>
+                <p>
+Note that the final destination within the Apache organisational structure
+will be decided upon graduation.
+                </p>
+                </blockquote>
+            </section>
+        </section>
+      </section>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Added: incubator/public/trunk/site-publish/guides/proposal.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/proposal.html?rev=422181&view=auto
==============================================================================
--- incubator/public/trunk/site-publish/guides/proposal.html (added)
+++ incubator/public/trunk/site-publish/guides/proposal.html Sat Jul 15 01:53:25 2006
@@ -0,0 +1,791 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+               "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<!--
+Copyright 1999-2006 The Apache Software Foundation
+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.
+-->
+<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>A Guide To Proposal Creation (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">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">Other Guides</div>
+    <menu compact="compact">
+          <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">Website</a></li> 
+            </menu>
+      <div class="menuheader"><a 
+href="http://wiki.apache.org/incubator">Wiki</a></div> 
+    <menu compact="compact">
+            </menu>
+
+     <!--#include virtual="/ads/bannerbar.html" -->    </td>
+    <!-- CONTENT -->
+    <td align="left" valign="top" class="content">
+                <h2><img src="/images/redarrow.gif" />
+   <a name="preamble">A Guide To Proposal Creation (DRAFT)</a>
+</h2>
+<div class="section-content">
+<h3>
+   <a name="status">Status - DRAFT</a>
+</h3>
+<div class="section-content">
+<p>
+This document is under <a href="#help-wanted">development</a>. This is the first 
+draft intended to allow public review. 
+          </p>
+</div>
+<h3>
+   <a name="abstract">Abstract</a>
+</h3>
+<div class="section-content">
+<p>
+This document is descriptive not normative. It describes ways to go about
+drawing up a proposal for submission. It is not an inflexible standard but
+respresents a consensus condensed from previous discussions on the
+incubator general list.
+          </p>
+</div>
+<h3>
+   <a name="background">Background</a>
+</h3>
+<div class="section-content">
+<p>
+Entry to the incubator is a democractic process. The incubator pmc votes on
+whether to accept or not. The proposal is the document upon which the pmc
+votes. So, though it's not necessary or sufficient to have a good proposal,
+a good proposal document will increase the chances of a positive result.
+           </p>
+<p>
+The proposal is (in some ways) a manifesto. It should shape the evolution of
+the product at apache. A lot of the information contained should be included
+in the initial project website.
+           </p>
+</div>
+<h3>
+   <a name="help-wanted">Help Wanted!</a>
+</h3>
+<div class="section-content">
+<p>
+Help to improve the system by posting a patch for this document to the
+incubator section of JIRA or a comment to the general list at incubator.
+          </p>
+</div>
+</div>
+           <h2><img src="/images/redarrow.gif" />
+   <a name="formulating">Formulating A Proposal</a>
+</h2>
+<div class="section-content">
+<p>
+Start by RTFM. The Entry To The incubator is a good place to start this
+process.
+       </p>
+<p>
+Subscribe to general@incubator.apache.org. Spend some time reviewing the 
+mailing lists archives . The mailing lists are the canonical form of
+communication and decision making at Apache. The documentation represents
+an attempt to codify the consensus formed on list.
+       </p>
+<p>
+Before drawing up a lengthy proposal, recruit a champion. [links to other
+documentation explaning role of champion] The champion knows how Apache work
+and should be able to help navigate the process.
+       </p>
+<p>
+Review recent proposals [links to the wiki] and how they have been received.
+       </p>
+<p>
+The incoming community needs to work together before presenting this
+proposal to
+the incubator. Think about goals and about the reasons for coming to apache.
+       </p>
+<p>
+Once the preparatory work is done, the proposal should be presented to the
+incubator.  This is done by posting the proposal
+in plain text in a email whose subject is prefixed with [PROPOSAL].
+       </p>
+<p>
+Expect to work on improving the template on list after presenting it. The
+wiki is an excellent way to develop a proposal. Consider creating a wiki
+page containing the same content and supplying a link. Interested parties
+may wish to add themselves to the watch list for the page so that received
+email notifications when the page is changed.
+       </p>
+<p>
+When the proposal seems finish and some sort of consensus has emerged, the
+proposal can be put to the vote.
+      </p>
+</div>
+           <h2><img src="/images/redarrow.gif" />
+   <a name="proposal-template">Proposal Template</a>
+</h2>
+<div class="section-content">
+<p>
+The aim of presenting a template with examples and comments is educational.
+Proposals are not required to adopt this format. If you can see a better
+way: great - try it. 
+      </p>
+<p>
+Every proposal is different. There may be sections which don't seem to be
+useful. It's fine to miss them out and to add new ones that the proposal seems
+to need.
+      </p>
+<p>
+In the following sections:
+      </p>
+<blockquote>
+      <p>
+Commentary is thus.
+      </p>
+      <p>
+<pre>Examples are thus.</pre>
+      </p>
+      </blockquote>
+<h3>
+   <a name="template">Template</a>
+</h3>
+<div class="section-content">
+<h4>
+   <a name="template-abstract">Abstract</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+What is the proposed project? 
+</p><p>
+A short descriptive summary of the
+project. Ideally one sentence in length.
+</p><p>
+The technical vision for an open source project should be communicatable 
+in a short paragraph. This paragraph will most like be used for
+the board resolution used to create the official project upon graduation,
+may be used as the first paragraph on the web site and as the DOAP
+description.
+</p>
+<pre>
+Examples
+       Geronimo will be a J2EE compliant container.
+       
+       Heraldry will develop technologies around the emerging  
+           user-centric identity space.
+           
+       Yoko will be a CORBA server.
+</pre>
+       </blockquote>
+</div>
+<h4>
+   <a name="template-proposal">Proposal</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+A lengthier description of the proposal. Should be reasonably declarative.
+More discursive material can be included in later sections.
+</p>
+<pre>
+Examples:
+</pre>
+        </blockquote>
+</div>
+<h4>
+   <a name="template-background">Background</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+For some projects, it may be useful to provide context for those unfamiliar
+with the project space and history.
+</p><p>
+If there any likelihood of confusion over the meaning of some terms (for example, 
+if there is not a single widely adopted definition), explain what is meant by them.
+if the problem domain is likely to be unfamiliar to many then please give an outline.
+<p>
+</p>
+This content should be capable of being safely ignored by any domain
+experts.
+<p>
+</p>
+This material should probably find an eventual home on the project website.
+</p>
+<pre>
+Examples:
+</pre>
+        </blockquote>
+</div>
+<h4>
+   <a name="template-rationale">Rationale</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+Why does this project need to exist and why should it be adopted by apache?
+<p>
+</p>
+More discursive material is probably better in this section rather than in
+the proposal.
+<p>
+</p>
+This content should be ignorable for those for whom the need is obvious.
+</p>
+<pre>
+Examples:
+</pre>
+        </blockquote>
+</div>
+<h4>
+   <a name="template-initial-goals">Initial Goals</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+Only include this section if it is not obvious. If the proposal is complex
+(probably involving multiple code bases) then people may worry about it's
+practicallity and whether it may drag in too much Apache energy. 
+<p>
+</p>
+This is a good place to explain the plan and demonstrate that the proposal
+is feasible and has been thought through.
+</p>
+<pre>
+Example:
+    Initial Goals
+    -------------
+      * Expansion of Yadis and OpenID libraries into additional
+        languages beyond the existing Python, Ruby, Perl, and 
+        PHP libraries
+      * OpenID authentication specification revision to fix known
+        security considerations, investigate compatibility with 
+        the DIX IETF proposal, describe Yadis integration, and 
+        allow either an URL or XRI be used as the End User's 
+        Identifier
+      ...
+</pre>
+        </blockquote>
+</div>
+<h4>
+   <a name="template-current-status">Current Status</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+Questions are often asked about the current status of the constituent codebases
+and current development practices.
+It is sometimes useful to prempt these questions by stating honestly
+where how these balance up against principles and ideals. 
+Some proposals describe this section as criteria.
+</p><p>
+A few possible topics:
+</p>
+        </blockquote>
+<h5> 
+   <a name="template-meritocracy">Meritocracy</a> 
+</h5> 
+<div class="section-content">
+<p>
+        [need more content describing these attributes]
+        </p>
+</div>
+<h5> 
+   <a name="template-community">Community</a> 
+</h5> 
+<div class="section-content">
+<p>
+        [need more content describing these attributes]
+        </p>
+</div>
+<h5> 
+   <a name="template-core-developers">Core Developers</a> 
+</h5> 
+<div class="section-content">
+<p>
+        [need more content describing these attributes]
+        </p>
+</div>
+<h5> 
+   <a name="template-alignment">Alignment</a> 
+</h5> 
+<div class="section-content">
+<p>
+[need more content describing these attributes]
+        </p>
+</div>
+<pre>
+Examples:
+</pre>
+</div>
+<h4>
+   <a name="template-known-risks">Known Risks</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+An exercise in self-knowledge.
+Risks don't mean that a project is unacceptable.
+It is useful to collect together material prempting questions about possible risks.
+</p>
+        </blockquote>
+<h5> 
+   <a name="template-orphaned-products">Orphaned products</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+            <p>
+              [needs improvements?] This is the right place for the
+proposers to publically state their commitment to future development. It
+takes quite a while to recruit a diverse development community. So Apache
+needs to be confident that those already working on the product are still
+committed.
+            </p>
+<pre>
+Example (Yoko):
+    The contributors are leading vendors in this space.
+There is no risk of any of the usual warning signs of orphaned 
+or abandoned code.
+</pre>
+        </blockquote>
+</div>
+<h5> 
+   <a name="template-inexperience-with-open-source">Inexperience with Open Source</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+        <p>
+               [needs improvements?] One of the reasons why many closed
+project choose to move to here is the experience of Apache in the open
+source space. But this means an invest of energy by Apache so many people
+look for an indications of a willingness to learn and to give back to the community.
+        </p>
+        </blockquote>
+</div>
+<h5> 
+   <a name="template-homogenuous-developers">Homogenous Developers</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+               [needs improvements?] Healthy projects need a mix of
+developers. Open development means a commitment to encouraging a diverse mix
+of developers.
+                </p>
+            </blockquote>
+</div>
+<h5> 
+   <a name="template-reliance-on-salaired-developers">Reliance on Salaried Developers</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p> 
+               [needs improvements?] People worry about salaried developers
+who are interested in working on this project only whilst they are employed
+to do so. Apache focusses on people, not corporations. We'd like developers
+to continue to be involved with Apache no matter who their current employer
+happens to be.
+                </p>
+            </blockquote>
+</div>
+<h5> 
+   <a name="template-other-producrs">Relationships with Other Apache Products</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+               [needs improvements?]
+               People are concerned about projects that work just inside
+their own little bubble. Apache encourages projects to open to collaboration
+with other open source projects both within apache and without. This may be
+existing links but is also a good place to talk about potential future links
+and plans.
+                </p><p>
+               Apache allows different projects to have competing or
+overlapping goals. However, this should mean friendly competition with
+coorporation whenever this makes sense.
+                </p><p>
+It is not always obvious to all
+whether the proposers see themselves as direct competitors with an existing
+project, indirect competitors (same problem space, different ecological
+niche) or just peers with some overlap. So, it's best to note this. 
+It is polite to inform the the projects.
+In the case of indirect competition, it may be important that the abstract 
+describe accurately the niche.
+                </p>
+            </blockquote>
+</div>
+<h5> 
+   <a name="template-brand-fascination">A Fascination with the Apache Brand</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+               [needs improvements?] Concerns have been raised in the past
+that some projects are proposed just to generate positive publicity for
+themselves. This is a chance to build bridges with the community after past
+misdemeanors (for example, if any of those associated with the proposal have
+- in the past - sort to associate themselves with the Apache brand in
+factually incorrect ways) and promise good conduct for the future.
+                </p>
+            </blockquote>
+</div>
+<pre>
+Examples:
+</pre>
+</div>
+<h4>
+   <a name="template-documentation">Documentation</a>
+</h4>
+<div class="section-content">
+<blockquote>
+                <p>
+References to further reading material.
+                </p>
+            </blockquote>
+<pre>
+Examples:
+</pre>
+</div>
+<h4>
+   <a name="template-initial-source">Initial Source</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+Describes the origin of the proposed code base. If there is no initial source,
+note that here.
+</p>
+            </blockquote>
+<pre>
+Examples:
+</pre>
+</div>
+<h4>
+   <a name="template-ip">Source and Intellectual Property Submission Plan</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+More complex proposals (typically involving mutliple code bases) may find it useful
+to draw up an initial plan for the submission of the code here in a separate
+section. Demonstrates that the proposal is practical.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+</div>
+<h4>
+   <a name="template-external-dependencies">External Dependencies</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+External dependencies for the initial source is important. Apache has policy
+about dependencies allowed for projects. These are (to some extent) relaxed
+for projects under incubation. Listing dependencies and licenses allows any
+possible problems to be highlighted and the appropriate actions planned.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+</div>
+<h4>
+   <a name="template-cryptography">Cryptography</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+If the proposal involves cryptographic code either directly or indirectly,
+Apache needs to know so that the relevant export documentation can be
+obtained.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+</div>
+<h4>
+   <a name="template-required-resources">Required Resources</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+       Create a list of resources that the Apache infrastructure will be asked
+supply for this project. Note that the contents of this list may need to be developed.
+</p>
+            </blockquote>
+<h5> 
+   <a name="template-mailing-lists">Mailing lists</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+             Minimum project-private (for pmc) project-dev listing
+                </p><p>
+If this project is new to open source, it is often best to start with 
+these minimum lists. The initial focus needs to be on recruiting new developers. 
+Developers need to get into the habit of reading and checking commit messages.  
+As momentum is gained, the community may decide that to create commit 
+and user lists in the usual way.
+                </p><p>
+Existing open source projects moving to Apache will probably want to adopt the
+same mailing list set up here as they have already.
+                </p>
+            </blockquote>
+</div>
+<h5> 
+   <a name="template-subversion-directory">Subversion Directory</a> 
+</h5> 
+<div class="section-content">
+</div>
+<h5> 
+   <a name="template-issue-tracking">Issue Tracking</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+Apache runs JIRA and Bugzilla.
+                </p>
+            </blockquote>
+</div>
+<h5> 
+   <a name="template-other-resources">Other Resources</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+        Other resources such as continuous integration and so on should be
+added by the Podling later in the usual way (votes on list) as momentum is gained. 
+The infrastructure documentation should explain the process.
+                </p><p>
+        If the proposal requires other special infrastructure, it is best to
+give an explaination. The Apache infrastructure team usually take some
+convincing before allowing new services on core Apache hardware.
+                </p>
+<pre>
+Examples:
+</pre>
+                </blockquote>
+</div>
+</div>
+<h4>
+   <a name="template-initial-committers">Initial Committers</a>
+</h4>
+<div class="section-content">
+<blockquote>
+<p>
+        List of committers used to bootstrap the community. Note which have
+submitted CLAs.
+</p>
+<p>
+        It is a good idea to submit CLAs at the same time as proposal and
+before acceptance. There is nothing lost by having a CLA on file at Apache
+but they do take some time to process.
+</p>
+<pre>
+Examples:
+</pre>
+            </blockquote>
+</div>
+<h4>
+   <a name="template-affiliations">Affiliations</a>
+</h4>
+<div class="section-content">
+<blockquote>
+                <p>
+Little bit of a controversial subject. [link to mailing list discussions] 
+Committers at Apache are individuals
+and work here on their own behalf. They are judged on their merits not their
+affiliations. However, in the spirit of full disclosure, it is useful for
+any current affiliations which may effect their perceived independence to be 
+listed openly at the start.
+                </p><p>
+For example, those in a salaried positions whose job is to work on the
+project should list their affiliation. Having this list helps to judge how
+much diversity exists in the initial list and so how much work there is to
+do.
+                </p>
+                <p>
+It's probably best to do this in a separate section away from the committers
+list. This list is only for initial committers and drafted into the Podling.
+It does not need to be maintained and affiliations of new committers elected 
+after the bootstrap do not need to be listed.
+                </p>
+<pre>
+Examples:
+</pre>
+                </blockquote>
+</div>
+<h4>
+   <a name="template-sponsors">Sponsors</a>
+</h4>
+<div class="section-content">
+<h5> 
+   <a name="template-champion">Champion</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                <p>
+[needs improvements?] A champion should be found before the proposal is
+submitted.
+                </p>
+                </blockquote>
+</div>
+<h5> 
+   <a name="template-mentors">Mentors</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                    <p>
+[needs improvements?]
+            The list of mentors may well be established during development
+of the proposal. The absolute minimum is a single mentor but the current
+consensus is that (at least) three mentors will make things go more
+smoothly. Three mentors gives a quorum and allows the project more autonomy.
+                </p>
+                <p>
+The number of mentors a podling can have is limited only by the
+energy and interest of those eligable to mentor.
+                </p>
+                </blockquote>
+</div>
+<h5> 
+   <a name="template-sponsoring-entity">Sponsoring Entity</a> 
+</h5> 
+<div class="section-content">
+<blockquote>
+                        <p>
+This is the organisational unit within Apache taking resposibility for this
+proposal.
+The sponsoring entity can be:
+</p>
+<ul>
+        <li>Apache Board</li>
+        <li>Incubator PMC</li>
+        <li>Another Apache project</li>
+</ul>
+                <p>
+Unless there are strong links to an existing pmc, it is recommended that the
+proposal asked that the incubator pmc to act as sponsor.
+                </p>
+                <p>
+Note that the final destination within the Apache organisational structure
+will be decided upon graduation.
+                </p>
+                </blockquote>
+</div>
+</div>
+</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/activemq.html">ActiveMQ</a></li> 
+          <li><a href="/projects/adffaces.html">ADF Faces</a></li> 
+          <li><a href="/projects/agile.html">Agila</a></li> 
+          <li><a href="/projects/altrmi.html">AltRMI</a></li> 
+          <li><a href="/projects/cayenne.html">Cayenne</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/harmony.html">Harmony</a></li> 
+          <li><a href="/projects/juice.html">JuiCE</a></li> 
+          <li><a href="/projects/log4net.html">log4net</a></li> 
+          <li><a href="/projects/log4php.html">log4php</a></li> 
+          <li><a href="/projects/lokahi.html">Lokahi</a></li> 
+          <li><a href="/projects/lucene4c.html">Lucene4c</a></li> 
+          <li><a href="/projects/lucene.net.html">Lucene.Net</a></li> 
+          <li><a href="/projects/mod_ftp.html">mod_ftp</a></li> 
+          <li><a href="/projects/ode.html">Ode</a></li> 
+          <li><a href="/projects/ofbiz.html">OFBiz</a></li> 
+          <li><a href="/projects/openejb.html">OpenEJB</a></li> 
+          <li><a href="/projects/openjpa.html">OpenJPA</a></li> 
+          <li><a href="/projects/roller.html">Roller</a></li> 
+          <li><a href="/projects/servicemix.html">ServiceMix</a></li> 
+          <li><a href="/projects/solr.html">Solr</a></li> 
+          <li><a href="/projects/stdcxx.html">stdcxx</a></li> 
+          <li><a href="/projects/synapse.html">Synapse</a></li> 
+          <li><a href="/projects/tsik.html">TSIK</a></li> 
+          <li><a href="/projects/tuscany.html">Tuscany</a></li> 
+          <li><a href="/projects/wadi.html">wadi</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-2006, 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>



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


Mime
View raw message