Overview
~~~~~~~~

The Eclipse Technology Top Level Project (the “Eclipse Technology
Project”) is an open source software research and development project,
which encapsulates three related activity streams, each of which is
based on or uses the Eclipse Platform and/or Eclipse Tools:

1.  academic research projects and other exploratory investigations
(“Research Stream”);
2.  development of educational materials, teaching aids and courseware
(“Education Stream”);
3.  incubation of small-scale, innovative platform and tools projects
(“Incubators Stream”).

Mission
~~~~~~~

The mission of the Eclipse Technology Project is to provide a home
within the Eclipse Foundation for small, informally structured Projects
which add new capabilities to the Eclipse software base (Incubators
Stream), foster greater community awareness and understanding of Eclipse
(Education Stream), or explore research issues in Eclipse-relevant
domains such as programming languages, tools, and development
environments (Research Stream). The Eclipse Technology Project is
intended to:

1.  provide the open source community with a lighter weight alternative
to the larger scale, more structured development activities carried out
by other PMCs, and
2.  create opportunities for researchers, academics and educators to
play a significant role within the Eclipse community.

Scope
~~~~~

The scope of the Eclipse Technology Project will encompass a wide
variety of small Projects, rather than a few large ones. While
anticipating enormous diversity in the content of these activities, from
a process-oriented viewpoint they will all share important common
characteristics, which argues for a common management envelope:

* Focus on pre-competitive development and research
* Use of informal development processes
* Fluid Project tracking due to frequent plan changes
* Flexible milestones which adapt based on partial results
* Small teams
* Resource commitments tentative, due to volunteer labor or lack of
sponsor funding
* Development often cross-cuts the scope of several other Eclipse
Foundation Projects

The Eclipse Technology Project serves as a single point of focus for
such teams, and provides them with a home within the Eclipse community,
to encourage communication, and where appropriate, collaboration and
coordination. Providing common management for these Projects facilitates
maximum sharing and creation of common components, and avoids redundant
efforts. In many cases successful Research Projects will evolve into
Incubators, and Incubators in turn may migrate to other PMCs, either by
merging into an existing Project, or by forming the basis for a new one.

The Education Stream plays a vital role in promoting the use of the
Eclipse Platform. By making high quality educational materials freely
available, we both enable self-education by individual users, and
facilitate the incorporation of Eclipse-related materials into
university courses and commercial educational offerings.

Project Management Committee
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Projects under this Charter are managed by a group known as the
Project Management Committee (the “PMC”).

PMCs are expected to ensure that:

* All Projects operate effectively by providing leadership to guide the
Project’s overall direction and by removing obstacles, solving problems,
and resolving conflicts.
* All Project plans, technical documents and reports are publicly
available
* All Projects operate using open source rules of engagement:
meritocracy, transparency, and open participation. These principles work
together. Anyone can participate in a Project. This open interaction,
from answering questions to reporting bugs to making code contributions
to creating designs, enables everyone to recognize and utilize the
contributions.

The PMC has the following responsibilities:

* Providing the leadership and vision to guide the Project's overall
direction in a manner consistent with the Eclipse Foundation
Architectural Roadmap.
* Providing assistance and support to the developers and researchers
working on the Project by removing obstacles, solving problems, and
resolving conflicts.
* Ensuring that Project plans are produced.
* Working with the Eclipse Management Organization (the “EMO”) to
establish the development processes and infrastructure needed for the
development team to be effective.
* Recommending new Projects to the EMO.
* Recommending the initial set of Project committers for each new
Project overseen by the PMC, and establishing the procedures consistent
with this Charter for voting in new committers.
* Helping to ensure that the Projects overseen by the PMC have enough
contributors, and working to fill vacancies in roles.
* Producing “how to get involved” guidelines to help new potential
contributors get started.
* Coordinating relationships with other Eclipse Foundation Projects.
* Facilitating code or other donations by individuals or companies.
* Making recommendations to the Eclipse Foundation Board regarding
contributions proposed under licenses other than the EPL.
* Working with the EMO and Committers to ensure in-bound contributions
are made in accordance with the Eclipse Foundation IP Policy.
* Acting as a focal point for the community in representing the Projects
it oversees.
* The PMC Lead is appointed by the Board. The initial PMC is selected by
the PMC Lead. Thereafter, to become a member of the PMC, an individual
must be nominated by another member of the PMC, and unanimously approved
by all PMC members.

