Skip to content

Contributing

Garrett Dimon edited this page Aug 5, 2021 · 3 revisions

So you're interested in helping improve Reviewer? That's great! This will help provide some context and guidance so you can get started.

Code of Conduct

Everyone interacting in the Reviewer project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

Get Familiar with Reviewer's Philosophy

Reviewer could potentially be pulled in countless directions, so these basic guidelines can help provide some context for adding or improving functionality. They're open for discussion and evolution, but they represent the lense through which ideas are evaluated.

  • Reduce friction? Reviewer's only job is to unify a collection of disparate commands so they're easier to use more frequently.
  • Be fast to be frequent. Being easier to use is only half the battle. If it's slow, it won't be run.
  • Stay out of the way. Using Reviewer should never slow or block releases unless the team using it wants it to.
  • Do one thing at a time. Reviewer streamlines using multiple tools, but people can only fix one problem at a time. When it finds a problem, it stops immediately so you can fix it.
  • Be helpful. If Reviewer can help someone fix something, it should automatically suggest a solution.
  • Silence is success. Srolling back through screenfuls of "successful" output doesn't help. Reviewer only shows output from a tool when it's actionable or requested.
  • Nudge. Don't judge. While individual tools may provide an overall score, grade, or report, Reviewer focuses on exposing opportunities rather than quantifying quality.
  • Simple but tunable. Reviewer should work out of the box, but code review tools offer endless options. Reviewer has to empower teams can tune each tool's options to meet their needs.
  • Bend. Don't break. With countless tools run in a variety of approaches, Review needs to accommodate all approaches. So whether you're working with a shell script, Rake, Bundler, Yarn, or something else, you get a unified approach to running the commands.
  • Context matters. It should be just as easy to run all the tools, a subset, or a single tool based on what you want in any given moment.
  • Different tools. Different severities. Tools should be run in order of importance so you don't waste time fixing downstream effects of an upstream issue.

Development

After checking out the repo, run bin/setup to install dependencies. Then, run exe/rvw to run the Reviewer suite. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and the created tag, and push the .gem file to rubygems.org.

Discussions, Issues, and Pull Requests

Bug reports and pull requests are welcome on GitHub at https://github.com/garrettdimon/reviewer/issues. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the code of conduct.

Releases

Visit the Projects area to get a feel for Reviewer's near-term roadmap or take a look at the Changelog to see what's been going on recently.

Clone this wiki locally