There are many ways to get involved and contribute to Eclipse TPTP.
On one level, it is extremely valuable to have developers use the TPTP Platform, provide feedback and share experiences on the TPTP newsgroups. Additionally, any problems can be reported, so that they may be addressed in future releases.
Another level of involvement would be to actually solve some of the problems that may be uncovered by modifying or writing the necessary code and creating patches that can be 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 enhancing a particular area of the tool or creating new functionality.
Communicating Your Desires/Intentions
After deciding to become an official TPTP Contributor, 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 Bugzilla, the open source change management system used by Eclipse Projects. To ensure that these Bugzilla entries are seen apart from problem reports, the word "plan" should be used in the keywords field, and the severity of the entry should be set to "enhancement". This should be used to describe the enhancements or new capabilities you propose to do. The mailing lists and newsgroups could also be used for discussing or proposing, in a more informal way, enhancements or new capabilities. 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 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 up to the writer. Please make sure to include enough detail provide clear understanding of your ideas.
Becoming a Committer
As a completely open source project, every developer's contribution is welcomed. 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 him/her to affect the future of the Project (or Subsystem). Other developers define patches and submit them, indirectly, through Committers.
A developer can gain 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 TPTP Project Charter. 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 Test & Performance Project community, feedback has been collected and approval for the work has been given, the code changes can be pushed 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 additional responsibilities.
Commitment to Testing
Everyone who contributes content to Eclipse projects is expected and required 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 required 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.
Committing to contribute significant code to the TPTP also means committing to participate in the test-fix cycles by executing 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 TPTP 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.
Back to the top