In the unlikely event that a member of the PMC becomes disruptive to the
process or ceases to contribute for an extended period, the member may
be removed by unanimous vote of remaining PMC members. PMC members may
resign at any time by delivering notice of their resignation to the PMC
Lead.

The PMC is responsible for producing and maintaining the Project
Charter. Development must conform to any rules or processes outlined in
the Charter, so a change to the development process may necessitate a
change to the Charter. Changes to the Charter are approved by the Board.

The work of the PMC is shared by the PMC members. All PMC members are
expected to contribute actively. In particular, PMC members are expected
to take responsibility for overseeing certain areas of work in the
Project, and reporting to the PMC on these areas.

Active participation in the user newsgroups and the appropriate
developer mailing lists is a responsibility of all PMC members, and is
critical to the success of the Project. PMC members are required to
monitor the main Project mailing list, and the developer mailing lists
for all Projects and components they are overseeing.

Roles
~~~~~

The Projects under this Charter are operated as meritocracies -- the
more you contribute, and the higher the quality of your contribution,
the more you are allowed to do. However with this comes increased
responsibility.

Users
~~~~~

Users are the people who use the output from the Project. Output will
typically consist of software and research. Software in this context
means intellectual property in electronic form, including source and
binary code, documentation, courseware, reports and papers.

Developers
~~~~~~~~~~

Users who contribute software or research become developers. Developers
are encouraged to participate in the user newsgroup(s), and should
monitor the developer mailing list associated with their area of
contribution. When appropriate, developers may also contribute to
development design discussions related to their area of contribution.
Developers are expected to be proactive in reporting problems in the bug
tracking system.

Committers
~~~~~~~~~~

Developers who give frequent and valuable contributions to a Project, or
component of a Project (in the case of large Projects), can have their
status promoted to that of a "Committer" for that Project or component
respectively. A Committer has write access to the source code repository
for the associated Project (or component), and gains voting rights
allowing them to affect the future of the Project (or component).

In order for a Developer to become a Committer on a particular Project
overseen by the PMC, another Committer for the same Project (or
component as appropriate) can nominate that Developer or the Developer
can ask to be nominated. Once a Developer is nominated, the Committers
for the Project (or component) will vote. If there are at least 3
positive votes and no negative votes, the Developer is recommended to
the PMC for commit privileges. If the PMC also approves, the Developer
is converted into a Committer and given write access to the source code
repository for that Project (or component). Becoming a Committer is a
privilege that is earned by contributing and showing discipline and good
judgement. It is a responsibility that should be neither given nor taken
lightly.

At times, Committers may go inactive for a variety of reasons. The
decision making process of the Project relies on active committers who
respond to discussions and votes in a constructive and timely manner.
The PMC is responsible for ensuring the smooth operation of the Project.
A Committer that is disruptive, does not participate actively, or has
been inactive for an extended period may have his or her commit status
removed by the PMC.

Active participation in the user newsgroup and the appropriate developer
mailing lists is a responsibility of all Committers, and is critical to
the success of the Project. Committers are required to monitor and
contribute to the user newsgroup.

Committers are required to monitor the developer mailing list associated
with all Projects and components for which they have commit privileges.
This is a condition of being granted commit rights to the Project or
component. It is mandatory because committers must participate in votes
(which in some cases require a certain minimum number of votes) and must
respond to the mailing list in a timely fashion in order to facilitate
the smooth operation of the Project. When a Committer is granted commit
rights they will be added to the appropriate mailing lists. A Committer
must not be unsubscribed from a developer mailing list unless their
associated commit privileges are also removed.

Committers are required to track, participate in, and vote on, relevant
discussions in their associated Projects and components. There are three
voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain).

Committers are responsible for proactively reporting problems in the bug
tracking system, and annotating problem reports with status information,
explanations, clarifications, or requests for more information from the
submitter. Committers are responsible for updating problem reports when
they have done work related to the problem.

Projects
~~~~~~~~

The work under this Top Level Project is further organized into
Projects. New Projects must be consistent with the mission of the Top
Level Project, be recommended by the PMC, and confirmed by the EMO.
Projects can be discontinued by decision of the Board.

