Skip to main content
Eclipse Standard Top-Level Charter

This document defines standard terms for Eclipse Top Level Project Charters. It is intended that the Charters for Top Level Projects reference this document rather than inheriting by copy-and-paste.


To be defined in the individual Top Level Project Charter.


To be defined in the individual Top Level Project Charter.


To be defined in the individual Top Level Project Charter.

Project Management Committee

The Projects under this Charter are managed by a group known as the Project Management Committee (the "PMC"). The PMC’s duties are described in 4.6 Leaders of the Eclipse Development Process.

It is the PMC’s responsibility to ensure the projects within its umbrella operate as active and viable open source projects, and to take steps to reboot, archive, or restructure projects if they become inactive or otherwise fail to meet the requirements of the Eclipse Development Process.

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. Because of the diversity amongst individual projects, PMC members are not expected to maintain anything other than general currency with projects outside their assigned technical areas.


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 are the people who use the output from the Project. Output typically consists of software in form of extensible frameworks and exemplary tools. Software in this context means intellectual property in electronic form, including source and binary code, documentation, courseware, reports and whitepapers.


Users who contribute software, documentation, or other materially useful content become contributors. Contributors are encouraged to participate in the user forums, and should monitor the developer mailing list associated with their area of contribution. When appropriate, contributors may also contribute to development design discussions related to their area of contribution. Contributors are expected to be proactive in reporting problems in the bug tracking system.


Contributors who give frequent and valuable contributions to a Project can have their status promoted to that of a "Committer" for that Project respectively. See 4.7 Committers and Contributors of the Eclipse Development Process for the process and responsibilities that entails.

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

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

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

Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects. 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.


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 recommendation of the PMC, and confirmed by the EMO.

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.


The Eclipse Development Process has no formal notion of component. As such Eclipse Foundation infrastructure provides no formal means of managing membership or privileges at a component level. Projects may opt to informally designate different functional areas in a project as de facto components, but access to resources associated with those functional areas must be managed by social convention with oversight from the project leadership.


The PMC works with the EMO to ensure the required infrastructure is provided for the Project. The Project infrastructure includes, at minimum:

  • An issue tracker;

  • One or more source repositories that must collectively include all of the source code for the Project’s software;

  • A website to contain information about the Project, including documentation, reports and papers, courseware, downloads of releases, and this Charter;

  • A download server (or space on a server);

  • A developer mailing list ("dev-list") for discussions pertaining to the Project as a whole or that cross Projects;

  • Additional project mailing lists (as needed) for technical discussions related to the Project; and

  • A forum where users, contributors, and Committers can interact regarding general questions and issues about the Project.

All services are open for public participation (with archives where appropriate). Project Committers have special access to some resources (e.g. write access to source code repositories and the download server). The Project team is obligated to use the issue tracker provided by the EMO for all issues related to the project. The provided download server must be used as the primary means to distribute all milestone and release builds produced by the Project.

The Development Process

All projects are required to operate according to the rules established by the most current version Eclipse Development Process.

Each Project must identify, and make available on its web site, the requirements and priorities 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 decide which changes may be committed to the master code base of a Project respectively. The PMC defines the decision process, but that process must include the ability for Committers to veto the change. The decision process employed may change with the phase of development.  Common decision processes include:

  • Retroactive - changes are proactively made by Committers but can be vetoed by a single Committer. 

  • Proactive - 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 as applicable.

  • Three Positive - No code is committed without a vote; 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. Special rules may be established by the PMC for Projects with fewer than three Committers. 

The master copy of the code base must reside on the Project web site where it is accessible to all users, contributors, 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, and any other interested parties,


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

Back to the top