| 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. |