Please refer to Bugzilla entry #240475 to join the discussion about this proposal. This document will be valid when all agree

People often ask "What does it take to get involved with the development of the Eclipse PDT?" There are many ways to get involved. On the lightweight end of scale, there is involvement by using the Eclipse PDT and providing feedback and sharing your experiences on the Eclipse and Eclipse PDT 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 by enhancing a particular area of the tool or by creating new functionality.

The purpose of this document is to help people and organizations understand what it means to "commit" to Eclipse PDT Development at this highest level. Basically, it involves a commitment to describe, develop, test and document your contributions.

Communicating Your Desires/Intentions

The first step involves letting the Eclipse PDT user community and other Eclipse PDT development team members know what you propose to do. The mechanism for this is to create Bugzilla entries to describe the enhancements or new capabilities you are proposing. 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.

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.

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 Eclipse PDT community and the rest of the Eclipse PDT development team to understand what you are doing and to provide feedback. The format of these documents is not important, the content is.

Becoming a committer

Every developer's contribution is welcomed. And in time, developers can become committers. A committer is a developer who has write access to the source code repository for Eclipse PDT, and has voting rights which allow them to affect the future of Eclipse PDT. Other developers define patches and submit them, indirectly, through committers. A developer gains such committer rights through frequent and valuable contributions to Eclipse PDT. For more information in what it means to be or to become an Eclipse project committer, see the Eclipse PDT Project Charter. We should point out that creating and submitting quality patches is the best way to obtain committer privileges for future work.

Delivering the Code

Once the feature and design documents have been distributed to the rest of the Eclipse PDT community and feedback has been collected, its time to start pushing the code changes into the development stream. For those that have committer privileges, these changes can be pushed directly into the stream. 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 which won't be discussed here.

Commitment To Testing

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 "blessed" as we progress through the release candidates.

Therefore, committing to contribute significant code to the Eclipse PDT also means committing to participation in the test-fix cycles by executing your test plans against the release candidates build leading up to the final release build.

Commitment to Documentation

An important part of any enhancement or addition to the Eclipse PDT 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. The on-line documentation content should be sent to the pdt-dev group in html format for approval by the PDT technical writer.

So, finally, committing to contribute code to the Eclipse PDT also means committing to contributing the associated on-line documentation content for the part of the tool that is being enhanced or created.

• PDT development environment (checking out the code)
• Conventions and Guidelines
• Articles about PDT development
• Unit testing for PDT
• Working procedures
• Project plan