You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@incubator.apache.org by jo...@apache.org on 2017/06/24 11:32:08 UTC
[2/3] incubator git commit: Continued converting pages to new layout
and technology.
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/names.xml
----------------------------------------------------------------------
diff --git a/pages/guides/names.xml b/pages/guides/names.xml
deleted file mode 100644
index 23caf15..0000000
--- a/pages/guides/names.xml
+++ /dev/null
@@ -1,366 +0,0 @@
-<?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>Podling Name Search Guide</title>
- <atom url="http://mail-archives.apache.org/mod_mbox/incubator-general/?format=atom">general@incubator.apache.org Archives</atom>
- <link href="http://purl.org/DC/elements/1.0/" rel="schema.DC"/>
- </properties>
- <body>
- <section>
- <title>Podling Name Search Guide</title>
- <ul>
- <li>
- <a href="#intro">Introduction</a>
- <ul>
- <li><a href="#meet-the-team">Meet The Apache Branding Team</a></li>
- <li><a href="#trademarks">Trademarks</a></li>
- <li><a href="#alv2">Trademarks And The Apache License</a></li>
- <li><a href="#naming-hints">What Makes A Name Good</a></li>
- <li><a href="#name-search">Podling Suitable Name Search</a></li>
- </ul>
- </li>
- <li>
- <a href="#search">Conducting A Suitable Name Search</a>
- <ul>
- <li>
- <a href="#elimination">Eliminate Unsuitable Names</a>
- <ul>
- <li><a href="#main-sequence">The Main Sequence</a></li>
- <li><a href="#ethical-suitability">Appropriateness</a></li>
- <li><a href="#uniqueness-what-and-why">Unique Enough Names</a></li>
- <li>
- <a href="#uniqueness-how-to">How To Collect Evidence Of Uniqueness</a>
- <ul>
- <li><a href="#evidence-oss">Evidence Of Open Source Adoption</a></li>
- <li><a href="#evidence-registration">Evidence Of Registration</a></li>
- <li><a href="#evidence-web">Evidence Of Use On The World Wide Web</a></li>
- </ul>
- </li>
- </ul>
- </li>
- </ul>
- </li>
- </ul>
- </section>
-
- <section id='intro'>
- <title>Introduction</title>
- <p>
- This guide is <strong>not</strong> <em>legal advice</em> or <em>legal opinion</em>:
- <strong>do not</strong> use it as a substitute.
- Its aims are education and information <strong>only</strong>.
- </p><p>
- This process filters out unsuitable names early,
- reducing the legal resources required and
- limiting the potential disruption to a community of a forced name change
- later. A smooth path, but not the only one. If there are reasons
- why this road isn't right for your podling,
- consult <a href='http://mail-archives.apache.org/mod_mbox/incubator-general/'>incubator general</a>.
- </p>
- <section id="meet-the-team">
- <title>Meet The Apache Branding Team</title>
-<p>
-Names <a href='http://www.apache.org/foundation/marks/#whoweare'>fall</a> within the responsibilities of the
-<a href='http://www.apache.org/foundation/'>V.P., Brand Management</a> (and
-<a href='http://www.apache.org/foundation/marks/#whoweare'>team</a>). Please start by reading:</p>
- <ul>
- <li>the <a href='http://www.apache.org/foundation/marks/' rel='tag'>Apache Trademark Policy</a> <br/>(which introduces trademarks and outlines our policy);</li>
- <li>the <a href='http://www.apache.org/foundation/marks/faq/' rel='tag'>Apache Trademark FAQs</a> <br/>(which answers questions asked by downstream consumers); and</li>
- <li>the <a href='http://www.apache.org/foundation/marks/pmcs.html'>Apache Project Branding Requirements</a> <br/>(which guides PMCs).</li>
- </ul>
- <p>For podlings in the Incubator, naming issues are managed co-operatively by the Brand and Incubator communities.
-Rules for podlings include all branding requirements for PMCs, plus a few extras.
- </p>
- </section>
- <section id="trademarks">
- <title>Trademarks</title>
- <p>
-Trademark law is a complex subject.
-Distinctive differences from other intellectual property laws (such as patent or copyright) mean that
-intuition or knowledge gained from other areas may not be applicable.
-The <a href='http://www.apache.org/foundation'>Apache Software Foundation</a> is
-a <a href='http://www.apache.org/foundation/faq.html#is-ASF-a-corporation'>US corporation</a>.
-Developing some understanding of the basic principles of US trademark law is therefore important.
- </p><p>
-Please read:
- </p>
- <ul>
- <li><a href='http://www.apache.org/foundation/marks/#principles'>Description of key trademark principles</a> for Apache projects;</li>
- <li><abbr title='United States Patent and Trademark Office'>USPTO</abbr> trademark
- <ul>
- <li><a href='http://www.uspto.gov/trademarks/index.jsp'>home</a> page</li>
- <li><a href='http://www.uspto.gov/trademarks/basics/index.jsp'>basics</a>, and follow the links for materials;</li>
- </ul></li>
- <li><a href='http://en.wikibooks.org/wiki/US_Trademark_Law'>US Trademark Law</a> WikiBook; and</li>
- <li><a href='http://www.ifosslr.org/ifosslr/article/view/11/37'>Passport Without A Visa: Open Source Software Licensing and Trademarks
- </a> by Tiki Dare and Harvey Anderson
- in the <a href='http://www.ifosslr.org/'>International Free and Open Source Software Law Review</a>.</li>
- </ul>
- </section>
-
- <section id="alv2">
- <title>Trademarks And The Apache License</title>
- <p>
-Like <a href='http://www.ifosslr.org/ifosslr/article/view/11/37'>many</a>
-<a href='http://www.opensource.org' rel='tag'>open source</a> licenses, the
-<a href='http://www.apache.org/licenses/LICENSE-2.0.html'>Apache License, Version 2.0</a>
-focuses on granting copyright and patent rights to the public.
-The <em>trademark</em> section permits only very limited trademark rights.
- </p>
- <blockquote cite='http://www.apache.org/licenses/LICENSE-2.0.html#trademarks'>
- <p><strong>6. Trademarks.</strong>
-This License does not grant permission to use the trade names, trademarks,
-service marks, or product names of the Licensor, except as required for
-reasonable and customary use in describing the origin of the Work and
-reproducing the content of the NOTICE file.
- </p>
- </blockquote>
- <p class='attribution'><a href='http://www.apache.org/licenses/LICENSE-2.0.html#trademarks'>Apache License, Version 2.0
- </a></p>
- <p>
-All Apache projects share the Apache License. This issues standard <strong>copy</strong>
-and <strong>patent</strong> rights to
-downstream consumers. <strong>Trademark</strong> rights for Apache products are issued and managed independently,
-beyond the Apache License. This allows Apache communities to use trademark law to protect their reputation and that of the
-<a href='http://www.apache.org/foundation/'>Foundation</a>, within the broader
-framework provided by the Brand team.
- </p>
- </section>
-
- <section id='naming-hints'>
- <title>What Makes A Name Good</title>
- <p>Good names for commercial products or <code>UNIX</code> utilities have tended to work less well here at Apache.
- Many successful Apache project names are memorable, unusual and a little
- <a href='http://www.sdtimes.com/TOP_FIVE_HEAD_SCRATCHINGEST_NAMES_FOR_APACHE_PROJECTS/By_Victoria_Reitano/About_APACHE_and_HADOOP_and_HARMONY_and_MYSQL_and_OODT_and_YAY/35959'>whimsical</a>.
- These qualities also happen to be useful when it comes to securing trademark protection.
- Have fun. Be creative.
- </p>
- </section>
- <section id="name-search">
- <title>Podling Suitable Name Search</title>
- <p>
-The initial <a href='http://incubator.apache.org/guides/proposal.html'>proposal</a>
-establishes a working name for the new podling.
-Often some discussion and filtering of suitable names happens during the election
-process but this proposed name is <strong>not</strong> final, only <em>provisional</em>.
-The community may choose to change it. Or the community may discover that the name is unsuitable:
-in which case a suitable new name must be found.
- </p><p>
-A podling needs to discover whether a name is suitable.
-The Incubator community calls this process the <em>suitable name search</em>.
-This avoids any potential confusion with phrases like
-<em>trademark search</em> with technical meanings in the trademark community.
-Please be careful with language. In particular:
-</p>
-<ul>
-<li>avoid using loaded technical legal terms;</li>
-<li>use plain, simple English to describe what you did and what you found;</li>
-<li>avoid speculation; and</li>
-<li>don't offer <em>advice</em> or <em>opinions</em>.</li>
- </ul>
-
- <p>
-A suitable name search must be successfully completed before a podling can graduate.
-This isn't the only way one might be done, just a smooth path.
-</p><p>
-Names are an essential part of building a brand and community.
-Switching names wastes the efforts put into establishing the original name.
-Therefore complete this task as soon as possible.
-</p>
-
- </section>
- </section>
-
- <section id='search'>
- <title>Conducting A Suitable Name Search</title>
- <p>The aim - to find a name that is acceptable to the community and is not unsuitable.</p>
- <p>
-A suitable name search has public and private elements.
-The <a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>tracker</a> provides the public record.
-Incubator best practice evolves over time, documentation lags.
-The public records of past searches are a primary source of guidance.
-Review now the records of previous searches, beginning with the most recent then working back.
- </p><p>
- The public record consists of <em>actions</em> (how you searched) and <em>facts</em> (what your search found). In particular,
- in <strong>all</strong> public forums (mailing lists, issue trackers and so on):
- </p>
-
- <ul>
- <li><strong>Do not</strong> speculate.</li>
- <li><strong>Do not</strong> use loaded technical legal language.</li>
- <li><strong>Do not</strong> offer
- <ul>
- <li>opinions,</li>
- <li>advice,</li>
- <li>interpretation, or</li>
- <li>analysis.</li>
- </ul>
- </li>
- </ul>
-
- <p>
-Use the public lists in the Incubator to ask questions about <em>how</em> the search should be conducted.
-Once the information is collected and collated, then ask the trademark team to help interpret and analyse these results
-on the private lists, copying in the PPMC. Finally discuss the results of your investigation on the private PPMC list.
-Whether a name is suitable or unsuitable (or somewhere in between) should be recorded when the issue is closed.
- </p>
- <section id='elimination'>
- <title>Eliminate Unsuitable Names</title>
- <p>To be suitable, a name needs to be</p>
- <ul>
- <li>judged <em>appropriate</em> by the wider community; and</li>
- <li><em>unique enough</em> to avoid confusion</li>
- </ul>
- <p>
-Facts and activities performed are <a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>recorded</a> for the public.
-Interpretation and analysis of these facts happens on private mailing lists, the PPMC private in the first instance.
-Whether the name proved suitable or unsuitable should be entered into the public record
-but take care to use our language (<em>ethically unsuitable</em> or
-<em>not unique enough</em>) and to avoid loaded legal terms.
- </p>
-
- <section id='main-sequence'><title>The Main Sequence</title>
- <p>
-Every podling is unique, but using a <a href='http://outreach.atnf.csiro.au/education/senior/astrophysics/stellarevolution_mainsequence.html'>cosmic</a>
-metaphor, most fit into a main sequence. For podlings on the main sequence,
-most of the bugs should have been squashed and rough edges documented away, so expect a smooth journey.
-Away from the main sequence, process may need to be grown, documentation is likely be sparse
-and progress less smooth.
- </p><p>
-The main sequence is described here. This well known path is
-appropriate for almost all podlings.
-If there are good reasons to think that your podling is a special case, discuss this with the
-<a href='http://mail-archives.apache.org/mod_mbox/incubator-general/'>Incubator community</a>
-and reach consensus on the way forward.
- </p>
- </section>
-
- <section id='ethical-suitability'>
- <title>Appropriateness</title>
- <p>
-Some names are not appropriate for open source projects.
-Acceptability under
-<a href='http://www.law.cornell.edu/uscode/15/1052.shtml'>US Trademark Law</a> is a good base line.
-This excludes marks that
- </p>
- <blockquote cite='http://www.law.cornell.edu/uscode/15/1052.shtml'>
-Consists of or comprises immoral, deceptive, or scandalous matter;
-or matter which may disparage or falsely suggest a connection with persons,
-living or dead, institutions, beliefs, or national symbols, or bring them into contempt, or disrepute;
- </blockquote>
- <p class='attribution'><a href='http://www.law.cornell.edu/uscode/15/1052.shtml'>US Code 15:1052
- </a></p>
- <p>
-Proposals with inappropriate names are unlikely to pass the initial hustings but spend a few moments considering
-whether anything has been missed. Check for alternative meanings, perhaps in foreign languages.
- </p>
- </section>
- <section id='uniqueness-what-and-why'><title>Unique Enough Names</title>
- <p>
-The name needs be unique enough to avoid confusion with software that already exists.
-For the community to be able to protect its reputation for quality and openness,
-its name needs to unique enough to have potential as a trademark.
- </p>
- <p>
-But this isn't only about being able to register trademark protection.
-Ethics also plays a role. Even where a name may offer enough protection, existing adoption
-of the name by an active community may mean that the choice needs to be eliminated on ethical grounds.
-There is some judgment involved in this decision. So, involve the wider Incubator community if a name is already
-used.
- </p>
- </section>
- <section id='uniqueness-how-to'>
- <title>How To Collect Evidence Of Uniqueness</title>
- <p>
-To decide whether a potential name is <em>unique enough</em> to be suitable
-</p>
-<ol>
-<li>Collect evidence about current name usage.</li>
-<li><a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>Record</a> the facts.</li>
-<li>Analyse and interpret these facts; in private with help from the brand team.</li>
-<li>Reach consensus about whether the name is unique enough.</li>
-<li><a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>Record</a> whether the name is suitable.</li>
-<li>If unsuitable then the community should pick a more unique name and repeat this process.</li>
-</ol>
- <section id="evidence-oss">
- <title>Evidence Of Open Source Adoption</title>
- <p>
-Existing adoption amongst another active open source community may give ethical
-reasons for eliminating a name. This is an example of a condition with a fractal
-boundary. Not every name which has been used before need be eliminated as unsuitable
-but this is an issue which needs to be discussed more widely and
-a consensus reached with the broad
-<a href='http://mail-archives.apache.org/mod_mbox/incubator-general/'>Incubator community</a>.
- </p>
- <p>
-Look for evidence of existing adoption amongst open source communities by searching well known
-foundries (for example <a href='http://www.github.com'>GitHub</a> and
-<a href='http://www.sourceforge.net'>Sourceforge</a>)
-and the web (use several search engines for example <a href='http://www.bing.com'>Bing</a>,
-<a href='http://www.google.com'>Google</a> and <a href='http://www.yahoo.com'>Yahoo</a>).
-Review recent <a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>records</a>
-for contemporary details about where to search.
-<a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>Record</a> each search and describe the results.
- </p>
- <p>
-If the name been used by the same community before it arrived at Apache, that's fine but should be noted in the
-<a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>record</a>.
- </p>
- </section>
- <section id="evidence-registration">
- <title>Evidence Of Registration</title>
- <p>
-A number of online resources exist which may help to discover evidence of
-competing registered trademarks.
-Not every trademark is registered. Not every registered trademark is listed in these resources.
-Even if evidence is found of existing registrations,
-this does not necessary eliminate the proposed name. Just
-<a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>record</a> the facts.
-Leave analysis and interpretation to private lists.
-When a search returns a large number of hits, focus on live registrations related to software.
-</p><p>
-The foremost online resource is <abbr title='Trademark Electronic Search System'>TESS</abbr> run by
-<abbr title='United States Patent and Trademark Office'>USPTO</abbr>. Before using
-TESS, please browse the documentation links from
-<a href='http://www.uspto.gov/trademarks/index.jsp'>USPTO trademark home</a>.
- </p>
- <p>
-Other resources which allow cheap searches of their databases exist but are often
-ephemeral. Review the <a href='https://issues.apache.org/jira/browse/PODLINGNAMESEARCH'>records</a>
-for the state of this art.
- </p>
- </section>
- <section id="evidence-web">
- <title>Evidence Of Use On The World Wide Web</title>
- <p>
-Registration of trademark is not required. Rights may also be obtained by use of a mark in commerce.
- </p><p>
-Use a variety of web search engines (for example, <a href='http://www.bing.com'>bing</a>, <a href='http://www.google.com'>google</a>
-and <a href='http://search.yahoo.com'>yahoo</a>) to survey usage on the world wide web.
-</p><ul>
-<li>The
-results returned by a search for the name itself may provide evidence of well known usages of the term.</li>
-<li>The results returned by searching for the name and <code>software</code> may provide evidence of
-existing use in trade. You may also want to search for the name and key functionality the software provides
- and name and <code>open source</code></li>
-</ul>
- </section>
- </section>
- </section>
- </section>
-
- </body>
-</document>
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/participation.ad
----------------------------------------------------------------------
diff --git a/pages/guides/participation.ad b/pages/guides/participation.ad
index f0a3536..e555906 100644
--- a/pages/guides/participation.ad
+++ b/pages/guides/participation.ad
@@ -12,7 +12,7 @@
= Guide to Participation
Apache Incubator PMC
2002-10-16
-:jbake-type: guide
+:jbake-type: pmcGuide
:jbake-status: published
:idprefix:
:toc:
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/pmc.ad
----------------------------------------------------------------------
diff --git a/pages/guides/pmc.ad b/pages/guides/pmc.ad
index a5a009e..8b9615c 100644
--- a/pages/guides/pmc.ad
+++ b/pages/guides/pmc.ad
@@ -12,7 +12,7 @@
= The Incubator PMC
Apache Incubator PMC
2002-10-16
-:jbake-type: guide
+:jbake-type: pmcGuide
:jbake-status: published
:idprefix:
:toc:
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/podling_bootstrap.ad
----------------------------------------------------------------------
diff --git a/pages/guides/podling_bootstrap.ad b/pages/guides/podling_bootstrap.ad
deleted file mode 100644
index 8bff099..0000000
--- a/pages/guides/podling_bootstrap.ad
+++ /dev/null
@@ -1,334 +0,0 @@
-<section id='bootstrap'><title>[DRAFT] Podling Bootstrap</title>
-<p>
-<strong>NOTE</strong> This section is a DRAFT under development.
-</p>
-<p>
-Following podling creation, it needs to be bootstrapped. Here are some of
-the tasks:
-
-- Ensure link:#mentors-ipmc[Mentors are on the IPMC][<code>Mentors</code>]
-- Add podling to link:#Sending+in+an+Incubation+Report[reporting schedule] [<code>IPMC member</code>]
-- link:#Initialize+Podling+Status+Page[Initialize project status page] [<code>IPMC member</code>]
-- Start link:#orientation'>orientation</a> [<code><a href='#who-committers[Prospective committers]</code>]
-- Start <code>CLA</code> and <code>CCLA</code> submission [<code>link:#who-committers[Prospective committers]</code>]
-- Start link:#initial-ip-clearance[IP Clearance]
-[<code>IPMC member</code>]
-- Request Required Resources
-** link:#request-mailing-lists'>Mailing Lists</a> [<a href='#who-infra[Infrastructure Team]]
-** Consider and plan link:#transition-mailing-lists[transition to official mailing lists]
-
-- link:#Set+Up+Repository[Subversion] [IPMC]
-- link:#request-issue-tracking'>Issue Tracking</a> [<a href='#who-infra[Infrastructure Team]]
-** Consider and plan link:#issue-tracking-transition[issue tracking transition]
-
-- link:#create-website'>Create website</a> [<code><a href='#who-committers[Prospective committers]</code>]
-** Consider and plan link:#web-site-transition[web site transition]
-
-<section id='mentors-ipmc'><title>Mentors MUST be on the IPMC</title>
-<p>
-Mentors link:/incubation/Incubation_Policy.html#Mentor[MUST] be on the IPMC.
-Any prospective Mentors who are not yet on the IPMC should ask to be added (by election).
-Email the application to <code>private@incubator.apache.org</code>.
-</p>
-<note>
-This process may take a few days.
-</note>
-</section>
-
-<section id='submit-cla'><title>CLA and CCLA Submission</title>
-<p>
-Prospective committers need to submit a
-Contributor License Agreement
-(link:http://www.apache.org/licenses/#clas[CLA]).
-This process can take a while so it is recommended that committers start to submit
-these as soon as the podling is accepted.
-</p>
-</section>
-
-<section id='initial-ip-clearance'><title>IP Clearance</title>
-<section id='initial-up-clearance-general'><title>Background</title>
-<p>
-Existing codebases need to be imported through the standard IP clearance
-process. This means that a Software Grant Agreement
-(link:http://www.apache.org/licenses/#grants[SGA])
-or Contributor License Agreement
-(link:http://www.apache.org/licenses/#clas[CLA])
-need to be submitted
-for all copyright owners. This process may take a while so it is best to
-start as soon as the podling is accepted.
-</p>
-<p>
-The acceptance of the initial codebases is approved by the
-IPMC as part of the acceptance motion. So, no vote is required by the
-PPMC. Otherwise, follow the standard IP clearance
-link:#poding-ip-clearance[process for podlings].
-</p>
-</section>
-<section id='initial-provenance'><title>Establishing Provenance</title>
-<p>
-Paperwork needs to be submitted to Apache that grants a legal license on the code
-to the Apache Software Foundation.
-As a rule of thumb, if all the material contributors to the code
-are joining the podling as initial contributors, then CLAs (individual or corporate)
-are all you need. The individuals must submit the 'individual' CLA (ICLA).
-If there are employers involved who might claim
-rights in the code, then corporate CLAs (CCLAs) are needed for those employers.
-</p><p>
-If, on the other hand, there are material contributors who are <strong>
-not</strong> joining the podling as initial contributors, or if there
-are additional corporate entities who can claim rights in the code,
-then SGAs are required from those individuals or corporations.
-</p>
-<p>
-The foregoing is only a rule of thumb. Generally, the mentors of a new project
-will need to consult with general@incubator.apache.org or the Apache legal team
-about the particular circumstances.
-</p>
-<p>
-It may take some time to track down all contributors. It is not necessary to
-have paperwork on file for all contributions before the code is imported.
-It may be necessary to reverse some patches and rewrite areas of code if
-contributors cannot be found or at not happy about given Apache written
-permission to use their code.
-</p><p>
-No releases are possible until the provenance of all the code to be release
-has been clearly established and the relevant paperwork filed with Apache. It is
-therefore important to keep the status updated.
-</p><p>
-Receipts of ICLAs, CCLAs, and SGAs are recorded by the secretary in
-the private foundation repository. Reading is restricted to members and officers
-of the foundation. If there is no officer or member available then ask on the
-general list.
-</p>
-</section>
-<section id='initial-import-code-dump'><title>Initial Code Dump</title>
-<p>
-For corporate contributions, the SGA or CCLA MUST be completed, submitted
-and received before the code is imported.
-</p><p>
-For contributions composed of patches from individual contributors,
-it is safe to import the code once the major contributors (by volume)
-have completed ICLAs or SGAs.
-</p><p>
-In either case, the code to be imported should be attached to a JIRA
-and then imported. It is recommended that the previous version
-control system is tagged so that the imported version is precisely known.
-</p><p>
-A public record MUST be made of the code imported. If the import is not
-attached to JIRA then it MUST be committed to version control.
-</p>
-<section id='svn-history'><title>Importing History</title>
-<p>
-The incoming code can either be committed as a snapshot or as a complete version
-control export including history (provided that the import is available in a format
-readable by subversion).
-Importing with history allows existing open source projects who want to maintain
-older versions at Apache to easily perform source diffs and so on. Import just the
-latest code allows a clean break to be made with the past. The choice is left to
-the community of the incoming project.
-</p><p>
-The infrastructure team will perform the import including
-mapping IDs but it is an operation that requires skill, time and care. In this case,
-please ask the infrastructure team politely.
-</p>
-</section>
-</section>
-<section id='crypto-audit'><title>Audit Cryptography</title>
-<p>
-Before the code base is committed into an Apache repository, the contribution
-link:http://www.apache.org/dev/crypto.html[MUST] be checked
-and any restricted cryptography reported appropriately. Read and follow
-link:http://www.apache.org/dev/crypto.html[this guide].
-</p>
-</section>
-<section id='initial-clean-up'>
-<title>Initial Clean Up</title>
-<p>
-Once a JIRA has been created, the source should be cleaned up.
-</p>
-<p>
-- Ensure source files use the standard Apache boilerplates.
-This may mean replacing existing license headers. The
-tools in
-<code>
-https://svn.apache.org/repos/private/committers/tools
-</code>
-and
-<code>
-https://svn.apache.org/repos/private/committers/relicense
-</code>
-may be useful.
-
-- Ensure that NOTICE and LICENSE documents are present and
-correct
-
-- Add any required notices. Consider moving copyright
-attributions from source documents to the NOTICE. Read
-<a href='http://www.apache.org/legal/src-headers.html'>
-Apache policy on headers
-</a>
-.
-
-- Audit the source for any potential licensing issues. Any
-which are found should either resolved immediately (when
-required) or noted in the status document for later.
-
-It is recommended that the initial clean up be is started
-before the code is committed. It MUST be completed before any
-releases are cut.
-</p>
-<section id='clean-up-best-practice'>
-<title>Clean Up Best Practice</title>
-<p>
-It is recommended that version control is used to create a
-public record of the process. This will assist anyone
-auditing the code provenance (now or in the future) to
-easily perform due diligence without contacting the people
-who performed the clean up. The clean up process should
-therefore clearly document (using version control) the
-evolution of the IP licensing.
-</p>
-<p>
-Particular care needs to be taken with commit messages
-during clean up. The intended audience needs to include
-lawyers and code auditors. Members of the public need to be
-able to follow and understand the process from these
-messages alone.
-</p>
-<p>
-It is therefore recommended that the initial source is
-(after being expanded from the archive) checked in as is
-into a special directory (
-<code>${project}/trunk/import</code>
-is suggested). The original packaging, copyright statements
-and license notices should be preserved. A standard Apache
-LICENSE and appropriate NOTICE should be added at the top
-for the copyright for the collective work (see
-<a href='http://www.apache.org/legal/src-headers.html'>
-policy
-</a>
-). Take particular care with this commit message. As with
-any patch that contains code which is not the original work
-of the committer, the JIRA url (for the artifact imported)
-needs to be included together with notes about the original
-copyright owner and any associated paperwork. The fact that
-this is a exact import including original headers should be
-noted to stop any queries about these foreign headers.
-</p>
-<p>
-The cleanup should then proceed in a number of commits. If
-the source provenance is complex, break the process up into
-a number of logical steps committing each in turn with a
-good message.
-</p>
-<p>
-In particular, take care when relocating copyright
-statements and license notices into the NOTICE in the root
-directory: consider moving each copyright owner individually
-so that it is easier to audit. (See
-<a
-href='http://www.apache.org/legal/src-headers.html#notice'>
-policy
-</a>
-.)
-</p>
-<p>
-Once a section of code has been cleaned up
-(and link:#repackaging[repackaged],
-if necessary) normal development can begin.
-</p>
-</section>
-</section>
-<section id='repackaging'><title>On Repackaging</title>
-<p>
-It is recommended - but not mandated - that source is repackaged
-under the Apache namespace. There is no need to use the incubator
-namespace. For example, Java source might be repackaged to
-<code>org.apache.foo.Bar</code> or a DTD to <code>http://dtd.apache.org/foo/bar</code>.
-</p><p>
-Existing open source projects moving to Apache may well need to consider
-carefully how they will approach this transition.
-</p>
-</section>
-<section id='documents-clean-up'><title>Update Documents</title>
-<p>
-Check the documentation for references to the old home of the project and update them
-with references to Apache.
-</p><p>
-Read
-link:http://incubator.apache.org/guides/branding.html[Branding Guide].
-Ensure that appropriate disclaimers are added to the appropriate documentation.
-Consider adding a <code>DISCLAIMER</code> text document.
-</p>
-<section id='build-clean-up'><title>Update Build</title>
-<p>
-If the project uses link:http://maven.apache.org[Apache Maven], the pom will
-need to be updated to reflect that the project is now at Apache. In particular:
-</p>
-<ul>
-<li>Update <code>mailingLists</code>
-<li>Update <code>organization</code>
-<li>Update <code>url</code>
-<li>Update <code>issueManagement</code>
-<li>Check <code>licenses</code>
-<li>Update <code>scm</code>
-<li>Update <code>groupId</code>
-<li>Update <code>manifestEntries</code>. It is recommended that the
-standard Apache settings are used
-<li>Update <code>developers</code> to use apache IDs (when known)
-<li>Update <code>distributionManagement</code>
-<li>Consider specifying a link:http://maven.apache.org/pom.html#relocation[relocation]
-</ul>
-<p>
-If the project uses link:http://ant.apache.org[Apache Ant], the build script
-will probably need to be updated. In particular:
-</p>
-<ul>
-<li>Ensure any MANIFESTs generated refer to Apache. It is recommended that the
-standard Apache settings are used.
-<li>Check that <code>LICENSE</code>, <code>NOTICE</code> and - if appropriate -
-<code>DISCLAIMER</code> documents are copied into binary artifacts
-</ul>
-</section>
-</section>
-</section>
-<section id='orientation'><title>Orientating New Committers: Understanding Apache</title>
-<p>
-When a committer is elected by a typical top level project, the nominator
-and other PMC members educate the new committer about Apache. In the Incubator, this
-inductive must be performed by the Mentors. This process is one of the most important
-for the long term health of a project.
-</p><p>
-Apache works on the principle that discussions should happen on the most open forum
-available. Unless the matter involves a sensitive matter (such as security or
-personal issues), it should be raised on an open mailing list (typically the podling dev list
-or the incubator general list). Use of the incubator private list should be reserved
-for official notifications and sensitive topics.
-</p><p>
-Mentors need to take care. During the initial bootstrapping a habit may develop
-of emailing private list. It is important to break this habit as soon as the mailing
-lists are available.
-</p><p>
-Netiquette about the correct use of <code>cc</code>'s may also be difficult to
-effectively impart. During the bootstrap process there are a number of occasions
-where <code>cc</code>'s are required. The typical usage is to copy in a private
-listing to indicate that the action has the lazy permission of the committee.
-<code>cc</code>'s are very commonly used to create inefficient ad-hoc mailing lists in
-the commercial world. Except for a small number of defined processes, <code>cc</code>'s
-are frowned upon at Apache. Mentor need to encourage questions to be asked first
-on the public lists of the project then raised (if necessary) to the general
-incubator list.
-</p><p>
-TODO: content, links, prose, reconsider name for this section
-</p>
-</section>
-
-<section id='issue-tracking-transition'><title>Issue Tracking Transition</title>
-<p>
-Issues for Apache projects should be tracked on Apache hardware. Some projects arrive
-with existing issues tracking. So, in the end these need to be replaced (for new development
-at least) by the Apache issues tracker. Options need to be discussed publically on list
-and a consensus reached about the best transition strategy.
-</p>
-</section>
-</section>
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator/blob/e258a499/pages/guides/proposal.ad
----------------------------------------------------------------------
diff --git a/pages/guides/proposal.ad b/pages/guides/proposal.ad
new file mode 100644
index 0000000..ec833ae
--- /dev/null
+++ b/pages/guides/proposal.ad
@@ -0,0 +1,893 @@
+= A Guide To Proposal Creation
+//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.
+:jbake-type: proposalGuide
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+This document provides guidance only. Policy is found link:/incubation/Incubation_Policy.html[here].
+
+== Abstract
+
+This document is descriptive, not normative. It describes approaches to
+drawing up a proposal for submission. It is not an inflexible standard but
+represents a consensus condensed from discussions on the
+link:lists.html#general+at+incubator.apache.org[general mailing list].
+
+=== Background
+link:entry.html[Entry] to the incubator is a democratic
+link:/incubation/Process_Description[process] decided by a vote.
+The proposal is the document upon which the
+link:/incubation/Roles_and_Responsibilities.html#Sponsor[Sponsor] votes.
+So, though it's neither necessary nor sufficient to have a good proposal,
+a good proposal increases the chances of a positive result.
+
+Proposals to the incubator generate attention. The
+link:lists.html#general+at+incubator.apache.org[general mailing list] is open,
+widely discussed and well indexed. It is a very public space.
+The proposal is a manifesto.
+A good proposal should target also the wider audience and not just the
+link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[jury].
+Use this time to engage and inform potential
+link:participation.html#developer[developers]
+and link:participation.html#user[users].
+
+Much of the information will be reused in the
+link:sites.html[Podling website].
+A good proposal should shape the future evolution of the project
+but each proposal captures only the particular instant at birth.
+It is understood that projects change and evolve.
+
+=== Continuous Improvement
+The link:/incubation/Process_Description.html[Incubation process] is continuously evolving.
+Hopefully this will help newer projects to be even stronger and more successful then existing ones.
+One consequence of this approach is that precedence is not always a reliable guide.
+Another is that documentation may be a little outdated.
+
+=== Help Wanted!
+Help to improve the system by posting a patch for this document to the
+link:https://issues.apache.org/jira/browse/INCUBATOR[incubator section]
+of link:http://issues.apache.org/jira[JIRA]
+or a comment to the link:lists.html#general+at+incubator.apache.org[general list].
+
+== Formulating A Proposal
+=== Preparation
+
+Start with research. The link:entry.html[incubator entry guide] is a good place to start.
+Read the link:http://www.apache.org[Apache]
+link:http://www.apache.org/foundation[documentation].
+
+link:lists.html[Subscribe] to the
+link:lists.html#general+at+incubator.apache.org[general mailing list].
+Spend some time reviewing the
+link:http://mail-archives.apache.org/mod_mbox/incubator-general/[mailing lists archives].
+The mailing lists are the canonical form of
+link:http://www.apache.org/foundation/how-it-works.html#communication[communication]
+and link:http://www.apache.org/foundation/how-it-works.html#decision-making[decision making]
+at Apache. Documentation is an attempt to codify the consensus formed and record the decisions taken on list.
+
+Before starting on the formal proposal, recruit a
+link:/incubation/Roles_and_Responsibilities.html#Champion[Champion]. The Champion understands
+Apache and should be able to help navigate the process.
+
+Review link:http://wiki.apache.org/incubator/[recent proposals] and how they have been
+link:http://mail-archives.apache.org/mod_mbox/incubator-general/[received].
+
+The incoming community needs to work together before presenting this
+proposal to the incubator. Think about and discuss future goals and the reasons for coming to Apache.
+Feel free to ask questions link:lists.html#general+at+incubator.apache.org[on list].
+
+Every proposal is different. There will always be some aspects which do not seem
+to fit well into the link:#proposal-template[template].
+Use the template as a guide but do not feel constrained
+by it. Adopt what works and change what doesn't. That's fine - in fact, it's expected.
+
+Be sure to add your proposal to link:http://wiki.apache.org/incubator/ProjectProposals[this list].
+
+=== Project Name
+While it is important to ensure a
+link:graduation.html#notes-names[suitable project name]
+and product names sometime during incubation, it is not necessary
+to do this prior to entering incubation. In fact, be careful not to
+disrupt your proposal and entry process.
+
+=== Presentation
+
+Once the preparatory work is done, the proposal should be presented to the
+incubator. Post the proposal in plain text in an email to the
+link:lists.html#general+at+incubator.apache.org[mailing list]
+whose subject is prefixed with _[PROPOSAL]_. You should be clear
+that you want to discuss your proposal when submitting this mail.
+
+If there is interest in the proposal, expect a lively debate to begin.
+Approval is an open and
+link:http://www.apache.org/foundation/voting.html[democratic]
+link:entry.html#understanding[process].
+Discussion is an important part of opinion formation. A proposal
+will require development if it is to gain the maximum level of support from the
+link:/whoweare.html[electorate].
+
+=== Developing The Proposal
+
+Expect to work on improving the proposal on the list after presenting it.
+No preparation can cover every question. It is usual for unexpected
+and novel questions to be asked. This is often a sign of interest. So
+(though it may sometimes feel like an ordeal)
+approach these questions as a positive opportunity.
+
+The link:http://wiki.apache.org/incubator/[wiki] is a good
+development tool. Consider creating a wiki page containing the evolving proposal
+content. Those who are interested should add themselves
+to the watch list for the page so they can receive change notifications.
+
+Developing the proposal on the wiki allows easy collaboration. This has disadvantages
+as well as advantages. The wiki is just a tool to assist the easy development of the
+final proposal (the one that will be voted upon). Not every change improves a proposal
+and there is no requirement that every change is accepted by the proposers. Note that the incubator
+asks all participants to abide by appropriate link:participation.html[netiquette].
+
+Effective management of this development is an exercise in community building.
+The wiki is not an appropriate forum for debating changes. Discussion should be
+gently moved onto the appropriate
+link:lists.html#general+at+incubator.apache.org[mailing list].
+
+=== The Vote
+
+When the proposal seems finished and some sort of consensus has emerged, the
+proposal should be put to a vote.
+
+If the wiki is used to develop the proposal, please ensure that the wiki
+matches the final proposal then add a notice to the wiki that development of
+the document is now complete:
+
+[literal]
+----
+/!\ '''FINAL''' /!\
+
+This proposal is now complete and has been submitted for a VOTE.
+----
+
+Embed the final proposal text or a link to a specific revision number of the
+wiki proposal page in the email which kicks off the VOTE thread. If a change
+is required after the vote has been called then the vote must be cancelled,
+the change made, and the vote restarted. Alternatively, Mentors will advise
+on how to make the change once the proposal has been accepted if this is
+appropriate. Do not edit the wiki proposal unless you cancel the vote
+thread.
+
+== Proposal Template
+
+The aim of presenting a template with examples and comments is educational.
+Proposals are not required to adopt this format.
+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. Best practice evolves. Innovation is acceptable.
+
+The format is less important than the content.
+
+Each section is broken down into a commentary/explanation and examples, in the following format
+
+[literal]
+--
+== SECTION ==
+Commentary:
+
+ Commentary is thus.
+
+Examples:
+
+ Examples are thus.
+--
+
+The proposal template can be copy and pasted into the Incubator Wiki to speed up creation. Please remove excess commentary and examples sections
+
+[literal]
+--
+== Abstract ==
+Commentary:
+
+ A short descriptive summary of the
+ project. A short paragraph, ideally one sentence in length.
+
+ The abstract should be suitable for reuse in
+
+the board resolution used to create the official project upon graduation,
+ as the first paragraph on the podling web site and in the DOAP document.
+
+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.
+
+
+= Proposal =
+
+Commentary:
+
+ A lengthier
+description of the proposal. Should be reasonably declarative. More discursive material should be included in the rationale (or other later sections).
+
+Example:
+
+ XAP is to provide an XML-based
+declarative framework for building,
+ deploying and maintaining rich, interactive, Ajax-powered web
+ applications. A basic principal of XAP is to leverage existing Ajax
+
+
+=== Background
+===
+Commentary:
+
+ Provides context for those unfamiliar with the problem space and history.
+
+ Explain terms whose meanings may be misunderstood (for example, where there is not a single widely
+adopted definition).
+
+ This content should be capable of being safely ignored by domain experts. It should probably find an eventual home on the Podling website.
+
+Example (Heraldry):
+
+ To
+provide some background, the Higgins Project is being actively
+ developed within Eclipse and is a framework that will enable users
+ and enterprises to integrate identity, profile, and
+relationship
+ information across multiple systems. Using context providers,
+ existing and new systems such as directories, collaboration spaces
+ ...
+
+=== Rationale ===
+Commentary:
+
+
+Explains why this project needs to exist and why should it be adopted by Apache. This is the right place for discursive material.
+
+Example (Beehive):
+
+ There is a strong need for a cohesive,
+easy-to-use programming model
+ for building J2EE applications. Developers new to Java are forced to
+ learn a myriad of APIs just to build simple applications; advanced
+ J2EE developers are
+forced to write tedious plumbing code; and tools
+ authors are limited in what they can do to simplify the experience
+ due to the underlying complexity.
+
+=== Initial Goals ===
+Commentary:
+ A
+complex proposal (involving multiple existing code bases, for example) may cause concerns about its practicality. A good way to address these concerns is to create a plan that demonstrates the
+proposal is feasible and has been carefully thought through.
+
+ Many projects will not need this section.
+
+
+Example (Heraldry):
+
+ * 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
+
+=== Current Status ===
+Commentary:
+ This section (and the contained
+topics) describes the candidate's current status and development practices. This should be an honest assessment balancing these against Apache's principles and development ideals.
+
+ For some
+proposals, this is a chance to demonstrate understanding of the issues that will need to addressed before graduation. For others, this is a chance to highlight the close match with Apache that already
+exists. Proposals without an initial code base should just simply state that.
+
+ Some proposals name this section criteria (though the term is a little misleading).
+
+ *
+'''Meritocracy:'''
+
+Commentary:
+
+ Apache is a meritocracy.
+
+ Once a developer has submitted enough good patches then it should be natural that they are elected to committer. It should be
+natural that active committers are elected to the project management committee (PMC).
+
+ This process of renewal is vital to the long term health of Apache projects. This is the right place to
+demonstrate that this process is understood by the proposers.
+
+
+Example (OFBiz):
+
+ OFBiz was originally created by David E. Jones and Andy Zeneski in
+ May 2001. The project now has committers
+and users from around the
+ world. The newer committers of the project joined in subsequent
+ years by initially submitting patches, then having commit privileges
+ for some of the applications,
+and then privileges over a larger
+ range of applications...
+
+Example (Beehive):
+
+ We plan to do everything possible to encourage an environment that
+ supports a meritocracy. One of the
+lessons that the XMLBeans
+ committers have learned is that meritocracies don't just evolve
+ from good intentions; they require actively asking the community
+ for help, listing/specifying the
+work that needs to be done, and
+ keeping track of and encouraging members of the community who make
+ any contributions...
+
+ * '''Community:'''
+Commentary:
+
+ Apache is interested only
+in communities.
+
+ Candidates should start with a community and have the potential to grow and renew this community by attracting new users and developers. Explain how the proposal fits this
+vision.
+
+Example (Beehive):
+
+ BEA has been building a community around predecessors to this
+ framework for the last two years. There is currently an active
+ newsgroup that should help us
+build a new community at Apache.
+
+Example (WebWork2):
+
+ The WebWork 2 community has a strong following with active mailing
+ lists and forums.
+
+Example (WADI):
+
+ The need for a full service
+clustering and caching component in the
+ open source is tremendous as its use can be applied in many areas,
+ thus providing the potential for an incredibly large community.
+
+ * '''Core
+Developers:'''
+
+Apache is composed of individuals.
+
+It is useful to provide a brief introduction to the developers on the initial committers list. This is best done here (and not in that
+section). This section may be used to discuss the diversity of the core development team.
+
+
+Example (ServiceMix)
+ The core developers are a diverse group of developers many of which
+ are
+already very experienced open source developers. There is at
+ least one Apache Member together with a number of other existing
+ Apache Committers along with folks from various companies.
+
+http://servicemix.org/Team
+
+Example (WADI)
+ WADI was founded by Jules Gosnell in 2004, it now has a strong base
+ of developers from Geronimo, Castor, OpenEJB, Mojo, Jetty,
+ ActiveCluster,
+ActiveMQ, and ServiceMix.
+
+ * '''Alignment:'''
+
+Describe why Apache is a good match for the proposal. An opportunity to highlight links with Apache projects and development
+philosophy.
+
+
+Example (Beehive):
+ The initial code base is targeted to run within Tomcat, but the goal
+ is to allow the framework to run on any compliant Servlet or J2EE
+ container. The Web
+services component, based on JSR-181, will
+ leverage Axis. The NetUI component builds on top of Struts. The
+ underlying Controls component framework uses Velocity. There are
+ other projects that
+we will need to work with, such as the Portals
+ and Maven projects.
+
+'''Known Risks'''
+
+An exercise in self-knowledge. Risks don't mean that a project is unacceptable. If they are
+recognized and noted then they can be addressed during incubation.
+
+ * '''Orphaned products''':
+
+A public commitment to future development.
+
+Recruiting a diverse development community and
+strong user base takes time. Apache needs to be confident that the proposers are committed.
+
+
+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.
+
+
+
+Example (Ivy):
+Due to its small number of committers, there is a risk of being orphaned.
+The main knowledge of the codebase is still
+mainly owned by Xavier Hanin.
+Even if Xavier has no plan to leave Ivy development, this is a problem we
+are aware of and know that need to be worked on so that the project become
+less dependent on
+an individual.
+
+
+
+Example (Tika):
+There are a number of projects at various stages of maturity that implement
+a subset of the proposed features in Tika. For many potential users the
+existing
+tools are already enough, which reduces the demand for a more
+generic toolkit. This can also be seen in the slow progress of this proposal
+over the past year.
+
+However, once the project gets
+started we can quickly reach the feature level
+of existing tools based on seed code from sources mentioned below. After that
+we believe to be able to quickly grow the developer and user communities
+based
+on the benefits of a generic toolkit over custom alternatives.
+
+ * '''Inexperience with Open Source:'''
+
+
+If the proposal is based on an existing open source project with a history
+of open development, then highlight this here.
+
+If the list of initial committers contains developers with strong open source backgrounds then highlight this here.
+
+Inexperience with open source
+is one reason why closed projects choose to apply for incubation. Apache has developed over the years a store of experience in this area. Successfully opening up a closed project means an investment
+of energy by all involved. It requires a willingness to learn and to give back to the community. If the proposal is based around a closed project and comes with very little understand of the open
+source space, then acknowledge this and demonstrate a willingness to learn.
+
+
+Example (Cayenne):
+ Cayenne was started as an open source project in 2001 and has
+ remained so for 5
+years.
+
+
+
+Example (Beehive):
+ Many of the committers have experience working on open source
+ projects. Five of them have experience as committers on other
+ Apache projects.
+
+
+
+Example
+(Ivy):
+ While distributed under an open source license, access to Ivy was initially
+ limited with no public access to the issue tracking system or svn
+ repository. While things have changed
+since then - the svn repository is
+ publicly accessible, a JIRA instance has been setup since june 2005, many
+ new features are first discussed on the forum or JIRA - experience with a
+ true
+open source development model is currently limited.
+ However, Maarten has already a good experience with true open development
+ process, and bring his experience to the project.
+
+
+
+Example
+(River):
+ The initial committers have varying degrees of experience with open source
+ projects. All have been involved with source code that has been released under
+ an open source license, but
+there is limited experience developing code with an
+ open source development process. We do not, however, expect any difficulty in
+ executing under normal meritocracy rules.
+
+ * '''Homogenous
+Developers:'''
+
+Healthy projects need a mix of developers. Open development requires a commitment to encouraging a diverse mixture. This includes the art of working as part of a geographically
+scattered group in a distributed environment.
+
+Starting with a homogenous community does not prevent a project from entering incubation. But for those projects, a commitment to creating a diverse
+mix of developers is useful. Those projects who already have a mix should take this chance to highlight that they do.
+
+
+Example (Beehive):
+ The current list of committers includes developers from
+several
+ different companies plus many independent volunteers. The committers
+ are geographically distributed across the U.S., Europe, and Asia.
+ They are experienced with working in a
+distributed environment.
+
+
+
+Example (River)
+ Since the Jini Technology Starter Kit has been mainly developed to date by Sun
+ Microsystems, the vast majority of initial committers to the
+project are from
+ Sun. Over the years, Sun has received bug fixes and enhancements from other
+ developers which have been incorporated into the code. Our plan is to work with
+ these other
+developers and add them as committers as we progress. There are
+ three other initial committers (non Sun): Bill Venners, Dan Creswell, and Mark
+ Brouwer. Bill is the lead of the Service UI API
+work, Dan has been involved with
+ much Jini-based development, including an implementation of the JavaSpaces
+ service called Blitz <http://www.dancres.org/blitz/>, and Mark is veteran of
+ much
+Jini-based development, including commercial work at Virgil
+ <http://www.virgil.nl> as well as leading the open source Cheiron
+ <http://www.cheiron.org> project.
+
+
+
+Example (Ivy):
+ With only
+two core developers, at least they are not homogenous! Xavier and
+ Maarten knew each other only due to their common interest in Ivy.
+
+ * '''Reliance on Salaried Developers''':
+
+A project
+dominated by salaried developers who are interested in the code only whilst they are employed to do so risks its long term health.
+
+Apache is about people, not corporations. We hope that developers
+continue to be involved with Apache no matter who their current employer happens to be.
+
+This is a right place to indicate the initial balance between salaried developers and volunteers. It's also
+good to talk about the level of commitment of the developers.
+
+
+Example (OpenJPA):
+ Most of the developers are paid by their employer to contribute to
+ this project, but given the anticipation
+from the Java community for
+ the a JPA implementation and the committers' sense of ownership for
+ the code, the project would continue without issue if no salaried
+ developers contributed to
+the project.
+
+
+
+Example (River):
+ It is expected that Jini development will occur on both salaried time and on
+ volunteer time, after hours. While there is reliance on salaried developers
+
+(currently from Sun, but it's expected that other company's salaried developers
+ will also be involved), the Jini Community is very active and things should
+ balance out fairly quickly. In the
+meantime, Sun will support the project in the
+ future by dedicating 'work time' to Jini, so that there is a smooth transition.
+
+
+
+Example (Wicket):
+ None of the developers rely on Wicket for
+consulting work, though two -
+ Martijn and Eelco - are writing Wicket In Action (publisher Manning) in
+ their spare time. Most of the developers use Wicket for their day jobs,
+ some for
+multiple projects, and will do so for a considerable while as
+ their companies (specifically Topicus, Cemron and Teachscape) choose
+ Wicket as their development framework of choice.
+
+ *
+'''Relationships with Other Apache Products:'''
+
+Apache projects should be open to collaboration with other open source projects both within Apache and without. Candidates should be willing to
+reach outside their own little bubbles.
+
+This is a an opportunity to talk about existing links. It is also the right place to talk about potential future links and plans.
+
+Apache allows different
+projects to have competing or overlapping goals. However, this should mean friendly competition between codebases and cordial cooperation between communities.
+
+It is not always obvious whether a
+candidate is a direct competitor to an existing project, an indirect competitor (same problem space, different ecological niche) or are just peers with some overlap. In the case of indirect
+competition, it is important that the abstract describes accurately the niche. Direct competitors should expect to be asked to summarize architectural differences and similarities to existing
+projects.
+
+
+Example (OpenJPA):
+ Open JPA will likely be used by Geronimo, requires some Apache
+ products (regexp, commons collections, commons lang, commons pool),
+ and supports Apache
+commons logging.
+
+Example (River)
+ Currently the only tie to Apache projects is the starter kit's use
+ of the Ant build tool. There are potential future ties (http server,
+ database backend,
+etc)that will be explored.
+
+ * '''A Excessive Fascination with the Apache Brand:'''
+
+Concerns have been raised in the past that some projects appear to have been proposed just to generate
+positive publicity for the proposers. This is the right place to convince everyone that is not the case.
+
+This is also the right place 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.
+
+
+Example (CeltiXfire):
+ While we expect the Apache brand may help attract more contributors,
+ our interests in starting this project is based on the factors
+ mentioned in the
+Rationale section. However, we will be sensitive to
+ inadvertent abuse of the Apache brand and will work with the
+ Incubator PMC and the PRC to ensure the brand policies are
+respected.
+
+
+
+Example (Wicket):
+ The ASF has a strong brand, and that brand is in itself attractive.
+ However, the developers of Wicket have been quite successful on
+ their own and could
+continue on that path with no problems at all.
+ We are interested in joining the ASF in order to increase our
+ contacts and visibility in the open source world. Furthermore, we
+ have been
+enthusiastic users of Apache from the earliest hour
+ (remember JServ anyone?), and feel honored at getting the
+ opportunity to join the club.
+
+
+
+Example (OpenJPA):
+ We think that Open JPA is
+something that will benefit from wide
+ collaboration, being able to build a community of developers and
+ committers that outlive the founders, and that will be embraced
+ by other Apache efforts,
+such as the Geronimo project.
+
+'''Documentation'''
+
+References to further reading material.
+
+
+Examples (Heraldry):
+ [1] Information on Yadis can be found at:
+ http://yadis.org
+
+http://www.openidenabled.com
+
+ [2] Information on OpenID can be found at:
+ http://www.openid.net
+ http://www.openidenabled.com
+
+ The mailing list for both OpenID and Yadis is located
+at:
+ http://lists.danga.com/mailman/listinfo/yadis
+ ...
+
+'''Initial Source'''
+
+Describes the origin of the proposed code base. If the initial code arrives from more than one source,
+this is the right place to outline the different histories.
+
+If there is no initial source, note that here.
+
+
+Example (Heraldry):
+ OpenID has been in development since the summer of 2005. It
+currently
+ has an active community (over 15 million enabled accounts) and
+ libraries in a variety of languages. Additionally it is supported by
+ LiveJournal.com and is continuing to gain
+traction in the Open
+ Source Community.
+
+ Yadis has been in development since late 2005 and the specification
+ has not changed since early 2006. Like OpenID, it has libraries in
+ various
+languages and there is a large overlap between the two
+ communities. The specification is...
+
+
+'''Source and Intellectual Property Submission Plan'''
+
+Complex proposals (typically
+involving multiple code bases) may find it useful to draw up an initial plan for the submission of the code here. Demonstrate that the proposal is practical.
+
+
+Example (Heraldry):
+ * The OpenID
+specification and content on openid.net from Brad
+ Fitzpatrick of Six Apart, Ltd. and David Recordon of VeriSign,
+ Inc.
+ * The domains openid.net and yadis.org from Brad Fitzpatrick of
+
+Six Apart, Ltd. and Johannes Ernst of NetMesh, Inc.
+ * OpenID libraries in Python, Ruby, Perl, PHP, and C# from JanRain,
+ Inc.
+ ...
+ * Yadis conformance test suite from NetMesh and
+VeriSign, Inc.
+
+ We will also be soliciting contributions of further plugins and
+ patches to various pieces of Open Source software.
+
+'''External Dependencies''':
+
+ External
+dependencies for the initial source is important. Only some external dependencies are allowed by Apache policy. These restrictions are (to some extent) initially relaxed for projects under
+incubation.
+
+ If the initial source has dependencies which would prevent graduation then this is the right place to indicate how these issues will be resolved.
+
+
+ Example (CeltiXfire):
+ The
+dependencies all have Apache compatible licenses. These include
+ BSD, CDDL, CPL, MPL and MIT licensed dependencies.
+
+'''Cryptography'''
+
+If the proposal involves cryptographic code either
+directly or indirectly, Apache needs to know so that the relevant paperwork can be obtained.
+
+'''Required Resources''':
+
+ * '''Mailing lists:'''
+
+ The minimum required lists are
+private@{podling}.incubator.apache.org (for confidential PPMC discussions) and dev@{podling}.incubator.apache.org lists. Note that projects historically misnamed the private list pmc. To avoid
+confusion over appropriate usage it was resolved that all such lists be renamed.
+
+ If this project is new to open source, then starting with these minimum lists is the best approach. The initial
+focus needs to be on recruiting new developers. Early adopters are potential developers. As momentum is gained, the community may decide to create commit and user lists as they become necessary.
+
+
+Existing open source projects moving to Apache will probably want to adopt the same mailing list set up here as they have already. However, there is no necessity that all mailing lists be created
+during bootstrapping. New mailing lists can be added by a VOTE on the Podling list.
+
+ By default, commits for {podling} will be emailed to commits@{podling}.incubator.apache.org. It is therefore
+recommended that this naming convention is adopted.
+
+ Mailing list options are described at greater length elsewhere.
+
+
+ Example (Beehive):
+ * private@beehive.incubator.apache.org (with
+moderated subscriptions)
+ * dev@beehive.incubator.apache.org
+ * commits@beehive.incubator.apache.org
+
+
+ * '''Subversion Directory:'''
+
+ It is conventional to use all lower case,
+dash-separated (-) directory names. The directory should be within the incubator directory space (http://svn.apache.org/repos/asf/incubator).
+
+
+ Example (OpenJPA):
+
+https://svn.apache.org/repos/asf/incubator/openjpa
+
+
+
+ * '''Git Repositories:'''
+ It is conventional to use all lower case, dash-separated (-) repository names. The repository should be
+prefixed with incubator and later renamed assuming the project is promoted to a TLP.
+
+
+ Example (Blur):
+
+https://git-wip-us.apache.org/repos/asf/incubator-blur.git
+
+
+ * '''Issue Tracking:'''
+
+ Apache runs JIRA and Bugzilla. Choose one. Indicate the name by which project should be known in the
+issue tracking system.
+
+
+ Example (OpenJPA):
+ JIRA Open-JPA (OPEN-JPA)
+
+
+ * '''Other Resources:'''
+
+ Describe here any other special infrastructure requirements necessary for the
+proposal. Note that the infrastructure team usually requires a compelling argument before new services are allowed on core hardware. Most proposals should not require this section.
+
+ Most standard
+resources not covered above (such as continuous integration) should be added after bootstrapping. The infrastructure documentation explains the process.
+
+
+'''Initial Committers'''
+
+List of
+committers (stating name and an email address) used to bootstrap the community. Mark each which has submitted a contributor license agreement (CLA). Existing committers should use their apache.org
+email address (since they require only appropriate karma). Others should use the email address that is (or will be) on the CLA. That makes it easy to match CLAs with proposed committers to the
+project.
+
+It is a good idea to submit CLAs at the same time as the proposal. Nothing is lost by having a CLA on file at Apache but processing may take some time.
+
+Note this and this. Consider
+creating a separate section where interested developers can express an interest (and possibly leave a brief introduction) or ask them to post to the general list.
+
+
+Example (OpenJPA):
+ Abe White
+(awhite at bea dot com)
+ Marc Prud'hommeaux (mprudhom at bea dot com)
+ Patrick Linskey (plinskey at bea dot com)
+ ...
+ Geir Magnusson Jr (geirm at apache dot org) *
+ Craig Russell (clr at
+apache dot org) *
+
+'''Sponsors'''
+
+Little bit of a controversial subject. 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 the perceived independence of the initial committers to be listed openly at the
+start.
+
+For example, those in 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.
+
+This is best done in a separate section away from the committers list.
+
+Only the affiliations of committers on the initial bootstrap list are relevant. These
+committers have not been added by the usual meritocratic process. It is strongly recommended that the once a project is bootstrapped, developers are judged by their contributions and not by their
+background. This list should not be maintained after the bootstrap has been completed.
+
+ * '''Champion:'''
+ The Champion is a person already associated with Apache who leads the proposal
+process. It is common - but not necessary - for the Champion to also be proposed as a Mentor.
+
+ A Champion should be found while the proposal is still being formulated. Their role is to help
+formulate the proposal and work with you to resolve comments and questions put forth by the IPMC while reviewing the proposal.
+
+ * '''Nominated Mentors:'''
+
+Lists eligible (and willing)
+individuals nominated as Mentors [definition] for the candidate.
+
+Three Mentors gives a quorum and allows a Podling more autonomy from the Incubator PMC, so the current consensus is that three
+Mentors is a good number. Any experienced Apache community member can provide informal mentorship anyway, what's important is to make sure the podling has enough regularly available mentors to
+progress smoothly. There is no restriction on the number of mentors, formal or informal, a Podling may have.
+
+
+ * '''Sponsoring Entity''':
+ The Sponsor is the organizational unit within
+Apache taking responsibility for this proposal. The sponsoring entity can be:
+
+ - the Apache Board
+ - the Incubator
+ - another Apache project
+ The PMC for the appropriate project will decide
+whether to sponsor (by a vote). Unless there are strong links to an existing Apache project, it is recommended that the proposal asks that the Incubator for sponsorship.
+
+ Note that the final
+destination within the Apache organizational structure will be decided upon graduation.
+
+--
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org