Evaluation during Harvesting
Last updated at 4:35 pm UTC on 16 January 2006
Goals of the harvesting process
Note that as of the 3.9 alpha development period all bug, fixes, and enhancements are now submitted to the Mantis Server and all evaluations should be made there. Many of the guidelines below relate to the past when email was used for all communication and (obsolete) BFAV was used to manage reports. These guidelines can still be used as guidelines but can and should be adapted now that the process has changed.
Criteria that every submission must satisfy
- Submission must be a Change Set (CS), filed out from a change sorter
- CS must include a Preamble describing
- For [ENH]: what the enhancement does and why it is valuable
- For [FIX]: what the bug was and how this fixes it. Please also include instructions for reproducing the bug
- (include link to good example preambles)
- Please provide a short summary of what testing has been done on the changes (if any)
- Any known problems with the change set (things that it breaks, ...) should be described
- Please do NOT send class fileOuts, .st files, or include the change set text in the body of your email
Proposal 1: For core parts of the system, changes should be considered if it is either clearly non-disruptive (e.g. comment change, clear bug fix), or important. For more peripheral parts of the system (e.g. Blob morph, or IRC chat), the quality review need not be so detailed though clearly substandard code should be rejected.
Proposal 2: Keeping the system understandable and reliable should be one of the most important criteria. We should generally avoid adding kludges, unless it is clearly a short term work around
Questions to consider when harvesting:
- Are the changes of general use?
- Do they conflict with other changes being considered for the system?
- How well tested are they?
- Are the changes to important subsystems?
- Are the changes localized? (e.g. only a few classes or methods?)
- Does this simplify the system?
- If it does not simplify the system, does it add significant value to offset the added complexity?
- Are the changes clearly documented?
- Email description
- Change Set Preamble
- Class comments
- Method comments