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:
bundle && bundle exec rake
We are using Rubocop because we love static code analyzers.
Ways to run Rubocop:
bundle exec rubocop
bundle exec rakewould run the test suite and after that it runs the Ruby static code analyzer.
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! We use Minitest in this project.
Make the test pass. Always use
randfrom the Base class (just like the rest of the code) rather than
Kernel#randto preserve the deterministic feature.
We care about code coverage and use
SimpleCovto analyze the code and generate test coverage reports. It's possible to check the test coverage by running
bundle exec rake coverage_report. Please make sure to not decrease our
current % covered.
When adding a new class, add a new yaml file to
lib/locales/enrather than adding translations to
lib/locales/en.yml. For example, if you add Faker::MyThing, put your translations in
lib/locales/en/my_thing.yml. See the locale README for more info.
Methods with optional arguments should use keyword rather than positional arguments. An exception to this could be a method that takes only one optional argument, and it's unlikely that that method would ever take more than one optional argument.
Push to your fork and submit a pull request.
Github Flow for contributors and collaborators
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 youserlf:
- 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?
- Two spaces, no tabs.
- No trailing whitespace. Blank lines should not have any space.
my_method( my_arg )or
a = band not
- Follow the conventions you see used in the source already.
- Use the
rake consoletask to start a session with Faker loaded.