

 p { margin-bottom:10px; } blockquote { margin-left:2em; margin-right:	  |	 p { margin-bottom:10px; } blockquote { margin-left:2em; margin-right:


Eclipse Development Process							Eclipse Development Process

Contents									Contents


1 Purpose									1 Purpose
2 Principles									2 Principles

2.1 Open Source									2.1 Open Source
Rules of Engagement								Rules of Engagement
2.2 Eclipse Ecosystem								2.2 Eclipse Ecosystem
2.3 Three Communities								2.3 Three Communities
2.4 Clear, Concise, and								2.4 Clear, Concise, and
Evolving									Evolving


3 Requirements									3 Requirements

3.1 Requirements and								3.1 Requirements and
Guidelines									Guidelines


4 Project Structure and								4 Project Structure and
Organization									Organization

4.1 Committers									4.1 Committers
4.2 Code and Releases								4.2 Code and Releases
4.3 IP Records									4.3 IP Records
4.4 Community Awareness								4.4 Community Awareness
4.5 Scope									4.5 Scope
4.6 Leaders									4.6 Leaders
									  >
									  >	4.6.1 Project Management Committee
									  >	(PMC)
									  >	4.6.2 Project Lead(s)
									  >
									  >
4.7 Committers and								4.7 Committers and
Contributors									Contributors
4.8 Councils									4.8 Councils
4.9 Incubator Projects								4.9 Incubator Projects


5 Roadmap Process								5 Roadmap Process
6 Development Process								6 Development Process

6.1 Mentors									6.1 Mentors
6.2 Project Lifecycle								6.2 Project Lifecycle
6.2.1 Pre-proposal								6.2.1 Pre-proposal
6.2.2 Proposal									6.2.2 Proposal
6.2.3 Incubation								6.2.3 Incubation
6.2.4 Mature									6.2.4 Mature
6.2.5 Top-Level									6.2.5 Top-Level
6.2.6 Archived									6.2.6 Archived
6.3 Reviews									6.3 Reviews

6.3.1 Creation Review								6.3.1 Creation Review
6.3.2 Graduation Review								6.3.2 Graduation Review
6.3.3 Release Review								6.3.3 Release Review
6.3.4 Promotion Review								6.3.4 Promotion Review
6.3.5 Continuation								6.3.5 Continuation
Review										Review
6.3.6 Termination								6.3.6 Termination
Review										Review
6.3.7 Move Review								6.3.7 Move Review
6.3.8 Restructuring								6.3.8 Restructuring
Review										Review
6.3.9 Combining Reviews								6.3.9 Combining Reviews


6.4 Releases									6.4 Releases
6.5 Grievance Handling								6.5 Grievance Handling


7 Precedence									7 Precedence
8 Revisions									8 Revisions

8.1 Revision 2.4								8.1 Revision 2.4


1. Purpose									1. Purpose
This document describes the Development Process for the Eclipse			This document describes the Development Process for the Eclipse
Foundation. In particular, it describes how the Membership at Large,		Foundation. In particular, it describes how the Membership at Large,
the Board of Directors, other constituents of the Ecosystem, and the		the Board of Directors, other constituents of the Ecosystem, and the
Eclipse Management Organization (EMO) lead, influence, and collaborate		Eclipse Management Organization (EMO) lead, influence, and collaborate
with Eclipse Projects to achieve these Eclipse purposes:			with Eclipse Projects to achieve these Eclipse purposes:
The Eclipse technology is a vendor-neutral, open				The Eclipse technology is a vendor-neutral, open
development platform supplying frameworks and exemplary, extensible		development platform supplying frameworks and exemplary, extensible
tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary i		tools (the 'Eclipse Platform'). Eclipse Platform tools are exemplary i
that they verify the utility of the Eclipse frameworks, illustrate the		that they verify the utility of the Eclipse frameworks, illustrate the
appropriate use of those frameworks, and support the development and		appropriate use of those frameworks, and support the development and
maintenance of the Eclipse Platform itself; Eclipse Platform tools are		maintenance of the Eclipse Platform itself; Eclipse Platform tools are
extensible in that their functionality is accessible via documented		extensible in that their functionality is accessible via documented
programmatic interfaces. The purpose of Eclipse Foundation Inc., is to		programmatic interfaces. The purpose of Eclipse Foundation Inc., is to
advance the creation, evolution, promotion, and support of the Eclipse		advance the creation, evolution, promotion, and support of the Eclipse
Platform and to cultivate both an open source community and an			Platform and to cultivate both an open source community and an
ecosystem of complementary products, capabilities, and				ecosystem of complementary products, capabilities, and
services.									services.

									  |	Explanatory comments, guidelines, and checklists - as well as
									  |	additional requirements added by the EMO per <a href=
Explanatory comments, guidelines, and checklists - as			  <
well as additional requirements added by the EMO per <a href=		  <
"#3_Requirements">section 3 - are noted in yellow boxes.			"#3_Requirements">section 3 - are noted in yellow boxes.

									  <
									  <
This document has five sections:						This document has five sections:

Principles outlines the basic							Principles outlines the basic
principles upon which the development process is based.				principles upon which the development process is based.
Requirements describes the							Requirements describes the
requirements that the Eclipse community has for its development			requirements that the Eclipse community has for its development
process.									process.
Structure and									Structure and
Organization specifies the structure and organization of the			Organization specifies the structure and organization of the
projects and project community at Eclipse.					projects and project community at Eclipse.
Roadmap Process describes							Roadmap Process describes
the manner by which the EMO will work with the projects to create the		the manner by which the EMO will work with the projects to create the
annual Eclipse Roadmap.								annual Eclipse Roadmap.
Development Process								Development Process
outlines the lifecycle and processes required of all Eclipse			outlines the lifecycle and processes required of all Eclipse
projects.									projects.

2. Principles									2. Principles
The following describe the guiding principles used in developing this	  |	The following describes the guiding principles used in developing
Development Process.							  |	this Development Process.
2.1 Open Source									2.1 Open Source
Rules of Engagement								Rules of Engagement

Open - Eclipse is open to all; Eclipse provides the same			Open - Eclipse is open to all; Eclipse provides the same
opportunity to all. Everyone participates with the same rules; there		opportunity to all. Everyone participates with the same rules; there
are no rules to exclude any potential contributors which include, of		are no rules to exclude any potential contributors which include, of
course, direct competitors in the marketplace.					course, direct competitors in the marketplace.
Transparent - Project discussions, minutes, deliberations,			Transparent - Project discussions, minutes, deliberations,
project plans, plans for new features, and other artifacts are open,		project plans, plans for new features, and other artifacts are open,
public, and easily accessible.							public, and easily accessible.
Meritocracy - Eclipse is a meritocracy. The more you				Meritocracy - Eclipse is a meritocracy. The more you
contribute the more responsibility you will earn. Leadership roles in		contribute the more responsibility you will earn. Leadership roles in
Eclipse are also merit-based and earned by peer acclaim.			Eclipse are also merit-based and earned by peer acclaim.

2.2 Eclipse Ecosystem								2.2 Eclipse Ecosystem
Eclipse as a brand is the sum of its parts (all of the Projects), and	  |	Eclipse as a brand is the sum of its parts (all of the Projects),
Projects should strive for the highest possible quality in extensible	  |	and Projects should strive for the highest possible quality in
frameworks, exemplary tools, transparent processes, and project		  |	extensible frameworks, exemplary tools, transparent processes, and
openness.								  |	project openness.
The Eclipse Foundation has the responsibility to				The Eclipse Foundation has the responsibility to
...cultivate...an ecosystem of complementary products,				...cultivate...an ecosystem of complementary products,
capabilities, and services.... It is therefore a key principle			capabilities, and services.... It is therefore a key principle
that the Eclipse Development Process ensures that the projects are		that the Eclipse Development Process ensures that the projects are
managed for the benefit of both the open source community and the		managed for the benefit of both the open source community and the
ecosystem members. To this end, all Eclipse projects are required		ecosystem members. To this end, all Eclipse projects are required
to:										to:

communicate their project plans and plans for new features (major		communicate their project plans and plans for new features (major
and minor) in a timely, open and transparent manner;				and minor) in a timely, open and transparent manner;
create platform quality frameworks capable of supporting the			create platform quality frameworks capable of supporting the
building of commercial grade products on top of them;				building of commercial grade products on top of them;
ship extensible, exemplary tools which help enable a broad			ship extensible, exemplary tools which help enable a broad
community of users; and								community of users; and
participate in the annual Roadmap process to ensure maximum			participate in the annual Roadmap process to ensure maximum
transparency and bi-directional communication with the ecosystem.		transparency and bi-directional communication with the ecosystem.

2.3 Three Communities								2.3 Three Communities
Essential to the Purposes of the Eclipse Foundation is the development	  |	Essential to the Purposes of the Eclipse Foundation is the
of three inter-related communities around each Project:			  |	development of three inter-related communities around each Project:

Contributors and Committers - a thriving, diverse and				Contributors and Committers - a thriving, diverse and
active community of developers is the key component of any Eclipse		active community of developers is the key component of any Eclipse
Project. Ideally, this community should be an open, transparent,		Project. Ideally, this community should be an open, transparent,
inclusive, and diverse community of Committers and (non-Committer)		inclusive, and diverse community of Committers and (non-Committer)
Contributors. Attracting new Contributors and Committers to an open		Contributors. Attracting new Contributors and Committers to an open
source project is time consuming and requires active recruiting, not		source project is time consuming and requires active recruiting, not
just passive "openness". The Project Leadership must make reasonable		just passive "openness". The Project Leadership must make reasonable
efforts to encourage and nurture promising new Contributors.			efforts to encourage and nurture promising new Contributors.

Projects must have the diversity goals to ensure diversity of		  |	Projects must have diversity goals to ensure diversity of thought
thought and avoiding relying on any one company or organization. At th	  |	and avoid relying on any one company or organization. At the same time
same time, we acknowledge that enforcing a particular diversity metric	  |	we acknowledge that enforcing a particular diversity metric is a poor
is a poor way to achieve these goals; rather we expect the project	  |	way to achieve these goals; rather we expect the project leadership to
leadership to help the diversity evolve organically.			  |	help the diversity evolve organically.
Diversity is a means to an end, not an end in itself, thus			Diversity is a means to an end, not an end in itself, thus
diversity goals will differ by project based on the other			diversity goals will differ by project based on the other
accomplishments of the project(s).						accomplishments of the project(s).
Project are required to explain their diversity efforts and		  |	Projects are required to explain their diversity efforts and
accomplishments during Reviews.							accomplishments during Reviews.


Users - an active and engaged user community is					Users - an active and engaged user community is
proof-positive that the Project's exemplary tools are useful and		proof-positive that the Project's exemplary tools are useful and
needed. Furthermore, a large user community is one of the key factors		needed. Furthermore, a large user community is one of the key factors
in creating a viable ecosystem around an Eclipse project, thus			in creating a viable ecosystem around an Eclipse project, thus
encouraging additional open source and commercial organizations to		encouraging additional open source and commercial organizations to
participate. Like all good things, a user community takes time and		participate. Like all good things, a user community takes time and
effort to bring to fruition, but once established is typically			effort to bring to fruition, but once established is typically
self-sustaining.								self-sustaining.
Adopters - an active and engaged adopter/plug-in developer			Adopters - an active and engaged adopter/plug-in developer
community is the only way to prove that an Eclipse project is providin		community is the only way to prove that an Eclipse project is providin
extensible frameworks and extensible tools accessible via documented		extensible frameworks and extensible tools accessible via documented
APIs. Reuse of the frameworks within the companies that are			APIs. Reuse of the frameworks within the companies that are
contributing to the project is necessary, but not sufficient to			contributing to the project is necessary, but not sufficient to
demonstrate an adopter community. Again, creating, encouraging, and		demonstrate an adopter community. Again, creating, encouraging, and
nurturing an adopter community outside of the Project's developers		nurturing an adopter community outside of the Project's developers
takes time, energy, and creativity by the Project Leadership, but is		takes time, energy, and creativity by the Project Leadership, but is
essential to the Project's long-term open source success.			essential to the Project's long-term open source success.

The Eclipse community considers the absence of any one or more of thes	  |	The Eclipse community considers the absence of any one or more of
communities as proof that the Project is not sufficiently open,		  |	these communities as proof that the Project is not sufficiently open,
transparent, and inviting, and/or that it has emphasized tools at the		transparent, and inviting, and/or that it has emphasized tools at the
expense of extensible frameworks or vice versa.					expense of extensible frameworks or vice versa.
2.4 Clear, Concise,								2.4 Clear, Concise,
and Evolving									and Evolving
It is an explicit goal of the Development Process to be as clear and		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		concise as possible so as to help the Project teams navigate the
complexities, avoid the pitfalls, and become successful as quickly as		complexities, avoid the pitfalls, and become successful as quickly as
possible.									possible.
This document imposes requirements and constraints on the operation		This document imposes requirements and constraints on the operation
of the Projects, and it does so on behalf of the larger Eclipse			of the Projects, and it does so on behalf of the larger Eclipse
community. It is an explicit goal of the Development Process to provid		community. It is an explicit goal of the Development Process to provid
as much freedom and autonomy to the Projects as possible while ensurin		as much freedom and autonomy to the Projects as possible while ensurin
the collective qualities benefit the entire Eclipse community.			the collective qualities benefit the entire Eclipse community.
Similarly, this document should not place undue constraints on the		Similarly, this document should not place undue constraints on the
EMO or the Board that prevent them from governing the process as		EMO or the Board that prevent them from governing the process as
necessary. We cannot foresee all circumstances and as such should be		necessary. We cannot foresee all circumstances and as such should be
cautious of being overly prescriptive and/or requiring certain fixed		cautious of being overly prescriptive and/or requiring certain fixed
metrics.									metrics.
The frameworks, tools, projects, processes, community, and even the		The frameworks, tools, projects, processes, community, and even the
definition of Quality continues to, and will continue to, evolve.		definition of Quality continues to, and will continue to, evolve.
Creating rules or processes that force a static snapshot of any of		Creating rules or processes that force a static snapshot of any of
these is detrimental to the health, growth, and ecosystem impact of		these is detrimental to the health, growth, and ecosystem impact of
Eclipse.									Eclipse.
Part of the strength of this document is in what it does not say,		Part of the strength of this document is in what it does not say,
and thus opens for community definition through convention, guidelines		and thus opens for community definition through convention, guidelines
and public consultation. A document with too much structure becomes to		and public consultation. A document with too much structure becomes to
rigid and prevents the kind of innovation and change we desire for		rigid and prevents the kind of innovation and change we desire for
Eclipse. In areas where this document is vague, we expect the Projects		Eclipse. In areas where this document is vague, we expect the Projects
and Members to engage the community-at-large to clarify the current		and Members to engage the community-at-large to clarify the current
norms and expectations.								norms and expectations.
3. Requirements									3. Requirements
This document and any additional criteria as established by the EMO		This document and any additional criteria as established by the EMO
contain requirements, recommendations, and suggestions.			  |	contains requirements, recommendations, and suggestions.
<span style=									<span style=
"margin-right:6px; margin-top:5px; float:left; color:ivory; background		"margin-right:6px; margin-top:5px; float:left; color:ivory; background
RRequired - Certain responsibilities and behaviors are				RRequired - Certain responsibilities and behaviors are
required of participants in Eclipse open source projects. Projects tha		required of participants in Eclipse open source projects. Projects tha
fail to perform the required behaviors will be terminated by the EMO.		fail to perform the required behaviors will be terminated by the EMO.
In keeping with the Guiding Principles, the number of requirements mus		In keeping with the Guiding Principles, the number of requirements mus
be kept to an absolute minimum.							be kept to an absolute minimum.
<span style=									<span style=
"margin-right:6px; margin-top:5px; float:left; color:ivory; background		"margin-right:6px; margin-top:5px; float:left; color:ivory; background
GGuideline - Other responsibilities and behaviors are				GGuideline - Other responsibilities and behaviors are
recommended best practices. Collectively, we have learned that Project		recommended best practices. Collectively, we have learned that Project
are more likely to be successful if the team members and leaders follo		are more likely to be successful if the team members and leaders follo
these recommendations. Projects are strongly encouraged to follow thes		these recommendations. Projects are strongly encouraged to follow thes
recommendations, but will not be penalized by this Process if they do		recommendations, but will not be penalized by this Process if they do
not.										not.
3.1 Requirements and								3.1 Requirements and
Guidelines									Guidelines
This document is entirely composed of requirements. In addition to the	  |	This document is entirely composed of requirements. In addition to
requirements specified in this Development Process, the EMO is		  |	the requirements specified in this Development Process, the EMO is
instructed to clarify, expand, and extend this Process by creating a		instructed to clarify, expand, and extend this Process by creating a
set of Eclipse Project Development Guidelines to advance the creation,		set of Eclipse Project Development Guidelines to advance the creation,
evolution, promotion, and support of the Eclipse Platform and to		evolution, promotion, and support of the Eclipse Platform and to
cultivate both an open source community and an ecosystem of			cultivate both an open source community and an ecosystem of
complementary products and services.						complementary products and services.
The EMO is not permitted to override or ignore the requirements			The EMO is not permitted to override or ignore the requirements
listed in this document without the express written endorsement of the		listed in this document without the express written endorsement of the
Board of Directors.								Board of Directors.
4. Structure and							  |	4. Project Structure and
Organization									Organization
The Eclipse Projects are organized hierarchically. The top of the	  |
hierarchy are the set of Top Level Projects. Each Top Level		  |	This version of the document adds the word "Project" to the title of
Project contains one or more Sub-Projects. Each Sub-Project		  |	this section to better qualify that it discusses the structure and
contains zero or more Sub-Projects. The term Project refers to		  |	organization of projects. The <a href=
either a Top-Level Project or a Sub-Project. Projects may be referred	  |	"#4_Structure_and_Organization">previous version of this document
to as Sub-Projects or Components, but the choice of common name does	  |	defined notions of "Operating" and "Container" Projects. These notions
not change the characteristics of the Project.				  |	have been abandoned in favour of a more generalized notion of Project.
Projects with no child Projects are Operating Projects.			  |	Under this new structure, projects can opt to function as Operating
Projects with one or more child Projects are Container Projects.	  |	Projects by choosing not to maintain a code repository.
									  >	See <a href=
									  >	"https://bugs.eclipse.org/bugs/show_bug.cgi?id=301065">Bug
									  >	301065.
									  >
									  >	A Project 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 help
									  >	developers expose their hard work to a broad audience of consumers.
									  >	Eclipse Projects are organized hierarchically. A special type of
									  >	Project, Top-Level Projects, sit at the top of the hierarchy.
									  >	Each Top-Level Project contains one or more Projects. Each Project may
									  >	itself contain zero or more Projects. A project that has one or more
									  >	Projects is said to be the "parent" of those Projects. A Project that
									  >	has a parent is oftentimes referred to as a Sub-Project. 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.
The descendants of a Project are the Project itself and				The descendants of a Project are the Project itself and
transitive closure of its child Projects. The top parent of a			transitive closure of its child Projects. The top parent of a
Project is the Top-Level Project at the top of the hierarchy.			Project is the Top-Level Project at the top of the hierarchy.
Projects are the unit entity for:						Projects are the unit entity for:

Committers									Committers
Code and Releases								Code and Releases
IP Records									IP Records
Community Awareness								Community Awareness

As defined by the <a href=							As defined by the <a href=
"/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf#page=19">Ecl		"/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf#page=19">Ecl
Bylaws - Article VII, the Eclipse Management Organization			Bylaws - Article VII, the Eclipse Management Organization
(EMO) consists of the Foundation staff and the Councils. The term		(EMO) consists of the Foundation staff and the Councils. The term
EMO(ED), when discussing an approval process, refers to the			EMO(ED), when discussing an approval process, refers to the
subset of the EMO consisting of the Executive Director and whomever he		subset of the EMO consisting of the Executive Director and whomever he
or she may delegate that specific approval authority to.			or she may delegate that specific approval authority to.
4.1 Committers									4.1 Committers
An Operating Project has a self-managing set of Committers. The		  |
Committers of an Operating Project have the exclusive right to elect	  |	The previous version of this document
new Committers to their Project -- no other group, including a parent	  |	introduced a notion of a "union" of committers that was never fully
									  >	defined or utilized. That notion has been removed.
									  >	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.
									  >
									  >	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) into two or
									  >	more Sub-Projects.
									  >	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.				Project, can force a Project to accept a new Committer.
The set of Committers of a Container Project is the union of all the	  |	There is no roll-up of committers: the set of committers on a
Committers of the child Projects.					  |	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-projec
									  >	does not give you any automatic rights on the "parent" project).
									  >	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.
									  >
