Cover image for Too busy to contribute to Rails?
Doctolib Engineering

Too busy to contribute to Rails?

fwuensche profile image Flavio Wuensche Updated on ・3 min read

No more excuses πŸ˜‰ here's an extremely short guide to get you started today!


First, if you haven’t forked the Rails project yet, then go to https://github.com/rails/rails and do it now.

If you’ve already worked with Rails, then there are only three new dependencies to install:

brew cask install virtualbox
brew cask install vagrant
vagrant plugin install vagrant-vbguest

We'll also use the rails-dev-box, a virtual machine for Ruby on Rails core development. This project automates the setup of a development environment for working on Ruby on Rails itself. We'll use the virtual machine to create a local environment with everything we need to start hacking and run the test suites.

git clone https://github.com/rails/rails-dev-box.git
cd rails-dev-box 
git clone git@github.com:YOUR_USERNAME/rails.git # your fork
git checkout -b YOUR_NEW_BRANCH # your new feature or bug fix
vagrant up # this will take a long long time

cd rails
code . # or whatever editor of your choice

Now you can explore the code, make your changes, and write tests. But in order to run the tests, you'll need a little extra step.

Running tests

Since you've already launched your virtual machine with the vagrant up command, all you need now is to ssh into it:

cd rails-dev-box 
vagrant ssh

# vagrant mounts that directory as /vagrant within the virtual machine
vagrant@rails-dev-box:~$ cd /vagrant/rails
vagrant@rails-dev-box:/vagrant/rails$ bundle

Finally, to start running your tests, you can:

# run all the tests
$ cd rails
$ bundle exec rake test # will take a long long time...

# or run a particular component
$ cd actionmailer
$ bundle exec rake test

# or run a specific file
$ cd actionview
$ bundle exec ruby -w -Itest test/template/form_helper_test.rb

# or run a single test
$ cd actionmailer
$ bundle exec ruby -w -Itest test/mail_layout_test.rb -n test_explicit_class_layout

Once everything is ready, you can commit and push to your forked GitHub repo and open a pull request.

Code review

The code review might be the longest part. Depending on how busy the core team is, they can take some time to reply, but be patient. The most important part comes from you. Think about what context you could provide in order for them to quickly understand the issue. Do you have an example? How about screenshots? Add everything to your PR description in a clear way so they can optimize their work πŸ€—

Once you've had someone review your code, you might have some changes to make. Use the previous setup to make the changes, test them locally, and push it again.

Before merging

You’ll need to squash your commits and, if it's been too long since you opened your pull request, you'll also want to rebase your branch on top of the upstream master.

cd rails-dev-box/rails 
git fetch upstream
git rebase -i upstream/master
git push --force origin YOUR_BRANCH_NAME

That should update your PR history and relaunch the CI.

If you need some guidance on how to rebase on top of master, thoughtbot has a pretty detailed article going through the whole workflow.

Keep on contributing

I hope that helps! Here's a sample of a contribution to Rails we made at Doctolib: github.com/rails/rails/pull/37581. Notice how descriptive the comments are and how long a review process can take. That should help you find some inspiration and reduce anxiety 😌

Please leave a comment with questions or suggestions below. And if you want to contribute to building the future of healthcare, Doctolib is hiring Ruby on Rails developers in Paris, Berlin, Nantes, and more yet to come...

Doctolib Engineering

We are hiring in all positions. If you want to build a better healthcare system, visit our career page: https://about.doctolib.fr/jobs


markdown guide