| 1 | # How to contribute
|
| 2 |
|
| 3 | We'd love to accept your patches and contributions to this project. There are a just a few small guidelines you need to follow.
|
| 4 |
|
| 5 | ## Submitting a patch
|
| 6 |
|
| 7 | 1. It's generally best to start by opening a new issue describing the bug or
|
| 8 | feature you're intending to fix. Even if you think it's relatively minor,
|
| 9 | it's helpful to know what people are working on. Mention in the initial
|
| 10 | issue that you are planning to work on that bug or feature so that it can
|
| 11 | be assigned to you.
|
| 12 |
|
| 13 | 2. Considering each syndication client seem to have their own specificities, make
|
| 14 | sure you provide enough information about the client in question if you want
|
| 15 | to add new elements or update existing ones. Link to their official documentation
|
| 16 | and provide examples.
|
| 17 |
|
| 18 | 3. Create and run tests. Your new addition must be covered by unit tests.
|
| 19 |
|
| 20 | 4. Follow the normal process of [forking][] the project, and setup a new
|
| 21 | branch to work in.
|
| 22 |
|
| 23 | 5. Do your best to have [well-formed commit messages][] for each change.
|
| 24 | This provides consistency throughout the project, and ensures that commit
|
| 25 | messages are able to be formatted properly by various git tools.
|
| 26 |
|
| 27 | 6. Finally, push the commits to your fork and submit a [pull request][].
|
| 28 |
|
| 29 | [forking]: https://help.github.com/articles/fork-a-repo
|
| 30 | [well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
| 31 | [squash]: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits
|
| 32 | [pull request]: https://help.github.com/articles/creating-a-pull-request
|