53 lines
2.0 KiB
Markdown
53 lines
2.0 KiB
Markdown
# How to Contribute
|
|
|
|
Corteza projects are [Apache 2.0 licensed](LICENSE) and accept contributions via
|
|
GitHub pull requests. This document outlines some of the conventions on
|
|
development workflow, commit message formatting, contact points and other
|
|
resources to make it easier to get your contribution accepted.
|
|
|
|
# Certificate of Origin
|
|
|
|
By contributing to this project you agree to the Developer Certificate of
|
|
Origin (DCO). This document was created by the Linux Kernel community and is a
|
|
simple statement that you, as a contributor, have the legal right to make the
|
|
contribution. See the [DCO](DCO) file for details.
|
|
|
|
# Getting Started
|
|
|
|
- Fork the repository on GitHub
|
|
- Read the [Wiki](https://github.com/cortezaproject/corteza-server/wiki) for build and test instructions
|
|
- Play with the project, submit bugs, submit patches!
|
|
|
|
## Contribution Flow
|
|
|
|
This is a rough outline of what a contributor's workflow looks like:
|
|
|
|
- Create a topic branch from where you want to base your work (usually master).
|
|
- Make commits of logical units.
|
|
- Make sure your commit messages are in the proper format (see below).
|
|
- Push your changes to a topic branch in your fork of the repository.
|
|
- Make sure the tests pass, and add any new tests as appropriate.
|
|
- Submit a pull request to the original repository.
|
|
|
|
Thanks for your contributions!
|
|
|
|
### Format of the Commit Message
|
|
|
|
See [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
|
|
|
|
Summary of the article and the seven rules of a great Git commit message
|
|
|
|
1. Separate subject from body with a blank line
|
|
2. Limit the subject line to 50 characters
|
|
3. Capitalize the subject line
|
|
4. Do not end the subject line with a period
|
|
5. Use the imperative mood in the subject line
|
|
6. Wrap the body at 72 characters
|
|
7. Use the body to explain what and why vs. how
|
|
|
|
We are not terribly strict against a particular commit message format, but
|
|
the general rule is to avoid non-descriptive single-word commit messages like "fix".
|
|
|
|
We might ask you to rewrite/rebase your commit messages if they land too far from the
|
|
rules above.
|