| <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <title>Eclipse Test & Performance Tools Platform Project</title> |
| <link rel="stylesheet" href="../eclipse-webtools/templates/eclipse/eclipse.css"></head> |
| <body text="#000000" bgcolor="#ffffff" link="#0000ee" vlink="#551a8b" alink="#ff0000"> |
| |
| <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <tr> |
| <td ALIGN=LEFT width="60%"><font class=indextop>eclipse test & performance tools platform project</font><br> |
| <font class=indexsub>Project Charter</font></td> |
| <td WIDTH="40%"><img SRC="../../images/Idea.jpg" HSPACE=50 height=86 width=120 align=CENTER></td> |
| </tr> |
| </table> |
| |
| <p>This project proposal is in the <a href="/projects/dev_process/"> |
| Proposal Phase</a> 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 <a href="contributing.html">join the project</a>. |
| Please send all feedback to the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.test-and-performance">eclipse.test-and-performance |
| newsgroup</a> or the <a href="https://dev.eclipse.org/mailman/listinfo/test-and-performance-proposal"> |
| test-and-performance-proposal</a> mailing list.</p> |
| <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <tr> |
| <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF" face="Arial,Helvetica">Eclipse Test & Performance Tools Platform Project Charter - v0.2</font></b></td> |
| </tr> |
| |
| <tr> |
| <td> |
| <p><b>Overview</b><br> |
| The Eclipse Test & Performance Tools Platform Top-Level Project (the |
| "Eclipse Test & Performance Project") is an open source |
| collaborative software development project dedicated to providing a robust, |
| extensible, commercial quality, and freely available industry platform |
| intended to reduce the cost and complexity of implementing effective and |
| highly interoperable test & performance tools.<br> |
| <br> |
| 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 over time.</p> |
| <p><b>Mission</b><br> |
| The mission of the Eclipse Test & Performance Project is to build a generic, |
| extensible, standards-based tool platform upon which software developers |
| can create specialized, differentiated, and interoperable offerings for |
| world class test and performance tools.</p> |
| <p><b>Scope</b><br> |
| The Eclipse Test & Performance Project will extend the family of Eclipse |
| technologies to provide an open development platform supplying frameworks |
| and services for test and performance tools that are used throughout the |
| lifecycle (e.g., testing, tracing/profiling, tuning, logging, monitoring, |
| analysis, autonomics, administration, etc., but not development tools |
| such as optimizing compilers) and support a spectrum of standalone through |
| highly-distributed and embedded through enterprise computing systems.<br> |
| <br> |
| The project will also deliver exemplary tools that verify the utility |
| of and illustrate the appropriate use of the platform, support the development |
| and maintenance of the platform itself, and are extensible via documented |
| programmatic interfaces.</p> |
| <p><b>Project Management Committee</b><br> |
| The Eclipse Test & Performance Project and Projects under its Charter |
| are managed by a small group known as the <a href="pmc.html">Eclipse Test |
| & Performance Tools Platform Project Management Committee</a> (the "PMC").</p> |
| <p>The PMC is expected to ensure that:</p> |
| <ul> |
| <li>All Projects operate effectively by providing leadership to guide |
| the Project's overall direction and by removing obstacles, solving problems, |
| and resolving conflicts.</li> |
| <li>All Project plans, technical documents and reports are publicly available.</li> |
| <li>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.</li> |
| </ul> |
| <p>The PMC has the following responsibilities:</p> |
| <ul> |
| <li>Providing the leadership and vision to guide the Project's overall |
| direction. </li> |
| <li>Providing assistance and support to the developers working on the |
| project by removing obstacles, solving problems, and resolving conflicts. |
| </li> |
| <li>Ensuring that Project plans are produced, and presenting these plans |
| to the EMO.</li> |
| <li>Establishing the development processes and infrastructure needed for |
| the development team to be effective. </li> |
| <li>Recommending new Projects to the EMO, and appointing the Project Lead. |
| </li> |
| <li>Establishing the initial set of Project committers and establishing |
| the procedures for voting in new committers. </li> |
| <li>Helping to ensure that Projects have enough contributors, and helping |
| to fill vacancies in roles. </li> |
| <li>Producing "how to get involved" guidelines to help new potential contributors |
| get started. </li> |
| <li>Coordinating relationships with other Eclipse Foundation Projects. |
| </li> |
| <li>Facilitating code or other donations by individuals or organizations. |
| </li> |
| <li>Working with the EMO and Committers to ensure in-bound contributions |
| are made in accordance with the Eclipse Foundation IP Policy.</li> |
| <li>Representing the Project to the outside world.</li> |
| </ul> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p><b>Requirements Group</b></p> |
| <p>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. |
| </p> |
| <p>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. </p> |
| <p>The Requirements Group will accomplish its objectives by working closely |
| with their represented organizations and individuals, the Project development |
| teams, and the ecosystem.</p> |
| <p><b>Architecture Group</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>The Architecture Group will accomplish its objectives by working closely |
| with the Project development teams and the Eclipse Architecture Council.</p> |
| <p><b>Planning Group</b></p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>The Planning Group will accomplish its objectives by working closely |
| with their represented organizations, the Project development teams, and |
| the Eclipse Planning Council.</p> |
| <p><b>Roles</b><br> |
| The Eclipse Test & Performance 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.</p> |
| <p><b>Users</b><br> |
| 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.</p> |
| <p><b>Developers</b><br> |
| 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.</p> |
| <p><b>Committers</b><br> |
| Developers who give frequent and valuable contributions to a Project, |
| or a subsystem of a Project (in the case of large Projects), can have |
| their status promoted to that of a "Committer" for that Project |
| or subsystem respectively. A Committer has write access to the source |
| code repository for the associated Project (or subsystem), and gains voting |
| rights allowing them to affect the future of the Project (or subsystem).</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>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. </p> |
| <p>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. </p> |
| <p>More restrictive rules for committing changes may be established by the |
| PMC near the end of release cycles or for maintenance streams.</p> |
| <p>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.</p> |
| <p>Projects<br> |
| The work under this Top Level Project is further organized into Projects. |
| New Projects must be significant works 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.</p> |
| <p>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.</p> |
| <p>See <a href="project_descriptions.html">Project Descriptions</a> for |
| additional information on the Projects under this Charter. </p> |
| <p><b>Subsystems</b><br> |
| The PMC may decide to divide a Project further into Subsystems. If a Project |
| is divided into Subsystems, commit privileges are normally granted at |
| the Subsystem level, and the Committers for a given Subsystem vote on |
| issues specific to that Subsystem. Subsystem are established and discontinued |
| by the PMC. When the PMC creates a Subsystem it appoints a Subsystem lead |
| to act as the technical leader and names the initial set of Committers |
| for the Subsystem. The Subsystem lead is designated as a Committer for |
| the Project and represents the Subsystem in discussions and votes pertaining |
| to the Project as a whole. Subsystem Committers do not participate in |
| votes at the level of the Project as a whole, unless they are also the |
| Subsystem lead.</p> |
| <p><b>Ports</b><br> |
| For Subsystems that contain platform-specific code, it may be advantageous |
| to allow developers to work on a port of the Subsystem to a new platform |
| without requiring that they already be Committers for the Subsystem. In |
| this case, the main code base is known as the Subsystem "core", |
| and the port code base is known as a Subsystem "port". The decision |
| to set up a port is made by the PMC. When a new port of a Subsystem 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 Subsystem, and all Committers |
| for the core Subsystem automatically also have commit and voting privileges |
| on the port. Normally the Subsystem Lead will also be the Port Lead.</p> |
| <p><b>Coordinated Release Cycles</b><br> |
| All Projects under the Eclipse Test & Performance Project will have |
| coordinated release plans, milestone dates, freeze cycles, builds, and |
| ship dates. Project Leads are responsible for coordinating their respective |
| Projects while the Eclipse Test & Performance Project Planning Group |
| will coordinate across Projects.</p> |
| <p>The Eclipse Test & Performance Project will typically have release |
| plans coincident with Eclipse Platform releases plus additional more frequent |
| interim releases where appropriate.</p> |
| <p><b>Infrastructure</b><br> |
| The infrastructure required to support the development process is the |
| responsibility of the PMC. The Eclipse Test & Performance Project |
| will have at least the following:</p> |
| <ul> |
| <li>Bug Database - Bugzilla database for tracking bugs and feature requests. |
| </li> |
| <li>Source Repository -- One or more CVS repositories containing both |
| the master source code and documentation for the Projects. </li> |
| <li>Website - A website will contain information about the Project, including |
| documentation, downloads of releases, and this charter. </li> |
| <li>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. </li> |
| <li>Project Mailing Lists - Development mailing list for technical discussions |
| and Committer voting related to the Project(s). This mailing list is |
| open to the public. </li> |
| <li>Subsystem Mailing Lists -- Development mailing list for technical |
| discussions and Committer voting related to the Subsystem. This mailing |
| list is open to the public. </li> |
| </ul> |
| <p><b>Development Process</b><br> |
| Each Project lead must produce a development plan for the release cycle, |
| and the development plan must be approved by the Eclipse Test & Performance |
| Planning Group.</p> |
| <p>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.</p> |
| <p>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.</p> |
| <p>The PMC is responsible for establishing the level of testing appropriate |
| for each subproject, and approving the test plans.</p> |
| <p>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.</p> |
| <p>The PMC may specify additional detailed development process guidelines |
| specific to this Project.</p> |
| <p><b>Licensing</b><br> |
| All contributions to Projects under this Charter must adhere to the Eclipse |
| Foundation Intellectual Property Policy.</p> |
| <p> </p> |
| </td> |
| </tr> |
| </table> |
| |
| </body> |
| </html> |
