Repository Workflow Rules

In order to maintain a smooth and efficient development process, we follow these repository workflow rules:

IMPORTANT: Keep the project board updated with your tasks. When you start a task, put it in the "In Progress" column. When you make a PR for your issue, put the associated issue in the "Under Review" column in the Project Board. Similarly, when the PR is merged, close the associated issue and remove it from the project. This makes sure that we know what you are working on or if you are waiting for a review and can start a task in the meantime. Of course, communication through Discord is more important, but keeping the Project Board updated helps a lot.

1. Code Review and Testing

• When reviewing code, only approve if the code has been tested using the sim. If you cannot run the sim for some reason, do not approve the PR!

  Explanation: Testing code using the simulation environment helps ensure that changes do not break the existing functionality and that they are compatible with the simulation setup.

2. Pull Request Description

• When making a pull request to noetic, make sure you describe clearly in the description what changes you made, why you made those changes, any other solutions you considered, and why you decided to implement this one. Also make sure to link the issue this PR relates to in the description of your PR for further context.

  Explanation: Providing a clear and detailed description of your changes and reasoning helps reviewers understand the purpose and impact of your pull request, facilitating a smoother review process.

3. GitHub Project and Task Management

• Only move a task to the "Done" column of the GitHub project when it has been merged into noetic. When a task is under review, move your task to the "Under Review" column so we know to look at it.

  Explanation: This ensures that the project board accurately reflects the status of tasks and avoids prematurely marking tasks as completed.

4. Branch Management

• If you make additional branches on the repo that will not be merged in a pull request, make sure the title clearly describes the purpose of the branch, and always delete any branches which are not immediately useful.

  Explanation: Keeping the branch names and the repository clean by removing unused branches helps maintain a tidy and organized codebase.

5. Communication and Absence

• If you are stuck or confused on a task, reach out to a lead! If we do not hear from you after two weeks and have not been given notice that you will be absent, we will have to consider that you have left the team, and your branches will be deleted or transferred to a different member.

  Explanation: Effective communication is essential for resolving issues and ensuring that tasks progress smoothly. If you are unable to work on a task for an extended period, it's important to inform the team to prevent delays.

6. Branching and Merging

• Always branch off of noetic, and regularly merge noetic into your branch to avoid merge conflicts (do this by running git merge origin/noetic while on your branch).

  Explanation: Starting your branches from the latest version of the main branch (noetic) and merging updates from noetic helps prevent merge conflicts and ensures that your branch remains up-to-date with the latest changes.

7. Assigning Reviewers

• Always assign at least one lead or senior member to your PR so it can be reviewed.

  Explanation: Assigning experienced team members to review your pull requests helps ensure that code quality and project standards are maintained.

8. Cross-Repository Pull Requests

• When making PRs that require changes in both the auv-sim-unity and AUV-2025 repositories, make sure you put a link to the other dependent PR in both PRs!

  Explanation: Linking dependent pull requests between repositories helps maintain a clear and organized workflow when changes span multiple repositories.

9. Documentation

• When you merge PRs, make sure that your code is thoroughly commented, any new dependencies that must be installed are added to the installation script, and that you update the Wiki such that it reflects any changes to package structure or functionality! As a code reviewer, make sure you double check that this has been done as well!

  Explanation: If this is not done, the documentation quickly becomes outdated and catching it up to the latest version of the codebase can be extremely time-consuming.

Remember that following these rules contributes to a more efficient and collaborative development process. If you have any questions or need assistance, don't hesitate to reach out to the team leads or senior members.