Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create CONTRIBUTING.md #54

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# Contributing Practices
## Branching Practices
The `main` branch should be treated as the branch with the last known working code (like for example, the code at the last competition which was known to work).

Branches containing individual features (like the rewrite of our drivetrain code) should branch off `main` for the most part, with the exception of feature branches that require code from other feature branches (like a feature branch that uses the newly written drivetrain code, in this case).

Before opening a pull request, make sure that you've tested your code thoroughly in our simulation to make sure that it works in our simulation, so glaringly obvious errors won't have to be addressed in the pull request reviews and reviews can be focused on enforcing proper code practices.

Before merging a pull request to `main`, make sure that the code has been thoroughly tested on the **robot**. Again, `main` should always have the last known working code.

Releases should be made off the `main` branch for the last known working code, so even if faulty code is pushed to `main` somehow, the last known working code is saved in a release (like the code at the end of a competition that we know works).

## Before you push your code
Make sure to always simulate your code using `./gradlew simulateJava` to thoroughly test the new code you've pushed and always make sure to clean up your code with Spotless Apply so we know that our code follows Kotlin code practices.

You can clean up your code to follow Kotlin practices with `./gradlew spotlessApply`. If you don't clean up your code with Spotless Apply, your code won't be able to be merged because the workflows will fail, enforcing that your code follows the Kotlin code practices.

When committing your code, use descriptive messages. If you're pushing code that adds a new state to superstructure which flashes the LEDs blue when a certain task occurs, don't write something like `"superstructure changed"`. Instead, write something more descriptive like `"Added new superstructure state for flashing LEDs blue when [task]"`.
Loading