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