8611afa3f0
Establish a formal convention for Git commit messages to improve the clarity and readability of the project's history. This standard follows the Conventional Commits specification and will enable potential future automation for changelog generation.
138 lines
No EOL
4.1 KiB
Markdown
138 lines
No EOL
4.1 KiB
Markdown
# 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](CODE_OF_CONDUCT.md).
|
|
|
|
## How Can I Contribute?
|
|
|
|
### Reporting Bugs
|
|
|
|
- **Ensure the bug was not already reported** by searching on GitLab under
|
|
[Issues](https://gitlab.com/rideaware/[repo-name]/-/issues).
|
|
- If you're unable to find an open issue addressing the problem,
|
|
[open a new one](https://gitlab.com/rideaware/[repo-name]/-/issues/new).
|
|
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! |