<?php
/*******************************************************************************
 * Copyright (c) 2008, 2010, 2011 Eclipse Foundation and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *    Bjorn Freeman-Benson (Eclipse Foundation) - initial API and implementation
 *    Wayne Beaton (Eclipse Foundation) - 2010, 2011 updates.
 *******************************************************************************/
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());

$pageTitle = "Eclipse Development Process 2011";
$pageAuthor = "Wayne Beaton";
$pageKeywords = "EDP, Eclipse Development Process";

include( '../_commonLeftNav.php' );

$previous = "/projects/dev_process/development_process_2010.php";
$diff = "development_process_2011_diff.php";
$pdf = "development_process_2011.pdf";
$bylaws = "/org/documents/eclipse_foundation-bylaws.pdf#page=19";
$ip_policy = "/org/documents/Eclipse_IP_Policy.pdf";

$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: <?php echo $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_Reserved">5 [Reserved]</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>


		<div class="comment">
			<p>Removed references to the Roadmap.</p>
		</div>
		<p>This document has the following 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="#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>

		<div class="comment">
			<p>References to the Roadmap have been removed.</p>
		</div>
		<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; and</li>
			<li>ship extensible, exemplary tools which help enable a broad
				community of users</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>
			<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>
			<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>

		<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="<?php echo $bylaws; ?>">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>

		<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="/projects/dev_process/images/subprojects-resources-291x300.png" />

		<h3>
			<a name="4_2_Code_and_Releases"></a>4.2 Code and Releases
		</h3>

		<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>

		<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>

		<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>
		<div class="comment">
			<p>Discussion of the Requirements Council has been removed from
			this section. The language has also been changed slightly: rather
			than refer to the &quot;three Councils&quot;, it instead refers to
			the &quot;Councils&quot;.</p>
		</div>
		<p>The Councils defined in Bylaws section VII are comprised of
			Strategic members and PMC representatives. The Councils help guide
			the Projects as follows:</p>
		<ul>
			<li>The <b>Planning Council</b> is responsible for establishing a
				coordinated Simultaneous Release (a.k.a, "the release train"). The
				Planning Council is further 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 (i)
				monitoring, guiding, and influencing the software architectures used
				by Projects, (ii) new project mentoring, and (iii) maintaining and
				revising the Eclipse Development Process. 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>Added a single line to indicate that incubators do not
			require a proposal.</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. A proposal
				is not required to create an Incubator project.
		</p>

		<h2>
			<a name="5_Reserved"></a>5. [Reserved]
		</h2>
		<div class="comment">
			<p>Section 5 was formerly concerned with the Roadmap process. With the
			new iteration of the bylaws, we have removed the Roadmap.</p>
		</div>

		<h2>
			<a name="6_Development_Process"></a>6. Development Process
		</h2>
		<div class="comment">
			<p>References to the Roadmap have been removed. The provision that projects
			must fit within the scope of containing projects and the scope defined in the
			charter of the Top-Level Project has been added.</p>
		</div>
		<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. Further, projects
			must fit within the scope defined by their containing projects and
			the scope defined in the charter of their Top-Level Project.</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>

		<div class="comment">
			<p>References to the Roadmap have been removed.</p>
		</div>
		<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.</p>

		<h3>
			<a name="6_3_Reviews"></a>6.3 Reviews
		</h3>
		<div class="comment">
			<p>Previous versions make reference to creation and delivery
			of a presentation for reviews. This has been changed to instead
			reference review &quot;documentation&quot;. As a matter of practice
			we haven't done review calls in many years so a presentation-type
			format is unnecessary.</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 prepares documentation
			for, 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 documentation 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="<?php echo $ip_policy; ?>">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 review documentation must be available in a format that
						anyone in the Eclipse membership can review. PDF
						and HTML are acceptable single formats.</li>
					<li>The review documentation must have a correct copyright
						statement and license.</li>
					<li>The review documentation 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="<?php echo $ip_policy; ?>">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>

		<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="<?php echo $ip_policy; ?>">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>

		<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>

		<div class="comment">
			<p>References to the Roadmap have been removed.</p>
		</div>
		<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>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.6
		</h4>
		<p>This document was approved by the Eclipse Foundation Board of
			Directors in its meeting on June 15/2011. It takes effect (replacing
			all previous versions) on August 1/2011.</p>

	</div>
	<!-- midcolumn -->

	<div id="rightcolumn">
		<div class="sideitem">
			<h6>See also</h6>
			<ul>
				<li><a href="<?php echo $pdf; ?>">PDF version of this
						document</a></li>
				<li><a href="<?php echo $previous; ?>">Previous edition of this document</a>
				</li>
				<li><a href="<?php echo $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);
?>