<!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">
&nbsp; 
<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 &amp; Performance Tools Platform Top-Level Project (the 
        &quot;Eclipse Test &amp; Performance Project&quot;) 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 &amp; 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 &amp; Performance Project 
        Requirements Group (the &quot;Requirements Group&quot;) 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 &amp; Performance Project 
        Architecture Group (the &quot;Architecture Group&quot;) 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 &amp; Performance Project 
        Planning Group (the &quot;Planning Group&quot;) 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 &amp; 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 &quot;Committer&quot; 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 &quot;core&quot;, 
        and the port code base is known as a Subsystem &quot;port&quot;. 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 &amp; 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 &amp; Performance Project Planning Group 
        will coordinate across Projects.</p>
      <p>The Eclipse Test &amp; 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 &amp; 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 &amp; 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>&nbsp;</p>
    </td>
  </tr>
</table>

</body>
</html>