Skip to content

Guidelines

Jump to bottom
arthur-mrgt edited this page Oct 4, 2024 · 1 revision

Guidelines

This section defines the workflows that maintain code quality and productivity.

Pull Request Guidelines

  • Code should be tested locally before submission to ensure that everything works as expected.
  • Pull requests should include a clear and detailed description of the changes:
    • Outline the purpose of the modifications.
    • Provide any relevant context or background information.
    • Explain how the changes were tested (e.g., manual tests, unit tests, etc.).
  • Ensure that the PR is small and focused. Large PRs are harder to review and prone to delays. Try to limit the scope of the PR to a specific feature, bug fix, or enhancement.
  • Follow the coding standards and conventions established by the team to maintain consistency in the codebase.
  • Include unit tests and integration tests where applicable, to validate the new functionality and ensure that existing features are not broken.
  • Keep the commit history clean and meaningful. Avoid unnecessary commits or rebase/squash commits before merging if required by the team.
  • Make sure the branch is up to date with the base branch before submitting the PR to avoid merge conflicts later on.

Pull Request Review Guidelines

  • Reviewer Rotation: Each PR must be reviewed by at least two different team members, and reviewers should rotate for every PR. This ensures that each developer's PR is reviewed by different people than their previous one, providing diverse perspectives on the code.
  • Choice of Reviewer: The developer submitting the PR has the option to choose one of the two reviewers if the selected reviewer has specific knowledge or involvement related to the code being reviewed. The second reviewer will be assigned by rotation.
  • Read the entire code and comment on sections that could be improved or where issues may arise. Ask questions when something isn’t clear or seems off.
  • When reviewing a new feature, ensure design patterns are properly applied and look for potential integration issues.
  • When reviewing changes to existing code, the code and commit messages together should clearly explain the changes, making them understandable even months later.
  • Leave positive feedback when appropriate (e.g., praise for refactoring code, improving performance, or solving complex problems).
  • Prefix your comments with a descriptor such as "Important", "Question", or "Nitpick" to give context to the nature of your feedback. This helps the author prioritize which comments require action.
  • Focus on constructive criticism. Instead of targeting the author, frame suggestions around improvements to the code (e.g., "Have you considered…?" or "A possible improvement could be…").
  • If you have no major issues, it's acceptable to comment with "LGTM" (Looks Good To Me) for small changes or bug fixes. However, for larger PRs, always aim to discuss or clarify elements of the code.
  • Ensure the review is done in a timely manner to avoid blocking the team’s progress.
  • All code reviews should be conducted in English to maintain consistency and facilitate collaboration within the team.

Communication Protocol for Complex Merges

  • Use Discord to discuss potential merge conflicts before pushing.
  • Create small, incremental pull requests to avoid large merge conflicts.
  • TODO: COMPLETE

Branch Naming Conventions

  • feature/feature-name
  • bugfix/issue-number
  • hotfix/issue-description

Testing Protocol

  • All new features must include unit tests using JUnit.
  • Use MockK for mocking dependencies during tests.
  • Test coverage should not decrease after a pull request is merged.
  • TODO: COMPLETE
Clone this wiki locally