| <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); $App = new App(); $Nav = new Nav(); $Menu = new Menu(); include($App->getProjectCommon()); # All on the same line to unclutter the user's desktop' |
| /* 221934 - this page to remain on eclipse.org */ |
| |
| $pageTitle = "Eclipse Development Process"; |
| |
| include( '../_commonLeftNav.php' ); |
| |
| $previous = "/projects/dev_process/development_process_2008.php"; |
| $next = "/projects/dev_process/development_process_2011.php"; |
| |
| $diff = "development_process_2010_diff.txt"; |
| |
| $commentary = isset($_GET['commentary']); |
| |
| ob_start(); |
| ?> |
| <style> |
| p { |
| margin-bottom:10px; |
| } |
| blockquote { |
| margin-left:2em; |
| margin-right:2em; |
| margin-bottom:10px; |
| } |
| .comment { |
| background-image:url(http://dev.eclipse.org/small_icons/apps/help-browser.png); |
| background-position: 5px 5px; |
| background-repeat:no-repeat; |
| display:<?= $commentary ? 'block' : 'none'?>; |
| float: right; |
| width:200px; |
| margin: 5px; |
| padding: 25px 2px 2px 2px; |
| border: 1px solid black; |
| background-color: #EEEEEE; |
| } |
| .comment p { |
| margin:3px; |
| } |
| .postit { |
| float: right; |
| width:150px; |
| margin: 5px; |
| padding: 2px; |
| border: 1px dashed black; |
| background-color: #FFFFDD; |
| } |
| #toc { |
| padding: 5px; |
| } |
| #toc ul { |
| list-style-type: none; |
| list-style-image: none; |
| margin-top: 1px; |
| margin-bottom: 1px; |
| padding-top: 1px; |
| padding-bottom: 1px; |
| text-align: left; |
| } |
| #toc li{ |
| margin-top: 1px; |
| margin-bottom: 1px; |
| padding-top: 0; |
| } |
| </style> |
| <div id="maincontent"> |
| <div id="midcolumn"> |
| |
| <h1>Eclipse Development Process</h1> |
| <div class="homeitem3col"> |
| <h2>Contents</h2> |
| <div id="toc"> |
| <ul> |
| <li><a href="#1_Purpose">1 Purpose</a></li> |
| <li><a href="#2_Principles">2 Principles</a> |
| <ul> |
| <li><a href="#2_1_Open_Source_Rules_of_Engagement">2.1 Open Source Rules of Engagement</a></li> |
| <li><a href="#2_2_Eclipse_Ecosystem">2.2 Eclipse Ecosystem</a></li> |
| <li><a href="#2_3_Three_Communities">2.3 Three Communities</a></li> |
| <li><a href="#2_4_Clear_Concise_and_Evolving">2.4 Clear, Concise, and Evolving</a></li> |
| </ul></li> |
| <li><a href="#3_Requirements">3 Requirements</a> |
| <ul> |
| <li><a href="#3_1_Requirements_and_Guidelines">3.1 Requirements and Guidelines</a></li> |
| </ul></li> |
| <li><a href="#4_Structure_and_Organization">4 Project Structure and Organization</a> |
| <ul> |
| <li><a href="#4_1_Committers">4.1 Committers</a></li> |
| <li><a href="#4_2_Code_and_Releases">4.2 Code and Releases</a></li> |
| <li><a href="#4_3_IP_Records">4.3 IP Records</a></li> |
| <li><a href="#4_4_Community_Awareness">4.4 Community Awareness</a></li> |
| <li><a href="#4_5_Scope">4.5 Scope</a></li> |
| <li><a href="#4_6_Leaders">4.6 Leaders</a> |
| <ul> |
| <li><a href="#4_6_1_PMC">4.6.1 Project Management Committee (PMC)</a></li> |
| <li><a href="#4_6_2_PL">4.6.2 Project Lead(s)</a></li> |
| </ul> |
| </li> |
| <li><a href="#4_7_Committers_and_Contributors">4.7 Committers and Contributors</a></li> |
| <li><a href="#4_8_Councils">4.8 Councils</a></li> |
| <li><a href="#4_9_Incubators">4.9 Incubator Projects</a></li> |
| </ul></li> |
| <li><a href="#5_Roadmap_Process">5 Roadmap Process</a></li> |
| <li><a href="#6_Development_Process">6 Development Process</a> |
| <ul> |
| <li><a href="#6_1_Mentors">6.1 Mentors</a></li> |
| <li><a href="#6_2_Project_Lifecycle">6.2 Project Lifecycle</a></li> |
| <li><a href="#6_2_1_Pre-Proposal">6.2.1 Pre-proposal</a></li> |
| <li><a href="#6_2_2_Proposal">6.2.2 Proposal</a></li> |
| <li><a href="#6_2_3_Incubation">6.2.3 Incubation</a></li> |
| <li><a href="#6_2_4_Mature">6.2.4 Mature</a></li> |
| <li><a href="#6_2_5_Top-Level">6.2.5 Top-Level</a></li> |
| <li><a href="#6_2_6_Archived">6.2.6 Archived </a></li> |
| <li><a href="#6_3_Reviews">6.3 Reviews</a> |
| <ul> |
| <li><a href="#6_3_1_Creation_Review">6.3.1 Creation Review</a></li> |
| <li><a href="#6_3_2_Graduation_Review">6.3.2 Graduation Review</a></li> |
| <li><a href="#6_3_3_Release_Review">6.3.3 Release Review</a></li> |
| <li><a href="#6_3_4_Promotion_Review">6.3.4 Promotion Review</a></li> |
| <li><a href="#6_3_5_Continuation_Review">6.3.5 Continuation Review</a></li> |
| <li><a href="#6_3_6_Termination_Review">6.3.6 Termination Review</a></li> |
| <li><a href="#6_3_7_Move_Review">6.3.7 Move Review</a></li> |
| <li><a href="#6_3_8_Restructuring_Review">6.3.8 Restructuring Review</a></li> |
| <li><a href="#6_3_9_Combining_Reviews">6.3.9 Combining Reviews</a></li> |
| </ul></li> |
| <li><a href="#6_4_Releases">6.4 Releases</a></li> |
| <li><a href="#6_5_Grievance_Handling">6.5 Grievance Handling</a></li> |
| </ul></li> |
| <li><a href="#7_Precedence">7 Precedence</a></li> |
| <li><a href="#8_Revisions">8 Revisions</a> |
| <ul> |
| <li><a href="#8_1_Revision">8.1 Revision 2.4</a></li> |
| </ul></li> |
| </ul> |
| </div> |
| </div> |
| |
| <h2><a name="1_Purpose"></a>1. Purpose</h2> |
| <p>This document describes the Development Process for the Eclipse Foundation. In |
| particular, it describes how the Membership at Large, the Board of Directors, other |
| constituents of the Ecosystem, and the Eclipse Management Organization (EMO) lead, |
| influence, and collaborate with Eclipse Projects to achieve these Eclipse purposes:</p> |
| |
| <blockquote><em>The Eclipse technology is a vendor-neutral, open development platform supplying |
| frameworks and exemplary, extensible tools (the 'Eclipse Platform'). Eclipse Platform tools |
| are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the |
| appropriate use of those frameworks, and support the development and maintenance of |
| the Eclipse Platform itself; Eclipse Platform tools are extensible in that their |
| functionality is accessible via documented programmatic interfaces. The purpose |
| of Eclipse Foundation Inc., is to advance the creation, |
| evolution, promotion, and support of the Eclipse Platform and to cultivate both an |
| open source community and an ecosystem of complementary products, capabilities, and services.</em></blockquote> |
| |
| <div class="postit"><p>Explanatory comments, guidelines, |
| and checklists - as well as additional requirements added by the EMO per <a href="#3_Requirements">section 3</a> - are noted |
| in yellow boxes.</p></div> |
| |
| <p>This document has five sections:</p> |
| <ul> |
| <li><a href="#2_Principles"><em>Principles</em></a> outlines the basic principles upon which the development process is based.</li> |
| <li><a href="#3_Requirements"><em>Requirements</em></a> describes the requirements that the Eclipse community has for its development process.</li> |
| <li><a href="#4_Structure_and_Organization"><em>Structure and Organization</em></a> specifies the structure and organization of the projects and project community at Eclipse.</li> |
| <li><a href="#5_Roadmap_Process"><em>Roadmap Process</em></a> describes the manner by which the EMO will work with the projects to create the annual Eclipse Roadmap.</li> |
| <li><a href="#6_Development_Process"><em>Development Process</em></a> outlines the lifecycle and processes required of all Eclipse projects.</li> |
| </ul> |
| |
| <h2><a name="2_Principles"></a>2. Principles</h2> |
| <p>The following describes the guiding principles used in developing this Development Process.</p> |
| |
| <h3><a name="2_1_Open_Source_Rules_of_Engagement"></a>2.1 Open Source Rules of Engagement</h3> |
| <ul> |
| <li> <b>Open</b> - Eclipse is open to all; Eclipse provides the same opportunity |
| to all. Everyone participates with the same rules; there are no rules to exclude |
| any potential contributors which include, of course, direct competitors in the marketplace.</li> |
| <li> <b>Transparent</b> - Project discussions, minutes, deliberations, project plans, |
| plans for new features, and other artifacts are open, public, and easily accessible.</li> |
| <li> <b>Meritocracy</b> - Eclipse is a meritocracy. The more you contribute the more |
| responsibility you will earn. Leadership roles in Eclipse are also merit-based and |
| earned by peer acclaim.</li> |
| </ul> |
| |
| <h3><a name="2_2_Eclipse_Ecosystem"></a>2.2 Eclipse Ecosystem</h3> |
| <p>Eclipse as a brand is the sum of its parts (all of the Projects), and Projects |
| should strive for the highest possible quality in extensible frameworks, |
| exemplary tools, transparent processes, and project openness.</p> |
| <p> |
| The Eclipse Foundation has the responsibility |
| to <em>...cultivate...an ecosystem of complementary products, capabilities, and services...</em>. |
| It is therefore a key |
| principle that the Eclipse Development Process ensures that the projects are managed for the |
| benefit of both the open source community and the ecosystem members. |
| To this end, all Eclipse projects are required to:</p> |
| <ul> |
| <li> communicate their project plans and plans for new features (major and minor) in a timely, open and transparent manner;</li> |
| <li> create platform quality frameworks capable of supporting the building of commercial grade products on top of them;</li> |
| <li> ship extensible, exemplary tools which help enable a broad community of users; and</li> |
| <li> participate in the annual Roadmap process to ensure maximum transparency and bi-directional communication with the ecosystem.</li> |
| </ul> |
| |
| <h3><a name="2_3_Three_Communities"></a>2.3 Three Communities</h3> |
| <p>Essential to the Purposes of the Eclipse Foundation is the development of three |
| inter-related communities around each Project:</p> |
| <ul> |
| <li> <b>Contributors</b> and <b>Committers</b> - a thriving, diverse and active community |
| of developers is the key component of any Eclipse Project. Ideally, this |
| community should be an open, transparent, inclusive, and diverse community |
| of Committers and (non-Committer) Contributors. Attracting new Contributors and |
| Committers to an open source project is time consuming and requires active |
| recruiting, not just passive "openness". The Project Leadership must make reasonable |
| efforts to encourage and nurture promising new Contributors. |
| <ul> |
| <li> Projects must have diversity goals to ensure diversity of thought and avoid |
| relying on any one company or organization. At the same time, we acknowledge |
| that enforcing a particular diversity metric is a poor way to achieve these goals; |
| rather we expect the project leadership to help the diversity evolve organically.</li> |
| <li> Diversity is a means to an end, not an end in itself, thus diversity goals |
| will differ by project based on the other accomplishments of the project(s).</li> |
| <li> Projects are required to explain their diversity efforts and accomplishments during Reviews.</li> |
| </ul></li> |
| <li> <b>Users</b> - an active and engaged user community is proof-positive that |
| the Project's exemplary tools are useful and needed. Furthermore, a large |
| user community is one of the key factors in creating a viable |
| ecosystem around an Eclipse project, thus encouraging additional open source and |
| commercial organizations to participate. Like all good things, a user community |
| takes time and effort to bring to fruition, but once established is |
| typically self-sustaining.</li> |
| <li> <b>Adopters</b> - an active and engaged adopter/plug-in developer community |
| is the |
| only way to prove that an Eclipse project is providing extensible frameworks |
| and extensible tools accessible via documented APIs. Reuse of the frameworks |
| within the companies that are contributing to the project is necessary, but |
| not sufficient to demonstrate an adopter community. Again, creating, encouraging, |
| and nurturing an adopter community outside of the Project's developers takes time, |
| energy, and creativity by the Project Leadership, but is essential |
| to the Project's long-term open source success.</li> |
| </ul> |
| <p>The Eclipse community considers the absence of any one or more of these |
| communities as proof that the Project is not sufficiently open, transparent, |
| and inviting, and/or that it has emphasized tools at the expense of |
| extensible frameworks or vice versa.</p> |
| |
| <h3><a name="2_4_Clear_Concise_and_Evolving"></a>2.4 Clear, Concise, and Evolving</h3> |
| <p>It is an explicit goal of the Development Process to be as clear and concise |
| as possible so as to help the Project teams navigate the complexities, |
| avoid the pitfalls, and become successful as quickly as possible.</p> |
| <p> |
| This document imposes requirements and constraints on the operation of the |
| Projects, and it does so on behalf of the larger Eclipse community. It is |
| an explicit goal of the Development Process to provide as much freedom |
| and autonomy to the Projects as possible while ensuring the collective |
| qualities benefit the entire Eclipse community.</p> |
| <p> |
| Similarly, this document should not place undue constraints on the EMO or the Board |
| that prevent them from governing the process as necessary. We cannot foresee all |
| circumstances and as such should be cautious of being overly prescriptive and/or |
| requiring certain fixed metrics.</p> |
| <p> |
| The frameworks, tools, projects, processes, community, and even the |
| definition of Quality continues to, and will continue to, evolve. Creating rules |
| or processes that force a static snapshot of any of these is detrimental to the |
| health, growth, and ecosystem impact of Eclipse.</p> |
| <p> |
| Part of the strength of this document is in what it does not say, and |
| thus opens for community definition through convention, guidelines, and public consultation. |
| A document with too much structure becomes too rigid and prevents the kind of |
| innovation and change we desire for Eclipse. In areas where this document is |
| vague, we expect the Projects and Members to engage the community-at-large |
| to clarify the current norms and expectations.</p> |
| |
| <h2><a name="3_Requirements"></a>3. Requirements</h2> |
| <p>This document and any additional criteria as established by the EMO contains requirements, recommendations, and suggestions.</p> |
| <p> |
| <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#FF9999; |
| border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; |
| padding-left:2px; padding-right:2px; font-family:times; ">R</span><b>Required</b> - Certain responsibilities and behaviors |
| are required of participants in Eclipse open source projects. Projects that fail to |
| perform the required behaviors will be terminated by the EMO. In keeping with the |
| Guiding Principles, the number of requirements must be kept to an absolute minimum.</p> |
| <p> |
| <span style="margin-right:6px; margin-top:5px; float:left; color:ivory; background:#00CC99; |
| border:1px solid #444; font-size:30px; line-height:25px; padding-top:2px; padding-left:2px; |
| padding-right:2px; font-family:times; ">G</span><b>Guideline</b> - Other responsibilities |
| and behaviors are recommended best practices. Collectively, we have learned that Projects |
| are more likely to be successful if the team members and leaders follow these recommendations. |
| Projects are strongly encouraged to follow these recommendations, but will not be penalized by |
| this Process if they do not.</p> |
| |
| <h3><a name="3_1_Requirements_and_Guidelines"></a>3.1 Requirements and Guidelines</h3> |
| <p>This document is entirely composed of requirements. In addition to the requirements specified |
| in this Development Process, the EMO is instructed to clarify, expand, and extend this Process |
| by creating a set of Eclipse Project Development Guidelines to advance the creation, evolution, |
| promotion, and support of the Eclipse Platform and to cultivate both an open source community |
| and an ecosystem of complementary products and services. </p> |
| <p> |
| The EMO is not permitted to override or ignore the requirements listed in this document |
| without the express written endorsement of the Board of Directors.</p> |
| |
| <h2><a name="4_Structure_and_Organization"></a>4. Project Structure and Organization</h2> |
| <div class="comment"> |
| <p>This version of the document adds the word "Project" to the title |
| of this section to better qualify that it discusses the structure and organization |
| of projects. The <a href="<?= $previous ?>#4_Structure_and_Organization">previous version</a> of this |
| document defined notions of "Operating" and |
| "Container" Projects. These notions have been abandoned |
| in favour of a more generalized notion of Project. Under this new |
| structure, projects can opt to function as Operating Projects by |
| choosing not to maintain a code repository.</p> |
| <p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=301065">Bug 301065</a>.</p></div> |
| |
| <p>A <b>Project</b> is the main operational unit at Eclipse. Specifically, all open source |
| software development at Eclipse occurs within the context of a Project. Projects have leaders, developers, |
| code, builds, downloads, websites, and more. Projects are more than just the sum of their many parts, |
| they are the means by which open source work is organized when presented to the communities of |
| developers, adopters, and users. Projects provide structure that helps developers expose their |
| hard work to a broad audience of consumers.</p> |
| |
| <p>Eclipse Projects are organized hierarchically. A special type of Project, <b>Top-Level Projects</b>, |
| sit at the top of the hierarchy. Each Top-Level Project contains one or more Projects. |
| Each Project may itself contain zero or more Projects. A project that has one or more Projects |
| is said to be the "parent" of those Projects. A Project that has a parent is oftentimes |
| referred to as a <b>Sub-Project</b>. The term Project refers to either a Top-Level Project or a Sub-Project. |
| Projects may be referred to as Sub-Projects or Components, but the choice of common |
| name does not change the characteristics of the Project.</p> |
| |
| <p> |
| The <b>descendants</b> of a Project are the Project itself and transitive closure of its child Projects. |
| The <b>top parent</b> of a Project is the Top-Level Project at the top of the hierarchy.</p> |
| <p> |
| Projects are the unit entity for:</p> |
| <ul> |
| <li>Committers</li> |
| <li>Code and Releases</li> |
| <li>IP Records</li> |
| <li>Community Awareness</li> |
| </ul> |
| <p> |
| As defined by the <a href="/org/documents/eclipse_foundation-bylaws.pdf#page=19">Eclipse Bylaws - Article VII</a>, |
| the <b>Eclipse Management Organization (EMO)</b> consists of the Foundation staff and the Councils. The |
| term <b>EMO(ED)</b>, when discussing an approval process, refers to the subset of the EMO |
| consisting of the Executive Director and whomever he or she may delegate that specific approval authority to.</p> |
| |
| <h3><a name="4_1_Committers"></a>4.1 Committers</h3> |
| <div class="comment"> |
| <p>The <a href="<?= $previous ?>#4_1_Committers">previous version</a> of this |
| document introduced a notion of a "union" of committers that was never fully |
| defined or utilized. That notion has been removed.</p> |
| <p>We attempt to make it clear that each project has exactly one set of committers. This |
| has been driven by the negative experiences of the past in attempting to manage multiple |
| committer groups in a single project. We further attempt to make it clear that there is |
| no roll-up of committers; a committer in a sub-project is not automatically a committer |
| in a parent project.</p></div> |
| |
| <p>Each project has exactly one set of committers. Each Project's set of Committers is |
| distinct from that of any other Project, including Sub-Projects or parent Projects. |
| All Project Committers have equal rights and responsibilities within the Project. |
| Partitioning of responsibility within a Project is managed using social convention. |
| A Project may, for example, divide itself into logical partitions of functionality; it |
| is social convention that prevents Committers from one logical partition from doing |
| inappropriate work in another. If finer-grained management of committer responsibilities |
| is required, a project should consider partitioning |
| (via a <a href="#6_3_8_Restructuring_Review">Restructuring Review</a>) into |
| two or more Sub-Projects.</p> |
| |
| <p>The Committers of a project have the exclusive right to elect new Committers to |
| their Project–no other group, including a parent Project, can force a Project to accept a new Committer.</p> |
| |
| <p>There is no roll-up of committers: the set of committers on a project is exactly that set of |
| people who have been explicitly elected into that role for the project (i.e. being a committer |
| on a sub-project does not give you any automatic rights on the "parent" project). |
| </p> |
| |
| <p>In practical terms, each Project has a single Unix group of its Committers that provides write-access |
| to the Project's resources. Pictorially below, we see that a Project, in addition to the various resources |
| and Committers it has, can also have zero or more Sub-Projects. Each of these Sub-Projects has its own |
| distinct set of Committers and resources.</p> |
| |
| <img src="images/subprojects-resources-291x300.png"/> |
| |
| <h3><a name="4_2_Code_and_Releases"></a>4.2 Code and Releases</h3> |
| |
| <div class="comment"> |
| <p>The <a href="<?= $previous ?>#4_2_Code_and_Releases">previous version</a> of this |
| document restricted code ownership to the former notion of "Operating" projects. With |
| the generalization of projects, it is now possible for a project at any level in the hierarchy |
| to have (or not have) code.</p> |
| <p>This version of the document clarifies that a project in the incubation phase may |
| make pre-1.0 releases only.</p></div> |
| |
| <p>Each Project owns and maintains a collection of resources.</p> |
| |
| <p>Resources may include source code, a project website, space on the downloads server, |
| access to build resources, and other services provided by the Eclipse Foundation infrastructure. |
| The exact infrastructure provided by the Eclipse Foundation varies over time |
| and is defined outside this process document.</p> |
| |
| <p>A project is not strictly required to make use of all the resources made available; a project might, |
| for example, opt to <em>not</em> maintain a source code repository. Such a Project might operate as an |
| organizational unit, or container, for several Sub-Projects. Similarly, a Project might opt to |
| provide a consolidated website, build and/or download site for its Sub-Projects (the Sub-Projects would then |
| not require those resources for themselves).</p> |
| |
| <p>Each Project has a single Bugzilla component for its bugs. </p> |
| |
| <p> |
| Any Project in the Mature Phase may make a <b>Release</b>. |
| A Project in the Incubation Phase with two Mentors may make a pre-1.0 <b>Release</b>. |
| A Release may include the code from any subset of the Project's descendants. </p> |
| |
| <h3><a name="4_3_IP_Records"></a>4.3 IP Records</h3> |
| <p>A Project at any level may receive IP clearance for contributions and third-party libraries. |
| IP approval will often include the same approval for all descendant Projects. |
| However, IP clearance will only be granted at the most appropriate technical |
| level. </p> |
| |
| <h3><a name="4_4_Community_Awareness"></a>4.4 Community Awareness</h3> |
| <p>Projects are the level of communication with the larger Eclipse community and ecosystem. |
| Projects may either have their own communications (website, mailing lists, forums/newsgroups, etc) |
| or they may be part of a parent Project's communications (website, mailing list, forums/newsgroups, etc). |
| In either case, the Project is required to maintain an open and public communication channel with |
| the Eclipse community including, but not limited to, project plans, schedules, design discussions, and so on.</p> |
| <p> |
| All Projects must make the communication channels easy to find. Projects are further required to |
| make the separate communication channels of their child Projects (if any) easy to find.</p> |
| <p> |
| Any Project in the Incubation Phase must correctly identify its website and Releases. |
| A Project with at least one descendant Project in Incubation Phase must correctly annotate |
| its own website so as to notify the Eclipse community that incubating Projects exist in its hierarchy. |
| Any Release containing code from an Incubation Phase project must be correctly labeled, |
| i.e., the Incubation Phase is viral and expands to cover all Releases in which it is included. </p> |
| |
| <h3><a name="4_5_Scope"></a>4.5 Scope</h3> |
| <p>Each Top-Level Project has a <b>Charter</b> which describes the purpose, <b>Scope</b>, |
| and operational rules for the Top-Level Project. The Charter should refer to, and describe |
| any refinements to, the provisions of this Development Process. The Board approves the |
| Charter of each Top-Level Project.</p> |
| <p> |
| Sub-Projects do not have separate Charters; Sub-Projects operate under the Charter of their parent Top-Level Project.</p> |
| <p> |
| All Projects have a defined <b>Scope</b> and all initiatives within that Project are |
| required to reside within that Scope. Initiatives and code that is found to be |
| outside the Scope of a Project may result in the termination of the Project. |
| The Scope of Top-Level Projects is part of the Charter, as approved by the Board |
| of Directors of the Eclipse Foundation. </p> |
| <p> |
| The Scope of a Sub-Project |
| is defined by the initial project proposal |
| as reviewed and approved by the <b>Project Management Committee (PMC)</b> (as further |
| defined below) of the Project's |
| Project's top parent |
| and by the EMO. A Project's Scope |
| must be a subset of |
| its parent's Scope.</p> |
| |
| <h3><a name="4_6_Leaders"></a>4.6 Leaders</h3> |
| <div class="comment"> |
| <p>The <a href="<?= $previous ?>#4_6_Leaders">previous version</a> of this |
| document used confusing language in an attempt to combine the discussion of |
| PMCs and Project Leads. This version separates these discussions in an attempt |
| to make more explicit the process of bringing leaders on board and |
| the role that the two different types of leaders play. Sections 4.6.1 and 4.6.2 |
| are new with this version of the document.</p> |
| <p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=300002">Bug 300002</a> |
| and <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=300006">Bug 300006</a>.</p></div> |
| |
| <p>There are two different types of Project leadership at Eclipse: The Project |
| Management Committee (PMC) and Project Leads. Both forms of leadership are required to:</p> |
| <ul> |
| <li>ensure that their Project is operating effectively by guiding the overall |
| direction and by removing obstacles, solving problems, and resolving conflicts;</li> |
| <li>operate using open source rules of engagement: meritocracy, transparency, |
| and open participation; and</li> |
| <li>ensure that the Project and its Sub-Projects (if any) conform to the |
| Eclipse Foundation IP Policy and Procedures.</li> |
| </ul> |
| |
| <p>The leadership for a Project is composed of the Project's Project Lead(s), |
| the leadership of the parent Project (if any) and the PMC Leads and PMC Members |
| for the Top-Level Project.</p> |
| |
| <h4><a name="4_6_1_PMC"></a>4.6.1 Project Management Committee (PMC)</h4> |
| |
| <p>Top-level projects are managed by a Project Management Committee (PMC). A PMC has |
| one or more PMC Leads and zero or more PMC Members. Together the PMC provides oversight |
| and overall leadership for the projects that fall under their top-level project. The PMC |
| as a whole, and the PMC Leads in particular, are ultimately responsible for ensuring |
| that the Eclipse Development Process is understood and followed by their projects. |
| The PMC is additionally responsible for maintaining the top-level project's charter.</p> |
| |
| <p>PMC Leads are approved by the Board; PMC members are elected by the existing PMC Leads |
| and Members, and approved by the EMO(ED).</p> |
| |
| <h4><a name="4_6_2_PL"></a>4.6.2 Project Lead</h4> |
| |
| <p>Eclipse Projects are managed by one or more Project Leads. Project Leads are responsible |
| for ensuring that their Project's Committers are following the Eclipse Development Process, |
| and that the project is engaging in the right sorts of activities to develop vibrant communities |
| of users, adopters, and contributors. The initial project leadership is appointed and approved |
| in the creation review. Subsequently, additional Project Leads must be elected by the |
| project's Committers and approved by the Project's PMC and the EMO(ED).</p> |
| |
| <p>In the unlikely event that a member of the Project leadership becomes disruptive to the |
| process or ceases to contribute for an extended period, the member may be removed by the |
| unanimous vote of the remaining Project Leads (if there are at least two other Project Leads), |
| or unanimous vote of the Project's PMC.</p> |
| |
| <p>In exceptional situations, such as projects with zero active committers or projects with |
| disruptive Committers and no effective Project Leads, the Project Leadership Chain has the |
| authority to make changes (add, remove) to the set of committers and/or Project Leads of that project.</p> |
| |
| <h3><a name="4_7_Committers_and_Contributors"></a>4.7 Committers and Contributors</h3> |
| <div class="comment"> |
| <p>The <a href="<?= $previous ?>#4_7_Committers_and_Contributors">previous version</a> |
| made specific references to the types of resources that a committer has write access |
| to (code, web, and Bugzilla). In this version, the discussion of the resources has |
| been generalized.</p></div> |
| |
| <p>Each Project has a <b>Development Team</b>, led by |
| the Project Leaders. |
| The Development Team is composed of |
| <b>Committers</b> and <b>Contributors</b>. <b>Contributors</b> are individuals who contribute code, |
| fixes, tests, documentation, or other work that is part of the Project. |
| <b>Committers</b> have write access to the Project's resources (source code repository, bug tracking system, |
| website, build server, downloads, etc.) |
| and are expected to influence the Project's development. </p> |
| |
| <div class="postit">See <a href="new-committer.php">guidelines and |
| checklists</a> for electing a new committer. |
| </div><p>Contributors who have the trust of the Project's Committers can, through election, |
| be promoted Committer for that Project. The breadth of a Committer's influence |
| corresponds to the breadth of their contribution. A Development Team's Contributors |
| and Committers may (and should) come from a diverse set of organizations. |
| A Committer gains voting rights allowing them to affect the |
| future of the Project. Becoming a Committer is a privilege that is earned by |
| contributing and showing discipline and good judgment. It is a responsibility |
| that should be neither given nor taken lightly, nor is it a right based on |
| employment by an Eclipse Member company or any company employing existing |
| committers.</p> |
| <p> |
| The election process begins with an existing Committer on the same Project |
| nominating the Contributor. The Project's Committers will vote for a period of no |
| less than one week of standard business days. |
| If there are at least three (3) positive votes and no negative votes within the |
| voting period, the Contributor is recommended to the project's PMC |
| for commit privileges. If there are three (3) or fewer Committers on the Project, |
| a unanimous positive vote of all Committers is substituted. |
| If the PMC approves, and the Contributor signs the appropriate Committer legal agreements |
| established by the EMO (wherein, at the very least, the Developer |
| agrees to abide by the Eclipse Intellectual Property Policy), the Contributor |
| becomes a Committer and is given write access to the source code for that Project.</p> |
| <p> |
| At times, Committers may become inactive for a variety of reasons. |
| The decision making process of the Project relies on active committers who respond |
| to discussions and vote in a constructive and timely manner. |
| The Project Leaders are responsible for ensuring the smooth operation of the Project. |
| A Committer who is disruptive, does not participate actively, or has been inactive |
| for an extended period may have his or her commit status revoked by the Project Leaders. |
| (Unless otherwise specified, "an extended period" is defined as "no activity for more than |
| six months".)</p> |
| <p> |
| Active participation in the user forums/newsgroups and the appropriate developer mailing lists |
| is a responsibility of all Committers, and is critical to the success of the Project. |
| Committers are required to monitor and contribute to the user forums/newsgroups.</p> |
| <p> |
| Committers are required to monitor the mailing lists associated with the Project. |
| This is a condition of being granted commit rights to the Project. |
| It is mandatory because committers must participate in votes (which in some cases |
| require a certain minimum number of votes) and must respond to the mailing list in |
| a timely fashion in order to facilitate the smooth operation of the Project. When a |
| Committer is granted commit rights they will be added to the appropriate mailing lists. |
| A Committer must not be unsubscribed from a developer mailing list unless their |
| associated commit privileges are also revoked.</p> |
| <p> |
| Committers are required to track, participate in, and vote on, relevant |
| discussions in their associated Projects and components. There are three |
| voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain).</p> |
| <p> |
| Committers are responsible for proactively reporting problems in the bug |
| tracking system, and annotating problem reports with status information, |
| explanations, clarifications, or requests for more information from the |
| submitter. Committers are responsible for updating problem reports when |
| they have done work related to the problem.</p> |
| <p> |
| Committer, PMC Lead, Project Lead, and Council Representative(s) are roles; |
| an individual may take on more than one of these roles simultaneously.</p> |
| |
| <h3><a name="4_8_Councils"></a>4.8 Councils</h3> |
| <p>The three Councils defined in Bylaws section VII are comprised of Strategic |
| members and PMC representatives. The three Councils help guide the Projects as follows:</p><ul> |
| <li>The <b>Requirements Council</b> is primarily responsible for the Eclipse Roadmap. There |
| will always be more requirements than there are resources to satisfy them, thus the |
| Requirements Council gathers, reviews, and categorizes all of these incoming |
| requirements - from the entire Eclipse ecosystem - and proposes a coherent |
| set of <b>Themes and Priorities</b>.</li> |
| <li>The <b>Planning Council</b> is responsible for establishing a coordinated |
| Simultaneous Release (a.k.a, "the release train") that supports the Themes |
| and Priorities in the Roadmap. The Planning Council is responsible for |
| cross-project planning, architectural issues, user interface conflicts, |
| and all other coordination and integration issues. The Planning Council |
| discharges its responsibility via collaborative evaluation, prioritization, |
| and compromise.</li> |
| <li><div class="postit">See <a href="architecture-council.php">guidelines and |
| checklists</a> for the Architecture Council. |
| </div>The <b>Architecture Council</b> is responsible for the development, |
| articulation, and maintenance of the Eclipse Platform Architecture and |
| ensuring the Principles of the Development Process through mentorship. |
| Membership in the Architecture Council is per the Bylaws through Strategic |
| Membership, PMCs, and by appointment. The Architecture Council will, at |
| least annually, recommend to the EMO(ED), Eclipse Members who have sufficient |
| experience, wisdom, and time to be appointed to the Architecture Council and |
| serve as Mentors. Election as a Mentor is a highly visible confirmation of |
| the Eclipse community's respect for the candidate's technical vision, good |
| judgement, software development skills, past and future contributions to |
| Eclipse. It is a role that should be neither given nor taken lightly. |
| Appointed members of the Architecture Council are appointed to |
| two |
| year renewable terms.</li> |
| </ul> |
| <h3><a name="4_9_Incubators"></a>4.9 Incubator Projects</h3> |
| <div class="comment"> |
| <p>This version of this document formalizes the notion of an "Incubator" |
| project. The original draft of this document attempted to restrict the number and |
| structure of incubators, but the language was removed to allow for future |
| flexibility. A project may have more than one incubator; an incubator project |
| may itself have an incubator sub-project. Creating multiple incubators is |
| expected to be atypical; attempts to create multiple incubators will be |
| challenged by the PMC and EMO.</p> |
| <p>An important requirement for an incubator is that there must be some set of |
| committers from the parent project who are also committers on the incubator. |
| Since incubators are never expected to graduate, they do not require mentors.</p> |
| </div> |
| |
| <p>A Project may designate a Sub-Project as an "Incubator". |
| An Incubator is a Project that is intended to perpetually remain in the |
| <a href="#6_2_3_Incubation">Incubation</a> phase. Incubators are an excellent place to |
| innovate, test new ideas, grow functionality that may one day be moved into another |
| Project, and develop new committers.</p> |
| |
| <p>Incubator Projects never have releases; they do not require yearly continuation reviews |
| and they are not part of the annual release train. Incubators may have builds, and downloads. |
| They conform to the standard incubation branding requirements and are subject to the IP due |
| diligence rules outlined for incubating Projects. Incubators do not graduate.</p> |
| |
| <p>The scope of an Incubator Project must fall within the scope of its parent project. |
| The committer group of the Incubator Project must overlap with that of the parent project |
| (at least one committer from the parent project must be a committer for the Incubator). |
| Incubator projects do not require Architecture Council mentors (the parent project's |
| committers are responsible for ensuring that the Incubator project conform to the rules |
| set forth by the Eclipse Development Process).</p> |
| |
| <p>An Incubator project should designated as such by including the word "Incubator" in |
| its name (e.g. "Eclipse Incubator"). To do otherwise is considered exceptional and |
| requires approval from the PMC and EMO(ED).</p> |
| |
| <p>Only Top-Level Projects and Projects in the <a href="#6_2_4_Mature">Mature phase</a> may create |
| an Incubator. Incubators are created via a <a href="#6_3_1_Creation_Review">Creation Review</a>. Alternatively, |
| an Incubator can be created as part of a <a href="#6_3_2_Graduation_Review">Graduation</a>, |
| <a href="#6_3_4_Promotion_Review">Promotion</a>, or <a href="#6_3_8_Restructuring_Review">Restructuring</a> |
| Review.</p> |
| |
| <h2><a name="5_Roadmap_Process"></a>5. Roadmap Process</h2> |
| <div class="comment"> |
| <p>This section has been modified to explicitly state that project may opt to |
| aggregate their plan with that of descendant projects.</p></div> |
| <p>The Roadmap describes the collective Eclipse Projects future directions and consists of two parts:</p><ol> |
| <li><b>Themes and Priorities</b> from the Requirements Council</li> |
| <li><b>Project Plans</b> from Projects</li> |
| </ol> |
| <p>The Roadmap must be consistent with the Purposes as described in Bylaws section 1.1. It is |
| developed using the prescribed <a href="/org/councils/roadmap_v2_0/index.php#process">roadmap process</a>. </p> |
| <p> |
| The Roadmap is prepared by the Councils and approved by the Board annually. A proposed Roadmap |
| or Roadmap update is disseminated to the Membership at Large for comment and feedback in advance |
| of its adoption. This dissemination and all discussion and debate around the Roadmap must be |
| held in an open and transparent public forum, such as mailing lists or newsgroups. </p> |
| <p> |
| Prior to any Board vote to approve a Roadmap or Roadmap update, every Member has the right to |
| communicate concerns and objections to the Board.</p> |
| <p> |
| The process of producing or updating the Roadmap is expected to be iterative. An initial |
| set of Themes and Priorities may be infeasible to implement in the desired timeframe; subsequent |
| consideration may reveal new implementation alternatives or critical requirements that alter |
| the team's perspective on priorities. The EMO orchestrates interaction among and within the |
| Councils to drive the Roadmap to convergence.</p> |
| <p> |
| This Development Process, the EMO, the Councils, and the Projects all acknowledge that the |
| success of the Eclipse ecosystem is dependent on a balanced set of requirements and |
| implementations. A Roadmap that provides too large a burden on the Projects will be |
| rejected and ignored; similarly, a Roadmap that provides no predictable Project plans |
| will be unhelpful to the business and technical plans being created by the ecosystem. |
| A careful balance of demands and commitments is essential to the ongoing success of the |
| Eclipse Projects, frameworks, and ecosystem.</p> |
| <p> |
| The Project Leadership is expected to ensure that their Project Plans are consistent |
| with the Roadmap, and that all plans, technical documents and reports are publicly |
| available. To meet this requirement, each Project is required |
| to create a transparently |
| available Project Plan in an EMO-defined file format |
| that meets the following criteria:</p><ol> |
| <li>Enumerates the areas of change in the frameworks and tools for each proposed Release</li> |
| <li>Consistent with and categorized in terms of the themes and priorities of the Roadmap</li> |
| <li>Identifies and accommodates cross-project dependencies</li> |
| <li>Addresses requirements critical to the Ecosystem and/or the Membership at Large </li> |
| <li>Advances the Project in functionality, quality, and performance</li> |
| </ol> |
| <p>A Project may incrementally revise their Project Plan to deliver additional tasks provided that:</p><ol> |
| <li>the approved Roadmap is not put in jeopardy; and</li> |
| <li>the work is consistent with the Project Plan criteria (as described above)</li> |
| </ol> |
| <p>A project may produce an aggregate plan for itself and its descendants. In this |
| case descendents would share their ancestor's plan.</p> |
| |
| <h2><a name="6_Development_Process"></a>6. Development Process</h2> |
| <p>All Eclipse Projects, and hence all Project Proposals, must be consistent with the Purposes and the then-current Roadmap.</p> |
| <p> |
| Projects must work within their Scope. Projects that desire to expand beyond their |
| current Scope must seek an enlargement of their Scope using a public Review as described below.</p> |
| <p> |
| All projects are required to report their status at least quarterly |
| using the <a href="/projects/dev_process/project-status-infrastructure.php">EMO defined status reporting procedures</a>.</p> |
| <p> |
| Projects must provide advanced notification of upcoming features and frameworks via their Project Plan.</p> |
| |
| <h3><a name="6_1_Mentors"></a>6.1 Mentors</h3> |
| <p>New Proposals that intend to do a Release |
| are required to have at least two <b>Mentors</b>. New Proposals |
| that will only Release code as part of a parent Project's Release are not required |
| to have Mentors. Mentors must |
| be members of the Architecture Council. The Mentors (including |
| name, affiliation, and current Eclipse projects/roles) must be listed in the Proposal. |
| Mentors are required to monitor and |
| advise the new Project during its Incubation Phase, but are released from that |
| duty |
| once the Project graduates to the Mature Phase.</p> |
| |
| <h3><a name="6_2_Project_Lifecycle"></a>6.2 Project Lifecycle</h3> |
| <img src="/projects/images/Development-process-small.gif" align="right"> |
| <p>Projects go through six distinct phases. The transitions from phase to phase are open and transparent public reviews.</p> |
| |
| <h4><a name="6_2_1_Pre-Proposal"></a>6.2.1 Pre-proposal</h4> |
| <div class="postit">See <a href="pre-proposal-phase.php">guidelines and |
| checklists</a> about writing a proposal. |
| </div><p>An individual or group of individuals declares their interest in, |
| and rationale for, establishing a project. The EMO will assist such groups in |
| the preparation of a project Proposal. </p><ul> |
| <li>The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.</li> |
| </ul> |
| |
| <h4><a name="6_2_2_Proposal"></a>6.2.2 Proposal</h4> |
| <div class="postit">See <a href="proposal-phase.php">guidelines and |
| checklists</a> about gathering support for a proposal. |
| </div><p>The proposers, in conjunction with the destination PMC and |
| the community, collaborate in public to enhance, refine, and clarify |
| the proposal. Mentors (if necessary) |
| for the project must be identified during this phase.</p><ul> |
| <li>The Proposal phase ends with a <a href="#6_3_1_Creation_Review">Creation Review</a>, or withdrawal.</li> |
| <li>The Proposal may be withdrawn by the proposers.</li> |
| <li>The EMO(ED) will withdraw a proposal that has been inactive for more than six months.</li> |
| </ul> |
| |
| <h4><a name="6_2_3_Incubation"></a>6.2.3 Incubation</h4> |
| <div class="postit">See <a href="incubation-phase.php">guidelines and |
| checklists</a> about incubation. |
| </div><p>After the project has been created, the purpose of the incubation |
| phase is to establish a fully-functioning open-source project. In this context, |
| incubation is about developing the process, the community, and the technology. |
| Incubation is a phase rather than a place: new projects may be incubated under |
| any existing Project. </p><ul> |
| <li>The Incubation phase may continue with a Continuation Review or a Release Review.</li> |
| <li>Top-Level Projects cannot be incubated and can only be created from one or more |
| existing Mature-phase Projects.</li> |
| <li>The Incubation phase ends with a Graduation Review or a Termination Review.</li> |
| <li>Designated <a href="#4_9_Incubators">Incubator Projects</a> may remain perpetually |
| in the Incubation phase; no reviews are required.</li> |
| </ul> |
| <p>Many Eclipse Projects are proposed and initiated by individuals with extensive and |
| successful software development experience. This document attempts to define a process |
| that is sufficiently flexible to learn from all its participants. At the same time, |
| however, the Incubation phase is useful for new Projects to learn the community-defined |
| Eclipse-centric open source processes.</p> |
| |
| <div class="postit">See <a href="parallel-ip-process.php">guidelines and |
| checklists</a> for utilizing the Parallel IP process. |
| </div><p>Only projects that are properly identified as being in the incubation phase |
| (including designated <a href="#4_9_Incubators">Incubator Projects</a>) may use |
| the Parallel IP process to reduce IP clearance process for new contributions.</p> |
| |
| <h4><a name="6_2_4_Mature"></a>6.2.4 Mature</h4> |
| <div class="postit">See <a href="mature-phase.php">guidelines and |
| checklists</a> about the mature phase. |
| </div><p>The project team has demonstrated that they are an open-source |
| project with an open and transparent process; an actively involved and growing |
| community; and Eclipse Quality technology. The project is now a mature member of |
| the Eclipse Community. Major releases continue to go through Release Reviews.</p><ul> |
| <li>Mature phase projects have Releases through Release Reviews.</li> |
| <li>A Mature Project may be promoted to a Top-Level Project through a Promotion Review.</li> |
| <li>A Mature Project that does not participate in a Release |
| in given year may continue through a Continuation Review.</li> |
| <li>Inactive Mature phase projects may be archived through a Termination Review.</li> |
| </ul> |
| |
| <h4><a name="6_2_5_Top-Level"></a>6.2.5 Top-Level</h4> |
| <div class="postit">See <a href="top-level-phase.php">guidelines and |
| checklists</a> about being a top-level project. |
| </div> |
| <p>Projects that have demonstrated the characteristics of a Top-Level Project (e.g., |
| consistent leadership in a technical area and the recruitment of a wider developer |
| community) can be promoted to Top-Level Project status. This promotion occurs through |
| a Promotion Review. Upon the successful completion of a Promotion Review, the EMO(ED) |
| may recommend that the project be promoted to the Board of Directors and ask that its |
| Charter be reviewed and approved.</p> |
| |
| <h4><a name="6_2_6_Archived"></a>6.2.6 Archived</h4> |
| <div class="postit">See <a href="archived-phase.php">guidelines and |
| checklists</a> for archiving projects. |
| </div><p>Projects that become inactive, either through dwindling resources or by reaching their natural |
| conclusion, are archived. Projects can reach their natural conclusion in a number |
| of ways: for example, a project might become so popular that it is absorbed into one of the |
| other major frameworks. Projects are moved to Archived status through a Termination Review. </p> |
| <p> |
| If there is sufficient community interest in reactivating an Archived Project, the Project |
| will start again with Creation Review. As there must be good reasons to have moved a |
| Project to the Archives, the Creation Review provides a sufficiently high bar to prove that those |
| reasons are no longer valid. It also ensures that the original or updated project goals |
| are still consistent with the Purposes and Roadmap.</p> |
| |
| <h3><a name="6_3_Reviews"></a>6.3 Reviews</h3> |
| <div class="comment"> |
| <p>This iteration of the document removes the notion of a "review call" in |
| favour of a "review period" during which the community is given an opportunity |
| to comment. This acknowledges the reality that the optional review calls |
| required by the <a href="<?= $previous ?>#6_3_Reviews">previous version</a> of this document |
| <em>never</em> actually occurred. Given that there will be no review calls, references to |
| "slides" have been removed.</p> |
| <p>See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=304878">Bug 304878</a>.</p> |
| </div> |
| |
| <p>The Eclipse Development Process is predicated on open and transparent behavior. All major |
| changes to Eclipse projects must be announced and reviewed by the membership-at-large. Major |
| changes include the Project Phase transitions as well as the introduction or exclusion of |
| significant new technology or capability. It is a clear requirement of this document that |
| members who are monitoring the appropriate media channels (e.g., mailing lists or RSS feeds) |
| not be surprised by the post-facto actions of the Projects.</p> |
| <p> |
| All Projects are required to participate in |
| at least one Review per year.</p> |
| <p> |
| For each <b>Review</b>, the project leadership makes a presentation to, and |
| receives feedback from, the Eclipse membership. </p> |
| <p> |
| A Review is a fairly comprehensive process. Gathering the material for a Review and |
| preparing the presentation is a non-trivial effort, but the introspection offered by |
| this exercise is useful for the Project and results are very useful for the entire |
| Eclipse community. In addition, Reviews have a specific relationship to the requirements |
| of the <a href="/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP Policy</a>.</p> |
| <p> |
| All Reviews have the same general process:</p> |
| <ol> |
| <li>Projects are responsible for initiating the appropriate reviews. However, if a Project |
| does not do so and the EMO believes a Review is necessary, the EMO may initiate a Review on the Project's behalf.</li> |
| <li> A Review then continues with the Project's Leadership requesting that the EMO(ED) schedule the Review. </li> |
| <li> Prior to the start of the review period, the Project leadership provides the EMO with |
| review documentation. <ul> |
| <li> The review documentation material always includes a document that describes the review. The minimum |
| contents of the document are specified by the individual Review types.</li> |
| <li> The presentation material must be available in a format that anyone in the Eclipse |
| membership can review. For example, Microsoft Powerpoint files are not an acceptable |
| single format: such files may be one of the formats, but not the only format. Similarly |
| for Apple Keynote files and Microsoft Word files. PDF and HTML are acceptable single formats.</li> |
| <li> The presentation material must have a correct copyright statement |
| and license.</li> |
| <li> The presentation material must be <em>archival quality</em>. This means that the materials |
| must be comprehensible and complete on their own without requiring explanation by a human |
| presenter, reference to a wiki, or to other non-archived |
| web pages.</li> |
| </ul></li> |
| <li> The EMO announces the Review schedule and makes the documentation available to the membership-at-large.</li> |
| </ol> |
| <p>The criteria for the successful completion of each type of Review will be documented |
| in writing by the EMO in guidelines made available via the www.eclipse.org website. |
| Such guidelines will include, but are not limited to the following:</p><ol> |
| <li> Clear evidence that the project has vibrant committer, adopter and user communities |
| as appropriate for the type of Review.</li> |
| <li> Reasonable diversity in its committer population as appropriate for the type of |
| Review. Diversity status must be provided not only as number of people/companies, but |
| also in terms of effort provided by those people/companies. </li> |
| <li> Documented completion of all required due diligence under |
| the <a href="/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP Policy</a>.</li> |
| <li> For Continuation, Graduation and Release Reviews, the project |
| must have a current project plan, in the format specified by the EMO, available to the community.</li> |
| <li> Balanced progress in creating both frameworks and extensible, exemplary tools.</li> |
| <li> Showcase the project's quality through project-team chosen metrics and |
| measures, e.g., coupling, cyclomatic complexity, test/code coverage, |
| documentation of extensions points, etc.</li> |
| </ol> |
| <p> |
| The Review period is open for no less than one week and usually no more than |
| two weeks of generally accepted business days.</p> |
| <ol> |
| <li> The Review begins with |
| the EMO's posting of the review materials at the start of the Review period</li> |
| <li> |
| The proper functioning of the Eclipse Development Process is contingent on |
| the active participation of the Eclipse Members and Committers, especially in Reviews, |
| thus each Review has an EMO-designated discussion and feedback |
| communication channel: a forum/newgroup, a mailing list, or some other public forum.</li> |
| <li>If a Committer election is required for a Review (for example, for a <a href="#6_3_1_Creation_Review">Creation Review</a>), then it |
| is held simultaneously with the Review period. Thus the election and the Review will end at |
| the same time, allowing quick and efficient provisioning of the resulting Project.</li> |
| <li> The EMO(ED) approves or fails the Review based on the public comments, |
| the scope of the Project, and the Purposes of the Eclipse Foundation as |
| defined in the Bylaws. </li> |
| <li>The Review ends with the announcement of the results |
| in the defined Review communication channel (the EMO(ED) will request that the Project Lead make this announcement).</li> |
| </ol> |
| <p> |
| If any Member believes that the EMO has acted incorrectly in approving or |
| failing a Review may appeal to the Board to review the EMO's decision.</p> |
| |
| <h4><a name="6_3_1_Creation_Review"></a>6.3.1 Creation Review</h4> |
| <div class="postit">See <a href="creation-review.php">guidelines and |
| checklists</a> about Creation Reviews. |
| </div><p>The purpose of the Creation Review is to assess the community and membership |
| response to the proposal, to verify that appropriate resources are available |
| for the project to achieve its plan, and to serve as a committer election for |
| the project's initial Committers. The Eclipse Foundation strives not to be a |
| repository of "code dumps" and thus projects must be sufficiently staffed for forward progress. </p> |
| <p> |
| The Creation Review documents must include |
| short nomination bios of the proposed initial committers. |
| These bios should discuss |
| their relationship to, and history with, the incoming code |
| and/or their involvement with the area/technologies covered by the proposal. |
| The goal is to help keep any legacy contributors connected to new project and |
| explain that connection to the current and future Eclipse membership, as well |
| as justify the initial Committers' participation in a meritocracy.</p> |
| |
| <h4><a name="6_3_2_Graduation_Review"></a>6.3.2 Graduation Review</h4> |
| <div class="postit">See <a href="graduation-review.php">guidelines and |
| checklists</a> about Graduation Reviews. |
| </div><p>The purpose of the Graduation Review is to confirm that the Project is/has:</p><ul> |
| <li> a working and demonstrable code base of sufficiently high quality</li> |
| <li> active and sufficiently diverse communities appropriate to the size of the graduating code base: adopters, developers, and users</li> |
| <li> operating fully in the open following the Principles and Purposes of Eclipse</li> |
| <li> a credit to Eclipse and is functioning well within the larger Eclipse community</li> |
| </ul> |
| <p>The Graduation Review is about the phase change from Incubation Phase to |
| Mature Phase. If the Project and/or some of its code is simultaneously relocating to another Project, |
| the Graduation Review will be combined with a <a href="#6_3_8_Restructuring_Review">Restructuring Review</a>. </p> |
| |
| <h4><a name="6_3_3_Release_Review"></a>6.3.3 Release Review</h4> |
| <div class="postit">See <a href="release-review.php">guidelines and |
| checklists</a> about Release Reviews. |
| </div><p>The purposes of a Release Review are: to summarize the accomplishments of the release, |
| to verify that the IP Policy has been followed and all approvals have been received, to |
| highlight any remaining quality and/or architectural issues, and to verify that the |
| project is continuing to operate according to the Principles and Purposes of Eclipse.</p> |
| |
| <h4><a name="6_3_4_Promotion_Review"></a>6.3.4 Promotion Review</h4> |
| <p>The purpose of a Promotion Review is to determine if the Project has demonstrated |
| the characteristics of a Top-Level Project, e.g., consistent leadership in a |
| technical area and the recruitment of a wider developer community. The Project |
| will already be a well-functioning Mature Eclipse Project, so evidence to the |
| contrary will be a negative for promotion. Top-Level Projects, both through their |
| existence and their Council memberships, have substantial influence over direction |
| and operation of Eclipse, thus it behooves the membership to grant Top-Level status |
| only for merit: for demonstrated service to the larger Eclipse ecosystem.</p> |
| |
| <h4><a name="6_3_5_Continuation_Review"></a>6.3.5 Continuation Review</h4> |
| <p>The purpose of a Continuation Review is to verify that a Proposal or Project |
| continues to be a viable effort and a credit to Eclipse. The Project team will |
| be expected to explain the recent technical progress and to demonstrate sufficient |
| adopter, developer, and user support for the Project. The goal of the Continuation |
| Review is to avoid having inactive projects looking promising but never actually |
| delivering extensible frameworks and exemplary tools to the ecosystem.</p> |
| |
| <h4><a name="6_3_6_Termination_Review"></a>6.3.6 Termination Review</h4> |
| <div class="postit">See <a href="http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Information_for_Project_Leads#Termination_.28Archive.29_Reviews">Termination Review "How To"</a> for more information. |
| </div> |
| <p>The purpose of a Termination Review is to provide a final opportunity for the |
| Committers and/or Eclipse membership to discuss the proposed withdrawal of a |
| Proposal or archiving of a Project. The desired outcome is to find sufficient |
| evidence of renewed interest and resources in keeping the Project or Proposal |
| active.</p> |
| |
| <h4><a name="6_3_7_Move_Review"></a>6.3.7 Move Review</h4> |
| <p>A Move Review is considered to be a special type of |
| <a href="#6_3_8_Restructuring_Review">Restructuring Review</a>.</p> |
| |
| <h4><a name="6_3_8_Restructuring_Review"></a>6.3.8 Restructuring Review</h4> |
| <div class="comment"> |
| <p>This iteration of the document provides more detail on Restructuring Reviews. It |
| also considers a Move Review (as defined by the <a href="<?= $previous ?>#6_3_7_Move_Review">previous version</a> |
| of this document) to be a special type of a Restructuring Review.</p> |
| <p>This version of the document makes explicit a loophole that permits |
| the creation of new projects without engaging in the full proposal/creation |
| process. This applies only to new project with a scope that is a subset |
| of the original project's scope. There is no explicit requirement that a |
| project become a parent to the new projects. New projects can be created as |
| siblings or elsewhere in the project hierarchy. In the event that a restructuring |
| review results in unrelated projects, it is expected that the scope of the original project will be |
| adjusted accordingly.</p> |
| </div> |
| |
| <p>The purpose of a Restructuring Review is to notify the community of your intent |
| to make significant changes to one or more projects. "Significant changes" includes:</p> |
| <ul> |
| <li>Movement of significant chunks of functionality from one project to another;</li> |
| <li>Modification of the project structure, e.g. combining multiple projects into a single project, or |
| decomposing a single project into multiple projects; and/or</li> |
| <li>Change of project scope.</li> |
| </ul> |
| <p>A Restructuring Review may include the movement of significant chunks of code. |
| A move is considered significant if it has an impact on the community (i.e. if segments |
| of the community will notice that the code has moved). This may include entire projects, |
| bundles, and features, but likely excludes small fragments, code snippets |
| and individual files. The IP Log of all moved code must be reviewed prior to the start |
| of the review period (this, typically, is a subset of the project's IP Log). If all of |
| the code is moved out of a project, a Termination Review for that project can be |
| combined with the Restructuring Review.</p> |
| |
| <p>Note that, regardless of whether or not a review is required, moving code from |
| one Project to another is subject to the <a href="/org/documents/Eclipse_IP_Policy.pdf">Eclipse IP Policy</a>.</p> |
| |
| <p>A Restructuring Review may necessitate the construction of one or more new projects. |
| This tends to occur when an existing project is decomposed into two or more projects. In |
| this case, a Restructuring Review is similar to a Creation Review. Any new projects that |
| are created as part of a Restructuring Review must have their scope explicitly specified |
| as part of the review. The scope of any new project must be a subset of the scope of the |
| original project. Likewise, the set of committers assigned to a new project must be a |
| subset of the committers of the original project (additional committers can be elected |
| to the new project after it is created). Any new projects that fall outside of the scope |
| of the original project, or wish to establish a different set of committers, must undergo |
| the full project creation process.</p> |
| |
| <p>Committers can be moved along with code into a new project as part of the project |
| provisioning process. Committers cannot be moved along with code into an existing project. |
| In this case, the existing project must elect the new committers into the project.</p> |
| |
| <p>A project is expected to socialize pending changes using established communication channels prior |
| to initiating the review. A Restructuring Review must provide the community with at least one |
| week to review and respond to the changes. Prior to the start of that review period, the |
| community must be provided with (via the EMO) completed review documentation that describes |
| in specific terms what will be changed as part of the restructuring.</p> |
| |
| <p>This may include:</p> |
| |
| <ul> |
| <li>Name, description, scope, and committer lists of new projects that need to be created;</li> |
| <li>Source and target locations for moves of source code directories;</li> |
| <li>Reorganization of builds and downloads;</li> |
| <li>Contribution questionnaires (CQs) that need to be moved or piggy-back CQs that must be created;</li> |
| <li>Location of the approved IP Log; and</li> |
| <li>Other information that helps the community understand the change.</li> |
| </ul> |
| |
| <h4><a name="6_3_9_Combining_Reviews"></a>6.3.9 Combining Reviews</h4> |
| <div class="comment"> |
| <p>This section has been modified to explicitly allow multiple projects to |
| participate in a single. It is possible, for example, for a project and its |
| descendants to engage in a simultaneous Release Review.</p></div> |
| |
| <p>Reviews can be combined at the discretion of the PMC and EMO. Multiple Projects may participate |
| in a single Review. Similarly, multiple review types can be engaged in simultaneously. |
| A parent Project may, for example, engage in an aggregated Release Review involving itself and |
| some or all of its child projects; a consolidated Restructuring Review may move the code for |
| several projects; or a Release Review may be combined with a Graduation Review. When multiple |
| reviews are combined, the review documentation must explicitly state all of the Projects |
| and types of reviews involved, and include the required information about each.</p> |
| |
| <p>It should be noted that the purpose of combining reviews is to better serve the community, |
| rather than to reduce effort on the part of the project (though it is fortunate when it does both). |
| Combining a Release and Graduation review, or aggregating a Release Review of a Project |
| and several of it's child Projects generally makes sense. Combining Release Reviews |
| for multiple unrelated projects most likely does not.</p> |
| |
| <h3><a name="6_4_Releases"></a>6.4 Releases</h3> |
| <p><em>(Most of this section is borrowed and paraphrased from the excellent |
| <a href="http://www.apache.org/dev/release.html">Apache Software |
| Foundation Releases FAQ</a>. The Eclipse community has many of the same |
| beliefs about Releases as does the Apache community and their words were already excellent. |
| The Apache Software Foundation Releases FAQ is distributed under the |
| <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.)</em></p> |
| <p> |
| Releases are, by definition, anything that is distributed outside of the Committers |
| of a Project. If users are being directed to download a build, then |
| that build has been released (modulo the exceptions below). All Projects |
| and Committers must obey the Eclipse Foundation requirements on approving any release.</p> |
| <p> |
| <em>(Exception 1: nightly and integration builds)</em> |
| During the process of developing software and preparing a Release, various |
| nightly and integration builds |
| are made available to the developer community for testing purposes. Do not include |
| any links on the project website, blogs, wikis, etc. that might |
| encourage non-early-adopters to download |
| and use nightly builds, release candidates, or any other similar package (links |
| aimed at early-adopters and the project's developers are both permitted and encouraged). The |
| only people who are supposed to know about such packages are the people following |
| the developer mailing list and thus are aware of the limitations of such builds.</p> |
| <p> |
| <em>(Exception 2: milestone and release candidate builds)</em> |
| Projects are encouraged to use an agile development process including regular milestones |
| (for example, six week milestones). Milestones and release candidates are "almost releases" intended for |
| adoption and testing by early adopters. Projects are allowed to have links |
| on the project website, blogs, wikis, etc. to encourage these outside-the-committer-circle |
| early adopters to download and test the milestones and release candidates, but such communications must |
| include caveats explaining that these are not official Releases.</p> |
| |
| <ul> |
| <li>Milestones are to be labeled <code>x.yMz</code>, e.g., 2.3M1 (milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version 2.3), etc.</li> |
| <li>Release candidates are to be labeled <code>x.yRCz</code>, e.g., 2.3RC1 (release candidate 1 towards version 2.3).</li> |
| <li>Official Releases are the only downloads allowed to be labeled with <code>x.y</code>, e.g., 0.5, 1.0, 2.3, etc.</li> |
| </ul> |
| <p> |
| All official Releases must have a successful <a href="#6_3_3_Release_Review">Release Review</a> before being made available for download. </p> |
| <p> |
| <em>(Exception 3: bug fix releases with no new features)</em> |
| Bug fix releases (x.y.z, e.g., 2.3.1) with no new features over the base release (e.g., 2.3) |
| are allowed to be released without an additional Release Review. |
| If a bug fix release contains new features, then the Project must |
| have a full Release Review.</p> |
| <p> |
| Under no circumstances are builds and milestones to be used as a substitute for doing |
| proper official Releases. Proper Release management and reviews is a key aspect of |
| Eclipse Quality. </p> |
| |
| <h3><a name="6_5_Grievance_Handling"></a>6.5 Grievance Handling</h3> |
| <p>When a Member has a concern about a Project, the Member will raise |
| that concern with the Project's Leadership. If the Member is not |
| satisfied with the result, the Member can raise the concern with |
| the parent Project's Leadership. The Member can continue appeals |
| up the Project Leadership Chain and, if still not satisfied, thence |
| to the EMO, then the Executive Director, and finally to the Board. |
| All appeals and discussions will abide by the Guiding Principles of |
| being open, transparent, and public.</p> |
| <p> |
| Member concerns may include:</p><ul> |
| <li><b>Out of Scope.</b> It is alleged that a Project is |
| exceeding its approved scope.</li> |
| <li><b>Inconsistent with Purposes.</b> It is alleged that a Project |
| is inconsistent with the Roadmap and/or Purposes.</li> |
| <li><b>Dysfunctional.</b> It is alleged that a Project is not |
| functioning correctly or is in violation of one or more requirements |
| of the Development Process.</li> |
| <li><b>Contributor Appeal.</b> It is alleged that a Contributor who |
| desires to be a Committer is not being treated fairly.</li> |
| <li><b>Invalid Veto.</b> It is alleged that a -1 vote on a Review is |
| not in the interests of the Project and/or of Eclipse.</li> |
| </ul> |
| <p>A variety of grievance resolutions are available to the EMO up to, and |
| including, rebooting or restarting a project with new Committers and leadership.</p> |
| |
| <h2><a name="7_Precedence"></a>7. Precedence</h2> |
| <p>In the event of a conflict between this document and a Board-approved |
| project charter, the most recently approved document will take precedence.</p> |
| |
| <h2><a name="8_Revisions"></a>8. Revisions</h2> |
| <p>As specified in the Bylaws, the EMO is responsible for maintaining |
| this document and all changes must be approved by the Board.</p> |
| <p> |
| Due to the continued evolution of the Eclipse technology, the Eclipse |
| community, and the software marketplace, it is expected that the Development |
| Process (this document) will be reviewed and revised on at least an |
| annual basis. The timeline for that review should be chosen so as to |
| incorporate the lessons of the previous annual coordinate release and |
| to be applied to the next annual coordinated release. |
| </p><p> |
| The EMO is further responsible for ensuring that all plans, documents |
| and reports produced in accordance with this Development Process be |
| made available to the Membership at Large via an appropriate mechanism |
| in a timely, effective manner. |
| |
| </p><h4><a name="8_1_Revision"></a>8.1 Revision 2.5</h4> |
| <p>This document was approved by the Eclipse Foundation Board of Directors in its meeting |
| on May 19/2010. It takes effect (replacing all previous versions) on August 1/2010.</p> |
| |
| </div><!-- midcolumn --> |
| |
| <div id="rightcolumn"> |
| <div class="sideitem"> |
| <h6>See also</h6> |
| <ul> |
| <li><a href="development_process_2010.pdf">PDF version of this document</a></li> |
| <li><a href="<?= $previous ?>">Previous edition of this document</a></li> |
| <li><a href="<?= $next ?>">Next edition of this document</a></li> |
| <li><a href="<?= $diff ?>">Changes made since the previous version of this document</a></li> |
| <?= $commentary ? '' : '<li><a href="?commentary">This document with comments</a></li>' ?> |
| </ul> |
| </div> |
| </div> |
| |
| </div><!-- maincontent --> |
| |
| <?php |
| # Paste your HTML content between the EOHTML markers! |
| $html = ob_get_contents(); |
| ob_end_clean(); |
| |
| # Generate the web page |
| $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html); |
| ?> |