development/contributing.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Eclipse Web Tools Platform Project Development</title>
<link rel="stylesheet" href="../../default_style.css" type="text/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 web tools platform project</font><br>
        <font class="indexsub">contributing to the wtp project</font></td>
        <td width="40%"><img src="../../images/Idea.jpg" hspace="50" height="86" width="120" align="middle" alt=""></td>
    </tr>
</table>
<table border="0" cellspacing="5" cellpadding="2" width="100%">
    <tr>
        <td align="LEFT" valign="TOP"><i>This document was inspired by the <a class="external"
            href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/developer/Commitment.html?cvsroot=Tools_Project"
            target="_top">Contributing to the CDT document</a><!-- This image doesn't exist. <img class="outlink" src="../jst/images/out.png" alt="" width="6" height="6" />--></i>
        </td>
    </tr>
    <tr>
        <td align="LEFT" valign="TOP" bgcolor="#0080C0"><b> <font face="Arial,Helvetica" color="#FFFFFF">Introduction</font></b></td>
    </tr>
    <tr>
        <td valign="top">
        <p>People often ask, &quot;What does it take to get involved with the development of the WTP?&quot; There
        are many ways to get involved. On the lightweight end of scale, there is involvement by using the WTP and
        providing feedback and sharing your experiences on the Eclipse and WTP <a href="/forums/eclipse.webtools">newsgroups</a>. Beyond that, you can <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?classification=WebTools">report problems</a>
        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 WTP Development at this highest level. Basically, it involves a commitment to describe,
        develop, test and document your contributions.</p>
        </td>
    </tr>
    <tr>
        <td align="LEFT" valign="TOP" bgcolor="#0080C0"><b> <font face="Arial,Helvetica" color="#FFFFFF">Commitment
        to Development</font></b></td>
    </tr>
    <tr>
        <td valign="top">
        <h4>Communicating Your Desires/Intentions</h4>
        <p>The first step involves letting the WTP user community and other WTP development team members what you
        propose. 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. Bugzilla is seen here as a central repository of
        reference for enhancement demands as well as bug reports.  All known bug reports should be in Bugzilla.  A 
        bug that goes unreported will likely never be fixed.</p>
        <p>Bugzilla is the open source change management system used by Eclipse projects. To set these Bugzilla
        entries apart from other problem reports, Committers should use the word &quot;plan&quot; 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 WTP community and the rest of
        the WTP 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></p>
        <h4>Contributing Your Code (or other changes)</h4>
        <p>Every high quality contribution is welcomed, be it from a a Committer or a developer just fixing the one bug
        they're interested in. A Committer is a developer who has write access to the source code repository for the associated subproject (or
        component) and has voting rights allowing them to affect the future of the subproject (or component); other
        developers define patches and submit them, indirectly, through Committers. A developer gains such Committer
        rights through frequent and consistently valuable contributions to a subproject, or component of a subproject (in the case of
        large subprojects). For more information in what it means to be or to become an Eclipse project or subproject
        Committer, see the <a class="wikipage" href="../project-charter.html">WTP 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></p>
        <p></p>
        <h4>Delivering the Code</h4>
        <p>Once the feature and design documents have been floated to the rest of the WTP community and feedback has
        been harvested, its time to start pushing the code changes into the development stream. For those that have
        Committer privileges, these changes can be committed directly into the repository. Those without Committer privileges
        create patches that get reviewed and applied by Committers. Patch requests are communicated via attachments to
        Bugzilla bugs. Being a Committer entails certain responsibilities on its own which won't be discussed here.</p>
        <p>Patches from non-Committers are generally expected to have been made against the HEAD branch, generated from
        Eclipse with the Workspace option enabled and in the Unified format.  <a href="http://www.eclipse.org/webtools/community/tutorials/DevelopingWTP/DevelopingWTP.html">See here</a>
        for a more complete walkthrough.</p>
        <p></p>
        <h4>Commitment To Testing</h4>
        <p>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 way 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 WTP 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></p>
        <h4>Commitment to Documentation</h4>
        <p>An important part of any enhancement or addition to the WTP is making sure that the on-line help of the
        tool stays current with the changes. The responsibility for updating/modifying/writing 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 commit 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 WTP project, you may refer to the <a
            class="external"
            href="http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/cdt-home/user/docs.html?cvsroot=Tools_Project"
            target="_top">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 WTP 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>