| <!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>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, "What does it take to get involved with the development |
| of the Test & Performance Project?" 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 & 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 "commit" to the Test & 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 & 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 "plan" should be used in the keywords field, and the |
| severity of the entry should be set to "enhancement". 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 & 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 & Performance Project Committer, see the <a href="charter.html">Test |
| & 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 & 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 "blessed" as we progress through |
| the release candidates. </p> |
| <p>So, committing to contribute significant code to the Test & 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 & |
| 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 & 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> |
