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.
- Ways to run Rubocop:
-
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
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 runningopen coverage/index.html
. Please make sure to not decrease ourcurrent % covered
and add appropriate test cases when necessary. -
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. -
When removing a method, don't forget to deprecate it. You can
extend Gem::Deprecate
and use thedeprecate
method to accomplish this task. -
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 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?
- 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
.- use dash syntax for yaml arrays:
# this
a_things:
- small_thing
- big_thing
- other_thing
# instead of these:
b_things: [small_thing, big_thing, other_thing]
c_things: [
small_thing,
big_thing,
other_thing,
]
# If in doubt, `bundle exec rake reformat_yaml['lib/path/to/file.yml']`
- In general, follow the conventions you see used in the source already.
- ALL SHALL OBEY THE RUBOCOP
- Use the
rake console
task to start a session with Faker loaded.