Eclipse Web Tools Platform Project Charter - v0.3

Overview
The Eclipse Web Tools Platform Project is an open source collaborative software development project dedicated to providing a generic, extensible, standards-based tool platform for producing Web-centric technologies.

This document describes the composition and organization of the project, roles and responsibilities of the participants, and development process for the project. The project charter is a living document that will be updated to reflect the evolution of the development process evolving over time.

Mission
The mission of the Web Tools Platform Project is to build a generic, extensible, standards-based tool platform upon which software providers can create specialized, differentiated offerings for producing applications based on J2EE, Java and Web technologies.

Scope
The Web Tools Platform Project will build on the Eclipse Project, and other core Eclipse technologies, to provide a common foundation of frameworks and services for tooling products. The project will also deliver tooling products, for exemplary purposes or to validate the underlying platform.

Project Management Committee
The Eclipse Web Tools Platform Project is managed by a small group known as the Eclipse Web Tools Platform Project Management Committee.

The Eclipse Web Tools Platform PMC is responsible for the strategic direction and success of the Web Tools Platform Project. This governing and advisory body is expected to ensure the project's welfare and guide its overall direction. The PMC is responsible for overall development direction, conflict resolution, development processes and infrastructure, and the overall technical success of the project.

The PMC has the following responsibilities:

• Providing the leadership and vision to guide the project's overall direction.
• Providing assistance and support to the developers working on the project by removing obstacles, solving problems, and resolving conflicts.
• Ensuring that subproject plans are produced, and presenting these plans to the Board.
• Establishing the development processes and infrastructure needed for the development team to be effective.
• Creating subprojects and components, and establishing the initial sets of subproject or component committers, and establishing the procedures for voting for new committers.
• Helping to ensure that subprojects have enough contributors, and helping to fill vacancies in roles.
• Producing “how to get involved” information to help new potential contributors get started.
• Coordinating relationships with other eclipse.org projects.
• Facilitating code or other donations by individuals or companies.
• Ensures licensing is compatible with licensing established by the Board.
• Representing the project to the outside world.

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 a member of the PMC, and unanimously approved by all PMC members. The goal is to keep the membership of the PMC small.

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.

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.

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 newsgroup 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 subprojects and components they are overseeing.

Roles
The Eclipse Web Tools Platform Project is a meritocracy -- 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 products that the Project produces. People in this role aren't contributing code, but they are using the products, reporting bugs, and making feature requests and suggestions. Users are encouraged to participate through the user newsgroup(s), asking questions, providing suggestions, and helping other users. Users are also encouraged to report problem reports using the bug tracking system.

Developers
Users who contribute code or documentation become developers. Developers are the people who contribute code, fixes, documentation, or other work that goes into the product. Developers are also 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 subproject, or component of a subproject (in the case of large subprojects), can have their status promoted to that of a "Committer" for that subproject or component respectively. A Committer has write access to the source code repository for the associated subproject (or component), and gains voting rights allowing to affect the future of the subproject (or component).

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

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 subprojects and components for which they have commit privileges. This is a condition of being granted commit rights to the subproject 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 subprojects 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.

Subprojects
The work of the Project may be organized into subprojects. New subprojects must be significant works consistent with the mission and scope of the Eclipse Web Tools Platform Project, and be approved by the PMC. When a new subproject is created, the PMC appoints a subproject lead to act as the technical leader and names the initial set of Committers for the subproject. Thereafter the PMC may appoint a new subproject lead from time to time as required, but the new subproject lead must be confirmed by a majority of the other Committers of the subproject. Subproject leads are accountable to the PMC for the success of their project.

Subproject Components
The PMC may decide to divide a subproject further into components. If a subproject is divided 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 subproject and represents the component in discussions and votes pertaining to the subproject as a whole. Component Committers do not participate in votes at the level of the subproject as a whole, unless they are also the component lead.

Ports
For components that contain platform-specific code, it may be advantageous to allow developers to work on a port of the component to a new platform without requiring that they already be committers for the component. In this case the main code base is known as the component "core", and the port code base is known as a component "port". The decision to set up a port is made by the PMC. When a new port of a component is created, the PMC appoints a Port Lead, and an initial set of committers who will have commit and voting privileges specifically for the port. The port is done under the auspices of the core component, and all committers for the core component automatically also have commit and voting privileges on the port. Normally the Component Lead will also be the Port Lead.

Coordinated Release Cycles
All subprojects and components under the Web Tools Platform Project will have coordinated release plans, milestone dates, freeze cycles, builds, and ship dates. These subprojects will be coordinated by a group consisting of the subproject leads, the component leads from these subprojects, and the members of the PMC.

Infrastructure
The infrastructure required to support the development process is the responsibility of the PMC. The Eclipse Web Tools Platform Project will have at least the following:

• Bug Database - Bugzilla-like database for tracking bugs and feature requests.
• Source Repository -- One or more CVS repositories containing both the master source code and documentation for the subprojects.
• Website - A website will contain information about the project, including documentation, downloads of releases, and this charter.
• General Mailing List - Mailing list for development discussions pertaining to the project as a whole or that cross subprojects. This mailing list is open to the public.
• Subproject Mailing Lists - Development mailing list for technical discussions and committer voting related to the subproject. This mailing list is open to the public.
• Component Mailing Lists -- Development mailing list for technical discussions and committer voting related to the component. This mailing list is open to the public.
• A newsgroup where users, developers, and committers can interact regarding general questions and issues about the project.

The Development Process
Each subproject lead must produce a development plan for the release cycle, and the development plan must be approved by the PMC and by a majority of Committers of the subproject.

Each subproject 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 subproject 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 subproject or component decide which changes may be committed to the master code base of a subproject 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 subproject or component.

Special rules may be established by the PMC for subprojects 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 subproject or component, as applicable. More restrictive rules for releasing changes may be established by the PMC near the end of release cycles or for maintenance streams.

The master copy of the code base must reside on the project web site where it is accessible to all 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 establishing 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.

The PMC is responsible for establishing the level of testing appropriate for each subproject, and approving the test plans.

All development technical discussions are conducted using the development mailing lists. If discussions are held offline, then a summary should be posted to the mailing list to keep the other committers (and other interested parties) informed.

Licensing
All contributions to the Eclipse Web Tools Platform Project must adhere to the Common Public License /legal/cpl-v10.html. Notwithstanding the above, at the discretion of the PMC, Eclipse Web Tools Platform Project downloads may include separately licensed code from third parties as a convenience and where permitted by the third party license, provided this is clearly indicated.

All contributors should be aware that licensing recommendations from the Board are now to adopt the Eclipse Public License and that a migration from CPL to EPL is to be expected before end of year 2004.

Meanwhile, all contributions must contain the following copyright notice.

--- Copyright (c) {date} {name of original contributor} and others. All rights reserved. This program and the accompanying materials are made available under the terms of the Common Public License v1.0 that accompanies this distribution, and is available at /legal/cpl-v10.html

Contributors: <contributor1> - <description of contribution> <contributor2> - <description of contribution> ... ---

The original contributor is the one who contributes the first version of the file. A contributor may be a person or an organization - whoever owns the copyright. If the contributor is an organization, the person may also be indicated. For each additional contributor, indicate the part of the code or contribution that came from the contributor, especially if it contains an interesting algorithm or data table etc. For clarity, also indicate the contributor in the actual section of contributed code. Also reference the Bugzilla bug ID if applicable. The basic principle is to clearly identify the contribution... especially if it is a separable block of code.