You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@incubator.apache.org by po...@apache.org on 2017/07/06 00:20:52 UTC
[21/51] incubator git commit: Continuing progress on converting to
asciidoc.
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/pages/guides/proposal.xml
----------------------------------------------------------------------
diff --git a/pages/guides/proposal.xml b/pages/guides/proposal.xml
new file mode 100644
index 0000000..77d2a66
--- /dev/null
+++ b/pages/guides/proposal.xml
@@ -0,0 +1,1045 @@
+<?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.
+-->
+
+<!DOCTYPE document
+[
+<!ENTITY root-path '..'> <!-- The path to the incubator root -->
+]>
+
+<document>
+ <properties>
+ <title>A Guide To Proposal Creation</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</title>
+ <section id='TOC'><title>Contents</title><toc/></section>
+ <section id="status">
+ <title>Status</title>
+ <p>
+This document provides guidance only. Policy is found <a href="/incubation/Incubation_Policy.html">here</a>.
+ </p>
+ </section>
+ <section id="abstract">
+ <title>Abstract</title>
+ <p>
+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
+<a href='lists.html#general+at+incubator.apache.org'>general mailing list</a>.
+ </p>
+ </section>
+ <section id="background">
+ <title>Background</title>
+ <p>
+<a href='entry.html'>Entry</a> to the incubator is a democratic
+<a href="/incubation/Process_Description">process</a> decided by a vote.
+The proposal is the document upon which the
+<a href="/incubation/Roles_and_Responsibilities.html#Sponsor">Sponsor</a> votes.
+So, though it's neither necessary nor sufficient to have a good proposal,
+a good proposal increases the chances of a positive result.
+ </p>
+ <p>
+Proposals to the incubator generate attention. The
+<a href='lists.html#general+at+incubator.apache.org'>general mailing list</a> 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
+<a href="/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">
+jury</a>.
+Use this time to engage and inform potential
+<a href='participation.html#developer'>developers</a>
+and <a href='participation.html#user'>users</a>.
+ </p>
+ <p>
+Much of the information will be reused in the
+<a href='sites.html'>Podling website</a>.
+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.
+ </p>
+ </section>
+ <section id='note-on-improvements'><title>Continuous Improvement</title>
+ <p>
+The <a href="/incubation/Process_Description.html">Incubation process</a> 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.
+ </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
+<a href='https://issues.apache.org/jira/browse/INCUBATOR'>incubator section</a>
+of <a href='http://issues.apache.org/jira'>JIRA</a>
+or a comment to the <a href='lists.html#general+at+incubator.apache.org'>general list</a>.
+ </p>
+ </section>
+ </section>
+ <section id="formulating"><title>Formulating A Proposal</title>
+ <section id='preparation'><title>Preparation</title>
+ <p>
+Start with research. The <a href='entry.html'>incubator entry guide</a> is a good place to start.
+Read the <a href='http://www.apache.org'>Apache</a>
+<a href='http://www.apache.org/foundation'>documentation</a>.
+ </p>
+ <p>
+<a href='lists.html'>Subscribe</a> to the
+<a href='lists.html#general+at+incubator.apache.org'>general mailing list</a>.
+Spend some time reviewing the
+<a href='http://mail-archives.apache.org/mod_mbox/incubator-general/'>mailing lists archives</a>.
+The mailing lists are the canonical form of
+<a href='http://www.apache.org/foundation/how-it-works.html#communication'>communication</a>
+and <a href='http://www.apache.org/foundation/how-it-works.html#decision-making'>decision making</a>
+at Apache. Documentation is an attempt to codify the consensus formed and record the decisions taken on list.
+ </p>
+ <p>
+Before starting on the formal proposal, recruit a
+<a href="/incubation/Roles_and_Responsibilities.html#Champion">Champion</a>. The Champion understands
+Apache and should be able to help navigate the process.
+ </p>
+ <p>
+Review <a href='http://wiki.apache.org/incubator/'>recent proposals</a> and how they have been
+<a href="http://mail-archives.apache.org/mod_mbox/incubator-general/">received</a>.
+ </p>
+ <p>
+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 <a href='lists.html#general+at+incubator.apache.org'>on list</a>.
+ </p>
+ <p>
+Every proposal is different. There will always be some aspects which do not seem
+to fit well into the <a href='#proposal-template'>template</a>.
+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.
+ </p>
+ <p>
+Be sure to add your proposal to <a href='http://wiki.apache.org/incubator/ProjectProposals'>this list</a>.
+ </p>
+ </section>
+ <section id='name'><title>Project Name</title>
+ <p>
+ While it is important to ensure a
+ <a href="graduation.html#notes-names">suitable project name</a>
+ 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.
+ </p>
+ </section>
+ <section id='presentation'><title>Presentation</title>
+ <p>
+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
+<a href='lists.html#general+at+incubator.apache.org'>mailing list</a>
+whose subject is prefixed with <code>[PROPOSAL]</code>. You should be clear
+that you want to discuss your proposal when submitting this mail.
+ </p>
+ <p>
+If there is interest in the proposal, expect a lively debate to begin.
+Approval is an open and
+<a href='http://www.apache.org/foundation/voting.html'>democratic</a>
+<a href='entry.html#understanding'>process</a>.
+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
+<a href="/whoweare.html">electorate</a>.
+ </p>
+ </section>
+ <section id='developing'><title>Developing The Proposal</title>
+ <p>
+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.
+ </p>
+ <p>
+The <a href='http://wiki.apache.org/incubator/'>wiki</a> 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.
+ </p>
+ <p>
+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 <a href='participation.html'>netiquette</a>.
+ </p>
+ <p>
+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
+<a href='lists.html#general+at+incubator.apache.org'>mailing list</a>.
+ </p>
+ </section>
+ <section id='vote'><title>The Vote</title>
+ <p>
+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:
+ </p>
+<source>
+----
+/!\ '''FINAL''' /!\
+
+This proposal is now complete and has been submitted for a VOTE.
+----
+</source>
+ <p>
+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.
+ </p>
+ </section>
+</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.
+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.
+ </p>
+ <p>
+The format is less important than the content.
+ </p>
+ <p>
+In the following sections:
+ </p>
+ <note>
+ <p>
+Commentary is thus.
+ </p>
+ </note>
+ <source>
+Examples are thus.
+ </source>
+ <section id='template-abstract'><title>Abstract</title>
+ <note>
+<p>
+A short descriptive summary of the
+project. A short paragraph, ideally one sentence in length.
+</p><p>
+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 <a href='sites.html'>web site</a>
+and in the <a href='http://projects.apache.org/create.html'>DOAP</a> document.
+</p>
+ </note>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-proposal'><title>Proposal</title>
+ <note>
+<p>
+A lengthier description of the proposal. Should be reasonably declarative.
+More discursive material should be included in the <a href='#template-rationale'>rationale</a>
+(or other later sections).
+</p>
+ </note>
+<source>
+Example (XAP):
+ 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
+ ...
+</source>
+ </section>
+ <section id='template-background'><title>Background</title>
+ <note>
+<p>
+Provides context for those unfamiliar with the problem space and history.
+</p><p>
+Explain terms whose meanings may be misunderstood (for example,
+where there is not a single widely adopted definition).
+<p>
+</p>
+This content should be capable of being safely ignored by domain experts.
+It should probably find an eventual home on the Podling website.
+</p>
+ </note>
+<source>
+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
+ ...
+</source>
+ </section>
+ <section id='template-rationale'><title>Rationale</title>
+ <note>
+<p>
+Explains why this project needs to exist and why should it be adopted by Apache.
+This is the right place for discursive material.
+</p>
+ </note>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-initial-goals'><title>Initial Goals</title>
+ <note>
+<p>
+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.
+</p>
+<p>
+Many projects will not need this section.
+</p>
+ </note>
+<source>
+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
+ ...
+</source>
+ </section>
+ <section id='template-current-status'><title>Current Status</title>
+ <note>
+<p>
+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
+<a href='http://www.apache.org/foundation/'>principles</a> and
+<a href='http://www.apache.org/foundation/how-it-works.html#management'>development ideals</a>.
+</p><p>
+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.
+</p><p>
+Some proposals name this section <em>criteria</em> (though the term is a little misleading).
+</p>
+ </note>
+ <section id='template-meritocracy'><title>Meritocracy</title>
+ <note>
+ <p>
+Apache is a
+<a href='http://www.apache.org/foundation/how-it-works.html#meritocracy'>meritocracy</a>.
+ </p><p>
+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).
+ </p>
+ <p>
+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.
+ </p>
+ </note>
+ <source>
+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...
+ </source>
+ </section>
+ <section id='template-community'><title>Community</title>
+ <note>
+ <p>
+Apache is interested only in communities.
+ </p><p>
+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.
+ </p>
+ </note>
+<source>
+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...
+</source>
+ </section>
+ <section id='template-core-developers'><title>Core Developers</title>
+ <note>
+ <p>
+Apache is composed of <a href='http://www.apache.org/foundation/how-it-works.html#hats'>individuals</a>.
+ </p>
+ <p>
+It is useful to provide a brief introduction to the developers on the
+<a href='#template-initial-committers'>initial committers</a> 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.
+ </p>
+ </note>
+ <source>
+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.
+</source>
+ </section>
+ <section id='template-alignment'><title>Alignment</title>
+ <note>
+ <p>
+Describe why Apache is a good match for the proposal.
+An opportunity to highlight links with Apache
+<a href='http://projects.apache.org'>projects</a>
+and <a href='http://www.apache.org/foundation/how-it-works.html'>development philosophy</a>.
+ </p>
+ </note>
+<source>
+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.
+</source>
+ </section>
+ </section>
+ <section id='template-known-risks'><title>Known Risks</title>
+ <note>
+<p>
+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.
+</p>
+ </note>
+ <section id='template-orphaned-products'><title>Orphaned products</title>
+ <note>
+ <p>
+A public commitment to future development.
+ </p><p>
+Recruiting a diverse development community and strong user base takes time.
+Apache needs to be confident that the proposers are committed.
+ </p>
+ </note>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-inexperience-with-open-source'><title>Inexperience with Open Source</title>
+ <note>
+ <p>
+If the proposal is based on an existing open source project with a history of open development,
+then highlight this here.
+ </p>
+ <p>
+If the list of <a href='#template-initial-committers'>initial committers</a> contains developers
+with strong open source backgrounds then highlight this here.
+ </p>
+ <p>
+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.
+ </p>
+ </note>
+<source>
+Example (Cayenne):
+ Cayenne was started as an open source project in 2001 and has
+ remained so for 5 years.
+ </source>
+ <br/>
+ <source>
+Example (Beehive):
+ Many of the committers have experience working on open source
+ projects. Five of them have experience as committers on other
+ Apache projects.
+ </source>
+ <br/>
+ <source>
+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.
+ </source>
+ <br/>
+ <source>
+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.
+</source>
+ </section>
+ <section id='template-homogenuous-developers'><title>Homogenous Developers</title>
+ <note>
+ <p>
+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.
+ </p>
+ <p>
+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.
+ </p>
+ </note>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-reliance-on-salaried-developers'><title>Reliance on Salaried Developers</title>
+ <note>
+ <p>
+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.
+ </p><p>
+Apache is <a href='http://www.apache.org/foundation/how-it-works.html#hats'>about</a> people,
+not corporations. We hope that developers continue to be involved with Apache
+no matter who their current employer happens to be.
+ </p>
+ <p>
+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.
+ </p>
+ </note>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-other-producrs'><title>Relationships with Other Apache Products</title>
+ <note>
+ <p>
+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.
+ </p><p>
+This is a an opportunity to talk about existing links. It is also the right 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 between codebases and cordial cooperation between communities.
+ </p><p>
+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.
+ </p>
+ </note>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-brand-fascination'><title>A Excessive Fascination with the Apache Brand</title>
+ <note>
+ <p>
+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.
+ </p><p>
+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.
+ </p>
+ </note>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+<br/>
+<source>
+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.
+</source>
+ </section>
+ </section>
+ <section id='template-documentation'><title>Documentation</title>
+ <note>
+ <p>
+References to further reading material.
+ </p>
+ </note>
+<source>
+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
+ ...
+</source>
+ </section>
+ <section id='template-initial-source'><title>Initial Source</title>
+ <note>
+<p>
+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.
+</p><p>
+If there is no initial source, note that here.
+</p>
+ </note>
+<source>
+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>
+ </section>
+ <section id='template-ip'><title>Source and Intellectual Property Submission Plan</title>
+ <note>
+<p>
+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.
+</p>
+ </note>
+<source>
+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.
+</source>
+ </section>
+ <section id='template-external-dependencies'><title>External Dependencies</title>
+ <note>
+<p>
+External dependencies for the initial source is important. Only some external dependencies
+are allowed by Apache <a href='http://www.apache.org/legal/3party.html'>policy</a>.
+These restrictions are (to some extent) initially relaxed
+for projects under incubation.
+</p>
+<p>
+If the initial source has dependencies which would prevent graduation
+then this is the right place to indicate how these issues will be resolved.
+</p>
+ </note>
+<source>
+Example (CeltiXfire):
+ The dependencies all have Apache compatible licenses. These include
+ BSD, CDDL, CPL, MPL and MIT licensed dependencies.
+</source>
+ </section>
+ <section id='template-cryptography'><title>Cryptography</title>
+ <note>
+<p>
+If the proposal involves cryptographic code either directly or indirectly,
+Apache needs to know so that the
+<a href='http://www.apache.org/dev/crypto.html'>relevant paperwork</a> can be obtained.
+</p>
+ </note>
+ </section>
+ <section id='template-required-resources'><title>Required Resources</title>
+ <note>
+<p>
+Resources that infrastructure will be asked to supply for this project.
+</p>
+ </note>
+ <section id='template-mailing-lists'><title>Mailing lists</title>
+ <note>
+ <p>
+The minimum required lists are private@<em>{podling}</em>.incubator.apache.org
+(for confidential <a href='ppmc.html'>PPMC</a> discussions)
+and dev@<em>{podling}</em>.incubator.apache.org lists.
+<a href='ppmc.html#PPMC+Mail+List'>Note</a>
+that projects historically
+misnamed the <em>private</em> list <em>pmc</em>. To
+avoid confusion over appropriate usage it was
+<a href="/official/mailing-lists.html#july-2005">resolved</a>
+that all such lists be renamed.
+ </p><p>
+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.
+ </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. However, there is no necessity
+that all mailing lists be created during bootstrapping. New mailing lists can be
+<a href='http://www.apache.org/dev/infra-contact'>added</a>
+by a <a href='http://www.apache.org/foundation/voting.html'>VOTE</a>
+on the Podling list.
+ </p>
+ <p>
+By default, commits for <em>{podling}</em> will be emailed to
+commits@<em>{podling}</em>.incubator.apache.org.
+It is therefore recommended that this naming convention is adopted.
+ </p>
+ <p>
+Mailing list options are described at greater length
+<a href="http://wiki.apache.org/incubator/MailingListOptions">elsewhere</a>.
+ </p>
+ </note>
+<source>
+Example (Beehive):
+ * private@beehive.incubator.apache.org (with moderated subscriptions)
+ * dev@beehive.incubator.apache.org
+ * commits@beehive.incubator.apache.org
+</source>
+ </section>
+ <section id='template-subversion-directory'><title>Subversion Directory</title>
+ <note>
+ <p>
+It is conventional to use all lower case, dash-separated (<code>-</code>) directory names.
+The directory should be within the incubator directory space
+(<a href="http://svn.apache.org/repos/asf/incubator">http://svn.apache.org/repos/asf/incubator</a>).
+ </p>
+ </note>
+ <source>
+ Example (OpenJPA):
+ https://svn.apache.org/repos/asf/incubator/openjpa
+ </source>
+ </section>
+ <section id='template-git-repository'><title>Git Repository</title>
+ <note>
+ <p>
+ It is conventional to use all lower case, dash-separated (<code>-</code>) repository names.
+ The repository should be prefixed with incubator and later renamed assuming the project is promoted
+ to a TLP.
+ </p>
+ </note>
+ <source>
+ Example (Blur):
+ https://git-wip-us.apache.org/repos/asf/incubator-blur.git
+ </source>
+ </section>
+ <section id='template-issue-tracking'><title>Issue Tracking</title>
+ <note>
+ <p>
+Apache runs <a href='https://issues.apache.org/jira/secure/Dashboard.jspa'>JIRA</a>
+and <a href='http://issues.apache.org/bugzilla/'>Bugzilla</a>. Choose one. Indicate the
+name by which project should be known in the issue tracking system.
+ </p>
+ </note>
+<source>
+Example (OpenJPA):
+ JIRA Open-JPA (OPEN-JPA)
+</source>
+ </section>
+ <section id='template-other-resources'><title>Other Resources</title>
+ <note>
+ <p>
+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.
+ </p>
+ <p>
+Most standard resources not covered above (such as continuous integration)
+should be added after bootstrapping.
+The <a href='http://www.apache.org/dev'>infrastructure documentation</a> explains
+the process.
+ </p>
+ </note>
+ </section>
+ </section>
+ <section id='template-initial-committers'><title>Initial Committers</title>
+ <note>
+ <p>
+List of committers (stating name and an email address) used to bootstrap the community.
+Mark each which has submitted a
+<a href='http://www.apache.org/licenses/#clas'>contributor license agreement</a> (CLA).
+Existing committers should use their <code>apache.org</code> 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.
+ </p>
+ <p>
+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.
+ </p>
+ <p>
+Note <a href='#developing'>this</a> and
+<a href='participation.html#committer'>this</a>. 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
+<a href='lists.html#general+at+incubator.apache.org'>general list</a>.
+ </p>
+ </note>
+<source>
+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) *
+</source>
+ </section>
+ <section id='template-affiliations'><title>Affiliations</title>
+ <note>
+ <p>
+Little bit of a controversial
+<a href='http://mail-archives.apache.org/mod_mbox/incubator-general/200608.mbox/%3c5c902b9e0608071114i4a63ed67r505691b8d53ce31@mail.gmail.com%3e'>subject</a>.
+Committers at Apache are <a href='http://www.apache.org/foundation/how-it-works.html#hats'>individuals</a>
+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.
+ </p><p>
+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.
+ </p>
+ <p>
+This is best done in a separate section away from the committers
+list.
+ </p>
+ <p>
+Only the affiliations of committers on the initial bootstrap list
+are relevant. These committers have not been added by the usual
+<a href='http://www.apache.org/foundation/how-it-works.html#meritocracy'>meritocratic process</a>.
+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.
+ </p>
+ </note>
+ </section>
+ <section id='template-sponsors'><title>Sponsors</title>
+ <section id='template-champion'><title>Champion</title>
+ <note>
+ <p>
+The <a href="/incubation/Roles_and_Responsibilities.html#Champion">Champion</a> 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
+<a href='#template-mentors'>Mentor</a>.
+ </p>
+ <p>
+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.
+ </p>
+ </note>
+ </section>
+ <section id='template-mentors'><title>Nominated Mentors</title>
+ <note>
+ <p>
+Lists <a href="/incubation/Incubation_Policy.html#Mentor">eligible</a> (and willing)
+individuals nominated as <a href="/incubation/Roles_and_Responsibilities.html#Mentor">Mentors</a>
+[<a href="/incubation/Incubation_Policy.html#Mentor">definition</a>] for the candidate.
+ </p>
+<p>
+ <a href='participation.html#mentors'>Three Mentors</a> gives a quorum and allows a Podling more autonomy from the <a href="/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29">Incubator PMC</a>, 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.
+</p>
+ </note>
+ </section>
+ <section id='template-sponsoring-entity'><title>Sponsoring Entity</title>
+ <note>
+ <p>
+The <a href="/incubation/Roles_and_Responsibilities.html#Sponsor">Sponsor</a>
+is the organizational unit within Apache taking responsibility for this proposal.
+The sponsoring entity can be:
+</p>
+<ul>
+ <li>the Apache Board</li>
+ <li>the Incubator</li>
+ <li>another Apache project</li>
+</ul>
+ <p>
+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.
+ </p>
+ <p>
+Note that the final destination within the Apache organizational structure
+will be decided upon graduation.
+ </p>
+ </note>
+ </section>
+ </section>
+ </section>
+ </body>
+</document>
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/pages/guides/releasemanagement.ad
----------------------------------------------------------------------
diff --git a/pages/guides/releasemanagement.ad b/pages/guides/releasemanagement.ad
new file mode 100644
index 0000000..d5fd530
--- /dev/null
+++ b/pages/guides/releasemanagement.ad
@@ -0,0 +1,49 @@
+//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.
+= Release Management
+Apache Incubator PMC
+2002-10-16
+:jbake-type: guide
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+== What goes into a release
+
+A podling should begin to familiarize itself with ASF policies for releases. Those policies can be found at link:http://www.apache.org/dev/#releases[http://www.apache.org/dev/#releases].
+
+It is well understood that one of the goals of incubation is to help a podling understand how to
+build link:http://www.apache.org/dev/#releases[ASF compliant releases]. This is why its
+mandatory to have at least 3 +1 votes from
+link:/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29[IPMC members]
+review the releases (this should include your link:/incubation/Roles_and_Responsibilities.html#Mentor[mentors] but is not mandatory)
+for accuracy in compliance with the ASF and link:/incubation/Incubation_Policy.html#Releases[Incubator policies].
+The podling community, of course, needs to be fully engaged in review process as well. Anybody reviewing
+the releases will provide the release manager and IPMC members with information about what is wrong
+with the release. The severity of the issues and whether they are blocking or not may be discussed
+but the ultimate guidance on where podling releases may get additional flexibility belongs to the mentors and IPMC members.
+
+== Podling Constraints
+
+The link:/incubation/Incubation_Policy.html#Releases[Incubator policies] apply two additional constraints to podlings for their releases. They are repeated here for clarity only.
+- Release artifacts must include #incubating# in the final file name
+- Release artifacts must include a link:/guides/branding.html#disclaimers[disclaimer] as noted
+
+In order for a podling to receive full permission from the IPMC to execute the release, the release
+vote must be held on the link:/guides/lists.html#general+at+incubator.apache.org[incubator general list]
+and pass based on the link:http://apache.org/foundation/voting.html#ReleaseVotes[standard Package Release voting rules].
+Only Incubator PMC votes are binding, but all are encouraged to vote.
+
+The Incubator PMC expects the source releases to be staged on
+#https://dist.apache.org/repos/dist/dev/incubator/$podlingName# so that they can easily be moved
+to the release location via #svn mv#.
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/pages/guides/retirement.ad
----------------------------------------------------------------------
diff --git a/pages/guides/retirement.ad b/pages/guides/retirement.ad
new file mode 100644
index 0000000..070c438
--- /dev/null
+++ b/pages/guides/retirement.ad
@@ -0,0 +1,104 @@
+//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.
+= Guide to Retirement
+Apache Incubator PMC
+2002-10-16
+:jbake-type: guide
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+The intent of this document is to help Mentors and other
+community members understand retirement, both as a
+concept and a process.
+
+== What is Retirement?
+
+A retired podling is one which has been closed down on the
+initiative of the PPMC or the IPMC for various reasons. It is
+no longer developed at the Apache Incubator and does not have
+any other duties.
+
+It's important to view this process as being the retirement of
+the podling community, not the code. It should not be implied
+that the code is not for use - just that it has no community.
+So long as the Incubator's copyright requirements are
+fulfilled by the podling prior to retirement, its source code
+will continue to be made available through version control.
+
+Retiring a podling is analogous to moving a top-level Apache
+project to the link:http://attic.apache.org[Attic],
+but podlings receive a lower level of ongoing support -- for
+example, podling websites are deleted outright rather than
+munged to indicate retired status.
+
+== Deciding to retire
+
+In the vast majority of cases, a podling decides to retire on
+its own and that decision is later formally ratified by the
+Incubator PMC; very rarely, the IPMC may act unilaterally.
+(This is deliberate mimicry of Board oversight of TLPs --
+the language and role titles change but in general the Board
+and the IMPC merely implement the wishes of the community.)
+
+Before the IPMC gets involved, a public discussion and
+community vote SHOULD be held on the podling's dev list. This
+ensures that all podling stakeholders are properly informed and
+have the opportunity to participate in the decision.
+
+The final decision to retire the podling takes the form of a
+vote by the IPMC on general@incubator.
+
+== Steps to retirement
+
+Once the IPMC vote to retire the podling has closed, a Mentor or other volunteer needs to perform the following steps.
+
+- Update #content/podlings.xml#:
+** Update podling status to "retired".
+** Add an "enddate" attribute set to the date that the IPMC vote concluded.
+** Remove the "reporting" element.
+** Add the "resolution" element. (Follow the example of other recently retired podlings.)
+- Update the podling's status page with a prominent message indicating when the podling retired: <p><span class="retired">The ${podling} podling retired on XXXX-XX-XX</span></p>.
+- Has the copyright checkbox of the podling's incubation
+status page been checked off? If not, try to resolve it.
+If it cannot be resolved, the podling's source code must
+be removed from version control.
+- Delete the podling's dist dir, so that its releases will no
+longer be mirrored:
+#svn remove https://dist.apache.org/repos/dist/release/incubator/${podling}#
+Any incubating releases will still be available via
+link:http://archive.apache.org/dist/incubator[archive.apache.org/dist/incubator].
+- Create a file RETIRED.txt at the top-level of each podling
+source repository. This should contain something like the following:
+** #This podling has been retired, please see:<br/>http://incubator.apache.org/projects/index.html##{podling-name}
+- If the podling has a DOAP referenced in the link:https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml[projects.xml] file used for generating link:http://projects.apache.org[projects.apache.org], remove the entry.
+- Open a "task" INFRA JIRA ticket entitled "Retire the ${podling} Incubator podling". Open sub-tickets using "Create Sub-Task" as applicable:
+** Close ${podling} mailing lists
+** (If copyright task completed) Make ${podling} version control read-only
+** (If copyright task <strong>not</strong> completed) Remove ${podling} version control
+** (If JIRA) Move ${podling} JIRA to "retired" and set read-only
+** (If Bugzilla) Close ${podling} Bugzilla
+** Make ${podling} wiki read-only
+** Turn off ${podling} automatic builds
+** Update ${podling} Incubator SVN
+*** Add entries to asf-mailer.conf and send mail to cvs at incubator.apache.org
+*** Remove entries from asf-authorizaton - this makes the directory rw to the Incubator PMC.
+- After Infra modifies the website SVN permissions, disable
+the podling website by installing an link:http://svn.apache.org/repos/asf/incubator/ripple/site/.htaccess[.htaccess]
+file at the root of the podling website dir which consists
+of only a redirect to the podling status page.
+- When all steps towards retirement are done, announce completeness on general@incubator.
+- Indicate that the podling is closed down in the next board report.
+
+The user accounts of the projects committers do not need
+to be removed.
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/pages/guides/sites.ad
----------------------------------------------------------------------
diff --git a/pages/guides/sites.ad b/pages/guides/sites.ad
new file mode 100644
index 0000000..c162763
--- /dev/null
+++ b/pages/guides/sites.ad
@@ -0,0 +1,111 @@
+//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.
+= Podling Websites
+Apache Incubator PMC
+2002-10-16
+:jbake-type: guide
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+Podlings need to build a community in Apache in order to be accepted
+as part of the Apache Software Foundation. One of the tools used to build
+a community is the web site.
+
+== Podling Website Requirements
+
+Podlings are, by definition, not yet fully accepted as part of the
+Apache Software Foundation. Therefore, they are subject to additional
+constraints on their websites. These policies MUST be adhered to
+before Graduation is considered unless prior approval is obtained from
+the Incubator PMC.
+
+- The published site for each podling must conform to the guidelines in link:/guides/branding.html[Podling Branding/Publicity].
+- The sources for every podling site sources should be maintained in the podling's site SVN or git directory
+- The published site for each podling should conform to this URL space: #http://podlingname.incubator.apache.org/#
+- The staging site (if using CMS) for each podling should conform to this URL space: #http://podlingname.staging.apache.org/#
+- Every podling should maintain an incubation status file under: #http://incubator.apache.org/projects/podlingname.html#
+- Eventual extra incubation documents should be filed under: #http://incubator.apache.org/projects/podlingname/**#
+
+== Creating the Podling Website
+=== Creating A Good Podling Site
+
+Apache Project Web Sites typically include several standard pages.
+Each page is formatted with a navigation bar on the left and a project
+standard header that includes the Incubator graphic.
+
+The Web Site can be established during incubation, and migrated
+after incubation to a permanent place in the TLP home.
+
+- Project Home Page: the primary entry point to the site; contains project description, news, invitation to join the project.
+- License Page: link to the Apache License 2.0
+- Downloads: many projects in incubation will release code, and this page describes them and has links to the download pages that redirect to Apache Mirror sites.
+- Documentation: this page describes the project documentation, including javadoc for Java projects; guides, tutorials, and links to external documentation.
+- Committers: a list of current committers on the project.
+- Mailing Lists: there are several mailing lists that the community might be interested in, and this page contains mailto: links that allow easy subscription (and unsubscription) to any of them.
+- FAQ: frequently asked questions are answered here.
+- Road Map: if the project has a vision of future community or development activities, the road map is published here.
+- Source Code: links to the browsable source repository and git or svn commands to check out the sources.
+- Coding Standards: the coding standards for submitted code by the community, along with a description of how strict the project intends to be.
+- Issue Tracking: links to the JIRA or other issue tracking tool, possibly including frequently used filters for issue lists.
+- Dependencies: other projects that this project depends on.
+- favicon: the project's icon in a format suitable for a browser's address bar. If absent, an Apache Feather will be displayed.
+
+=== Web Site Generation Tool
+
+The choice of tool used to generate the web site is left to
+the podling. If you already have a tool that you are comfortable
+with, you can continue to use it. If you do not, consider using
+the link:http://www.apache.org/dev/cmsref.html[Apache CMS].
+
+Regardless of which tool you use, the web site should be maintained
+in the svn repository, and include the site generation tool as a binary
+file. This simplifies the process of site generation and enables changes
+to the site to be made by any committer. The generated site should also
+be checked into svn. This allows the generated site to be relocated
+to any part of the Apache site after incubation is complete.
+
+Since the site is independent of the code, it should exist high in
+the svn repository, e.g. parallel to the trunk of the source tree.
+
+=== Publishing Your Website
+
+Managing a podling's website is now the same as a top-level project. Review the link:http://www.apache.org/dev/project-site.html[Infra Documentation on Project Websites]
+
+=== Using A Wiki To Create Documentation
+
+Podlings may use a wiki to create documentation (including the website) providing that follow the
+link:http://cwiki.apache.org/[guidelines]. In particular, care must be taken to
+ensure that access to the wiki used to create documentation that may be included in the project
+release is restricted to only those with filed link:http://www.apache.org/licenses/[individual CLAs]. The PPMC MUST review all changes and ensure that trust is not abused.
+
+=== Web Site Transition
+
+Projects may arrive with existing web sites outside Apache. Contributing as much
+documentation as possible to the project from these sites is strongly encouraged.
+Offshore sites related to projects are fine but official web sites for Apache
+projects should be hosted by Apache.
+
+Some projects elect to maintain previous releases outside Apache. In this case, the existing site
+is typically retained as a hub for this maintenance work. Otherwise, sites should link
+or redirect to the official Apache site.
+
+Apache may accept donations of domains related to projects moving here.
+Infrastructure will then arrange for renewal of the domains and redirection
+of traffic the official site. Ask infrastructure for more details.
+
+Apache needs to deal with all commercial entities equitably. Linking to
+useful information on commercial sites is fine but unfair discrimination between
+commercial sites is not. Most Apache projects find it better to simply link only
+to relevant articles on commercial sites rather than having to vet every request
+for links to commercial activity.
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/pages/guides/website.ad
----------------------------------------------------------------------
diff --git a/pages/guides/website.ad b/pages/guides/website.ad
new file mode 100644
index 0000000..bd05300
--- /dev/null
+++ b/pages/guides/website.ad
@@ -0,0 +1,43 @@
+//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.
+= Updating the top-level Incubator website
+Apache Incubator PMC
+2002-10-16
+:jbake-type: guide
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+The Incubator website is generated by the `incubator-site` git repository. The primary document format is asciidoc, templates are based on gsp, and we use jbake to build it.
+
+You can edit files directly on github.
+
+#link pending#
+
+After you make changes, the site is built automatically. Build failures are sent to *cvs AT incubator.apache.org*
+
+== Edit the content
+=== Help Wanted!
+People with commit access to the "incubator-site" git repository can edit the source
+documents in the "content" directory. That is any ASF Member and
+any committer on a current podling in incubation. So you can all help to
+keep your project's Status page up-to-date, and if you find problems with
+the "guidelines" docs then can immediately fix them.
+If unsure, then discuss changes on the general mailing list.
+Note that the "policy" documents need special treatment.
+
+Anyone else can send patches to those documents to the INCUBATOR issue tracker.
+
+instructions coming...
+
+
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/pages/policy/roles_and_responsibilities.ad
----------------------------------------------------------------------
diff --git a/pages/policy/roles_and_responsibilities.ad b/pages/policy/roles_and_responsibilities.ad
new file mode 100644
index 0000000..9e9644a
--- /dev/null
+++ b/pages/policy/roles_and_responsibilities.ad
@@ -0,0 +1,254 @@
+= Roles and Responsibilities
+Apache Incubator PMC
+2002-10-16
+:jbake-type: policy
+:jbake-status: published
+:idprefix:
+:toc:
+:imagesdir: ../images/
+
+This document describes the roles (including Sponsor, Contributor, Mentor) and provides an overview of the responsibilities of the different parties involved in an incubation process.
+
+== The Board
+
+The link:http://www.apache.org/foundation/board/[Board Of Directors] of the
+link:http://www.apache.org/foundation/[Apache Software Foundation]
+manages
+the organizational affairs of the Foundation.
+The board is elected by the
+link:http://www.apache.org/foundation/members.html[Apache Members].
+
+The Board delegates responsibility for incubation to the
+link:#Incubator+Project+Management+Committee+%28PMC%29[IPMC].
+
+link:http://www.apache.org/foundation/board/[Directors]
+are often active in the
+Incubator.
+link:http://www.apache.org/foundation/how-it-works.html#hats[Conventionally],
+unless indicated otherwise, individuals speak personally. So, a Director speaking
+without their Board hat is not stating policy but expressing a personal opinion.
+
+See also: link:http://www.apache.org/foundation/how-it-works.html#management[How Apache Works]
+
+
+== Incubator Project Management Committee (IPMC)
+The Incubator PMC [link:/official/resolution.html[resolution]] is responsible for:
+
+* acceptance and oversight of candidate projects submitted or proposed to become part of the Foundation;
+* providing guidance and ensuring that sub-projects under it's purview develop products according to the Foundation's philosophy and guidelines for collaborative development;
+* providing a repository for the storage of incubation history and information;
+* assisting a Podling's Mentor in discharging her/his duties;
+* regularly evaluating projects under its purview for the purposes of recommending to the Sponsor whether the project should:
+** graduate from incubation;
+** continue to receive guidance and support within the Incubator; or
+** be terminated.
+
+To enable effective management of the process of incubation from the
+point of view of the PMC and from the point of view of members of a
+project under incubation, a set of policies and procedures are
+described below that identify roles and responsibilities of
+participants throughout the incubation lifecycle.
+
+A project going through the Incubator will therefore be required to
+regularly report to the Incubator PMC. This will help the PMC in its
+role of reviewing the status of a project under incubation.
+
+Finally, the Incubator PMC is the ASF body with the greatest level of
+expertise and experience in the Incubation process. They provide a
+store of knowledge that can be called on by the Mentor or a Podling
+during (or even after) the incubation process. In cases where an
+Incubation is particularly large, or where the Incubator PMC
+otherwise feels the Mentor needs additional assistance, the Incubator
+PMC may choose to provide an experienced Mentor to assist the main
+Mentor in discharging their duty.
+
+Individuals may be nominated to join the IPMC after a vote which
+passes with more than 3/4 of those voting. Additionally, any Member of the
+Apache Software Foundation may join the IPMC by request.
+
+See also: link:http://www.apache.org/foundation/how-it-works.html#management[How Apache Works]
+
+== Chair of the Incubator PMC
+The person appointed by the link:#board[Board] to have primary
+responsibility for oversight of the Incubator Project, its policies,
+and policy implementation.
+
+== Candidate
+A Candidate is a project proposed for incubation. A Candidate
+shall meet the following minimum criteria:
+
+* affiliated with a named link:#Champion[Champion]
+
+Optionally, a candidate may:
+
+* declare an affiliation with an existing Apache Project in which case the project will become the *Sponsor*;
+* specify requirements that may be anticipated during incubation; and/or
+* provide a summary of the project relationship/dependencies (existing or planned with existing Apache Projects/Products).
+
+Naturally, projects will need more than this in order to graduate from
+incubation status.
+
+A candidate project compliant with the above criteria may be proposed
+by the Champion to the Sponsor for acceptance as a Podling.
+Acceptance of a candidate shall be subject to the formal voting
+method of the Sponsor. Should that vote be accepted, the Sponsor will
+request that the Incubator PMC accept the candidate as a Podling
+under incubation. The Sponsor shall assign a Mentor, who shall be
+granted membership of the Incubator PMC for the duration of the
+incubation process.
+
+== Champion
+
+A candidate project shall be sponsored by an
+link:http://www.apache.org/foundation/index.html[Officer]
+or
+link:http://www.apache.org/foundation/members.html[Member]
+of the Foundation. The Champion assists the candidate on their
+initial submission to a Sponsor. While private conversations are not
+generally encouraged within the Apache community, the Champion's
+relationship with the Candidate should allow for this in order to
+educate the Candidate about the Apache Way and prepare the project
+for the questions and issues likely to be raised by the community.
+
+
+Before incubation begins, the Champion is expected to:
+* help with any process/ASF related hurdles before the Candidate enters incubation</li>
+* help find the right people in the ASF to speak with</li>
+* help to find Mentors</li>
+* drive the process of entering the Incubator, leading to a vote to accept the proposed podling
+
+== Sponsor
+
+The Sponsor is the entity within the ASF that makes the determination
+that a candidate would make a worthy addition to the ASF, and agrees
+to take on the candidate in question (or in the case of the Incubator
+PMC, assist it in finding a home) should it complete the incubation
+process.
+
+A Sponsor will be one of:
+
+* A Top Level Project within the ASF. In this case, the project in question has agreed that the candidate is a good fit for their project, and will take on the candidate as a sub-project upon successful completion of Incubation.
+* The Incubator PMC. In this case, the Incubator PMC agrees that the
+project in question will make a good addition to the ASF, but there
+is no clear "owner" of the candidate should it successfully complete
+incubation. An incubation exit requirement for such candidates will
+be the identification (and successfuly lobbying) of an "owner" entity
+* either the link:#board[Board] (and the candidate will be a TLP) or another
+project. In most cases, the Incubator PMC is the correct Sponsor (Candidates should discuss this
+with their Champion).
+
+[NOTE]
+====
+Note that a Sponsor is more than just a final resting place for a
+candidate that successfully completes incubation. The Sponsor, by
+taking on a candidate, is indicating that they believe the candidate
+will make a worthy addition to the ASF, and takes responsibility for
+assisting the podling through the Incubation process. The Sponsor is
+therefore expected to be actively involved in the incubation process
+and assist where necessary, giving the podling the best possible
+chance of success. In addition, an entity that is a Top Level Project
+should be involved in the Candidate's incubation in order to educate
+the Candidate about practices that are specific to that TLP and about
+other relevant projects within the TLP.
+
+However, while the Sponsor is expected to be actively involved, it is
+formally representated by the Mentors. The Mentors are the individuals
+accountable to the Incubator PMC for ensuring the incubation process
+is correctly followed. In cases where the Mentors are not fulfilling
+their responsibilities, the Sponsor (in particular its Chair) will be
+expected to remedy the situation.
+====
+
+==== Responsibilities of the Sponsor
+- to provide initial approval for a Canidate to be accepted as a Podling
+- to nominate Mentors for the incubation process
+
+== Mentor
+Mentors are chosen by the Sponsor to actively monitor the
+podling, guide the podling in
+link:http://apache.org/foundation/how-it-works.html[the Apache Way],
+and report its status
+to the Sponsor and the Incubator PMC. All Mentors must be members of the
+Incubator PMC. A Mentor has the following responsibilities
+toward the Incubator PMC, the Sponsor, and the community of the assigned
+Podling.
+
+=== Responsibilities toward Podling Community
+- to ensure that Incubator PMC decisions and/or issue are dealt with in
+a timely manner and ensure that decisions or resolutions affecting
+the Podling are communicated promptly and expeditiously;
+- to represent the interests of the Podling on the Incubator PMC;
+- to liaise between the ASF Secretary and the Podling on matters
+concerning CLA submission and acknowledgments;
+- to liaise between the ASF Infrastructure team and the Podling on
+matters concerning infrastructure support (mailing lists, CVS
+establishment, account establishment, etc.);
+- to assist the Podling on matters concerning the resolution of license
+transfers, copyright assignments, and/or software grants where
+applicable; and
+- to provide where and as appropriate, guidance on matters concerning
+Apache policies and practices - including the establishment of its
+internal steering committee.
+
+=== Responsibilities toward the Incubator PMC
+
+- monitoring the Podling through the incubation process;
+- evaluating the compliance of the Podling with Incubator PMC policies
+and procedures;
+- assessment of the Podling status with respect to continuation/exit
+strategy;
+- to notify the Incubator PMC and Sponsor of the completion of
+administrative actions; and
+- to provide updates to the Incubator PMC and Sponsor on the status of
+license grants (where and as appropriate) and other relevant legal
+information pertaining to the Podling.
+
+=== Responsibilities toward the Sponsor
+- provide status to the Sponsor as to the progress
+of the podling
+
+== Committers
+
+All committers on podlings should be familiar with link:http://www.apache.org/dev/#committers[Developer Information for Committers].
+
+The candidate shall declare an initial set of committers. On
+acceptance of a candidate project, the assigned Mentors shall be given
+access to the Podling's repository for the duration of the
+incubation process. This is to allow the Mentors to perform their
+incubation duties, and is for administrative purposes only. To be
+given full committer privileges, such as the right to add new code to
+the repository, the Mentors must earn them as would any other
+potential new committer. In some cases, the Mentors may be part of the
+initial set of declared committers, but this is not a requirement of
+the Incubation process.
+
+In association with its Mentor and Champion, a Podling community is
+largely free to get on with the stuff they want to do (code,
+architecture, product, solutions, etc.) with minimal disruption
+related to the incubator process.
+
+However, you need to make sure of a number of things:
+
+- keep your Mentors informed - they are reporting to the PMC and
+generally speaking "no news is bad news". Of course, conducting
+business on the project's mailing lists is one important way to do
+this.
+- make sure your Champion is continuously in-the-loop and has the
+latest and greatest information about your project
+- actively seek and recruit committers to your project - preferably
+linking you with existing Apache communities
+- make sure your decision making process is visible and accountable
+
+These activities are not unique to projects in the Incubator. For
+example, existing Apache Projects have regular reports made by their
+PMC Chair to the link:#board[Board].
+
+During the incubation, the committers will be expected to show how,
+as a group, they are upholding the ideals of the Apache community. In
+particular, as the Podling evolves it is anticipated that the Podling
+will establish procedures for the introduction of new committers
+through a process consistent with established Apache practices. If
+you are aiming for TLP status you may also want to start on drafting
+the policy and procedures you aim to put in place once accepted.
+
+
http://git-wip-us.apache.org/repos/asf/incubator/blob/f59ab76b/replacements
----------------------------------------------------------------------
diff --git a/replacements b/replacements
new file mode 100644
index 0000000..2f62293
--- /dev/null
+++ b/replacements
@@ -0,0 +1,2 @@
+Input: <a href=('|")(.+)('|")>(.+)</a>
+Output: link:$2[$4]
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org