Skip to content

Latest commit

 

History

History
20 lines (19 loc) · 2.05 KB

MRSubmissionChecklist.md

File metadata and controls

20 lines (19 loc) · 2.05 KB

MR submission Checklist

Before submitting a merge request for review, it is important to ensure that your MR adheres to the following checklist.

  • 1. Self-review the code: Ensure you have thoroughly reviewed the code yourself and addressed any issues or improvements.
  • 2. MR satisfies all specified requirements in the ticket, including bug fixes and new features.
  • 3. MR description includes the purpose of the MR, relevant ticket(s), and a summary of changes made.
  • 4. Provide test steps: Include steps to reproduce the issue or test the new functionality, ensuring other team members can verify the changes.
  • 5. Adhere to MVVM (or other defined) architecture patterns.
  • 6. Avoid code duplication: Reuse components when possible and avoid duplicating code across the codebase.
  • 7. Follow Dart naming conventions: Ensure proper naming conventions are used for variables, classes, and methods.
  • 8. Localizes user-facing strings
  • 9. Includes screenshots/videos of behavior changes: Provide visual evidence of any changes to UI or behavior for easier review and understanding.
  • 10. Formats code correctly & removes commented code
  • 11. Implements proper error handling: Ensure that the code anticipates and handles potential errors and edge cases gracefully.
  • 12. Avoids introducing technical debt: If the PR introduces technical debt, create and link appropriate tickets for future resolution.
  • 13. Includes relevant unit tests: Write unit tests that focus on testing behavior and functionality, rather than merely covering lines of code.
  • 14. Ensures code is performant and scalable: Verify that the changes do not introduce performance issues or bottlenecks, and can scale as needed.
  • 15. Comments are up-to-date and relevant to the code to describe complex logic and to add understanding for other developers.
  • 16. Make sure to address any issues flagged by the linter before submitting the code for MR review.
  • 17. Segregation of code into a proper folder structure namely providers, models, screens/pages, utils.