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 rake
would run the test suite and after that it runs the Ruby static code analyzer. If you want to try to fix the rubocop violations, you should runbundle exec rubocop -a
to try to autocorrect the issues. If this last command doesn't solve the violations, you'll need to google.
If you are not familiar with Rubocop, spend some time studying their page and a few study cases on the internet.
-
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. If you're not familiar with Minitest and are comfortable with Rspec, please ask a contributor/collaborator to review your PR.
-
Make the test pass. Always use
sample
,shuffle
, andrand
from the Base class (just like the rest of the code) rather thanArray#sample
,Array#shuffle
andKernel#rand
to preserve the deterministic feature. -
We care about code coverage and use
SimpleCov
to analyze the code and generate test coverage reports. It's possible to check the test coverage by runningbundle exec rake coverage_report
. Please make sure to not decrease ourcurrent % covered
. -
When adding a new class, add a new yaml file to
lib/locales/en
rather than adding translations tolib/locales/en.yml
. For example, if you add Faker::MyThing, put your translations inlib/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.
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.
- Prefer
&&
,||
overand
,or
. MyClass.my_method(my_arg)
notmy_method( my_arg )
ormy_method my_arg
.a = b
and nota=b
.- Follow the conventions you see used in the source already.