| :edpUrl: https://www.eclipse.org/projects/dev_process/ |
| |
| = 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._ |
| |
| == Overview |
| |
| _To be defined in the individual Top Level Project Charter._ |
| |
| == Mission |
| |
| _To be defined in the individual Top Level Project Charter._ |
| |
| == Scope |
| |
| _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 {edpUrl}#4_6_Leaders[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. |
| |
| == 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 |
| 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. |
| |
| === Contributors |
| |
| 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. |
| |
| === Committers |
| |
| 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 |
| {edpUrl}#4_7_Committers_and_Contributors[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. |
| |
| == 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 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. |
| |
| === Components |
| |
| 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. |
| |
| == Infrastructure |
| |
| 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 {edpUrl}[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, |
| |
| == Licensing |
| |
| All contributions to Projects under this Charter must adhere to the |
| link:/org/documents/Eclipse_IP_Policy.pdf[Eclipse Foundation |
| Intellectual Property Policy]. |