nicolaken 2003/10/07 08:53:29
Added: src/documentation/content/xdocs/incubation bylaws.xml
forms.cwiki Incubation_Policy.cwiki process.xml
Process_Description.cwiki
Roles_and_Responsibilities.cwiki
Log:
First pass at making the new website.
It generates correctly with Forrest, please give it a try;
suggestions are welcome :-)
Revision Changes Path
1.1
incubator/src/documentation/content/xdocs/incubation/bylaws.xml
Index: bylaws.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Incubator Project Mission/Bylaws</title>
<authors>
<person name="The Apache Incubator Project"
email="[email protected]" />
</authors>
<abstract>Guiding principles and project scope/bounds.</abstract>
</header>
<body>
<section>
<title>Project Mission</title>
<note>Under development.</note>
<p>Basically, to do all good things to help communities form
and new contributors understand what Apache is all about.</p>
</section>
<section>
<title>Bylaws</title>
<note>Also under development.</note>
<p>The bylaws of the project provide specifics about what
methods can/will be used to fulfill the project's mission,
and how it will govern itself.</p>
</section>
</body>
</document>
1.1
incubator/src/documentation/content/xdocs/incubation/forms.cwiki
Index: forms.cwiki
===================================================================
!!!Forms
* [Contributor's Agreement (PDF)|../forms/ASF_Contributor_License_2_form.pdf]
1.1
incubator/src/documentation/content/xdocs/incubation/Incubation_Policy.cwiki
Index: Incubation_Policy.cwiki
===================================================================
__This document is currently a working draft, with no formal status.__
!!!Introduction
In October 2002 the Board of Directors of the Apache Software Foundation
passed a resolution creating the Apache Incubator PMC (referred to as the
"Incubator PMC" in this document) charged with "accepting new products into the
Foundation, providing guidance and support to help each new product engender
their own collaborative community, educating new developers in the philosophy
and guidelines for collaborative development as defined by the members of the
Foundation, and proposing to the board the promotion of such products to
independent PMC status once their community has reached maturity" (reference
Board Resolution).
The Incubator was tasked with the following responsibilities (reference Board
Resolution) :
* the acceptance and oversight of new products submitted or proposed to
become part of the Foundation;
* providing guidance and ensuring that subprojects under its purview develop
products according to the Foundation's philosophy and guidelines for
collaborative development; and
* regularly evaluating products under its purview and making the
determination in each case of whether the product should be abandoned, continue
to receive guidance and support, or proposed to the board for promotion to full
project status as part of an existing or new Foundation PMC; and be it further.
!!About this Document
This document is the normative reference for the policies and procedures put
in place by the Incubator PMC for the Incubation process, which is used by the
Incubator PMC to discharge their duties as described above.
It contains the minimum requirements that all new products and projects must
meet before they will be fully accepted into the Apache Software Foundation.
The document makes use of the terms MUST, MUST NOT, REQUIRED, SHALL, SHALL
NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL. Where capitalised,
these terms are to be used as per the definitions found in [RFC
2119|http://www.ietf.org/rfc/rfc2119.txt].
!Status
__This document is currently a working draft, with no formal status.__
!Scope
This document contains the minimum requirements and processes that must be
met by products and projects wishing to become part of the Apache Software
Foundation.
This document does not apply outside the process of Incubation. Policies and
processes that need to be met by products under incubation are not mandated (by
this document) for other projects and sub-projects within the ASF.
!Relationship to Other Documents
This document is the normative set of requirements for Incubation. Where
other documents are in conflict, this document should be taken as correct.
!! Changing this Document
The contents of this document are formally approved by the Incubator PMC.
All changes must be authorised by the Incubator PMC.
!!Objectives of the Process
To provide a clear path for potential projects and sub-projects within the
ASF to move from proposal stage through to fully membership in such as way as
to ensure :
* new projects and sub-projects are developing products according to the
ASF's philophy and guidelines for collaborative development;
* the ownership of any code initially submitted by the project is formally
and legaly transferred to the ASF; and
* only those products that meet the Apache's requirements are fully accepted
into the ASF.
!!Overview of the Process
The incubation process covers the establishment of a candidate, acceptance
(or rejection) of a candidate leading to the potential establishment of a
Podling and associated incubation process, which ultimately leads to the
establishment or a new Apache Top-Level-Project (TLP) or sub-project within an
existing Apache Project.
{{{
establishment |------------| acceptance |----------| engagement
|----------|
---------------> | Candidate |-------------> | Podling |--------------->|
Project |
|------------| |----------|--|
|----------|
| | ^ |
| | | | continuation
V | |--------|
rejection |
V
termination
}}}
!!!Entry to Incubation
Entry to Incubation requires a number of hurdles be passed.
!! Proposal
In order to enter the Incubator, a Candidate MUST
* be nominated for incubation by a member of the Apache Software Foundation
("The Sponsor"); and
* be approved by a Sponsoring Entity.
Approval by a Sponsoring Entity will generally occur only after a vote within
the Entity, and will require that the Entity be convinced that the Candidate is
appropriate for Incubation. A Sponsoring Entity may be one of:
* the Board of the Apache Software Foundation;
* a Top Level Project (TLP) within the Apache Software Foundation (where the
TLP considers the Candidate to be a suitable sub-project); or
* the Incubator PMC.
To start this process, a Candidate SHOULD submit a proposal to a Sponsoring
Entity. The Proposal SHOULD, at minimum, detail the following areas :
__Need to provide a short list__
!!Acceptance of Proposal by Sponsoring Entity
The decision to accept a project MUST be taken on a vote by the Sponsoring
Entity, in accordance with that Entity's charter.
Upon a successful result, the Sponsoring Entity SHOULD request the Incubator
PMC take on the Candidate as a new Podling. The request to the Incubator PMC
MUST contain the following information :
* a reference to the results of the vote (so as to provide an audit trail for
the records);
* a reference to the Candidate's proposal;
* the Mentor, nominated by the Sponsoring Entity, who will guide the
Candidate through the Incubation Process. The nominated Mentor MUST be a
member of the Apache Software Foundation.
The Incubator PMC MAY immediately accept the Candidate, or may (at the
discretion of the Incubator PMC) require a successful VOTE by the Incubator PMC.
The nominated Mentor MAY be immediately accepted by the Incubator PMC.
However the Incubator PMC MAY also suggest a replacement Mentor. The Incubator
PMC has the final choice of Mentor.
!!Creation of Podling
Upon acceptance by the Incubator PMC, the Candidate becomes a Podling under
the care of the Incubator PMC.
Upon acceptance by the Incubator PMC, the Podling's Mentor becomes a member
of the Incubator PMC (should they not already be one).
!!!Incubation Activities
The following sections detail the minimum activities that must be undertaken
by the various parties during an Incuabation process.
!!Setting Up a New Podling
Once the Podling and Mentor have been accepted by the Incubator PMC, the
following activities SHOULD take place :
* creation of lists;
* creation of cvs;
* Incubator PMC mandating a helper Mentor
!!Ongoing Activities
The progress of a Podling SHALL be tracked in a STATUS file. The STATUS file
SHALL be stored in the ''incubator'' module in the ASF CVS repository.
The STATUS file SHALL include the following minimum content :
* status of setup tasks;
* all exit criteria (see section ''Exitting the Incubator'' below);
* status of Podling against exit criteria.
The Mentor MUST ensure that the STATUS file is up to date at all times.
!!Review of Activity
Each Podling in Incubation SHALL undergo a regular review of progress by the
Incubator PMC. Such reviews SHALL occur at least quaterly. The Incubator PMC
MAY, at their discretion, choose to review individual Podlings with greater
frequency. The Incubator PMC SHALL inform Podlings of review dates at least 4
weeks in advance.
At least one week prior to each review, the Mentor MUST produce a report for
the Incubator PMC detailing overall progress with a focus on the preceeding
review period. It is RECOMMENDED that the report be based on the STATUS file
for the Podling.
After each review, the Incubator PMC SHALL produce an Assessment of the
project. The Assessment SHALL contain one of three recommendations :
* that the Podling be Terminated;
* that the Podling continue in Incubation; or
* that the Podling be escalated out of the Incubator.
Termination and Escalation are discussed in more detail in section "Exitting
the Incubator".
!!Disputing an Assessment
If the Podling or Mentor disagree with an assessment, they MAY request the
Incubator PMC review the report. Such a request MUST include a details of what
the Podling and/or Mentor is disputing, and their reasons for doing so.
Upon receipt of an Assessment Dispute, the Incubator PMC SHALL review the
request and provide feedback to the Podling and Mentor. Such feedback MAY
include a change to the original Assessment.
Should the Podling and/or Mentor still disagree with the contents of the
report, they may appeal to the Board of the Apache Software Foundation. Such
an appeal MUST include
* the original assessment;
* the request for review to the Incubator PMC;
* the response from the Incubator PMC; and
* the reason the Podling and/or Mentor still dispute the report.
The Board of the Apache Software Foundation MAY, after reviewing the appeal,
choose to
* ammend the incubation Assessment;
* validate the assessment of the Incubator PMC; or
* take any other action it deems appropriate to the circumstance.
The decision of the Board of the Apache Software Foundation is final.
!!Continuation
A recommendation by the Incubator PMC for continuation of incubation SHALL
include development recommendations. The Incubator PMC SHALL ensure that the
recommended actions are tangible and quantifiable.
The Mentor SHALL review the contents of the continuation recommendation and
ensure that the development recommendations are carried out over the following
review period.
!!!Podling Constraints
While in Incubation, Podlings are constrained in the actions they can
undertake.
!!Branding
Podlings are, by definition, not yet fully accepted as part of the Apache
Software Foundation. Podling web sites MUST include a clear disclaimer on
their website and in all documentation stating that they are in incubation.
Podlings SHOULD use the following text for all disclaimers :
''<project name> is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the <name of sponsoring entity>. Incubation is
required of all newly accepted projects until a further review indicates that
the infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of the
code, it does indicate that the project has yet to be fully endorsed by the
ASF.''
Podlings wishing to use a different disclaimer message MUST have the
disclaimer approved by the Incubator PMC prior to use.
!!Releases
As podlings are not yet fully accepted as part of the Apache Software
Foundation, any software releases (including code held in publically available
CVS) made by Podlings will not be endorsed by the ASF.
However, as software releases are an important part of any software project,
they are permitted in certain circumstances, as follows.
Podlings in Incubation SHALL NOT perform any releases of software without the
explicit approval of the Incubator PMC. Such approval SHALL be given only
after the Incubator PMC has followed the process detailed in (Reference to
Charter), and SHALL NOT occur until all source has been legally transferred to
the ASF.
Therefore, should a Podling decide it wishes to perform a release, the
Podling SHALL formally request the Incubator PMC approve such a release. The
request SHALL have the endorsement of the Mentor.
Should the Incubator PMC, in accordance with (Reference to Charter) vote to
approve the request, the Podling MAY perform the release under the following
constraints :
* the release archive MUST contain the word "incubating" in the filename; and
* the release archive MUST contain an Incubation disclaimer (as described in
the previous section), clearly visible in the main documentation or README file.
!!Use of Apache Resources
__Is this required?__
!!!Exitting the Incubator
This section describes the requirements and process for exitting the
Incubator.
!!Minimum Exit Requirements
Prior to escalation to the ASF, a Podling needs to show that :
* it is a worthy and healthy project;
* it truly fits within the ASF framework;and
* it "gets" the Apache Way.
This is achieved by imposing a set of Exit Criteria that, when met, will
demonstrate these objectives.
Therefore, to successfully exit the Incubator and be escalated fully into the
ASF, a Podling SHALL meet the minimum exit requirements detailed below. The
Incubator PMC MAY set additional requirements at their discretion. Such
additional requirements MAY be proposed by the Mentor or the Sponsoring Entity,
however only the Incubator PMC is authorised to formally place such
requirements on a Podling.
The minimum requirements that a Podling SHALL meet prior to being
successfully escalated to the ASF are :
* __Legal__
** All code ASL'ed
** No non ASL or ASL compatbile dependencies in the code base
** License grant complate
** CLAs on file.
** Check of project name for trademark issues
* __Meritocracy / Community__
** Demonstrate an active and diverse development community
** No single organization supplies more than 50% of the active committers
(must be at least 3 independent committers)
** The above implies that new committers are admitted according to ASF
practices
** ASF style voting has been adopted and is standard practice
** Demonstrate ability to tolerate and resolve conflict within the community.
** Release plans are developed and excuted in public by the community.
*** (requriment on minimum number of such releases?)
*** Note: incubator projects are not permitted to issue an official Release.
Test snapshots (however good the quality) and Release ''plans'' are OK.
** Engagement by the incubated community with the other ASF communities,
particularly infrastructure@ (this reflects my personal bias that projects
should pay an nfrastructure "tax").
** Incubator PMC has voted for graduation
** Destination PMC, or ASF Board for a TLP, has voted for final acceptance
* __Alignment / Synergy__
** Use of other ASF subprojects
** Develop synergistic relationship with other ASF subprojects
* __Infrastructure__
** CVS module has been created
** Mailing list(s) have been created
** Mailing lists are being archived
** Bugzilla has been created
** Project website has been created
** Project ready to comply with ASF mirroring guidlines
** Project is integrated with GUMP if appropriate
** Releases are PGP signed by a member of the community
** Developers tied into ASF PGP web of trust
!!Termination of a Podling
If you receive a recommendation for termination then you have a problem.
Chances are that there are either legal or structural problems with your
project that in the opinion of the Incubator PMC are not resolvable within a
reasonable time frame. A termination decision is basically time to close down
the project. However, you do have the right to appeal a termination decision
with the Board of Directors and/or your Sponsoring Entity. You should be aware
that several Members of the Board are also Members of the Incubator PMC and as
such, an appeal is unlikely to be successful.
!!Migration as a Top Level Project
In cases where a Podling has successfully completed Incubation, and is
exitting the Incubator to become a Top Level Project, the Incubator PMC SHALL
provide a recommendation to the board that the Podling is ready to escalate.
The recommendation SHALL include a draft resolution for the board to vote on.
!!Migration as a sub-project
In cases where a Podling has successfully completed Incubation, and is
exitting the Incubator to become a sub-project within an already existing Top
Level Project, the Incubator PMC SHALL provide a recommendation to the TLP that
the Podling is ready to escalate.
!!!Roles in the Incubation Process
This section describes the roles involved in the Incubation process.
!!Incubator Project Management Committee (PMC)
(From the resolution that created the Incubator Project - see
http://incubator.apache.org/resolution.html)
The Incubator PMC 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 Sponsoring Entity whether the project should:
** successfully exit incubation;
** continue to receive guidance and support within the Incubator; or
** be terminated.
!!Chair of the Incubator PMC
The person appointed by the Board of Directors to have primary responsibility
for oversight of the Incubator Project, its policies, and policy implementation.
!!Candidate
A project that is proposed for incubation.
!!Sponsor
A Member of the Apache Software Foundation who supports a Candidate's
application for Incubation and who supports and assists the Podling through the
Incubation process.
!!Sponsoring Entity
The Sponsoring Entity 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 Sponsoring Entity will be one of:
* The Board of the Apache Software Foundation. In this case, it is expected
that the candidate would become a TLP on successful completion of Incubation.
* 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 board (and the
candidate will be a TLP) or another project.
!!Mentor
A Mentor is a role undertaken by a permanent member of the Apache Software
Foundation and is chosen by the Sponsoring Entity to actively lead in the
discharge of their duties (listed above). Upon acceptance by the Incubator
PMC, the Mentor automatically becomes a member of the Incubator PMC. A Mentor
has specific responsibilities towards the Incubator PMC, the Sponsoring Entity
and towards the members of the assigned Podling.
!!Committers
The candidate shall declare an initial set of committers. On acceptance of a
candidate project, the assigned Mentor shall be given access to the Podling's
cvs repository for the duration of the incubation process. This is to allow
the Mentor 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 Mentor must earn them as would any other
potential new committer. In some cases, the Mentor may be part of the initial
set of declared committers, but this is not a requirement of the Incubation
process.
!!!Appendix A - Glossary
__Should this be a reference elsewhere?__
1.1
incubator/src/documentation/content/xdocs/incubation/process.xml
Index: process.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
<title>Incubation Process</title>
<authors>
<person name="The Apache Incubator Project"
email="[email protected]" />
</authors>
<abstract>What it means to go through the Incubator.</abstract>
</header>
<body>
<section>
<title>Entry to/Exit from the Incubator</title>
<warning>The Incubator project team is still working on this,
and even so it will be refined by experience. So don't take
anything here as either complete or completely authoritative.</warning>
<note id="Podling">Things in the Incubator may end up
being new ASF projects,
or they may end up being incorporated into some existing
project (sometimes called a 'subproject'). But while they're
in the Incubator, they're neither -- so they need to be called
something else. The term tentatively chosen by one of
the Incubator team (the one writing these words ;-) is
<strong>podling</strong>.</note>
<p>A podling might reach the Incubator by referral,
or be born there. Here are some of the ways a podling might
get here:</p>
<ul>
<li>Some group external to the Foundation wants to donate an
existing codebase;</li>
<li>Some existing Foundation [sub]project wants to build up
viability and a community around a codebase;</li>
<li>Some group of people within the Foundation want to start
a new codebase and build a community around it;</li>
<li>[others..?]</li>
</ul>
<p>That's the entry to the Incubator. The exit path similarly
has a number of different options:</p>
<ul>
<li>The podling's codebase may be declared non-viable ('dead'), and
may
either languish in the Incubator or be relocated to a
software cemetery;</li>
<li>The community around the codebase may decide that the
Apache Software Foundation isn't the right place, and so the
foundation may return title to the code and wave
<em>sayonara</em>;</li>
<li>The podling may fit best within one of the existing
ASF projects, and negociations between the Incubator and that
project result in the podling moving there;</li>
<li>The podling may seem to belong with an existing project,
but the project in question refuses to accept it [what happens?];</li>
<li>The podling represents something sufficiently
unique as to warrant the creation of a completely new ASF
project.</li>
</ul>
<p>Those are essentially the ins and outs of the Incubator
project. The remaining piece is, of course, what goes on
<em>inside</em> the Incubator with a podling that hasn't
graduated/matured yet?</p>
</section>
<section>
<title>The Process of Incubation</title>
<warning>The Incubator project team is still working on this,
and even so it will be refined by experience. So don't take
anything here as either complete or completely authoritative.</warning>
<p>From the standpoint of a codebase being incubated, there are
some things that will need to happen before it will even
be possible for it to exit from the Incubator:</p>
<ol>
<li>All software in the codebase will need to have its copyright
assigned to The Apache Software Foundation; and</li>
<li>All software in the codebase will need to be licensed
(or multi-licensed) under the
<link href="http://www.apache.org/LICENSE";>Apache licence</link>.</li>
</ol>
<p>This means that the codebase will need to be examined to ensure
that, if and when the Foundation begins distributing it, it has
clear title to do so and isn't infringing on anyone's rights.</p>
<p>The process of incubation of the codebase's community is
a little different, and consists primarily of ensuring that
the community has adopted the Apache methodologies and guidelines,
and all legal concerns have been addressed. This means the
following (among others):</p>
<ul>
<li>All contributors must sign and submit a
<link href="forms/ASF_Contributor_License_2_form.pdf"
>Contributor's Licence Agreement</link>;</li>
<li>The community has adopted the Apache voting rules and
is otherwise following the Apache guidelines;</li>
<li>The community has decided on a policy for the
composition of its 'steering committee';</li>
<li>The exit strategy for the podling has defined up front.
In particular, the incubated podling needs to know:
<ol>
<li>To which ASF project (if any) it will be graduating. This
implies
that the project is question is sponsoring the podling, at least
in part.</li>
<li>The expected timeframe that the podling will
stay in the incubator. This is determined by mutual consent
among the community of the podling, the graduation
PMC of the project to which the codebase and community will
move at the end of incubation (if any), and the Incubator PMC.</li>
<li>The "graduation requirements" for leaving the Incubator.
Basically, what are the pre-defined goals
that must be met before the podling can leave the Incubator?</li>
</ol>
</li>
<li>[what else?]</li>
</ul>
<p>TBD. Licensing, copyright, steering ctte, voting, guidelines, ..</p>
</section>
<section>
<title>Incubation Phases</title>
<warning>The Incubator project team is still working on this,
and even so it will be refined by experience. So don't take
anything here as either complete or completely authoritative.</warning>
<fixme author="nicolaken">Summarize the phases the incubating projects
go throug from proposal
to running project.</fixme>
</section>
</body>
</document>
1.1
incubator/src/documentation/content/xdocs/incubation/Process_Description.cwiki
Index: Process_Description.cwiki
===================================================================
!!!The Process of Incubation
__This is currently a draft, and has no official status.__
!!!Overview of the Process
The incubation process covers the establishment of a candidate, acceptance
(or rejection) of a candidate leading to the potential establishment of a
Podling and associated incubation process, which ultimately leads to the
establishment or a new Apache Top-Level-Project (TLP) or sub-project within an
existing Apache Project.
{{{
establishment |------------| acceptance |----------| engagement
|----------|
---------------> | Candidate |-------------> | Podling |--------------->|
Project |
|------------| |----------|--|
|----------|
| | ^ |
| | | | continuation
V | |--------|
rejection |
V
termination
}}}
Readers should also review the [Roles and Responsibilities
|Roles_and_Responsibilities] document for a description of the various parties
involved in the Incubation process.
!!!Establishment
The first thing you will want to do is find a __Sponsor __ for your project.
One way to do this is to explore the Apache site to find similar projects.
Spend some time reading both the projects' web pages and mailing lists. By
simply lurking on the mailing lists (see Mailing Lists section in this
document), you may get ideas about who you would like to ask to help you with
your project proposal. However, Sponsors must either be ASF [members
|http://www.apache.org/foundation/members.html] or [officers
|http://www.apache.org/foundation/index.html] (see the Sponsor section later in
this document for more on Sponsor criteria and responsibilities). Once you
have found an eligible person who is willing to act as sponsor, you can use
this person to help you determine if and how your proposal can complement the
ASF. If you and your Sponsor are convinced that your candidate project would
fit with the "Apache Way", your Sponsor can help you to get it established.
The establishment of a candidate involves the preparation of a project
description (consistent with the candidate description detailed below) endorsed
by a __Sponsor__.
A __Candidate __ project description should be submitted to the relevant
mailing list(s) of a __Sponsoring Entity __ (see the Mailing Lists section in
this document). See the [Jakarta Guidelines for New Projects
|http://jakarta.apache.org/site/newproject.html] for a list of issues that
should be addressed in your proposal; also see [ASF Proposal Pages
|http://nagoya.apache.org/wiki/apachewiki.cgi?ASFProposalPages] for other
examples. Typically a __Candidate __ is submitted under a message tagged with
[[PROPOSAL]. Such a message will normally trigger some discussions on the
receiving mailing list(s). Your Sponsor will be involved in these discussions
acting as your advocate.
As a proposer you should consider the feedback and attempt to gauge a sense
of consensus. Do not be put off by extended threads under your initial post
that have little or nothing to do with you proposal - however, if you feel that
your candidate project is not being addresed you may want to specifically
request a decision on the Candidate by the Sponsoring Entity by posting a
request to the decision making list (either [EMAIL PROTECTED] or [EMAIL
PROTECTED]; see Mailing List section for more details). Sometimes a vote will
be announced without you asking for it (perhaps you have done some homework and
have a PMC member assisting you though the process), other times you may need
to cut through discussions and push your request forward for a decision.
!!! Acceptance
The decision to accept a project is taken on a vote by the Sponsoring Entity.
The format of this vote will depend on the rules of the entity in question.
Here again it helps if you have a PMC Member (or board member if the Sponsoring
Entity is the ASF board) aligned with your project (preferably as your sponsor)
because you stand a better chance of getting feedback about what is actually
happening. The Sponsoring Entity will typically take about 7-10 days before
announcing a vote result.
If that vote is affirmative, the Sponsoring Entity will propose to the
__Incubator PMC __ (referencing the voting result e-mail) that your candidate
project be escalated to __Podling __ status. The Sponsoring Entity will assign
a __Shepherd __. The Shepherd may, or may not, be your original Sponsor. If
not, it is expected your Sponsor will remain involved during the rest of the
Incubation process, providing as much assistance as possible.
The Shepherd is there to protect you, but be warned - the Shepherd is also
holding a big stick. The Shepherd is automatically made a member of the
Incubator PMC, and reports to both it and the Sponsoring Entity on your overall
health and suitability for eventual inclusion within the Apache Community (or
recommendation to terminate). However, the Shepherd (with the assistance of
the Sponsor) is also looking after you through the incubation.
One of the roles of the Shepherd is to keep away the wolves - and in the case
of incubation the wolf is the Incubator PMC, the policies, the process, and
inevitable bureaucracy and delays. The Shepherd can help you by guiding and
protecting you from much of this based on his/her experience in the process and
familiarity with the policy and procedures of incubation. In performing their
role, the Shepherd is representing the Sponsoring Entity.
Your Sponsoring Entity, represented by your Shepherd, has specific
responsibilities towards you and the Incubator PMC. There are a bunch of
administrative and technical actions to take care of. Your Shepherd is
responsible for ensuring that these things happen quickly and efficiently.
Also, your Shepherd is going to help you out with the getting in place of the
policies and procedures you use for introducing new comitters, decision making,
etc. These aspects will be watched closely by the Incubator PMC as they
provide a good indication of community dynamics, health and correlation with
Apache practices.
!!!Review
As your project sorts things out and things stabilize (infrastructure,
communications, decision making) you will inevitably come under an assessment
by the Incubator PMC concerning the exit of your project from the incubator.
Keep in mind that exit can be a good things and bad thing. Exit via escalation
to a top-level project or perhaps a subproject of an existing PMC would
typically be viewed as a positive exit. On the other-hand, termination is also
an exit condition that may be considered. With an upcoming assessment it is
generally a good idea to have your STATUS file right up to-date and to ensure
that your Shepherd is doing his/her job of evangelizing your project and has
good picture of where you are relative to acceptance or the last assessment
point. This information will help the Incubator PMC to recommend the best
action for for your project.
Conclusion of a review process will be a recommendation (to the Sponsoring
Entity) of one of the following:
* termination;
* continuation under incubation with recommendations; or
* exit via escalation into Apache.
Note that whilst this is a recommendation, it carries a lot of weight. A
Sponsoring Entity will only over-ride the recommendation of the Incubator in
exceptional circumstances, and even then it is likely that the issue in
question would be escalated to the ASF board for their consideration.
!!Termination
If you receive a recommendation for termination then you have a problem.
Chances are that there are either legal or structural problems with your
project that in the opinion of the Incubator PMC are not resolvable within a
reasonable time frame. A termination decision is basically time to close down
the project. However, you do have the right to appeal a termination decision
with the Board of Directors and/or your Sponsoring Entity. You should be aware
that several Members of the Board are also Members of the Incubator PMC and as
such, an appeal is unlikely to be successful.
!!Continuation
A recommendation by the Incubator PMC for continuation of incubation shall
include development recommendations. The Incubator PMC has a responsibility to
ensure that the recommended actions are tangible and quantifiable. For
example, an assessment could be that your project has not established a
sufficient community to be viable, in which case the Incubator PMC is obliged
to state specific targets that they consider as viable. This does not
necessarily mean that if you meet this target by the next review that you are
out of incubation - but it does give you concrete achievements that you can
site. Your Shepherd is also specifically accountable to you for ensuring that
the recommendations for continuation are usable, substantive and tangible. If
this is not the case, you have every right to appeal an Incubator decision to
the Apache Board - however, if your Shepherd is doing a good job, neither of
these scenarios should arise.
!!Escalation
For Podlings that aim to establish sub-projects or products within existing
communities you are almost home-free. The main issues you need to deal with now
is migration of you code into the target project - something you should be
confident in doing based on the contacts and understanding you gained during
initial establishment and incubation.
For projects aiming to be a Top-Level-Project (TLP), you have an additional
obstacle - namely the ASF Board. While the ASF Board might be your sponsoring
entity, this does not mean they have formally accepted you as a TLP. To
establish a TLP you need to draft a board motion that identifies the project
scope, mission and charter. You can submit the motion to the Board using the
[EMAIL PROTECTED] email address. Well-prepared projects will have already
developed contacts with members of the Board so this should not be a surprise
agenda item. Keep in mind that the Board can approve your motion as supplied,
amend it, or reject it. If you are rejected then you need to sort this out
with the Incubator PMC and allies you have developed during the incubation
process - i.e. for a TLP objective the Incubator PMC OK is only half of the
story.
However, in practice, assuming you are building contacts with members in
Apache, the Incubator PMC, and the ASF Board - the transition from Podling to
TLP should be a smooth and painless process.
1.1
incubator/src/documentation/content/xdocs/incubation/Roles_and_Responsibilities.cwiki
Index: Roles_and_Responsibilities.cwiki
===================================================================
!!!Roles and Responsibilities
__This is currently a draft, and has no official status.__
This document describes the roles (including Sponsor, Contributor, Shepherd)
and provides an overview of the responsibilities of the different parties
involved in an incubation process.
!!Incubator Project Management Committee (PMC)
(From the resolution that created the Incubator Project - see
http://incubator.apache.org/resolution.html)
The Incubator PMC 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 Shepherd in discharging her/his duties;
* regularly evaluating projects under its purview for the purposes of
recommending to the Sponsoring Entity whether the project should:
** successfully exit 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 Shepherd 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 Shepherd needs additional
assistance, the Incubator PMC may choose to provide an experienced Shepherd to
assist the main Shepherd in discharging their duty.
!!Chair of the Incubator PMC
The person appointed by the Board of Directors to have primary responsibility
for oversight of the Incubator Project, its policies, and policy implementation.
!!Candidate
A Candidate is a project that is proposed for incubation. A Candidate shall
meet the following minimum criteria:
* affiliated with a named *Sponsor* (an ASF Member or Officer; see below)
Optionally, a candidate may:
* declare an affiliation with an existing Apache Project in which case it is
expected that the Sponsor is a member of the affiliated project, and the
project will become the *Sponsoring Entity*;
* 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 exit incubation
status.
A candidate project compliant with the above criteria may be proposed by the
Sponsor to the Sponsoring Entity for acceptance as a Podling. Acceptance of a
candidate shall be subject to the formal voting method of the Sponsoring
Entity. Should that vote be accepted, the Sponsoring Entity will request that
the Incubator PMC accept the candidate as a Podling under incubation. The
Sponsoring Entity shall assign a Shepard, who shall be granted membership of
the Incubator PMC for the duration of the incubation process.
!!Sponsor
A candidate project shall be sponsored by an [Officer
|http://www.apache.org/foundation/index.html] or [Member
|http://www.apache.org/foundation/members.html] of the Foundation. The Sponsor
assists the candidate on their initial submission to a Sponsoring Entity.
While private conversations are not generally encouraged within the Apache
community, the Sponsor'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.
Where the Sponsor is not a Member of the Foundation (i.e. is an Officer
only), the Sponsor shall be a member of the PMC of the Sponsoring Entity.
While the Sponsor has no formal responsibility within the Incubation process
(other than to review and comment on a Candidate's proposal within the
Sponsoring Entity), it is expected that they will play an active role. A lack
of interest on the part of a Sponsor may be seen by the Incubator PMC as a
negative indicator during the course of incubation.
!!Sponsoring Entity
The Sponsoring Entity 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 Sponsoring Entity will be one of:
* The Board of the Apache Software Foundation. In this case, it is expected
that the candidate would become a TLP on successful completion of Incubation.
* 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 board (and the
candidate will be a TLP) or another project.
Note that a Sponsoring Entity is more than just a final resting place for a
candidate that successfully completes incubation. The Sponsoring Entity, 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 Sponsoring Entity 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 Sponsoring Entity is expected to be actively involved, it
is formally representated by the Shepherd. The Shepherd is the individual
accountable to the Incubator PMC for ensuring the incubation process is
correctly followed. In cases where the Shepherd is not fulfilling their
responsibilities, the Sponsoring Entity (in particular its Chair) will be
expected to remedy the situation.
!Responsibilities of the Sponsoring Entity
* to provide initial approval for a Canidate to be accepted as a Podling
* to nominate a Shepherd for the incubation process
!!Shepherd
A Shepherd is a role undertaken by a permanent member of the Apache Software
Foundation and is chosen by the Sponsoring Entity to actively lead in the
discharge of their duties (listed above). Upon acceptance by the Incubator
PMC, the Shepherd automatically becomes a member of the Incubator PMC. A
Shepherd has specific responsibilities towards the Incubator PMC, the
Sponsoring Entity and towards the members of the assigned Podling.
!Responsibilities towards Podling Members
* to ensure that Incubator PMC decisions and/or issue are dealt with in a
timely manner and ensure that decisions or resolutions effecting 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 towards 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 Sponsoring Entity of the completion of
administrative actions; and
* to provide updates to the Incubator PMC and Sponsoring Entity on the status
of license grants (where and as appropriate) and other relevant legal
information pertaining to the Podling.
!Committers
The candidate shall declare an initial set of committers. On acceptance of a
candidate project, the assigned Shepherd shall be given access to the Podling's
cvs repository for the duration of the incubation process. This is to allow
the Shepherd 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 Shepherd must earn them as would any other
potential new committer. In some cases, the Shepherd may be part of the
initial set of declared committers, but this is not a requirement of the
Incubation process.
In association with its Shepherd and Sponsor, 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 Shepherd informed - he/she is 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 Sponsor 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
ASF 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
