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