development checklists

Back to: QA Page or Development Page

Note: The checklists have been blocked so they can be easily copied and pasted into a merge request or issue comment. This syntax will generate a list with checkable boxes, but the reviewer should include notes preferably using emphasis such as the double underscore '__' as an added means of permanence since in some cases other users can alter the state of the checkbox.

Issue Review Checklist

This checklist is for initial adding of an issue.

Issue Review Checklist
- [ ] 1. Is it tagged with a type: defect or improvement?
- [ ] 2. Is it tagged with a priority: critical, normal or minor?
- [ ] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
- [ ] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
- [ ] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

Please be sure to address each item in a comment on the issue.

Peer Review Checklist for Merge Requests

This is for any merge.

Merge Review Checklist
- [ ] 1. Review all computer code.
- [ ] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
- [ ] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the [wiki](https://github.com/idaholab/raven/wiki/RAVEN-Code-Standards#python) for details.
- [ ] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
- [ ] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in <RunInfo> XML block, the node ```<internalParallel>``` to True.
- [ ] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
- [ ] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
- [ ] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
- [ ] 9. If any test used as a basis for documentation examples (currently found in `raven/tests/framework/user_guide` and `raven/docs/workshop`) have been changed, the associated documentation must be reviewed and assured the text matches the example.

Note that for any change that includes code changes we must document in the merge request that a code review was performed and that the regression tests were passed. (From PLN-4006)

Please be sure to address each item in a comment on the merge request.

Issue Close Checklist

This is for anytime an issue is closed.

Issue Closure Checklist
- [ ] 1. If the issue is a defect, is the defect fixed?
- [ ] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.)
- [ ] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
- [ ] 4. If the issue is a defect, does it impact the latest stable branch? If yes, is there any issue tagged with stable (create if needed)?
- [ ] 5. If the issue is being closed without a merge request, has an explanation of why it is being closed been provided?

Please be sure to address each item in a comment on the issue.