4.2 Code and Releases								4.2 Code and Releases
Each Operating Project owns and maintains a collection of source code	  |
and/or web pages.							  |	The previous version of this
Each Operating Project is the finest grained unit of infrastructure	  |	document restricted code ownership to the former notion of "Operating"
supplied by the Eclipse Foundation. Each Operating Project has a singl	  |	projects. With the generalization of projects, it is now possible for 
Unix group of its Committers that provides write-access to the		  |	project at any level in the hierarchy to have (or not have) code.
Project's files. Each Operating Project has a single bugzilla componen	  |	This version of the document clarifies that a project in the
for its bugs. ... The exact infrastructure provided by the Eclipse	  |	incubation phase may make pre-1.0 releases only.
Foundation varies over time and is defined outside this process		  |
document.								  |	Each Project owns and maintains a collection of resources.
While Operating Projects are the finest grained unit of			  |	Resources may include source code, a project website, space on the
infrastructure, there are no constraints on Projects self governing	  |	downloads server, access to build resources, and other services
themselves with finer-grained divisions on labor. For example, if	  |	provided by the Eclipse Foundation infrastructure. The exact
Project A wants to divide its code-based into two modules, A1 and A2,	  |	infrastructure provided by the Eclipse Foundation varies over time and
and have separate groups of its Committers work on each module, that's	  |	is defined outside this process document.
perfectly acceptable. However, if Project A wants to have fine-grained	  |	A project is not strictly required to make use of all the resources
access control for those two groups (i.e., separate unix groups), then	  |	made available; a project might, for example, opt to not
Project A will need to become a Container Project and create two new	  |	maintain a source code repository. Such a Project might operate as an
Sub-Projects, A.A1 and A.A2, as Operating Projects. That division will	  |	organizational unit, or container, for several Sub-Projects. Similarly
require a Creation+Move Review.						  |	a Project might opt to provide a consolidated website, build and/or
Container Projects do not have file infrastructure: no Unix group	  |	download site for its Sub-Projects (the Sub-Projects would then not
and no repository.							  |	require those resources for themselves).
									  >	Each Project has a single Bugzilla component for its bugs.
