<!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>Contributing to the Project </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>
<p><b><i>This document was inspired by the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/developer/Commitment.html?cvsroot=Tools_Project" target="_blank">Contributing 
  to the CDT document</a>.</i></b></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">Introduction</font></b></td>
  </tr>
  
  <tr> 
    <td> 
      <p>People often ask, &quot;What does it take to get involved with the development 
        of the Test &amp; Performance Project?&quot; There are many ways to get 
        involved. On the lightweight end of scale, there is involvement by using 
        the Hyades Platform and providing feedback and sharing your experiences 
        on the Eclipse and Test &amp; Performance Project newsgroups. Beyond that, 
        you can report problems that you discover, so that they may be addressed 
        in future releases. A deeper level of involvement would be to actually 
        solve some of the problems that you or others have uncovered by modifying/writing 
        the necessary code and creating patches that can applied by the project 
        committers. The final, and most beneficial way to get involved, is to 
        take responsibility for a significant piece of development work, whether 
        it's enhancing a particular area of the tool or creating new functionality.</p>
      <p>The purpose of this document is to help people and organizations understand 
        what it means to &quot;commit&quot; to the Test &amp; Performance Project 
        development at this highest level. Basically, it involves a commitment 
        to describe, develop, test and document your contributions.</p>
      </td>
  </tr>
</table>
<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
  <tr> 
    <td ALIGN=LEFT VALIGN=TOP BGCOLOR="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF">Commitment to Development </font></font></b></td>
  </tr>
  <tr> 
    <td>
      <p><b>Communicating Your Desires/Intentions</b><br>
        The first step involves informing the Test &amp; Performance Project user 
        community and other development team members of your proposal(s). The 
        mechanism for this is to create Bugzilla entries to describe the enhancements 
        or new capabilities you propose to do. The mailing lists and/or newgroups 
        could also be used for discussing or proposing, in a more informal way, 
        enhancements or new capabilities. Anyway, Buzilla is seen here as a central 
        repository of reference for enhancement demands. 
      </p>
      <p>Bugzilla is the open source change management system used by Eclipse 
        projects. To set these Bugzilla entries apart from other problem reports, 
        the word &quot;plan&quot; should be used in the keywords field, and the 
        severity of the entry should be set to &quot;enhancement&quot;. Following 
        these guidelines will ensure that all of these proposals get picked up 
        by the appropriate query and recorded in the plan for the upcoming release. 
      </p>
      <p>Feature specifications (what your code will do) and design specifications 
        (how it will do it) are an important aspect of the development effort. 
        These specifications will allow the Test &amp; Performance Project community 
        and the rest of the development team to understand what you are doing 
        and to provide feedback. The format of these documents is not important, 
        the content is. </p>
      <p><b>Becoming a Committer</b><br>
        Every Developer's contribution is welcomed. And over time, Developers 
        can become Committers. A Committer is a Developer who has write access 
        to the source code repository for the associated Project (or Subsystem), 
        and has voting rights allowing to affect the future of the Project (or 
        Subsystem); other Developers define patches and submit them, indirectly, 
        through Committers. A Developer gains such Committer rights through frequent 
        and valuable contributions to a Project (or Subsystem in the case of large 
        Projects). For more information in what it means to be or to become a 
        Test &amp; Performance Project Committer, see the <a href="charter.html">Test 
        &amp; Performance Project Charter</a>. We should point out that creating 
        and submitting quality patches is the best way to obtain Committer privileges 
        for future work. </p>
      <p><b>Delivering the Code<br>
        </b>Once the feature and design documents have been distribution to the 
        rest of the Test &amp; Performance Project community and feedback has 
        been harvested, its time to start pushing the code changes into the development 
        stream. For Developers that have Committer privileges, these changes can 
        be pushed directly into the stream. Developers without Committer privileges 
        create patches that get reviewed and applied by Committers. Patch requests 
        are communicated via the Project mailing lists. Being a Committer entails 
        certain responsibilities on its own which won't be discussed here. </p>
      <p><b>Commitment To Testing</b><br>
        Everyone that contributes content to Eclipse projects is expected to test 
        their contributions. When contributing a significant enhancement or feature, 
        that commitment means more than just assuring the community that the code 
        has been tested. It means documenting a test plan and committing to execute 
        that testing on release candidate builds. The Eclipse method of generating 
        releases is to generate a series of release candidate builds after all 
        of the development has been completed. Each release candidate goes through 
        a test-fix cycle where everyone tests their contributions and communicates 
        their findings. A collective decision is made as to which problems will 
        get fixed for the next release candidate, and the process is repeated. 
        Fewer and fewer fixes will be &quot;blessed&quot; as we progress through 
        the release candidates. </p>
      <p>So, committing to contribute significant code to the Test &amp; Performance 
        Project also means committing to participate in the test-fix cycles by 
        executing your test plans against the release candidates build leading 
        up to the final release build. </p>
      <p><b>Commitment to Documentation</b><br>
        An important part of any enhancement or addition to the TPP is making 
        sure that the on-line help of the tool stays current with the changes. 
        The responsibility for writing/modifying/updating the on-line help content 
        that is associated with some part of the tool lies with the contributors 
        of the code. Unless the contributors have Committer privileges, the on-line 
        documentation content would get submitted as a patch, much the same as 
        code. And, like code, producing and submitting quality documentation patches 
        is the way to obtain documentation committer privileges. </p>
      <p><i>Until a Documentation Style Guide is available for the Test &amp; 
        Performance Project, you may refer to the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/user/docs.html?cvsroot=Tools_Project" target="_blank">CDT 
        Documentation Style Guide</a> to help maintain a constant look and feel 
        for documentation originating from different contributors. There also 
        a couple of links that take you to additional information on how to contribute 
        help content for Eclipse projects. </i></p>
      <p>So, finally, committing to contribute code to the Test &amp; Performance 
        Project also means committing to contributing the associated on-line documentation 
        content for the part of the tool that is being enhanced or created. </p>
    </td>
  </tr>
</table>
</body>
</html>