Author: nicolaken Date: Tue Dec 14 02:12:06 2004 New Revision: 111802 URL: http://svn.apache.org/viewcvs?view=rev&rev=111802 Log: The Incubation docs are in html now. Keeping the ascii art as .aart text; it gets rendered to png automatically by Forrest. Added: incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.html - copied, changed from r111794, incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.html - copied, changed from r111794, incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.html - copied, changed from r111794, incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki Removed: incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki
Deleted: /incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki Url: http://svn.apache.org/viewcvs/incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki?view=auto&rev=111801 ============================================================================== Copied: incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.html (from r111794, incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki) Url: http://svn.apache.org/viewcvs/incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.html?view=diff&rev=111802&p1=incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki&r1=111794&p2=incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.html&r2=111802 ============================================================================== --- incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.cwiki (original) +++ incubator/public/branches/move2html4forrest/site-author/incubation/Incubation_Policy.html Tue Dec 14 02:12:06 2004 @@ -1,314 +1,303 @@ -!!!Incubation Policy -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]. - -!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. - -[incubation-process.png] - -!!!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 Champion"); and -* be approved by a Sponsor. - -Approval by a Sponsor 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 Sponsor 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 Sponsor. The Proposal SHOULD, at minimum, detail the following areas : - -__Need to provide a short list__ - -!!Acceptance of Proposal by Sponsor -The decision to accept a project MUST be taken on a vote by the Sponsor, in accordance with that Entity's charter. - -Upon a successful result, the Sponsor 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 Mentors, nominated by the Sponsor, who will guide the Candidate through the Incubation Process. At least one 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 Mentors MAY be immediately accepted by the Incubator PMC. However the Incubator PMC MAY also suggest replacement Mentors. The Incubator PMC has the final choice of Mentors. - -!!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 sponsor>. 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. - -Podlings websites SHOULD contain the Apache Incubator Project logo as sign of affiliation. - -!!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 - -The Podling is not yet an Apache project, and it should thus always refer to the Incubator Project Resource usage Guidelines, that are as follows. - -! Website - -* every project site sources stay in the project CVS - -* every project has this URL space where to publish the site: -{{{ http://incubator.apache.org/projectname/ -}}} -* every project has an incubation status file under -{{{ http://incubator.apache.org/projects/projectname.html -}}} -* every project has eventual extra incubation docs under: -{{{ http://incubator.apache.org/projects/projectname/** -}}} -* The website is live in directory on www.apache.org: -{{{ /www/incubator.apache.org/projectname -}}} - -To create the website, the directory {{/www/incubator.apache.org/projectname}} is checked out of CVS. We don't care how it gets into CVS, or which CVS module it lives in, but it had better be there. - -People using Maven, ForrestBot, or any other tool still have to address the CVS publishing requirement that the infrastructure team has laid out. If that is done, then we just run "cvs update" in that directory to load the site from CVS. - -The Mentors MUST add the information to the project incubation status file, to -descibe the CVS module and the directory which holds the published site. - -If the project does not want to host the published site in their project CVS, it has a space under: -{{{ incubator-site/build/site/projectname/** -}}} - -The site is automatically updated from CVS once a day. - -!!!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 Sponsor, 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 -** The project is not highly dependent on any single contributor (there's at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project) -** 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 Sponsor. 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 Sponsor 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. - -!!Champion - -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. - -!!Sponsor - -The Sponsor is the entity within the ASF that makes the determination that a candidate would make a worthy addition to the ASF, and agrees to take on the candidate in question (or in the case of the Incubator PMC, assist it in finding a home) should it complete the incubation process. - -A Sponsor will be one of: - -* 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 Sponsor 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 Sponsor 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. - - +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";> +<html> +<head> +<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> Incubation Policy</title> +<link href="http://purl.org/DC/elements/1.0/"; rel="schema.DC"> +</head> +<body> +<h1>Incubation Policy +</h1> +<p>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). </p> +<p>The Incubator was tasked with the following responsibilities (reference Board Resolution): </p> +<ul> +<li>the acceptance and oversight of new products submitted or proposed to become part of the Foundation; </li> +<li>providing guidance and ensuring that subprojects under its purview develop products according to the Foundation's philosophy and guidelines for collaborative development; and </li> +<li>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. </li> +</ul> +<h2>About this Document +</h2> +<p>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. </p> +<p>It contains the minimum requirements that all new products and projects must meet before they will be fully accepted into the Apache Software Foundation. </p> +<p>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 <a class="external" href="http://www.ietf.org/rfc/rfc2119.txt";>RFC 2119</a>. </p> +<h3>Scope +</h3> +<p>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. </p> +<p>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. </p> +<h3>Relationship to Other Documents +</h3> +<p>This document is the normative set of requirements for Incubation. Where other documents are in conflict, this document should be taken as correct. </p> +<h2>Changing this Document +</h2> +<p>The contents of this document are formally approved by the Incubator PMC. All changes must be authorised by the Incubator PMC. </p> +<h2>Objectives of the Process +</h2> +<p>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 : </p> +<ul> +<li>new projects and sub-projects are developing products according to the ASF's philophy and guidelines for collaborative development; </li> +<li>the ownership of any code initially submitted by the project is formally and legaly transferred to the ASF; and </li> +<li>only those products that meet the Apache's requirements are fully accepted into the ASF. </li> +</ul> +<h2>Overview of the Process +</h2> +<p>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. </p> +<p> +<img alt="incubation-process.png" src="incubation-process.png"></p> +<h1>Entry to Incubation +</h1> +<p>Entry to Incubation requires a number of hurdles be passed. </p> +<h2>Proposal +</h2> +<p>In order to enter the Incubator, a Candidate MUST </p> +<ul> +<li>be nominated for incubation by a member of the Apache Software Foundation ("The Champion"); and </li> +<li>be approved by a Sponsor. </li> +</ul> +<p>Approval by a Sponsor 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 Sponsor may be one of: </p> +<ul> +<li>the Board of the Apache Software Foundation; </li> +<li>a Top Level Project (TLP) within the Apache Software Foundation (where the TLP considers the Candidate to be a suitable sub-project); or </li> +<li>the Incubator PMC. </li> +</ul> +<p>To start this process, a Candidate SHOULD submit a proposal to a Sponsor. The Proposal SHOULD, at minimum, detail the following areas : </p> +<p> +<strong>Need to provide a short list</strong> +</p> +<h2>Acceptance of Proposal by Sponsor +</h2> +<p>The decision to accept a project MUST be taken on a vote by the Sponsor, in accordance with that Entity's charter. </p> +<p>Upon a successful result, the Sponsor SHOULD request the Incubator PMC take on the Candidate as a new Podling. The request to the Incubator PMC MUST contain the following information : </p> +<ul> +<li>a reference to the results of the vote (so as to provide an audit trail for the records); </li> +<li>a reference to the Candidate's proposal; </li> +<li>the Mentors, nominated by the Sponsor, who will guide the Candidate through the Incubation Process. At least one nominated Mentor MUST be a member of the Apache Software Foundation. </li> +</ul> +<p>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. </p> +<p>The nominated Mentors MAY be immediately accepted by the Incubator PMC. However the Incubator PMC MAY also suggest replacement Mentors. The Incubator PMC has the final choice of Mentors. </p> +<h2>Creation of Podling +</h2> +<p>Upon acceptance by the Incubator PMC, the Candidate becomes a Podling under the care of the Incubator PMC. </p> +<p>Upon acceptance by the Incubator PMC, the Podling's Mentor becomes a member of the Incubator PMC (should they not already be one). </p> +<h1>Incubation Activities +</h1> +<p>The following sections detail the minimum activities that must be undertaken by the various parties during an Incuabation process. </p> +<h2>Setting Up a New Podling +</h2> +<p>Once the Podling and Mentor have been accepted by the Incubator PMC, the following activities SHOULD take place : </p> +<ul> +<li>creation of lists; </li> +<li>creation of cvs; </li> +</ul> +<ul> +<li>Incubator PMC mandating a helper Mentor </li> +</ul> +<h2>Ongoing Activities +</h2> +<p>The progress of a Podling SHALL be tracked in a STATUS file. The STATUS file SHALL be stored in the <em>incubator</em> module in the ASF CVS repository. </p> +<p>The STATUS file SHALL include the following minimum content : </p> +<ul> +<li>status of setup tasks; </li> +<li>all exit criteria (see section <em>Exitting the Incubator</em> below); </li> +<li>status of Podling against exit criteria. </li> +</ul> +<p>The Mentor MUST ensure that the STATUS file is up to date at all times. </p> +<h2>Review of Activity</h2> +<p>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. </p> +<p>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. </p> +<p>After each review, the Incubator PMC SHALL produce an Assessment of the project. The Assessment SHALL contain one of three recommendations : </p> +<ul> +<li>that the Podling be Terminated; </li> +<li>that the Podling continue in Incubation; or </li> +<li>that the Podling be escalated out of the Incubator. </li> +</ul> +<p>Termination and Escalation are discussed in more detail in section "Exitting the Incubator". </p> +<h2>Disputing an Assessment +</h2> +<p>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. </p> +<p>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. </p> +<p>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 </p> +<ul> +<li>the original assessment; </li> +<li>the request for review to the Incubator PMC; </li> +<li>the response from the Incubator PMC; and </li> +<li>the reason the Podling and/or Mentor still dispute the report. </li> +</ul> +<p>The Board of the Apache Software Foundation MAY, after reviewing the appeal, choose to </p> +<ul> +<li>ammend the incubation Assessment; </li> +<li>validate the assessment of the Incubator PMC; or </li> +<li>take any other action it deems appropriate to the circumstance. </li> +</ul> +<p>The decision of the Board of the Apache Software Foundation is final. </p> +<h2>Continuation +</h2> +<p>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. </p> +<p>The Mentor SHALL review the contents of the continuation recommendation and ensure that the development recommendations are carried out over the following review period. </p> +<h1>Podling Constraints +</h1> +<p>While in Incubation, Podlings are constrained in the actions they can undertake. </p> +<h2>Branding +</h2> +<p>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. </p> +<p>Podlings SHOULD use the following text for all disclaimers : </p> +<p> +<em><project name> is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the <name of sponsor>. 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.</em> +</p> +<p>Podlings wishing to use a different disclaimer message MUST have the disclaimer approved by the Incubator PMC prior to use. </p> +<p>Podlings websites SHOULD contain the Apache Incubator Project logo as sign of affiliation. </p> +<h2>Releases +</h2> +<p>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. </p> +<p>However, as software releases are an important part of any software project, they are permitted in certain circumstances, as follows. </p> +<p>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. </p> +<p>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. </p> +<p>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 : </p> +<ul> +<li>the release archive MUST contain the word "incubating" in the filename; and </li> +<li>the release archive MUST contain an Incubation disclaimer (as described in the previous section), clearly visible in the main documentation or README file. </li> +</ul> +<h2>Use of Apache Resources</h2> +<p>The Podling is not yet an Apache project, and it should thus always refer to the Incubator Project Resource usage Guidelines, that are as follows. </p> +<h3>Website</h3> +<ul> +<li>every project site sources stay in the project CVS </li> +</ul> +<ul> +<li>every project has this URL space where to publish the site: </li> +</ul> +<pre class="code"> http://incubator.apache.org/projectname/ +</pre> +<ul> +<li>every project has an incubation status file under </li> +</ul> +<pre class="code"> http://incubator.apache.org/projects/projectname.html +</pre> +<ul> +<li>every project has eventual extra incubation docs under: </li> +</ul> +<pre class="code"> http://incubator.apache.org/projects/projectname/** +</pre> +<ul> +<li>The website is live in directory on www.apache.org: </li> +</ul> +<pre class="code"> /www/incubator.apache.org/projectname +</pre> +<p>To create the website, the directory <span class="codefrag">/www/incubator.apache.org/projectname</span> is checked out of CVS. We don't care how it gets into CVS, or which CVS module it lives in, but it had better be there. </p> +<p>People using Maven, ForrestBot, or any other tool still have to address the CVS publishing requirement that the infrastructure team has laid out. If that is done, then we just run "cvs update" in that directory to load the site from CVS. </p> +<p>The Mentors MUST add the information to the project incubation status file, to descibe the CVS module and the directory which holds the published site. </p> +<p>If the project does not want to host the published site in their project CVS, it has a space under: </p> +<pre class="code"> incubator-site/build/site/projectname/** +</pre> +<p>The site is automatically updated from CVS once a day. </p> +<h1>Exitting the Incubator</h1> +<p>This section describes the requirements and process for exitting the Incubator. </p> +<h2>Minimum Exit Requirements</h2> +<p>Prior to escalation to the ASF, a Podling needs to show that : </p> +<ul> +<li>it is a worthy and healthy project; </li> +<li>it truly fits within the ASF framework;and </li> +<li>it "gets" the Apache Way. </li> +</ul> +<p>This is achieved by imposing a set of Exit Criteria that, when met, will demonstrate these objectives. </p> +<p>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 Sponsor, however only the Incubator PMC is authorised to formally place such requirements on a Podling. </p> +<p>The minimum requirements that a Podling SHALL meet prior to being successfully escalated to the ASF are : </p> +<ul> +<li> +<strong>Legal</strong> +</li> +<ul> +<li>All code ASL'ed </li> +<li>No non ASL or ASL compatbile dependencies in the code base </li> +<li>License grant complate </li> +<li>CLAs on file. </li> +<li>Check of project name for trademark issues </li> +</ul> +</ul> +<ul> +<li> +<strong>Meritocracy / Community</strong> +</li> +<ul> +<li>Demonstrate an active and diverse development community </li> +<li>The project is not highly dependent on any single contributor (there's at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project) </li> +<li>The above implies that new committers are admitted according to ASF practices </li> +<li>ASF style voting has been adopted and is standard practice </li> +<li>Demonstrate ability to tolerate and resolve conflict within the community. </li> +<li>Release plans are developed and excuted in public by the community. </li> +<ul> +<li>(requriment on minimum number of such releases?) </li> +<li>Note: incubator projects are not permitted to issue an official Release. Test snapshots (however good the quality) and Release <em>plans</em> are OK. </li> +</ul> +<li>Engagement by the incubated community with the other ASF communities, particularly infrastructure@ (this reflects my personal bias that projects should pay an nfrastructure "tax"). </li> +<li>Incubator PMC has voted for graduation </li> +<li>Destination PMC, or ASF Board for a TLP, has voted for final acceptance </li> +</ul> +</ul> +<ul> +<li> +<strong>Alignment / Synergy</strong> +</li> +<ul> +<li>Use of other ASF subprojects </li> +<li>Develop synergistic relationship with other ASF subprojects </li> +</ul> +</ul> +<ul> +<li> +<strong>Infrastructure</strong> +</li> +<ul> +<li>CVS module has been created </li> +<li>Mailing list(s) have been created </li> +<li>Mailing lists are being archived </li> +<li>Bugzilla has been created </li> +<li>Project website has been created </li> +<li>Project ready to comply with ASF mirroring guidlines </li> +<li>Project is integrated with GUMP if appropriate </li> +<li>Releases are PGP signed by a member of the community </li> +<li>Developers tied into ASF PGP web of trust </li> +</ul> +</ul> +<h2>Termination of a Podling</h2> +<p>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 Sponsor. 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. </p> +<h2>Migration as a Top Level Project</h2> +<p>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. </p> +<h2>Migration as a sub-project</h2> +<p>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. </p> +<h1>Roles in the Incubation Process</h1> +<p>This section describes the roles involved in the Incubation process. </p> +<h2>Incubator Project Management Committee (PMC)</h2> +<p>(From the resolution that created the Incubator Project - see http://incubator.apache.org/resolution.html) </p> +<p>The Incubator PMC is responsible for : </p> +<ul> +<li>acceptance and oversight of candidate projects submitted or proposed to become part of the Foundation; </li> +<li>providing guidance and ensuring that sub-projects under it's purview develop products according to the Foundation's philosophy and guidelines for collaborative development; </li> +<li>providing a repository for the storage of incubation history and information; </li> +<li>assisting a Podling's Mentor in discharging her/his duties; </li> +<li>regularly evaluating projects under its purview for the purposes of recommending to the Sponsor whether the project should: </li> +<ul> +<li>successfully exit incubation; </li> +<li>continue to receive guidance and support within the Incubator; or </li> +<li>be terminated. </li> +</ul> +</ul> +<h2>Chair of the Incubator PMC</h2> +<p>The person appointed by the Board of Directors to have primary responsibility for oversight of the Incubator Project, its policies, and policy implementation. </p> +<h2>Candidate</h2> +<p>A project that is proposed for incubation. </p> +<h2>Champion</h2> +<p>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. </p> +<h2>Sponsor</h2> +<p>The Sponsor is the entity within the ASF that makes the determination that a candidate would make a worthy addition to the ASF, and agrees to take on the candidate in question (or in the case of the Incubator PMC, assist it in finding a home) should it complete the incubation process. </p> +<p>A Sponsor will be one of: </p> +<ul> +<li>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. </li> +<li>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. </li> +<li>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. </li> +</ul> +<h2>Mentor</h2> +<p>A Mentor is a role undertaken by a permanent member of the Apache Software Foundation and is chosen by the Sponsor 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 Sponsor and towards the members of the assigned Podling. </p> +<h2>Committers</h2> +<p>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. </p> +</body> +</html> Deleted: /incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki Url: http://svn.apache.org/viewcvs/incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki?view=auto&rev=111801 ============================================================================== Copied: incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.html (from r111794, incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki) Url: http://svn.apache.org/viewcvs/incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.html?view=diff&rev=111802&p1=incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki&r1=111794&p2=incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.html&r2=111802 ============================================================================== --- incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.cwiki (original) +++ incubator/public/branches/move2html4forrest/site-author/incubation/Process_Description.html Tue Dec 14 02:12:06 2004 @@ -1,58 +1,43 @@ -!!!The Process of Incubation - -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. - -[incubation-process.png] - -Readers should also review the [Roles and Responsibilities |site:incubation/rolesandersponsibilities] 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 __Champion __ 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, Champions must either be ASF [members |ext:apache/foundation/members] or [officers |ext:apache/foundation/officers] (see the Champion section later in this document for more on Champion criteria and responsibilities). Once you have found an eligible person who is willing to act as Champion, you can use this person to help you determine if and how your proposal can complement the ASF. If you and your Champion are convinced that your candidate project would fit with the "Apache Way", your Champion 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 __Champion__. - -A __Candidate __ project description should be submitted to the relevant mailing list(s) of a __Sponsor __ (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 Champion 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 your proposal - however, if you feel that your candidate project is not being addressed, you may want to specifically request a decision on the Candidate by the Sponsor 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 Sponsor. 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 Sponsor is the ASF board) aligned with your project (preferably as your Champion) because you stand a better chance of getting feedback about what is actually happening. The Sponsor will typically take about 7-10 days before announcing a vote result. - -If that vote is affirmative, the Sponsor will propose to the __Incubator PMC __ (referencing the voting result e-mail) that your candidate project be escalated to __Podling __ status. The Sponsor will assign a __Mentor __. The Mentor may, or may not, be your original Champion. If not, it is expected your Champion will remain involved during the rest of the Incubation process, providing as much assistance as possible. - -The Mentor is there to protect you, but be warned - the Mentor is also holding a big stick. The Mentor is automatically made a member of the Incubator PMC, and reports to both the PMC and the Sponsor about your overall health and suitability for eventual inclusion within the Apache Community (or recommendation to terminate). However, the Mentor (with the assistance of the Champion) is also looking after you through the incubation. - -One of the roles of the Mentor 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 Mentor 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 Mentor is representing the Sponsor. - -Your Sponsor, represented by your Mentor, has specific responsibilities towards you and the Incubator PMC. There are a bunch of administrative and technical actions to take care of. Your Mentor is responsible for ensuring that these things happen quickly and efficiently. Also, your Mentor 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 Mentor 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 Sponsor) 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 Sponsor 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 Sponsor. 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 cite. Your Mentor 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 Mentor 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 your 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 Sponsor, 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. In other words, for a TLP objective the Incubator PMC okay 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. - +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";> +<html> +<head> +<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> Process Description</title> +<link href="http://purl.org/DC/elements/1.0/"; rel="schema.DC"> +</head> +<body> +<h1>The Process of Incubation</h1> +<p>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. </p> +<p> +<img alt="incubation-process.png" src="incubation-process.png"></p> +<p>Readers should also review the <a href="site:incubation/rolesandersponsibilities">Roles and Responsibilities </a>document for a description of the various parties involved in the Incubation process. </p> +<h2>Establishment</h2> +<p>The first thing you will want to do is find a <strong>Champion </strong> 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, Champions must either be ASF <a href="ext:apache/foundation/members">members </a>or <a href="ext:apache/foundation/officers">officers </a>(see the Champion section later in this document for more on Champion criteria and responsibilities). Once you have found an eligible person who is willing to act as Champion, you can use this person to help you determine if and how your proposal can complement the ASF. If you and your Champion are convinced that your candidate project would fit with the "Apache Way", your Champion can help you to get it established. </p> +<p>The establishment of a candidate involves the preparation of a project description (consistent with the candidate description detailed below) endorsed by a <strong>Champion</strong> . </p> +<p>A <strong>Candidate </strong> project description should be submitted to the relevant mailing list(s) of a <strong>Sponsor </strong> (see the Mailing Lists section in this document). See the <a class="external" href="http://jakarta.apache.org/site/newproject.html";>Jakarta Guidelines for New Projects </a>for a list of issues that should be addressed in your proposal; also see <a class="external" href="http://nagoya.apache.org/wiki/apachewiki.cgi?ASFProposalPages";>ASF Proposal Pages </a>for other examples. Typically a <strong>Candidate </strong> is submitted under a message tagged with [[PROPOSAL]. Such a message will normally trigger some discussions on the receiving mailing list(s). Your Champion will be involved in these discussions acting as your advocate. </p> +<p>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 your proposal - however, if you feel that your candidate project is not being addressed, you may want to specifically request a decision on the Candidate by the Sponsor 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. </p> +<h2>Acceptance</h2> +<p>The decision to accept a project is taken on a vote by the Sponsor. 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 Sponsor is the ASF board) aligned with your project (preferably as your Champion) because you stand a better chance of getting feedback about what is actually happening. The Sponsor will typically take about 7-10 days before announcing a vote result. </p> +<p>If that vote is affirmative, the Sponsor will propose to the <strong>Incubator PMC </strong> (referencing the voting result e-mail) that your candidate project be escalated to <strong>Podling </strong> status. The Sponsor will assign a <strong>Mentor </strong> . The Mentor may, or may not, be your original Champion. If not, it is expected your Champion will remain involved during the rest of the Incubation process, providing as much assistance as possible. </p> +<p>The Mentor is there to protect you, but be warned - the Mentor is also holding a big stick. The Mentor is automatically made a member of the Incubator PMC, and reports to both the PMC and the Sponsor about your overall health and suitability for eventual inclusion within the Apache Community (or recommendation to terminate). However, the Mentor (with the assistance of the Champion) is also looking after you through the incubation. </p> +<p>One of the roles of the Mentor 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 Mentor 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 Mentor is representing the Sponsor. </p> +<p>Your Sponsor, represented by your Mentor, has specific responsibilities towards you and the Incubator PMC. There are a bunch of administrative and technical actions to take care of. Your Mentor is responsible for ensuring that these things happen quickly and efficiently. Also, your Mentor 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. </p> +<h2>Review</h2> +<p>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 Mentor 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. </p> +<p>Conclusion of a review process will be a recommendation (to the Sponsor) of one of the following: </p> +<ul> +<li>termination; </li> +<li>continuation under incubation with recommendations; or </li> +<li>exit via escalation into Apache. </li> +</ul> +<p>Note that whilst this is a recommendation, it carries a lot of weight. A Sponsor 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. </p> +<h2>Termination</h2> +<p>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 Sponsor. 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. </p> +<h2>Continuation</h2> +<p>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 cite. Your Mentor 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 Mentor is doing a good job, neither of these scenarios should arise. </p> +<h2>Escalation</h2> +<p>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 your 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. </p> +<p>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 Sponsor, 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. In other words, for a TLP objective the Incubator PMC okay is only half of the story. </p> +<p>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. </p> +</body> +</html> Deleted: /incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki Url: http://svn.apache.org/viewcvs/incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki?view=auto&rev=111801 ============================================================================== Copied: incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.html (from r111794, incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki) Url: http://svn.apache.org/viewcvs/incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.html?view=diff&rev=111802&p1=incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki&r1=111794&p2=incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.html&r2=111802 ============================================================================== --- incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.cwiki (original) +++ incubator/public/branches/move2html4forrest/site-author/incubation/Roles_and_Responsibilities.html Tue Dec 14 02:12:06 2004 @@ -1,110 +1,95 @@ -!!!Roles and Responsibilities - -This document describes the roles (including Sponsor, Contributor, Mentor) and provides an overview of the responsibilities of the different parties involved in an incubation process. - -!!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 Sponsor 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 Mentor or a Podling during (or even after) the incubation process. In cases where an Incubation is particularly large, or where the Incubator PMC otherwise feels the Mentor needs additional assistance, the Incubator PMC may choose to provide an experienced Mentor to assist the main Mentor in discharging their duty. - -!!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 *Champion* (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 Champion is a member of the affiliated project, and the project will become the *Sponsor*; -* specify requirements that may be anticipated during incubation; and/or -* provide a summary of the project relationship/dependencies (existing or planned with existing Apache Projects/Products). - -Naturally, projects will need more than this in order to exit incubation status. - -A candidate project compliant with the above criteria may be proposed by the Champion to the Sponsor for acceptance as a Podling. Acceptance of a candidate shall be subject to the formal voting method of the Sponsor. Should that vote be accepted, the Sponsor will request that the Incubator PMC accept the candidate as a Podling under incubation. The Sponsor shall assign a Mentor, who shall be granted membership of the Incubator PMC for the duration of the incubation process. - -!!Champion - -A candidate project shall be sponsored by an [Officer |http://www.apache.org/foundation/index.html] or [Member |http://www.apache.org/foundation/members.html] of the Foundation. The Champion assists the candidate on their initial submission to a Sponsor. While private conversations are not generally encouraged within the Apache community, the Champion's relationship with the Candidate should allow for this in order to educate the Candidate about the Apache Way and prepare the project for the questions and issues likely to be raised by the community. - -Where the Champion is not a Member of the Foundation (i.e. is an Officer only), the Champion shall be a member of the PMC of the Sponsor. - -While the Champion has no formal responsibility within the Incubation process (other than to review and comment on a Candidate's proposal within the Sponsor), it is expected that they will play an active role. A lack of interest on the part of a Champion may be seen by the Incubator PMC as a negative indicator during the course of incubation. - -!!Sponsor - -The Sponsor is the entity within the ASF that makes the determination that a candidate would make a worthy addition to the ASF, and agrees to take on the candidate in question (or in the case of the Incubator PMC, assist it in finding a home) should it complete the incubation process. - -A Sponsor will be one of: - -* 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 Sponsor is more than just a final resting place for a candidate that successfully completes incubation. The Sponsor, by taking on a candidate, is indicating that they believe the candidate will make a worthy addition to the ASF, and takes responsibility for assisting the podling through the Incubation process. The Sponsor is therefore expected to be actively involved in the incubation process and assist where necessary, giving the podling the best possible chance of success. In addition, an entity that is a Top Level Project should be involved in the Candidate's incubation in order to educate the Candidate about practices that are specific to that TLP and about other relevant projects within the TLP. - -However, while the Sponsor is expected to be actively involved, it is formally representated by the Mentor. The Mentor is the individual accountable to the Incubator PMC for ensuring the incubation process is correctly followed. In cases where the Mentor is not fulfilling their responsibilities, the Sponsor (in particular its Chair) will be expected to remedy the situation. - -!Responsibilities of the Sponsor - -* to provide initial approval for a Canidate to be accepted as a Podling -* to nominate a Mentor for the incubation process - -!!Mentor - -A Mentor is a role undertaken by a permanent member of the Apache Software Foundation and is chosen by the Sponsor 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 Sponsor 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 Sponsor of the completion of administrative actions; and -* to provide updates to the Incubator PMC and Sponsor on the status of license grants (where and as appropriate) and other relevant legal information pertaining to the Podling. - -!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. - -In association with its Mentor and Champion, a Podling community is largely free to get on with the stuff they want to do (code, architecture, product, solutions, etc.) with minimal disruption related to the incubator process. - -However, you need to make sure of a number of things: - -* keep your Mentor 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 Champion is continuously in-the-loop and has the latest and greatest information about your project -* actively seek and recruit committers to your project - preferably linking you with existing Apache communities -* make sure your decision making process is visible and accountable - -These activities are not unique to projects in the Incubator. For example, existing Apache Projects have regular reports made by their PMC Chair to the 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. - +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";> +<html> +<head> +<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> Roles_and_ Responsibilities</title> +<link href="http://purl.org/DC/elements/1.0/"; rel="schema.DC"> +</head> +<body> +<h1>Roles and Responsibilities</h1> +<p>This document describes the roles (including Sponsor, Contributor, Mentor) and provides an overview of the responsibilities of the different parties involved in an incubation process. </p> +<h2>Incubator Project Management Committee (PMC)</h2> +<p>(From the resolution that created the Incubator Project - see http://incubator.apache.org/resolution.html) </p> +<p>The Incubator PMC is responsible for : </p> +<ul> +<li>acceptance and oversight of candidate projects submitted or proposed to become part of the Foundation; </li> +<li>providing guidance and ensuring that sub-projects under it's purview develop products according to the Foundation's philosophy and guidelines for collaborative development; </li> +<li>providing a repository for the storage of incubation history and information; </li> +<li>assisting a Podling's Mentor in discharging her/his duties; </li> +<li>regularly evaluating projects under its purview for the purposes of recommending to the Sponsor whether the project should: </li> +<ul> +<li>successfully exit incubation; </li> +<li>continue to receive guidance and support within the Incubator; or </li> +<li>be terminated. </li> +</ul> +</ul> +<p>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. </p> +<p>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. </p> +<p>Finally, the Incubator PMC is the ASF body with the greatest level of expertise and experience in the Incubation process. They provide a store of knowledge that can be called on by the Mentor or a Podling during (or even after) the incubation process. In cases where an Incubation is particularly large, or where the Incubator PMC otherwise feels the Mentor needs additional assistance, the Incubator PMC may choose to provide an experienced Mentor to assist the main Mentor in discharging their duty. </p> +<h2>Chair of the Incubator PMC</h2> +<p>The person appointed by the Board of Directors to have primary responsibility for oversight of the Incubator Project, its policies, and policy implementation. </p> +<h2>Candidate</h2> +<p>A Candidate is a project that is proposed for incubation. A Candidate shall meet the following minimum criteria: </p> +<ul> +<li>affiliated with a named *Champion* (an ASF Member or Officer; see below) </li> +</ul> +<p>Optionally, a candidate may: </p> +<ul> +<li>declare an affiliation with an existing Apache Project in which case it is expected that the Champion is a member of the affiliated project, and the project will become the *Sponsor*; </li> +<li>specify requirements that may be anticipated during incubation; and/or </li> +<li>provide a summary of the project relationship/dependencies (existing or planned with existing Apache Projects/Products). </li> +</ul> +<p>Naturally, projects will need more than this in order to exit incubation status. </p> +<p>A candidate project compliant with the above criteria may be proposed by the Champion to the Sponsor for acceptance as a Podling. Acceptance of a candidate shall be subject to the formal voting method of the Sponsor. Should that vote be accepted, the Sponsor will request that the Incubator PMC accept the candidate as a Podling under incubation. The Sponsor shall assign a Mentor, who shall be granted membership of the Incubator PMC for the duration of the incubation process. </p> +<h2>Champion</h2> +<p>A candidate project shall be sponsored by an <a href="ext:apache/foundation/officers">Officer </a>or <a href="ext:apache/foundation/members">Member </a>of the Foundation. The Champion assists the candidate on their initial submission to a Sponsor. While private conversations are not generally encouraged within the Apache community, the Champion's relationship with the Candidate should allow for this in order to educate the Candidate about the Apache Way and prepare the project for the questions and issues likely to be raised by the community. </p> +<p>Where the Champion is not a Member of the Foundation (i.e. is an Officer only), the Champion shall be a member of the PMC of the Sponsor. </p> +<p>While the Champion has no formal responsibility within the Incubation process (other than to review and comment on a Candidate's proposal within the Sponsor), it is expected that they will play an active role. A lack of interest on the part of a Champion may be seen by the Incubator PMC as a negative indicator during the course of incubation. </p> +<h2>Sponsor</h2> +<p>The Sponsor is the entity within the ASF that makes the determination that a candidate would make a worthy addition to the ASF, and agrees to take on the candidate in question (or in the case of the Incubator PMC, assist it in finding a home) should it complete the incubation process. </p> +<p>A Sponsor will be one of: </p> +<ul> +<li>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. </li> +<li>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. </li> +<li>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. </li> +</ul> +<p>Note that a Sponsor is more than just a final resting place for a candidate that successfully completes incubation. The Sponsor, by taking on a candidate, is indicating that they believe the candidate will make a worthy addition to the ASF, and takes responsibility for assisting the podling through the Incubation process. The Sponsor is therefore expected to be actively involved in the incubation process and assist where necessary, giving the podling the best possible chance of success. In addition, an entity that is a Top Level Project should be involved in the Candidate's incubation in order to educate the Candidate about practices that are specific to that TLP and about other relevant projects within the TLP. </p> +<p>However, while the Sponsor is expected to be actively involved, it is formally representated by the Mentor. The Mentor is the individual accountable to the Incubator PMC for ensuring the incubation process is correctly followed. In cases where the Mentor is not fulfilling their responsibilities, the Sponsor (in particular its Chair) will be expected to remedy the situation. </p> +<h3>Responsibilities of the Sponsor</h3> +<ul> +<li>to provide initial approval for a Canidate to be accepted as a Podling </li> +<li>to nominate a Mentor for the incubation process </li> +</ul> +<h2>Mentor</h2> +<p>A Mentor is a role undertaken by a permanent member of the Apache Software Foundation and is chosen by the Sponsor 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 Sponsor and towards the members of the assigned Podling. </p> +<h3>Responsibilities towards Podling Members</h3> +<ul> +<li>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; </li> +<li>to represent the interests of the Podling on the Incubator PMC; </li> +<li>to liaise between the ASF Secretary and the Podling on matters concerning CLA submission and acknowledgments; </li> +<li>to liaise between the ASF Infrastructure team and the Podling on matters concerning infrastructure support (mailing lists, CVS establishment, account establishment, etc.); </li> +<li>to assist the Podling on matters concerning the resolution of license transfers, copyright assignments, and/or software grants where applicable; and </li> +<li>to provide where and as appropriate, guidance on matters concerning Apache policies and practices - including the establishment of its internal steering committee. </li> +</ul> +<h3>Responsibilities towards the Incubator PMC</h3> +<ul> +<li>monitoring the Podling through the incubation process; </li> +<li>evaluating the compliance of the Podling with Incubator PMC policies and procedures; </li> +<li>assessment of the Podling status with respect to continuation/exit strategy; </li> +<li>to notify the Incubator PMC and Sponsor of the completion of administrative actions; and </li> +<li>to provide updates to the Incubator PMC and Sponsor on the status of license grants (where and as appropriate) and other relevant legal information pertaining to the Podling. </li> +</ul> +<h3>Committers</h3> +<p>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. </p> +<p>In association with its Mentor and Champion, a Podling community is largely free to get on with the stuff they want to do (code, architecture, product, solutions, etc.) with minimal disruption related to the incubator process. </p> +<p>However, you need to make sure of a number of things: </p> +<ul> +<li>keep your Mentor 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. </li> +<li>make sure your Champion is continuously in-the-loop and has the latest and greatest information about your project </li> +<li>actively seek and recruit committers to your project - preferably linking you with existing Apache communities </li> +<li>make sure your decision making process is visible and accountable </li> +</ul> +<p>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. </p> +<p>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. </p> +</body> +</html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
