code review documentation (#34)

* add a pull request template

* add more pr checklist items

* add review guidelines document

* add review slas document

.github/pull_request_template.md

@@ -0,0 +1,28 @@
+# Pull Request
+
+## Description
+[Provide a brief description of the changes implemented in this pull request.]
+
+## Related Issues
+[Link any related issues or tasks from your project management system.]
+
+## Additional Notes
+[Add any additional context or notes that reviewers should know about.]
+
+## Checklist
+Please review and complete the following checklist before submitting your pull request:
+
+- [ ] I have ensured that the pull request is of a manageable size, allowing it to be reviewed within a single session.
+- [ ] I have reviewed my changes to ensure they are clear, concise, and well-documented.
+- [ ] I have updated the documentation, if applicable.
+- [ ] I have added or updated test cases to cover my changes, if applicable.
+- [ ] I have minimized the number of reviewers to include only those essential for the review.
+- [ ] I have notified teammates in the review thread to build awareness.
+
+## Checklist for Reviewers
+Please review and complete the following checklist during the review process:
+
+- [ ] The code follows best practices and conventions.
+- [ ] The changes implement the desired functionality or fix the reported issue.
+- [ ] The tests cover the new changes and pass successfully.
+- [ ] Any potential edge cases or error scenarios have been considered.

REVIEW_GUIDELINES.md

@@ -0,0 +1,55 @@
+# Code Review Guidelines
+
+Welcome to the code review process for the CDCgov/IDWA project. Code reviews are essential for maintaining code quality, sharing knowledge, and fostering collaboration among team members. Please consider these guidelines to ensure effective and constructive code reviews.
+
+## Goals of Code Reviews
+
+- Identify bugs and potential issues early in the development process.
+- Ensure code adheres to project standards, best practices, and coding conventions.
+- Share knowledge and encourage learning among team members.
+- Improve the overall quality and maintainability of the codebase.
+
+## Before Reviewing Code
+
+Before starting the code review process, make sure to:
+
+- Read the summary in full to understand the purpose and scope of the changes.
+- Review any relevant documentation or design specifications linked in the summary.
+
+## During the Review
+
+During the code review process, keep the following in mind:
+
+- **Be Respectful**: Use a friendly and respectful tone in your comments.
+- **Focus on the Code**: Base your comments and suggestions on the code itself, not the author.
+- **Be Constructive**: Provide specific feedback and suggestions for improvement.
+- **Ask Questions**: If something is unclear or seems inconsistent, don't hesitate to ask for clarification.
+- **Offer Alternatives**: Instead of just pointing out problems, suggest alternative approaches or solutions.
+- **Consider Readability**: Ensure the code is easy to read, understand, and maintain.
+- **Check for Edge Cases**: Verify that the code handles edge cases, error conditions, and boundary scenarios.
+- **Review Test Coverage**: Check if the code is adequately tested and whether new tests are needed.
+- **Validate Security**: Look for potential security vulnerabilities and ensure sensitive data is handled securely.
+
+## Providing Feedback
+
+When providing feedback on a pull request, consider using the following templates to structure your comments:
+
+- **Positive Feedback**: Highlight what was done well and why it's effective.
+- **Constructive Criticism**: Identify areas for improvement and suggest specific changes.
+- **Questions**: Seek clarification on unclear or ambiguous parts of the code.
+- **Suggestions**: Offer alternative approaches or solutions to the problem.
+
+## After the Review
+
+After completing the code review, ensure that:
+
+- All review comments have been addressed satisfactorily.
+- The code meets the project requirements and standards.
+- Tests pass successfully, and any new tests have been added.
+- The changes are well-documented and explained where necessary.
+
+## Conclusion
+
+Thank you for your dedication to maintaining code quality through code reviews. By following these guidelines and collaborating effectively with your team members, we can continue to deliver high-quality software that meets our users' needs.
+
+Happy reviewing!

REVIEW_SLAS.md

@@ -0,0 +1,35 @@
+# Code Review Service Level Agreements (SLAs)
+
+The following Service Level Agreements (SLAs) are established to ensure timely and effective code reviews within the CDCgov/IDWA project:
+
+## Response Time SLA
+
+- **Priority**: High
+- **Target Response Time**: Within 24 hours of the pull request submission
+- **Description**: Reviewers commit to providing initial feedback on the pull request within 24 hours of its submission. This feedback may include identifying potential issues, requesting further clarification or asking for additional time to review.
+
+## Review Completion SLA
+
+- **Priority**: Medium
+- **Target Completion Time**: Within 3 business days of the pull request submission
+- **Description**: Reviewers commit to completing the entire review process, including addressing feedback and approving or rejecting the pull request, within 3 business days of its submission. This ensures that pull requests are processed in a timely manner and do not remain open for an extended period.
+
+## Escalation Procedure
+
+- **Escalation Trigger**: Review exceeds response time SLA or completion SLA
+- **Escalation Contact**: @bryanbritten or @zdeveloper
+- **Description**: In the event that a pull request review exceeds the defined SLAs, the submitter or reviewer may escalate the issue to the designated escalation contact. The escalation contact will investigate the delay and take appropriate actions to expedite the review process.
+
+## Exceptions
+
+- **Exception Criteria**: Holidays, team member unavailability, or exceptional workload
+- **Description**: SLAs may be temporarily adjusted or waived in exceptional circumstances, such as during holidays, when team members are unavailable, or when the team is experiencing an exceptional workload. In such cases, affected parties will communicate the adjusted expectations and timelines accordingly.
+
+## Regular Review of SLAs
+
+- **Frequency**: Annually
+- **Description**: SLAs will be reviewed and evaluated annually to ensure they remain relevant and effective. Feedback from team members and observations of the review process will be considered when making adjustments to the SLAs.
+
+---
+
+By adhering to these SLAs, we aim to facilitate efficient and collaborative code review processes, ultimately contributing to the overall quality and velocity of our software development efforts.