Checklist for enhancements and defects

This document requires some bare-minimum knowledge of eclipse plug-ins and intends to clarify and expose certain technical requirements for the TPTP Development Process.

Tracking Enhancements
Enhancement Checklist
Defect Checklist

Tracking Enhancements

For every enhancement that has to be implemented via multiple check-ins, ensure that there is a separate bugzilla defect for each check-in, and for each defect follow the Resolving Defects process documented below. An enhancement may require multiple check-ins for several reasons:

The enhancement is implemented by more than one person (each person has their own defect to track their part of the enhancement),
The enhancement must span iterations (a defect to track which part of the work is complete in each iteration),
That's the unit of work that makes sense; e.g. if part of an enhancement requires updates to an editor and updates to a wizard, and all of the wizard work can be completed separately from the editor work, then there could be a defect for the editor and another defect for the wizard, and the feature would be dependent on both defects.
Personal preference (some people prefer many small check-ins over a single large check-in.)

Then make the enhancement dependent on the defects; i.e., in the "Bug XXXXX depends on" field of the bugzilla enhancement, type the bugzilla id of the defect(s) and click "Commit".

Resolving Enhancements

Before marking an enhancement "RESOLVED" or "FIXED" make sure that all of the items in this list are complete. Note that the obvious instructions, unit test and check in the code, are deliberately omitted from this list.

	1.	Follow the Eclipse Conventions [Details].
	2.	Follow the Eclipse User Interface Guidelines [Details].
	3.	Follow the Eclipse API Conventions [Details].
	4.	(Optional but recommended) Have a peer review the code or think of tests for the enhancement. [Details].
	5.	Add a test case to the functional test suite. [Details]
	6.	If applicable, write a TVT test case to cover the new function. [Details]
	7.	If applicable, write an enablement test case to cover the new function. [Details]
	8.	If applicable, add a case for the new provisional or public API. [Details]
	9.	If applicable, add Javadoc for the new provisional or public API. [Details]
	10.	Ensure that the on-line Help documentation is up-to-date. [Details]
	11.	Update the description document. [Details]
	12.	Ensure that all .properties, .xml, and .html files are well-formed. [Details]
	13.	Ensure that all code going into CVS is marked with a Bugzilla ID. [Details]
	14.	Externalize all strings to a .properties file. [Details]
	15.	Get IWAT message IDs for all your errors. [Details]
	16.	If applicable, open a defect to put information into the migration guide. [Details]

Resolving Defects

Before marking a defect "RESOLVED" or "FIXED" make sure that all of the items in this list are complete. Note that the obvious instructions, unit test and check in the code, are deliberately omitted from this list.

	1.	Follow the Eclipse Conventions [Details]
	2.	Follow the Eclipse User Interface Guidelines [Details]
	3.	Follow the Eclipse API Conventions [Details].
	4.	Add a test case to the functional test suite. [Details]
	5.	If applicable, update the TVT test case that was affected. [Details]
	6.	If applicable, update the enablement test case that was affected. [Details]
	7.	If applicable, update the test case for the API. [Details]
	8.	If applicable, update the Javadoc for the API. [Details]
	9.	If applicable, update the on-line Help documentation. [Details]
	10.	Ensure that all .properties, .xml, and .html files are well-formed. [Details]
	11.	Ensure that all code going into CVS is marked with a Bugzilla ID. [Details]
	12.	Externalize all strings to a .properties file. [Details]
	13.	Get IWAT message IDs for all your errors. [Details]