Any Project in the Mature Phase may make a Release. A Project			Any Project in the Mature Phase may make a Release. A Project
in the Incubation Phase with two Mentors may make a Release. A		  |	in the Incubation Phase with two Mentors may make a pre-1.0
Release may include the code from any subset of the Project's		  |	Release. A Release may include the code from any subset of the
descendants. However, if any code is included from an Operating		  |	Project's descendants.
Project, all the code from that Project must be included. In other	  <
words, an Operating Project is the level of granularity of code.	  <
4.3 IP Records									4.3 IP Records
A Project at any level may receive IP clearance for contributions and	  |	A Project at any level may receive IP clearance for contributions
third-party libraries. IP approval will often include the same approva	  |	and third-party libraries. IP approval will often include the same
for all descendant Projects. However, IP clearance will only be grante	  |	approval for all descendant Projects. However, IP clearance will only
at the most appropriate technical level thus only Operating Projects	  |	be granted at the most appropriate technical level.
should request IP clearance for contributions and Container Projects	  <
may request IP clearance for third-party libraries only if a majority	  <
of their descendants need that library.					  <
4.4 Community Awareness								4.4 Community Awareness
Projects are the level of communication with the larger Eclipse			Projects are the level of communication with the larger Eclipse
community and eco-system. Projects may either have their own		  |	community and ecosystem. Projects may either have their own
communications (website, mailing lists, newsgroups, etc) or they may b	  |	communications (website, mailing lists, forums/newsgroups, etc) or the
part of a parent Project's communications (website, mailing list,	  |	may be part of a parent Project's communications (website, mailing
newsgroups, etc). In either case, the Project is required to maintain	  |	list, forums/newsgroups, etc). In either case, the Project is required
an open and public communication channel with the Eclipse community	  |	to maintain an open and public communication channel with the Eclipse
including, but not limited to, project plans, schedules, design		  |	community including, but not limited to, project plans, schedules,
discussions, and so on.							  |	design discussions, and so on.
All Projects must make the communication channels easy to find.			All Projects must make the communication channels easy to find.
Container Projects are further required to make the separate		  |	Projects are further required to make the separate communication
communication channels of their child Projects (if any) easy to		  |	channels of their child Projects (if any) easy to find.
find.									  <
Any Project in the Incubation Phase must correctly identify its			Any Project in the Incubation Phase must correctly identify its
website and Releases. A Container Project with at least one descendant	  |	website and Releases. A Project with at least one descendant Project i
Project in Incubation Phase must correctly annotate its own website so	  |	Incubation Phase must correctly annotate its own website so as to
as to notify the Eclipse community that incubating Projects exist in	  |	notify the Eclipse community that incubating Projects exist in its
its hierarchy. Any Release containing code from an Incubation Phase	  |	hierarchy. Any Release containing code from an Incubation Phase projec
project must be correctly labeled, i.e., the Incubation Phase is viral	  |	must be correctly labeled, i.e., the Incubation Phase is viral and
and expands to cover all Releases in which it is included.		  |	expands to cover all Releases in which it is included.
4.5 Scope									4.5 Scope
Each Top-Level Project has a Charter which describes the			Each Top-Level Project has a Charter which describes the
purpose, Scope, and operational rules for the Top-Level Project.		purpose, Scope, and operational rules for the Top-Level Project.
The Charter should refer to, and describe any refinements to, the		The Charter should refer to, and describe any refinements to, the
provisions of this Development Process. The Board approves the Charter		provisions of this Development Process. The Board approves the Charter
of each Top-Level Project.							of each Top-Level Project.
Sub-Projects do not have separate Charters; Sub-Projects operate		Sub-Projects do not have separate Charters; Sub-Projects operate
under the Charter of their parent Top-Level Project.				under the Charter of their parent Top-Level Project.
All Projects have a defined Scope and all initiatives within			All Projects have a defined Scope and all initiatives within
that Project are required to reside within that Scope. Initiatives and		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		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 par		the termination of the Project. The Scope of Top-Level Projects is par
of the Charter, as approved by the Board of Directors of the Eclipse		of the Charter, as approved by the Board of Directors of the Eclipse
Foundation.									Foundation.
The Scope of a Sub-Project is defined by the initial project			The Scope of a Sub-Project is defined by the initial project
proposal as reviewed and approved by the Project Management			proposal as reviewed and approved by the Project Management
Committee (PMC) (as further defined below) of the Project's			Committee (PMC) (as further defined below) of the Project's
Project's top parent and by the EMO. A Project's Scope must be a subse		Project's top parent and by the EMO. A Project's Scope must be a subse
of its parent's Scope.								of its parent's Scope.
4.6 Leaders									4.6 Leaders
Top-Level Projects are managed by a Project Management Committee	  |
(PMC). Sub-Projects are managed by one or more Project			  |	The previous version of this document
Leaders. The PMC Lead(s) of a Top-Level Project are the Project		  |	used confusing language in an attempt to combine the discussion of PMC
Leader(s) of that project.						  |	and Project Leads. This version separates these discussions in an
PMC Leads are approved by the Board; PMC members and Project Leads	  |	attempt to make more explicit the process of bringing leaders on board
are approved by the EMO(ED). The initial Project Leadership is		  |	and the role that the two different types of leaders play. Sections
appointed and approved in the Creation Review. Subsequently, additiona	  |	4.6.1 and 4.6.2 are new with this version of the document.
Project Leadership (PMC members or Sub-Project Leaders) must be electe	  |	See <a href=
by the Project's Committers1 and the Board or EMO(ED) (for		  |	"https://bugs.eclipse.org/bugs/show_bug.cgi?id=300002">Bug 300002
PMC members and Sub-Project Leads respectively). In the unlikely event	  |	and Bug
that a member of the Project Leadership becomes disruptive to the	  |	300006.
process or ceases to contribute for an extended period, the member may	  |
be removed by (a) if there are at least two other Project Leaders, the	  |	There are two different types of Project leadership at Eclipse: The
unanimous vote of the remaining Project Leadership; or (b) unanimous	  |	Project Management Committee (PMC) and Project Leads. Both forms of
vote of the Project Leadership of the parent Project.			  |	leadership are required to:
1Until such time as the Foundation portal supports			  |
Project Leader elections, an election held on the Project's developer	  |	ensure that their Project is operating effectively by guiding the
mailing list will suffice.						  |	overall direction and by removing obstacles, solving problems, and
Each Project's leadership is required to:				  |	resolving conflicts;
									  <
ensure that the Project is operating effectively by guiding the		  <
Project's overall direction and by removing obstacles, solving		  <
problems, and resolving conflicts					  <
operate using open source rules of engagement: meritocracy,			operate using open source rules of engagement: meritocracy,
transparency, and open participation.					  |	transparency, and open participation; and
ensure that the projects and its sub-projects (if any) conform to	  |	ensure that the Project and its Sub-Projects (if any) conform to
the Eclipse Foundation IP Policy and procedures.			  |	the Eclipse Foundation IP Policy and Procedures.
									  |
In exceptional situations, such as Projects with zero active		  |	The leadership for a Project is composed of the Project's Project
Committers or Projects with disruptive Committers and no effective	  |	Lead(s), the leadership of the parent Project (if any) and the PMC
Project Leader(s), the Project Leadership Chain has the authority to	  |	Leads and PMC Members for the Top-Level Project.
make changes (add, remove) to the set of Committers and/or Project	  |	4.6.1 Project Management Committee
Lead(s) of that Project.						  |	(PMC)
									  >	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.
									  >	PMC Leads are approved by the Board; PMC members are elected by the
									  >	existing PMC Leads and Members, and approved by the EMO(ED).
									  >	4.6.2 Project Lead
									  >	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'
									  >	Committers and approved by the Project's PMC and the EMO(ED).
									  >	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 th
									  >	remaining Project Leads (if there are at least two other Project
									  >	Leads), or unanimous vote of the Project's PMC.
									  >	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.
4.7 Committers and								4.7 Committers and
Contributors									Contributors
Each Project has a Development Team, led by the Project Leaders.	  <
The Development Team is composed of Committers and			  <
Contributors. Contributors are individuals who contribute		  <
code, fixes, tests, documentation, or other work that is part of the	  <
Project. Committers have write access to the source code		  <
repository(ies) of the Project and are expected to influence the	  <
Project's development.							  <
									  <

									  >	The previous version
									  >	made specific references to the types of resources that a committer ha
									  >	write access to (code, web, and Bugzilla). In this version, the
									  >	discussion of the resources has been generalized.

									  >	Each Project has a Development Team, led by the Project
									  >	Leaders. The Development Team is composed of Committers and
									  >	Contributors. Contributors are individuals who contribute
									  >	code, fixes, tests, documentation, or other work that is part of the
									  >	Project. Committers 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.
