<?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 &quot;Project&quot; 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 &quot;Operating&quot; and 
&quot;Container&quot; 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 &quot;parent&quot; 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%20BYLAWS%202003_11_10%20Final.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 &quot;union&quot; 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&ndash;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 &quot;parent&quot; 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 &quot;Operating&quot; 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 &quot;Incubator&quot;
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 &quot;Incubator&quot;. 
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 &quot;Incubator&quot; in
its name (e.g. &quot;Eclipse Incubator&quot;). 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 &quot;review call&quot; in 
favour of a &quot;review period&quot; 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 
&quot;slides&quot; 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 &quot;code dumps&quot; 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 &quot;How To&quot;</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. &quot;Significant changes&quot; 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 &quot;almost releases&quot; 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);
?>