|eclipse test & performance tools platform project
This project proposal is in the Proposal Phase and is posted here to solicit additional project participation and ways the project can be leveraged from the Eclipse membership-at-large. You are invited to comment on and/or join the project. Please send all feedback to the eclipse.test-and-performance newsgroup or the test-and-performance-proposal mailing list.
|Eclipse Test & Performance Tools Platform Project Charter - v0.2|
Project Management Committee
The PMC is expected to ensure that:
The PMC has the following responsibilities:
The PMC Lead is appointed by the Board. The initial PMC members are 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. 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 must be 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 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 projects and subsystems they are overseeing.
The PMC Lead shall establish an Eclipse Test & Performance Project Requirements Group (the "Requirements Group") responsible for gathering, reviewing and categorizing incoming requirements, and proposing a coherent set of themes and priorities that will drive the Project Roadmap.
The PMC Lead will designate the Requirements Group Chair. The Requirements Group shall be comprised of one representative designated by each contributing organization and other individuals designated from time to time by the PMC Lead.
The Requirements Group will accomplish its objectives by working closely with their represented organizations and individuals, the Project development teams, and the ecosystem.
The PMC Lead shall establish an Eclipse Test & Performance Project Architecture Group (the "Architecture Group") responsible for the development, articulation, and maintenance of the Project architecture and alignment thereof with the Eclipse architecture.
The PMC Lead will designate the Architecture Group Chair and will also designate the Project representative to the Eclipse Architecture Council. The Architecture Group shall be comprised of a subset Project Committers nominated by the Chair and other individuals designated from time to time by the PMC Lead who represent the Project architecture.
The Architecture Group will accomplish its objectives by working closely with the Project development teams and the Eclipse Architecture Council.
The PMC Lead shall establish an Eclipse Test & Performance Project Planning Group (the "Planning Group") responsible for the development and maintenance of a Project Release Plan consistent with the Architecture, supporting the Roadmap, and supported by resource commitments of contributing organizations and individuals.
The PMC Lead will designate the Planning Group Chair and will also designate the Project representative to the Eclipse Planning Council. The Planning Group shall be comprised of one representative designated by each contributing organization and other individuals designated from time to time by the PMC Lead. Additionally, the Requirements Group and Architecture Group chairpersons will be members of the Planning Group.
The Planning Group will accomplish its objectives by working closely with their represented organizations, the Project development teams, and the Eclipse Planning Council.
In order for a Developer to become a Committer, another Committer for the same Project (or Subsystem) can nominate that Developer or the Developer can ask for it. Once a Developer is nominated, the Committers for the Project (or Subsystem) will vote. If there are at least three or a majority, whichever is less, of positive votes, the Developer is recommended to the PMC for Committer privileges. If the PMC approves, the Developer must sign the Committer Agreement established by the EMO, and the Developer is converted into a Committer and given write access to the source code repository for that Project (or Subsystem). 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. Committers may be asked to represent their respective Project and/or subsystems by membership on the Architecture Group.
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 Committer 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 Subsystems for which they have Committer privileges. 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 Committer privileges they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a developer mailing list unless their associated Committer privileges are also removed.
The Committers of a Project or Subsystem vote (+1:'yes', 0:'abstain', -1:'no/veto') to decide which changes may be committed to the master code base of a Project or Subsystem respectively. Three +1 ('yes') with no -1 ('no'/veto') votes are needed to approve a code change. All votes are conducted via the developer mailing list associated with the Project or Subsystem and must be followed by a justification within 24 hours or the veto becomes invalid.
Special rules may be established for Projects or Subsystem 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 Subsystem, as applicable.
More restrictive rules for committing changes may be established by the PMC near the end of release cycles or for maintenance streams.
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.
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.
See Project Descriptions for additional information on the Projects under this Charter.
Coordinated Release Cycles
The Eclipse Test & Performance Project will typically have release plans coincident with Eclipse Platform releases plus additional more frequent interim releases where appropriate.
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 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.
The PMC may specify additional detailed development process guidelines specific to this Project.