See guidelines and								See guidelines and
checklists for electing a new committer.					checklists for electing a new committer.
									  <
									  <
									  <
Contributors who have the trust of the Project's Committers can,		Contributors who have the trust of the Project's Committers can,
through election, be promoted Committer for that Project. The breadth		through election, be promoted Committer for that Project. The breadth
of a Committer's influence corresponds to the breadth of their			of a Committer's influence corresponds to the breadth of their
contribution. A Development Team's Contributors and Committers may (an		contribution. A Development Team's Contributors and Committers may (an
should) come from a diverse set of organizations. A Committer has writ	  |	should) come from a diverse set of organizations. A Committer gains
access to the source code repository for the Project and/or website	  |	voting rights allowing them to affect the future of the Project.
and/or bug tracking system. A Committer gains voting rights allowing	  |	Becoming a Committer is a privilege that is earned by contributing and
them to affect the future of the Project. Becoming a Committer is a	  |	showing discipline and good judgment. It is a responsibility that
privilege that is earned by contributing and showing discipline and	  |	should be neither given nor taken lightly, nor is it a right based on
good judgment. It is a responsibility that should be neither given nor	  |	employment by an Eclipse Member company or any company employing
taken lightly, nor is it a right based on employment by an Eclipse	  |	existing committers.
Member company or any company employing existing committers.		  |	The election process begins with an existing Committer on the same
The election process for Committers uses the open and transparent	  |	Project nominating the Contributor. The Project's Committers will vote
portal election system. The election process begins with an existing	  |	for a period of no less than one week of standard business days. If
Committer on the same Project nominating the Contribtor. The Project's	  |	there are at least three (3) positive votes and no negative votes
Committers will vote for a period of no less than one week of standard	  |	within the voting period, the Contributor is recommended to the
business days. If there are at least three (3) positive votes and no	  |	project's PMC for commit privileges. If there are three (3) or fewer
negative votes within the voting period, the Contributor is recommende	  |	Committers on the Project, a unanimous positive vote of all Committers
to the root project's PMC for commit privileges. If there are three (3	  |	is substituted. If the PMC approves, and the Contributor signs the
or fewer Committers on the Project, a unanimous positive vote of all	  |	appropriate Committer legal agreements established by the EMO (wherein
Committers is substituted. If the PMC approves, and the Contributor	  |	at the very least, the Developer agrees to abide by the Eclipse
signs the appropriate Committer legal agreements established by the EM	  |	Intellectual Property Policy), the Contributor becomes a Committer and
(wherein, at the very least, the Developer agrees to abide by the	  |	is given write access to the source code for that Project.
Eclipse Intellectual Property Policy), the Contributor becomes a	  <
Committer and is given write access to the source code for that		  <
Project.								  <
At times, Committers may become inactive for a variety of reasons.		At times, Committers may become inactive for a variety of reasons.
The decision making process of the Project relies on active committers		The decision making process of the Project relies on active committers
who respond to discussions and vote in a constructive and timely		who respond to discussions and vote in a constructive and timely
manner. The Project Leaders are responsible for ensuring the smooth		manner. The Project Leaders are responsible for ensuring the smooth
operation of the Project. A Committer who is disruptive, does not		operation of the Project. A Committer who is disruptive, does not
participate actively, or has been inactive for an extended period may		participate actively, or has been inactive for an extended period may
have his or her commit status revoked by the Project Leaders. (Unless		have his or her commit status revoked by the Project Leaders. (Unless
otherwise specified, "an extended period" is defined as "no activity		otherwise specified, "an extended period" is defined as "no activity
for more than six months".)							for more than six months".)
Active participation in the user newsgroup and the appropriate		  |	Active participation in the user forums/newsgroups and the
developer mailing lists is a responsibility of all Committers, and is	  |	appropriate developer mailing lists is a responsibility of all
critical to the success of the Project. Committers are required to	  |	Committers, and is critical to the success of the Project. Committers
monitor and contribute to the user newsgroup.				  |	are required to monitor and contribute to the user
									  >	forums/newsgroups.
Committers are required to monitor the mailing lists associated with		Committers are required to monitor the mailing lists associated with
the Project. This is a condition of being granted commit rights to the		the Project. This is a condition of being granted commit rights to the
Project. It is mandatory because committers must participate in votes		Project. It is mandatory because committers must participate in votes
(which in some cases require a certain minimum number of votes) and		(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		must respond to the mailing list in a timely fashion in order to
facilitate the smooth operation of the Project. When a Committer is		facilitate the smooth operation of the Project. When a Committer is
granted commit rights they will be added to the appropriate mailing		granted commit rights they will be added to the appropriate mailing
lists. A Committer must not be unsubscribed from a developer mailing		lists. A Committer must not be unsubscribed from a developer mailing
list unless their associated commit privileges are also revoked.		list unless their associated commit privileges are also revoked.
Committers are required to track, participate in, and vote on,			Committers are required to track, participate in, and vote on,
relevant discussions in their associated Projects and components. Ther		relevant discussions in their associated Projects and components. Ther
are three voting responses: +1 (yes), -1 (no, or veto), and 0			are three voting responses: +1 (yes), -1 (no, or veto), and 0
(abstain).									(abstain).
Committers are responsible for proactively reporting problems in the		Committers are responsible for proactively reporting problems in the
bug tracking system, and annotating problem reports with status			bug tracking system, and annotating problem reports with status
information, explanations, clarifications, or requests for more			information, explanations, clarifications, or requests for more
information from the submitter. Committers are responsible for updatin		information from the submitter. Committers are responsible for updatin
problem reports when they have done work related to the problem.		problem reports when they have done work related to the problem.
Committer, PMC Lead, Project Lead, and Council Representative(s) are		Committer, PMC Lead, Project Lead, and Council Representative(s) are
roles; an individual may take on more than one of these roles			roles; an individual may take on more than one of these roles
simultaneously.									simultaneously.
4.8 Councils									4.8 Councils
The three Councils defined in Bylaws section VII are comprised of		The three Councils defined in Bylaws section VII are comprised of
Strategic members and PMC representatives. The three Councils help		Strategic members and PMC representatives. The three Councils help
guide the Projects as follows:							guide the Projects as follows:

The Requirements Council is primarily responsible for the			The Requirements Council is primarily responsible for the
Eclipse Roadmap. There will always be more requirements than there are		Eclipse Roadmap. There will always be more requirements than there are
resources to satisfy them, thus the Requirements Council gathers,		resources to satisfy them, thus the Requirements Council gathers,
reviews, and categorizes all of these incoming requirements - from the		reviews, and categorizes all of these incoming requirements - from the
entire Eclipse ecosystem - and proposes a coherent set of Themes and		entire Eclipse ecosystem - and proposes a coherent set of Themes and
Priorities.									Priorities.
The Planning Council is responsible for establishing a				The Planning Council is responsible for establishing a
coordinated Simultaneous Release (a.k.a, "the release train") that		coordinated Simultaneous Release (a.k.a, "the release train") that
supports the Themes and Priorities in the Roadmap. The Planning Counci		supports the Themes and Priorities in the Roadmap. The Planning Counci
is responsible for cross-project planning, architectural issues, user		is responsible for cross-project planning, architectural issues, user
interface conflicts, and all other coordination and integration issues		interface conflicts, and all other coordination and integration issues
The Planning Council discharges its responsibility via collaborative		The Planning Council discharges its responsibility via collaborative
evaluation, prioritization, and compromise.					evaluation, prioritization, and compromise.

									  |	See guidelines
									  |	and checklists for the Architecture Council.
									  <
See guidelines and							  <
checklists for the Architecture Council.				  <
									  <
									  <
									  <
The Architecture Council is responsible for the development,			The Architecture Council is responsible for the development,
articulation, and maintenance of the Eclipse Platform Architecture and		articulation, and maintenance of the Eclipse Platform Architecture and
ensuring the Principles of the Development Process through mentorship.		ensuring the Principles of the Development Process through mentorship.
Membership in the Architecture Council is per the Bylaws through		Membership in the Architecture Council is per the Bylaws through
Strategic Membership, PMCs, and by appointment. The Architecture		Strategic Membership, PMCs, and by appointment. The Architecture
Council will, at least annually, recommend to the EMO(ED), Eclipse		Council will, at least annually, recommend to the EMO(ED), Eclipse
Members who have sufficient experience, wisdom, and time to be			Members who have sufficient experience, wisdom, and time to be
appointed to the Architecture Council and serve as Mentors. Election a		appointed to the Architecture Council and serve as Mentors. Election a
a Mentor is a highly visible confirmation of the Eclipse community's		a Mentor is a highly visible confirmation of the Eclipse community's
respect for the candidate's technical vision, good judgement, software		respect for the candidate's technical vision, good judgement, software
development skills, past and future contributions to Eclipse. It is a		development skills, past and future contributions to Eclipse. It is a
role that should be neither given nor taken lightly. Appointed members		role that should be neither given nor taken lightly. Appointed members
of the Architecture Council are appointed to two year renewable			of the Architecture Council are appointed to two year renewable
terms.										terms.

									  >	4.9 Incubator Projects
									  >
									  >	This version of this document formalizes the notion of an
									  >	"Incubator" project. The original draft of this document attempted to
									  >	restrict the number and structure of incubators, but the language was
									  >	removed to allow for future flexibility. A project may have more than
									  >	one incubator; an incubator project may itself have an incubator
									  >	sub-project. Creating multiple incubators is expected to be atypical;
									  >	attempts to create multiple incubators will be challenged by the PMC
									  >	and EMO.
									  >	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 d
									  >	not require mentors.
									  >
									  >	A Project may designate a Sub-Project as an "Incubator". An
									  >	Incubator is a Project that is intended to perpetually remain in the
									  >	Incubation 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.
									  >	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 standar
									  >	incubation branding requirements and are subject to the IP due
									  >	diligence rules outlined for incubating Projects. Incubators do not
									  >	graduate.
									  >	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).
									  >	An Incubator project should designated as such by including the word
									  >	"Incubator" in its name (e.g. "Eclipse Incubator"). To do otherwise is
									  >	considered exceptional and requires approval from the PMC and
									  >	EMO(ED).
									  >	Only Top-Level Projects and Projects in the <a href=
									  >	"#6_2_4_Mature">Mature phase may create an Incubator. Incubators
									  >	are created via a Creation Review.
									  >	Alternatively, an Incubator can be created as part of a <a href=
									  >	"#6_3_2_Graduation_Review">Graduation, <a href=
									  >	"#6_3_4_Promotion_Review">Promotion, or <a href=
									  >	"#6_3_8_Restructuring_Review">Restructuring Review.
5. Roadmap Process								5. Roadmap Process
The Roadmap describes the collective Eclipse Projects future direction	  |
and consists of two parts:						  |	This section has been modified to explicitly state that project may
									  >	opt to aggregate their plan with that of descendant projects.
									  >
									  >	The Roadmap describes the collective Eclipse Projects future
									  >	directions and consists of two parts:

Themes and Priorities from the Requirements Council				Themes and Priorities from the Requirements Council
Project Plans from Projects							Project Plans from Projects

The Roadmap must be consistent with the Purposes as described in Bylaw	  |	The Roadmap must be consistent with the Purposes as described in
section 1.1. It is developed using the prescribed <a href=		  |	Bylaws section 1.1. It is developed using the prescribed <a href=
"/org/councils/roadmap_v2_0/index.php#process">roadmap process.			"/org/councils/roadmap_v2_0/index.php#process">roadmap process.
The Roadmap is prepared by the Councils and approved by the Board		The Roadmap is prepared by the Councils and approved by the Board
annually. A proposed Roadmap or Roadmap update is disseminated to the		annually. A proposed Roadmap or Roadmap update is disseminated to the
Membership at Large for comment and feedback in advance of its			Membership at Large for comment and feedback in advance of its
adoption. This dissemination and all discussion and debate around the		adoption. This dissemination and all discussion and debate around the
Roadmap must be held in an open and transparent public forum, such as		Roadmap must be held in an open and transparent public forum, such as
mailing lists or newsgroups.							mailing lists or newsgroups.
Prior to any Board vote to approve a Roadmap or Roadmap update,			Prior to any Board vote to approve a Roadmap or Roadmap update,
every Member has the right to communicate concerns and objections to		every Member has the right to communicate concerns and objections to
the Board.									the Board.
The process of producing or updating the Roadmap is expected to be		The process of producing or updating the Roadmap is expected to be
iterative. An initial set of Themes and Priorities may be infeasible t		iterative. An initial set of Themes and Priorities may be infeasible t
implement in the desired timeframe; subsequent consideration may revea		implement in the desired timeframe; subsequent consideration may revea
new implementation alternatives or critical requirements that alter th		new implementation alternatives or critical requirements that alter th
team's perspective on priorities. The EMO orchestrates interaction		team's perspective on priorities. The EMO orchestrates interaction
among and within the Councils to drive the Roadmap to convergence.		among and within the Councils to drive the Roadmap to convergence.
This Development Process, the EMO, the Councils, and the Projects		This Development Process, the EMO, the Councils, and the Projects
all acknowledge that the success of the Eclipse ecosystem is dependent		all acknowledge that the success of the Eclipse ecosystem is dependent
on a balanced set of requirements and implementations. A Roadmap that		on a balanced set of requirements and implementations. A Roadmap that
provides too large a burden on the Projects will be rejected and		provides too large a burden on the Projects will be rejected and
ignored; similarly, a Roadmap that provides no predictable Project		ignored; similarly, a Roadmap that provides no predictable Project
plans will be unhelpful to the business and technical plans being		plans will be unhelpful to the business and technical plans being
created by the ecosystem. A careful balance of demands and commitments		created by the ecosystem. A careful balance of demands and commitments
is essential to the ongoing success of the Eclipse Projects,			is essential to the ongoing success of the Eclipse Projects,
frameworks, and ecosystem.							frameworks, and ecosystem.
The Project Leadership is expected to ensure that their Project			The Project Leadership is expected to ensure that their Project
Plans are consistent with the Roadmap, and that all plans, technical		Plans are consistent with the Roadmap, and that all plans, technical
documents and reports are publicly available. To meet this requirement		documents and reports are publicly available. To meet this requirement
each Project is required to create a transparently available Project		each Project is required to create a transparently available Project
Plan in an EMO-defined file format that meets the following			Plan in an EMO-defined file format that meets the following
criteria:									criteria:

Enumerates the areas of change in the frameworks and tools for each		Enumerates the areas of change in the frameworks and tools for each
proposed Release								proposed Release
Consistent with and categorized in terms of the themes and			Consistent with and categorized in terms of the themes and
priorities of the Roadmap							priorities of the Roadmap
Identifies and accommodates cross-project dependencies				Identifies and accommodates cross-project dependencies
Addresses requirements critical to the Ecosystem and/or the			Addresses requirements critical to the Ecosystem and/or the
Membership at Large								Membership at Large
Advances the Project in functionality, quality, and				Advances the Project in functionality, quality, and
performance									performance

A Project may incrementally revise their Project Plan to deliver		A Project may incrementally revise their Project Plan to deliver
additional tasks provided that:							additional tasks provided that:

the approved Roadmap is not put in jeopardy; and				the approved Roadmap is not put in jeopardy; and
the work is consistent with the Project Plan criteria (as described		the work is consistent with the Project Plan criteria (as described
above)										above)

									  >	A project may produce an aggregate plan for itself and its
									  >	descendants. In this case descendents would share their ancestor's
									  >	plan.
6. Development Process								6. Development Process
All Eclipse Projects, and hence all Project Proposals, must be			All Eclipse Projects, and hence all Project Proposals, must be
consistent with the Purposes and the then-current Roadmap.			consistent with the Purposes and the then-current Roadmap.
Projects must work within their Scope. Projects that desire to			Projects must work within their Scope. Projects that desire to
expand beyond their current Scope must seek an enlargement of their		expand beyond their current Scope must seek an enlargement of their
Scope using a public Review as described below.					Scope using a public Review as described below.
All projects are required to report their status at least quarterly		All projects are required to report their status at least quarterly
using the <a href=								using the <a href=
"/projects/dev_process/project-status-infrastructure.php">EMO defined		"/projects/dev_process/project-status-infrastructure.php">EMO defined
status reporting procedures.							status reporting procedures.
Projects must provide advanced notification of upcoming features and		Projects must provide advanced notification of upcoming features and
frameworks via their Project Plan.						frameworks via their Project Plan.
6.1 Mentors									6.1 Mentors
New Proposals that intend to do a Release are required to have at leas	  |	New Proposals that intend to do a Release are required to have at
two Mentors. New Proposals that will only Release code as part		  |	least two Mentors. New Proposals that will only Release code as
of a parent Project's Release are not required to have Mentors. Mentor	  |	part of a parent Project's Release are not required to have Mentors.
must be members of the Architecture Council. The Mentors (including	  |	Mentors must be members of the Architecture Council. The Mentors
name, affiliation, and current Eclipse projects/roles) must be listed	  |	(including name, affiliation, and current Eclipse projects/roles) must
in the Proposal. Mentors are required to monitor and advise the new	  |	be listed in the Proposal. Mentors are required to monitor and advise
Project during its Incubation Phase, but are released from that duty	  |	the new Project during its Incubation Phase, but are released from tha
once the Project graduates to the Mature Phase.				  |	duty once the Project graduates to the Mature Phase.
The Mentors must attend the Creation and Graduation Reviews.		  <
6.2 Project Lifecycle								6.2 Project Lifecycle
<img src="/projects/images/Development-process-small.gif" align=		<img src="/projects/images/Development-process-small.gif" align=
"right"> Projects go through six distinct phases. The transitions from	  |	"right">
phase to phase are open and transparent public reviews.			  |	Projects go through six distinct phases. The transitions from phase
									  >	to phase are open and transparent public reviews.
6.2.1 Pre-proposal								6.2.1 Pre-proposal
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about writing a proposal.						checklists about writing a proposal.
									  |	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.
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.				  <

The Pre-proposal phase ends when the Proposal is published by EMO		The Pre-proposal phase ends when the Proposal is published by EMO
and announced to the membership by the EMO.					and announced to the membership by the EMO.

6.2.2 Proposal									6.2.2 Proposal
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about gathering support for a proposal.				checklists about gathering support for a proposal.
									  <
									  <
									  <
The proposers, in conjunction with the destination PMC and the			The proposers, in conjunction with the destination PMC and the
community, collaborate in public to enhance, refine, and clarify the		community, collaborate in public to enhance, refine, and clarify the
proposal. Mentors (if necessary) for the project must be identified		proposal. Mentors (if necessary) for the project must be identified
during this phase.								during this phase.

The Proposal phase ends with a Creation Review or a Termination		  |	The Proposal phase ends with a <a href=
Review.									  |	"#6_3_1_Creation_Review">Creation Review, or withdrawal.
									  >	The Proposal may be withdrawn by the proposers.
									  >	The EMO(ED) will withdraw a proposal that has been inactive for
									  >	more than six months.

6.2.3 Incubation								6.2.3 Incubation
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about incubation.							checklists about incubation.
									  |	After the project has been created, the purpose of the incubation
									  |	phase is to establish a fully-functioning open-source project. In this
									  <
After the project has been created, the purpose of the incubation phas	  <
is to establish a fully-functioning open-source project. In this	  <
context, incubation is about developing the process, the community, an		context, incubation is about developing the process, the community, an
the technology. Incubation is a phase rather than a place: new project		the technology. Incubation is a phase rather than a place: new project
may be incubated under any existing Project.					may be incubated under any existing Project.

The Incubation phase may continue with a Continuation Review or a		The Incubation phase may continue with a Continuation Review or a
Release Review.									Release Review.
Top-Level Projects cannot be incubated and can only be created from		Top-Level Projects cannot be incubated and can only be created from
one or more existing Mature-phase Projects.					one or more existing Mature-phase Projects.
The Incubation phase ends with a Graduation Review or a Termination		The Incubation phase ends with a Graduation Review or a Termination
Review.										Review.
									  >	Designated Incubator Projects may
									  >	remain perpetually in the Incubation phase; no reviews are
									  >	required.

Many Eclipse Projects are proposed and initiated by individuals with		Many Eclipse Projects are proposed and initiated by individuals with
extensive and successful software development experience. This documen		extensive and successful software development experience. This documen
attempts to define a process that is sufficiently flexible to learn		attempts to define a process that is sufficiently flexible to learn
from all its participants. At the same time, however, the Incubation		from all its participants. At the same time, however, the Incubation
phase is useful for new Projects to learn the community-defined			phase is useful for new Projects to learn the community-defined
Eclipse-centric open source processes.						Eclipse-centric open source processes.
									  |	See guidelines
									  |	and checklists for utilizing the Parallel IP process.
									  |	Only projects that are properly identified as being in the
See guidelines and							  |	incubation phase (including designated <a href=
checklists for utilizing the Parallel IP process.			  |	"#4_9_Incubators">Incubator Projects) may use the Parallel IP
									  |	process to reduce IP clearance process for new contributions.
									  <
									  <
Only projects that are properly identified as being in the incubation	  <
phase may use the Parallel IP process to reduce IP clearance process	  <
for new contributions.							  <
6.2.4 Mature									6.2.4 Mature
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about the mature phase.						checklists about the mature phase.
									  |	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 
The project team has demonstrated that they are an open-source project	  |	mature member of the Eclipse Community. Major releases continue to go
with an open and transparent process; an actively involved and growing	  |	through Release Reviews.
community; and Eclipse Quality technology. The project is now a mature	  <
member of the Eclipse Community. Major releases continue to go through	  <
Release Reviews.							  <

Mature phase projects have Releases through Release Reviews.			Mature phase projects have Releases through Release Reviews.
A Mature Project may be promoted to a Top-Level Project through a		A Mature Project may be promoted to a Top-Level Project through a
Promotion Review.								Promotion Review.
A Mature Project that does not participate in a Release in given		A Mature Project that does not participate in a Release in given
year may continue through a Continuation Review.				year may continue through a Continuation Review.
Inactive Mature phase projects may be archived through a			Inactive Mature phase projects may be archived through a
Termination Review.								Termination Review.

6.2.5 Top-Level									6.2.5 Top-Level
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about being a top-level project.					checklists about being a top-level project.
									  <
									  <
									  <
Projects that have demonstrated the characteristics of a Top-Level		Projects that have demonstrated the characteristics of a Top-Level
Project (e.g., consistent leadership in a technical area and the		Project (e.g., consistent leadership in a technical area and the
recruitment of a wider developer community) can be promoted to			recruitment of a wider developer community) can be promoted to
Top-Level Project status. This promotion occurs through a Promotion		Top-Level Project status. This promotion occurs through a Promotion
Review. Upon the successful completion of a Promotion Review, the		Review. Upon the successful completion of a Promotion Review, the
EMO(ED) may recommend that the project be promoted to the Board of		EMO(ED) may recommend that the project be promoted to the Board of
Directors and ask that its Charter be reviewed and approved.			Directors and ask that its Charter be reviewed and approved.
6.2.6 Archived									6.2.6 Archived
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists for archiving projects.						checklists for archiving projects.
									  |	Projects that become inactive, either through dwindling resources or
									  |	by reaching their natural conclusion, are archived. Projects can reach
									  <
Projects that become inactive, either through dwindling resources or b	  <
reaching their natural conclusion, are archived. Projects can reach	  <
their natural conclusion in a number of ways: for example, a project		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 majo		might become so popular that it is absorbed into one of the other majo
frameworks. Projects are moved to Archived status through a Terminatio		frameworks. Projects are moved to Archived status through a Terminatio
Review.										Review.
If there is sufficient community interest in reactivating an			If there is sufficient community interest in reactivating an
Archived Project, the Project will start again with Creation Review. A		Archived Project, the Project will start again with Creation Review. A
there must be good reasons to have moved a Project to the Archives, th		there must be good reasons to have moved a Project to the Archives, th
Creation Review provides a sufficiently high bar to prove that those		Creation Review provides a sufficiently high bar to prove that those
reasons are no longer valid. It also ensures that the original or		reasons are no longer valid. It also ensures that the original or
updated project goals are still consistent with the Purposes and		updated project goals are still consistent with the Purposes and
Roadmap.									Roadmap.
6.3 Reviews									6.3 Reviews
The Eclipse Development Process is predicated on open and transparent	  |
behavior. All major changes to Eclipse projects must be announced and	  |	This iteration of the document removes the notion of a "review call"
reviewed by the membership-at-large. Major changes include the Project	  |	in favour of a "review period" during which the community is given an
Phase transitions as well as the introduction or exclusion of		  |	opportunity to comment. This acknowledges the reality that the optiona
significant new technology or capability. It is a clear requirement of	  |	review calls required by the previous
this document that members who are monitoring the appropriate media	  |	version of this document never actually occurred. Given
channels (e.g., mailing lists or RSS feeds) not be surprised by the	  |	that there will be no review calls, references to "slides" have been
post-facto actions of the Projects.					  |	removed.
									  >	See <a href=
									  >	"https://bugs.eclipse.org/bugs/show_bug.cgi?id=304878">Bug
									  >	304878.
									  >
									  >	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.
All Projects are required to participate in at least one Review per		All Projects are required to participate in at least one Review per
year.										year.
For each Review, the project leadership makes a presentation			For each Review, the project leadership makes a presentation
to, and receives feedback from, the Eclipse membership.				to, and receives feedback from, the Eclipse membership.
A Review is a fairly comprehensive process. Gathering the material		A Review is a fairly comprehensive process. Gathering the material
for a Review and preparing the presentation is a non-trivial effort,		for a Review and preparing the presentation is a non-trivial effort,
but the introspection offered by this exercise is useful for the		but the introspection offered by this exercise is useful for the
Project and results are very useful for the entire Eclipse community.		Project and results are very useful for the entire Eclipse community.
In addition, Reviews have a specific relationship to the requirements		In addition, Reviews have a specific relationship to the requirements
of the Eclipse IP								of the Eclipse IP
Policy.										Policy.
All Reviews have the same general process:					All Reviews have the same general process:

Projects are responsible for initiating the appropriate reviews.		Projects are responsible for initiating the appropriate reviews.
However, if a Project does not do so and the EMO believes a Review is		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. The	  |	necessary, the EMO may initiate a Review on the Project's behalf.
Project Leader initiates a review through the portal.2			  <
A Review then continues with the Project's Leadership requesting		A Review then continues with the Project's Leadership requesting
that the EMO(ED) schedule the Review.						that the EMO(ED) schedule the Review.
No less than one week in advance of the Review conference call, and	  |	Prior to the start of the review period, the Project leadership
preferably at least two weeks in advance, the Project leadership	  |	provides the EMO with review documentation.
provides the EMO with the archival presentation material.		  |
									  |	The review documentation material always includes a document that
The presentation material always includes a summary slide		  |	describes the review. The minimum contents of the document are
presentation or document. The minimum contents of the presentation are	  |	specified by the individual Review types.
proscribed by the individual Review types.				  <
The presentation material must be available in a format that anyone		The presentation material must be available in a format that anyone
in the Eclipse membership can review. For example, Microsoft Powerpoin		in the Eclipse membership can review. For example, Microsoft Powerpoin
files are not an acceptable single format - such files may be one of	  |	files are not an acceptable single format: such files may be one of th
the formats, but not the only format. Similarly for Apple Keynote file	  |	formats, but not the only format. Similarly for Apple Keynote files an
and Microsoft Word files. PDF and HTML are acceptable single		  |	Microsoft Word files. PDF and HTML are acceptable single formats.
formats.								  <
The presentation material must have a correct copyright statement		The presentation material must have a correct copyright statement
and license.									and license.
The presentation material must be archival quality. This			The presentation material must be archival quality. This
means that the materials must be comprehensible and complete on their		means that the materials must be comprehensible and complete on their
own without requiring explanation by a human presenter, reference to a		own without requiring explanation by a human presenter, reference to a
wiki, or to other non-archived web pages.					wiki, or to other non-archived web pages.


The EMO announces the Review schedule and makes the presentation	  |	The EMO announces the Review schedule and makes the documentation
materials available to the membership-at-large.				  |	available to the membership-at-large.

The criteria for the successful completion of each type of Review will	  |	The criteria for the successful completion of each type of Review
be documented in writing by the EMO in guidelines made available via	  |	will be documented in writing by the EMO in guidelines made available
the www.eclipse.org website. Such guidelines will include, but are not	  |	via the www.eclipse.org website. Such guidelines will include, but are
limited to the following:						  |	not limited to the following:

Clear evidence that the project has vibrant committer, adopter and		Clear evidence that the project has vibrant committer, adopter and
user communities as appropriate for the type of Review.				user communities as appropriate for the type of Review.
Reasonable diversity in its committer population as appropriate for		Reasonable diversity in its committer population as appropriate for
the type of Review. Diversity status must be provided not only as		the type of Review. Diversity status must be provided not only as
number of people/companies, but also in terms of effort provided by		number of people/companies, but also in terms of effort provided by
those people/companies.								those people/companies.
Documented completion of all required due diligence under the			Documented completion of all required due diligence under the
Eclipse IP									Eclipse IP
Policy.										Policy.
For Continuation, Graduation and Release Reviews, the project must		For Continuation, Graduation and Release Reviews, the project must
have a current project plan, in the format specified by the EMO,		have a current project plan, in the format specified by the EMO,
available to the community.							available to the community.
Balanced progress in creating both frameworks and extensible,			Balanced progress in creating both frameworks and extensible,
exemplary tools.								exemplary tools.
Showcase the project's quality through project-team chosen metrics		Showcase the project's quality through project-team chosen metrics
and measures, e.g., coupling, cyclomatic complexity, test/code			and measures, e.g., coupling, cyclomatic complexity, test/code
coverage, documentation of extensions points, etc.				coverage, documentation of extensions points, etc.

2Until such time as the Foundation portal supports			  |	The Review period is open for no less than one week and usually no
initiating Reviews, email to the <a href=				  |	more than two weeks of generally accepted business days.
"mailto:emo@eclipse.org">EMO will suffice.				  |
The Review itself:							  <
									  <
The Review is open for no less than one week and usually no more	  <
than two weeks of generally accepted business days. This is the		  <
Review period.								  <
The Review begins with the EMO's posting of the review materials at		The Review begins with the EMO's posting of the review materials at
the start of the Review period, and ends with either the end of the	  |	the start of the Review period
Review period or (see below) an optional conference call or other	  <
conference technology (e.g., web conferencing) so long as the		  <
technology is available to all members and incurs no additional costs	  <
to the attendees.							  <
The proper functioning of the Eclipse Development Process is			The proper functioning of the Eclipse Development Process is
contingent on the active participation of the Eclipse Members and		contingent on the active participation of the Eclipse Members and
Committers, especially in Reviews, thus each Review has an			Committers, especially in Reviews, thus each Review has an
EMO-designated discussion and feedback communication channel: a			EMO-designated discussion and feedback communication channel: a
newgroup, a mailing list, or some other public forum.			  |	forum/newgroup, a mailing list, or some other public forum.
If a Committer election is required for a Review (for example, for		If a Committer election is required for a Review (for example, for
a Move Review), then it is held simultaneously with the Review period.	  |	a Creation Review), then it is
Thus the election and the Review will end at the same time, allowing	  |	held simultaneously with the Review period. Thus the election and the
quick and efficient provisioning of the resulting Project.		  |	Review will end at the same time, allowing quick and efficient
Simultaneously with the opening of the Review, a date and time for	  |	provisioning of the resulting Project.
the optional conference call is announced. The call date shall be no	  <
less than the next day and no more than one week of standard business	  <
days after the last day of the Review. (For example, if the Review run	  <
from Wednesday the 4th through Tuesday the 10th, the call may be	  <
previously scheduled for any time from Wednesday the 11th through	  <
Wednesday the 18th.)							  <
The default is that the optional conference call not be held. However,	  <
during the Review period, any Eclipse Member with voting rights may	  <
request, via the Review's public communication channel, that the	  <
conference call be held. If any such requests exist at the end of the	  <
Review period, the conference call is held at its previously scheduled	  <
date and time.								  <
During the conference call, the Project Leadership (or EMO		  <
appointed Project representative) provides a brief summary of the	  <
reasons and justifications for the phase transition followed by a	  <
question and answer session.						  <
The EMO(ED) approves or fails the Review based on the public			The EMO(ED) approves or fails the Review based on the public
comments, the scope of the Project, and the Purposes of the Eclipse		comments, the scope of the Project, and the Purposes of the Eclipse
Foundation as defined in the Bylaws. The EMO(ED) announces the result	  |	Foundation as defined in the Bylaws.
in the defined Review communication channel.				  |	The Review ends with the announcement of the results in the defined
									  >	Review communication channel (the EMO(ED) will request that the Projec
									  >	Lead make this announcement).

If any Member believes that the EMO has acted incorrectly in			If any Member believes that the EMO has acted incorrectly in
approving or failing a Review may appeal to the Board to review the		approving or failing a Review may appeal to the Board to review the
EMO's decision.									EMO's decision.
6.3.1 Creation Review								6.3.1 Creation Review
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about Creation Reviews.						checklists about Creation Reviews.
									  <
									  <
									  <
The purpose of the Creation Review is to assess the community and		The purpose of the Creation Review is to assess the community and
membership response to the proposal, to verify that appropriate			membership response to the proposal, to verify that appropriate
resources are available for the project to achieve its plan, and to		resources are available for the project to achieve its plan, and to
serve as a committer election for the project's initial Committers. Th		serve as a committer election for the project's initial Committers. Th
Eclipse Foundation strives not to be a repository of ''code dumps'' an	  |	Eclipse Foundation strives not to be a repository of "code dumps" and
thus projects must be sufficiently staffed for forward progress.		thus projects must be sufficiently staffed for forward progress.
The Creation Review archival documents must include short nomination	  |	The Creation Review documents must include short nomination bios of
bios of the proposed initial committers. These bios should discuss	  |	the proposed initial committers. These bios should discuss their
their relationship to, and history with, the incoming code and/or thei	  |	relationship to, and history with, the incoming code and/or their
involvement with the area/technologies covered by the proposal. The		involvement with the area/technologies covered by the proposal. The
goal is to help keep any legacy contributors connected to new project		goal is to help keep any legacy contributors connected to new project
and explain that connection to the current and future Eclipse			and explain that connection to the current and future Eclipse
membership, as well as justify the initial Committers' participation i		membership, as well as justify the initial Committers' participation i
a meritocracy. (See [<a href=						  |	a meritocracy.
"http://mail-archives.apache.org/mod_mbox/incubator-general/200610.mbo	  <
6.3.2 Graduation Review								6.3.2 Graduation Review
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about Graduation Reviews.						checklists about Graduation Reviews.
									  <
									  <
									  <
The purpose of the Graduation Review is to confirm that the Project		The purpose of the Graduation Review is to confirm that the Project
is/has:										is/has:

a working and demonstratable code base of sufficiently high		  |	a working and demonstrable code base of sufficiently high
quality										quality
active and sufficiently diverse communities appropriate to the size		active and sufficiently diverse communities appropriate to the size
of the graduating code base: adopters, developers, and users			of the graduating code base: adopters, developers, and users
operating fully in the open following the Principles and Purposes		operating fully in the open following the Principles and Purposes
of Eclipse									of Eclipse
a credit to Eclipse and is functioning well within the larger			a credit to Eclipse and is functioning well within the larger
Eclipse community								Eclipse community

The Graduation Review is about the phase change from Incubation Phase	  |	The Graduation Review is about the phase change from Incubation
to Mature Phase. If the Project and/or some of its code is		  |	Phase to Mature Phase. If the Project and/or some of its code is
simultaneously relocating to another Project, the Graduation Review		simultaneously relocating to another Project, the Graduation Review
will be combined with a Move Review.					  |	will be combined with a <a href=
									  >	"#6_3_8_Restructuring_Review">Restructuring Review.
6.3.3 Release Review								6.3.3 Release Review
									  <
									  <
									  <
See guidelines and								See guidelines and
checklists about Release Reviews.						checklists about Release Reviews.
									  |	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
The purposes of a Release Review are: to summarize the accomplishments	  |	remaining quality and/or architectural issues, and to verify that the
of the release, to verify that the IP Policy has been followed and all	  |	project is continuing to operate according to the Principles and
approvals have been received, to highlight any remaining quality and/o	  |	Purposes of Eclipse.
architectural issues, and to verify that the project is continuing to	  <
operate according to the Princples and Purposes of Eclipse.		  <
6.3.4 Promotion Review								6.3.4 Promotion Review
The purpose of a Promotion Review is to determine if the Project has		The purpose of a Promotion Review is to determine if the Project has
demonstrated the characteristics of a Top-Level Project, e.g.,			demonstrated the characteristics of a Top-Level Project, e.g.,
consistent leadership in a technical area and the recruitment of a		consistent leadership in a technical area and the recruitment of a
wider developer community. The Project will already be a			wider developer community. The Project will already be a
well-functioning Mature Eclipse Project, so evidence to the contrary		well-functioning Mature Eclipse Project, so evidence to the contrary
will be a negative for promotion. Top-Level Projects, both through		will be a negative for promotion. Top-Level Projects, both through
their existance and their Council memberships, have substantial		  |	their existence and their Council memberships, have substantial
influence over direction and operation of Eclipse, thus it behooves th		influence over direction and operation of Eclipse, thus it behooves th
membership to grant Top-Level status only for merit: for demonstrated		membership to grant Top-Level status only for merit: for demonstrated
service to the larger Eclipse eco-system.				  |	service to the larger Eclipse ecosystem.
6.3.5 Continuation								6.3.5 Continuation
Review										Review
The purpose of a Continuation Review is to verify that a Proposal or		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 continues to be a viable effort and a credit to Eclipse. The
Project team will be expected to explain the recent technical progress		Project team will be expected to explain the recent technical progress
and to demonstrate sufficient adopter, developer, and user support for		and to demonstrate sufficient adopter, developer, and user support for
the Project. The goal of the Continuation Review is to avoid having		the Project. The goal of the Continuation Review is to avoid having
inactive projects looking promising but never actually delivering		inactive projects looking promising but never actually delivering
extensible frameworks and exemplary tools to the ecosystem.			extensible frameworks and exemplary tools to the ecosystem.
6.3.6 Termination								6.3.6 Termination
Review										Review
									  <
									  <
									  <
See <a href=									See <a href=
"http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Informatio		"http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Informatio
Termination Review "How To" for more information.				Termination Review "How To" for more information.
									  |	The purpose of a Termination Review is to provide a final
									  |	opportunity for the Committers and/or Eclipse membership to discuss th
									  |	proposed withdrawal of a Proposal or archiving of a Project. The
The purpose of a Termination Review is to provide a final opportunity	  |	desired outcome is to find sufficient evidence of renewed interest and
for the Committers and/or Eclipse membership to discuss the proposed	  |	resources in keeping the Project or Proposal active.
withdrawl 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.					  <
6.3.7 Move Review								6.3.7 Move Review
									  |	A Move Review is considered to be a special type of <a href=
									  |	"#6_3_8_Restructuring_Review">Restructuring Review.
									  <
See <a href=								  <
"http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Informatio	  <
Move Review "How To" for more information about Move Reviews.		  <
									  <
									  <
									  <
The purpose of a Move Review is to verify that there are no IP Legal	  <
impediments to the proposed move of code from one Project to another	  <
Project, and to act as an election (if necessary) for the Committers	  <
who are being added to the new Project.					  <
There are four Move Review cases:					  <
									  <
A subset of code is moving out of one Project (A) and into another	  <
Project (B). -- Project B's Committers may not have new committers	  <
imposed upon them, thus project B's Committers must elect (the subset	  <
of) Project A's Committers who are moving with the code to Project	  <
B.3									  <
An entire Project's (A) code is moving into another Project (B) and	  <
Project A is being terminated. -- Same as above: Project B's Committer	  <
must elect Project A's Committers to committer status on Project	  <
B.									  <
An entire Project (A) is moving from one parent Project (P) to		  <
another parent Project (Q). -- No Committers are changing Operating	  <
Projects, thus no elections are necessary.				  <
Code is moving out of one Project (A) and starting a new Project	  <
(C). -- This is a Creation Review, not a Move Review. Project C		  <
committers will be defined by the Creation Review.			  <
									  <
3Until such time as the Foundation portal supports			  <
Committer election-style voting for Move Reviews, an election held on	  <
the destination Project's developer mailing list will suffice.		  <
6.3.8 Restructuring								6.3.8 Restructuring
Review										Review
The purpose of a Restructuring Review is to verify that there are no I	  |
Legal impediments to the proposed restructuring, and to allow the	  |	This iteration of the document provides more detail on Restructuring
community a chance to comment on that restructuring. Restructuring may	  |	Reviews. It also considers a Move Review (as defined by the <a href=
involve splitting an existing Project into multiple Projects (typicall	  |	"#6_3_7_Move_Review">previous version of this document) to be a
one Operating Project into a Container Project with multiple new	  |	special type of a Restructuring Review.
Operating Sub-Projects) and/or combining existing Projects into fewer	  |	This version of the document makes explicit a loophole that permits
Projects (typically multiple Operating Projects into a single Operatin	  |	the creation of new projects without engaging in the full
Project).								  |	proposal/creation process. This applies only to new project with a
If a Restructuring Review involves combining two or more Committer	  |	scope that is a subset of the original project's scope. There is no
populations, each Committer population must elect the			  |	explicit requirement that a project become a parent to the new
other3, in order to explicitly maintain the principle of not		  |	projects. New projects can be created as siblings or elsewhere in the
allowing any Committer population to have new Committers imposed there	  |	project hierarchy. In the event that a restructuring review results in
upon.									  |	unrelated projects, it is expected that the scope of the original
									  >	project will be adjusted accordingly.
									  >
									  >	The purpose of a Restructuring Review is to notify the community of
									  >	your intent to make significant changes to one or more projects.
									  >	"Significant changes" includes:
									  >
									  >	Movement of significant chunks of functionality from one project to
									  >	another;
									  >	Modification of the project structure, e.g. combining multiple
									  >	projects into a single project, or decomposing a single project into
									  >	multiple projects; and/or
									  >	Change of project scope.
									  >
									  >	A Restructuring Review may include the movement of significant
									  >	chunks of code. A move is considered significant if it has an impact o
									  >	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.
									  >	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 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 committer
									  >	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.
									  >	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.
									  >	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.
									  >	This may include:
									  >
									  >	Name, description, scope, and committer lists of new projects that
									  >	need to be created;
									  >	Source and target locations for moves of source code
									  >	directories;
									  >	Reorganization of builds and downloads;
									  >	Contribution questionnaires (CQs) that need to be moved or
									  >	piggy-back CQs that must be created;
									  >	Location of the approved IP Log; and
									  >	Other information that helps the community understand the
									  >	change.
									  >
6.3.9 Combining Reviews								6.3.9 Combining Reviews
Multiple Reviews may occur simultaneous for a given Project. The most	  |
common combinations include Move+Release and Move+Graduation and	  |	This section has been modified to explicitly allow multiple projects
Graduation+Release.							  |	to participate in a single. It is possible, for example, for a project
									  >	and its descendants to engage in a simultaneous Release Review.
									  >
									  >	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.
									  >	It should be noted that the purpose of combining reviews is to
									  >	better serve the community, rather than to reduce effort on the part o
									  >	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.
6.4 Releases									6.4 Releases
(Most of this section is borrowed and paraphrased from the			(Most of this section is borrowed and paraphrased from the
excellent Apache								excellent Apache
Software Foundation Releases FAQ. The Eclipse community has many of		Software Foundation Releases FAQ. The Eclipse community has many of
the same beliefs about Releases as does the Apache community and their		the same beliefs about Releases as does the Apache community and their
words were already excellent. The Apache Software Foundation Releases		words were already excellent. The Apache Software Foundation Releases
FAQ is distributed under the <a href=						FAQ is distributed under the <a href=
"http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version		"http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version
2.0.)										2.0.)
Releases are, by definition, anything that is distributed outside of		Releases are, by definition, anything that is distributed outside of
the Committers of a Project. If users are being directed to download a		the Committers of a Project. If users are being directed to download a
build, then that build has been released (modulo the exceptions below)		build, then that build has been released (modulo the exceptions below)
All Projects and Committers must obey the Eclipse Foundation			All Projects and Committers must obey the Eclipse Foundation
requirements on approving any release.						requirements on approving any release.
(Exception 1: nightly and integration builds) During the			(Exception 1: nightly and integration builds) During the
process of developing software and preparing a Release, various nightl		process of developing software and preparing a Release, various nightl
and integration builds are made available to the developer community		and integration builds are made available to the developer community
for testing purposes. Do not include any links on the project website,		for testing purposes. Do not include any links on the project website,
blogs, wikis, etc. that might encourage non-early-adopters to download		blogs, wikis, etc. that might encourage non-early-adopters to download
and use nightly builds, release candidates, or any other similar		and use nightly builds, release candidates, or any other similar
package (links aimed at early-adopters and the project's developers ar		package (links aimed at early-adopters and the project's developers ar
both permitted and encouaged). The only people who are supposed to kno	  |	both permitted and encouraged). The only people who are supposed to
about such packages are the people following the developer mailing lis	  |	know about such packages are the people following the developer mailin
and thus are aware of the limitations of such builds.			  |	list and thus are aware of the limitations of such builds.
(Exception 2: milestone and release candidate builds)				(Exception 2: milestone and release candidate builds)
Projects are encouraged to use an agile development process including		Projects are encouraged to use an agile development process including
regular milestones (for example, six week milestones). Milestones and		regular milestones (for example, six week milestones). Milestones and
release candidates are "almost releases" intended for adoption and		release candidates are "almost releases" intended for adoption and
testing by early adopters. Projects are allowed to have links on the		testing by early adopters. Projects are allowed to have links on the
project website, blogs, wikis, etc. to encourage these				project website, blogs, wikis, etc. to encourage these
outside-the-committer-circle early adopters to download and test the		outside-the-committer-circle early adopters to download and test the
milestones and release candidates, but such communications must includ		milestones and release candidates, but such communications must includ
caveats explaining that these are not official Releases.			caveats explaining that these are not official Releases.

Milestones are to be labeled x.yMz, e.g., 2.3M1					Milestones are to be labeled x.yMz, e.g., 2.3M1
(milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version		(milestone 1 towards version 2.3), 2.3M2 (milestone 2 towards version
2.3), etc.									2.3), etc.
Release candidates are to be labeled x.yRCz, e.g.,				Release candidates are to be labeled x.yRCz, e.g.,
2.3RC1 (release candidate 1 towards version 2.3).				2.3RC1 (release candidate 1 towards version 2.3).
Official Releases are the only downloads allowed to be labeled with		Official Releases are the only downloads allowed to be labeled with
x.y, e.g., 0.5, 1.0, 2.3, etc.							x.y, e.g., 0.5, 1.0, 2.3, etc.

All official Releases must have a successful Release Review before	  |	All official Releases must have a successful <a href=
being made available for download.					  |	"#6_3_3_Release_Review">Release Review before being made available
									  >	for download.
(Exception 3: bug fix releases with no new features) Bug			(Exception 3: bug fix releases with no new features) Bug
fix releases (x.y.z, e.g., 2.3.1) with no new features over the base		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 (e.g., 2.3) are allowed to be released without an additional
Release Review. If a bug fix release contains new features, then the		Release Review. If a bug fix release contains new features, then the
Project must have a full Release Review.					Project must have a full Release Review.
Under no circumstances are builds and milestones to be used as a		Under no circumstances are builds and milestones to be used as a
substitute for doing proper official Releases. Proper Release			substitute for doing proper official Releases. Proper Release
management and reviews is a key aspect of Eclipse Quality.			management and reviews is a key aspect of Eclipse Quality.
6.5 Grievance Handling								6.5 Grievance Handling
When a Member has a concern about a Project, the Member will raise tha	  |	When a Member has a concern about a Project, the Member will raise
concern with the Project's Leadership. If the Member is not satisfied	  |	that concern with the Project's Leadership. If the Member is not
with the result, the Member can raise the concern with the parent	  |	satisfied with the result, the Member can raise the concern with the
Project's Leadership. The Member can continue appeals up the Project	  |	parent Project's Leadership. The Member can continue appeals up the
Leadership Chain and, if still not satisfied, thence to the EMO, then	  |	Project Leadership Chain and, if still not satisfied, thence to the
the Executive Director, and finally to the Board. All appeals and	  |	EMO, then the Executive Director, and finally to the Board. All appeal
discussions will abide by the Guiding Principles of being open,		  |	and discussions will abide by the Guiding Principles of being open,
transparent, and public.							transparent, and public.
Member concerns may include:							Member concerns may include:

Out of Scope. It is alleged that a Project is exceeding its			Out of Scope. It is alleged that a Project is exceeding its
approved scope.									approved scope.
Inconsistent with Purposes. It is alleged that a Project is			Inconsistent with Purposes. It is alleged that a Project is
inconsistent with the Roadmap and/or Purposes.					inconsistent with the Roadmap and/or Purposes.
Dysfunctional. It is alleged that a Project is not				Dysfunctional. It is alleged that a Project is not
functioning correctly or is in violation of one or more requirements o		functioning correctly or is in violation of one or more requirements o
the Development Process.							the Development Process.
Contributor Appeal. It is alleged that a Contributor who			Contributor Appeal. It is alleged that a Contributor who
desires to be a Committer is not being treated fairly.				desires to be a Committer is not being treated fairly.
Invalid Veto. It is alleged that a -1 vote on a Review is			Invalid Veto. It is alleged that a -1 vote on a Review is
not in the interests of the Project and/or of Eclipse.				not in the interests of the Project and/or of Eclipse.

A variety of grievance resolutions are available to the EMO up to, and	  |	A variety of grievance resolutions are available to the EMO up to,
including, rebooting or restarting a project with new Committers and	  |	and including, rebooting or restarting a project with new Committers
leadership.								  |	and leadership.
7. Precedence									7. Precedence
In the event of a conflict between this document and a Board-approved	  |	In the event of a conflict between this document and a
project charter, the most recently approved document will take		  |	Board-approved project charter, the most recently approved document
precedence.								  |	will take precedence.
8. Revisions									8. Revisions
As specified in the Bylaws, the EMO is responsible for maintaining thi	  |	As specified in the Bylaws, the EMO is responsible for maintaining
document and all changes must be approved by the Board.			  |	this document and all changes must be approved by the Board.
Due to the continued evolution of the Eclipse technology, the			Due to the continued evolution of the Eclipse technology, the
Eclipse community, and the software marketplace, it is expected that		Eclipse community, and the software marketplace, it is expected that
the Development Process (this document) will be reviewed and revised o		the Development Process (this document) will be reviewed and revised o
at least an annual basis. The timeline for that review should be chose		at least an annual basis. The timeline for that review should be chose
so as to incorporate the lessons of the previous annual coordinate		so as to incorporate the lessons of the previous annual coordinate
release and to be applied to the next annual coordinated release.		release and to be applied to the next annual coordinated release.
The EMO is further responsible for ensuring that all plans,			The EMO is further responsible for ensuring that all plans,
documents and reports produced in accordance with this Development		documents and reports produced in accordance with this Development
Process be made available to the Membership at Large via an appropriat		Process be made available to the Membership at Large via an appropriat
mechanism in a timely, effective manner.					mechanism in a timely, effective manner.
8.1 Revision 2.4							  |	8.1 Revision 2.5
This document was approved by the Eclipse Foundation Board of Director	  |	This document was approved by the Eclipse Foundation Board of
in its meeting on August 20, 2008. It replaces all previous versions.	  |	Directors in its meeting on May 19/2010. It takes effect (replacing al
&nbsp;									  |	previous versions) on August 1/2010.
									  >
									  >
									  >
									  >
									  >	See also
									  >
									  >	PDF version of this
									  >	document
									  >	Previous version of this document
									  >	Changes made since the previous version of this
									  >	document
									  >
									  >	This document with
									  >	comments
									  >	' ?&gt;
									  >
									  >