project-template/CONTRIBUTING.md

Contributing to RideAware Projects

First off, thank you for considering contributing! It's people like you that make RideAware a great community.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open-source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.

Code of Conduct

We take our community and our code of conduct seriously. By participating, you are expected to uphold this code. Please report unacceptable behavior to blake@rideaware.org. Read our full CODE_OF_CONDUCT.md.

How Can I Contribute?

Reporting Bugs

• Ensure the bug was not already reported by searching on GitLab under Issues.
• If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.

Suggesting Enhancements

• Open a new issue, clearly describing the enhancement and the motivation for it.
• Use a clear and descriptive title for the issue to identify the suggestion.

Merge Request Process

1. Fork the project and create your branch from main: git checkout -b feature/AmazingFeature or bugfix/FixThatBug.
2. Make your changes. Please write clean code and add comments where necessary.
3. Update the README.md with details of changes to the interface, if applicable.
4. Add or update tests to ensure your changes are covered.
5. Ensure all tests pass locally before pushing.
6. Commit your changes using our commit message guidelines (see below).
7. Push to the branch: git push origin feature/AmazingFeature.
8. Open a Merge Request to the main branch of the original repository.
9. A project maintainer will review your Merge Request.

Commit Message Guidelines

We follow a convention for our commit messages that helps us maintain a clear and automated project history. Please follow this format for your commits.

Each commit message consists of a header, an optional body, and an optional footer.

<type>: <subject>

[optional body]

[optional footer]

---

Header

The header is mandatory and should be a single line that contains a succinct description of the change.

<type>: <subject>

Allowed type values:

• feat: A new feature
• fix: A bug fix
• docs: Changes to documentation only
• style: Style/format changes (whitespace, semi-colons, etc.)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to our CI configuration files and scripts

Subject:

The subject contains a short description of the change.

• Use the imperative, present tense: "change" not "changed" nor "changes".
• Don't capitalize the first letter.
• No dot (.) at the end.

---

Body (Optional)

The body should provide more detail about the changes. Use it to explain the motivation behind the change and contrast it with previous behavior.

---

Footer (Optional)

The footer is used to reference tracking IDs like GitLab Issues or Merge Requests.

• Example: Resolves #207
• Example: See merge request !15

---

Examples

A simple fix:

fix: correct validation for user email format

A new feature with a body and footer:

feat: add user password reset API endpoint

Implement the /api/users/reset-password endpoint. This includes
generating a secure, single-use token and sending an email to the
user with the reset link.

Resolves #88

A change to the CI pipeline:

ci: add linting stage to build pipeline

---

Thank you for your contribution!