CONTRIBUTING.md

Contributing to Skunk

Have a fix for a problem you've been running into or an idea for a new feature you think would be useful? Bug reports and pull requests are welcome on GitHub at https://github.com/fastruby/skunk.

Here's what you need to do:

• Read and understand the Code of Conduct.
• Fork this repo and clone your fork to somewhere on your machine.
• Ensure that you have a working environment
• Read up on the architecture of the gem, and run the tests.
• Cut a new branch and write a failing test for the feature or bug fix you plan on implementing.
• Update the changelog when applicable.
• Read the guidelines when Releasing a new version
• Push to your fork and submit a pull request.
• Make sure the test suite passes on GitHub Actions and make any necessary changes to your branch to bring it to green..
• Check out the Help Wanted section for suggestions on how to support Skunk.

Setting up your environment

To install the dependencies, run:

bin/setup

You can also run bin/console for an interactive prompt that will allow you to experiment with the gem.

To install this gem onto your local machine, run:

bundle exec rake install.

Architecture

This project follows the typical structure for a gem: code is located in lib and tests are in test.

Under /lib/skunk, you find the CLI commands. Under lib/skunk/rubycritic you find skunk's extension from rubycritic gem.

Running all tests

To run all of the tests, simply run:

bundle exec rake

A word on the changelog

You may also notice that we have a changelog in the form of CHANGELOG.md. We use a format based on Keep A Changelog.

The important things to keep in mind are:

• If your PR closes any open GitHub issue, make sure you include Closes #XXXX in your comment.
• New additions get added under the main (unreleased) heading;
• Attach a link to the PR with the following format:

• <FEATURE | BUGFIX | CHORE>: Description of changes.

Releasing a new version

To release a new version, update the version number in version.rb.

To create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org, run:

bundle exec rake release

When Submitting a Pull Request:

• If your PR closes any open GitHub issues, please include Closes #XXXX in your comment.
• Please include a summary of the change and which issue is fixed or which feature is introduced.
• If changes to the behavior are made, clearly describe what are the changes and why.
• If changes to the UI are made, please include screenshots of the before and after.

Continuous integration

After opening your Pull Request, please make sure that all tests pass on the CI, to make sure your changes work in all possible environments. GitHub Actions will kick in after you push up a branch or open a PR.

If the build fails, click on a failed job and scroll through its output to verify what is the problem. Push your changes to your branch until the build is green.

Help Wanted

Skunk's formula is not perfect and it is certainly controversial. The SkunkScore could be calculated per method. This would provide a more accurate representation of the average SkunkScore in a module.

The SkunkScore of a module should be the average of the SkunkScores of all of its methods. Right now the SkunkScore is calculated using the totals for a module:

• Total Code Coverage Percentage per Module
• Total Churn per Module
• Total Cost per Module

Feel free to review and submit your suggestions to improve the method RubyCritic::AnalysedModule#skunk_score.

📘 Read Escaping The Tar Pit: Introducing Skunk v0.3.2 at RubyConf 2019 and Churn vs. Complexity vs. Code Coverage for more details about the skunk_score method.