-
Notifications
You must be signed in to change notification settings - Fork 21
development checklists
Andrea Alfonsi - INL edited this page Jul 31, 2020
·
2 revisions
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.
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 is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
- [ ] 4. 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.
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. If the input syntax change deprecates existing input files, a conversion script needs to be added.
- [ ] 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) for details.
- [ ] 4. Regression Test script should be run by the reviewer on the branch and pass (run “./run_tests --plugins” in RAVEN root after installing the plugin)
- [ ] 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.
- [ ] 6. The merge request must reference an issue. If the issue is closed, the issue close checklist shall be done.
Please be sure to address each item in a comment on the merge request.
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 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.