incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nicola...@apache.org
Subject cvs commit: incubator/src/documentation/content/xdocs/incubation bylaws.xml forms.cwiki Incubation_Policy.cwiki process.xml Process_Description.cwiki Roles_and_Responsibilities.cwiki
Date Tue, 07 Oct 2003 15:53:29 GMT
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="general@incubator.apache.org" />
      </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="general@incubator.apache.org" />
      </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 pmc@{project-name}.apache.org or board@apache.org; 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 board@apache.org 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: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message