37 lines
1.1 KiB
Markdown
37 lines
1.1 KiB
Markdown
# Contributing to the Harmony project
|
|
|
|
## Write small P-R
|
|
|
|
Aim for the smallest piece of work that is mergeable.
|
|
|
|
Mergeable means that :
|
|
|
|
- it does not break the build
|
|
- it moves the codebase one step forward
|
|
|
|
P-Rs can be many things, they do not have to be complete features.
|
|
|
|
### What a P-R **should** be
|
|
|
|
- Introduce a new trait : This will be the place to discuss the new trait addition, its design and implementation
|
|
- A new implementation of a trait : a new concrete implementation of the LoadBalancer trait
|
|
- A new CI check : something that improves quality, robustness, ci performance
|
|
- Documentation improvements
|
|
- Refactoring
|
|
- Bugfix
|
|
|
|
### What a P-R **should not** be
|
|
|
|
- Large. Anything over 200 lines (excluding generated lines) should have a very good reason to be this large.
|
|
- A mix of refactoring, bug fixes and new features.
|
|
- Introducing multiple new features or ideas at once.
|
|
- Multiple new implementations of a trait/functionnality at once
|
|
|
|
The general idea is to keep P-Rs small and single purpose.
|
|
|
|
## Commit message formatting
|
|
|
|
We follow conventional commits guidelines.
|
|
|
|
https://www.conventionalcommits.org/en/v1.0.0/
|