We love pull requests. Here's a quick guide:
- Fork the repo.
- Run the tests. We only take pull requests with passing tests, and it's great to know that you have a clean slate:
mix deps.get && mix test - We do
mix formatto keep our code base consistent and clean. - Please add a test for your change. Only refactoring and documentation changes require no new tests. If you are adding functionality or fixing a bug, we need a test!
- If you're adding doctests, please make sure to include 4 examples. 4 is our magic number in this library and this is our pattern.
- When removing a method, don't forget to deprecate it. You can use
@deprecated "message"to deprecate a faker interface method. - Push to your fork and submit a pull request.
For those of you with commit access, please check out Scott Chacon's blog post about github flow
- Anything in the master branch is deployable
- To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
If you're reviewing a PR, you should ask yourself:
- Does it work as described? A PR should have a great description.
- Is it understandable?
- Is it well implemented?
- Is it well tested?
- Is it well documented?
- Is it following the structure of the project?