|
| 1 | +# Contributing to ContextualLogger |
| 2 | + |
| 3 | +This document explains our guidelines and workflows to contributing to an Invoca open source project. Please take care to follow the guidelines, as they exist to help us manage changes in a timely and efficient manner. |
| 4 | + |
| 5 | +## Code of Conduct |
| 6 | +All contributors to this project must adhere to the [Community Code of Conduct](https://github.com/Invoca/contextual_logger/blob/master/code-of-conduct.md) |
| 7 | + |
| 8 | +## Environment Setup |
| 9 | +1. Install the ruby version specified in the [.ruby-version](https://github.com/Invoca/contextual_logger/blob/master/.ruby-version) file (preferably you're using [rvm](https://rvm.io/) or [rbenv](https://github.com/rbenv/rbenv) to manage ruby versions) |
| 10 | +2. Make a fork of ContextualLogger, then clone your fork to your machine |
| 11 | +3. Run `bundle install` in your ContextualLogger directory to install dependencies |
| 12 | + |
| 13 | +## Branching |
| 14 | + |
| 15 | +* __Create an issue before starting a branch__ |
| 16 | +* For bugs, prefix the branch name with `bug/` |
| 17 | +* For features, prefix the branch name with `feature/` |
| 18 | +* Include the issue number and a short description of the issue |
| 19 | + |
| 20 | +Examples |
| 21 | +* `bug/1234_fix_issue_with_formatter_not_formatting` |
| 22 | +* `feature/4321_merge_contexts_together` |
| 23 | + |
| 24 | +## Filing Issues |
| 25 | + |
| 26 | +* Use the appropriate template provided |
| 27 | +* Include as much information as possible to help: |
| 28 | + * The person who will be fixing the bug understand the issue |
| 29 | + * The person code reviewing the fix to understand what the original need was |
| 30 | +* Check for open issues before filing your own |
| 31 | + |
| 32 | +## Committing |
| 33 | + |
| 34 | +* Break your commits into logical atomic units. Well-segmented commits make it much easier for others to step through your changes. |
| 35 | +* Limit your subject (first) line to 50 characters (GitHub truncates more than 70). |
| 36 | +* Provide a body if you'd like to explain your commit in detail. |
| 37 | +* Capitalize the beginning of your subject line, and do not end the subject line with a period. |
| 38 | +* Your subject line should complete this sentence: `If applied, this commit will [your subject line]`. |
| 39 | +* Don't use [magic GitHub words](https://help.github.com/articles/closing-issues-using-keywords/) in your commits to close issues - do that in the pull request for your code instead. |
| 40 | +* Adapted from [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/#seven-rules). |
| 41 | + |
| 42 | +## Making Pull Requests |
| 43 | + |
| 44 | +* Use fill out the template provided |
| 45 | +* Provide a link to the issue being resolved by the PR |
| 46 | +* Make sure to include tests |
| 47 | +* Resolve linting comments from Hound before requesting review |
0 commit comments