When a new Project is created, the PMC nominates a Project lead to act
as the technical leader and nominates the initial set of Committers for
the Project, and these nominations are approved by the EMO. Project
leads are accountable to the PMC for the success of their Project.

Project Organization
~~~~~~~~~~~~~~~~~~~~

Given the fluid nature of Eclipse Technology Projects, organizational
changes are possible, in particular: dividing a Project into components;
dividing a Project into two or more independent Projects; and merging
two or more Projects into a single Project. In each case the initiative
for the change may come either from within the Project or from the PMC,
but the PMC must approve any change, and approval must be confirmed by
the EMO.

If a Project wishes to divide into components, commit privileges are
normally granted at the component level, and the committers for a given
component vote on issues specific to that component. Components are
established and discontinued by the PMC. When the PMC creates a
component it appoints a component lead to act as the technical leader
and names the initial set of Committers for the component. The component
lead is designated as a committer for the Project and represents the
component in discussions and votes pertaining to the Project as a whole.
Component committers do not participate in votes at the level of the
Project as a whole, unless they are also the component lead.

In cases where new Projects are being created, either by splitting or by
merging, the usual procedures as set forth in this Charter are followed.
In particular, developers will not necessarily have the same rights
after an organizational change that they enjoyed in the previous
structure.

Infrastructure
~~~~~~~~~~~~~~

The PMC works with the EMO to ensure the required infrastructure for the
Project. The Project infrastructure will include, at minimum:

* Bug Database - Bugzilla database for tracking bugs and feature
requests.
* Source Repository -- One or more CVS repositories containing all the
software for the Projects.
* Website - A website will contain information about the Project,
including documentation, reports and papers, courseware, downloads of
releases, and this Charter.
* General Mailing List - Mailing list for development discussions
pertaining to the Project as a whole or that cross Projects. This
mailing list is open to the public.
* Project Mailing Lists - Development mailing list for technical
discussions related to the Project. This mailing list is open to the
public.
* Component Mailing Lists -- Development mailing list for technical
discussions related to the component. This mailing list is open to the
public.

The Development Process
~~~~~~~~~~~~~~~~~~~~~~~

In this section the phrase “release cycle” will refer to a significant
block of Project activity, which corresponds to an actual release cycle
in the case of Incubators or Education Projects, or to a major stage of
a phased Research Project.

Each Project lead must produce a development plan for the release cycle,
and the development plan must be approved by a majority of Committers of
the Project. The plan must be submitted to the PMC for review. The PMC
may provide feedback and advice on the plan but approval rests with the
Project Committers.

Each Project must identify, and make available on its web site, the
requirements and prioritizations it is working against in the current
release cycle. In addition, each Project must post a release plan
showing the date and content of the next major release, including any
major milestones, and must keep this plan up to date.

The Committers of a Project or component decide which changes may be
committed to the master code base of a Project or component
respectively. Three +1 ('yes' votes) with no -1 ('no' votes or vetoes)
are needed to approve a code change. Vetoes must be followed by an
explanation for the veto within 24 hours or the veto becomes invalid.
All votes are conducted via the developer mailing list associated with
the Project or component.

Special rules may be established by the PMC for Projects or components
with fewer than three Committers. For efficiency, some code changes from
some contributors (e.g. feature additions, bug fixes) may be approved in
advance, or approved in principle based on an outline of the work, in
which case they may be committed first and changed as needed, with
conflicts resolved by majority vote of the Committers of the Project or
component, as applicable.

The master copy of the code base must reside on the Project web site
where it is accessible to all users, developers and committers.
Committers must check their changes and new work into the master code
base as promptly as possible (subject to any check-in voting rules that
may be in effect) in order to foster collaboration among widely
distributed groups and so that the latest work is always available to
everyone. The PMC is responsible for working with the Eclipse Foundation
to establish a release engineering and build process to ensure that
builds can be reliably produced on a regular and frequent basis from the
master code base and made available for download from the Project web
site. Builds in this context are intended to include not only code but
also reports, documentation, and courseware.

Each Project is responsible for establishing test plans and the level of
testing appropriate for the Project.

All development technical discussions are conducted using the
development mailing lists. If discussions are held offline, then a
summary must be posted to the mailing list to keep the other committers
informed.

Licensing
~~~~~~~~~

All contributions to Projects under this Charter must adhere to the
Eclipse Foundation Intellectual Property Policy.