ydah/rubocop-committee

# Contributing

If you encounter problems or have ideas for improvements or new features, please report them to the [issue tracker](https://github.com/ydah/rubocop-committee/issues) or submit a pull request. Please, try to follow these guidelines when you do so.

## Issue reporting

- Check that the issue has not already been reported.
- Check that the issue has not already been fixed in the latest code (a.k.a. `master`).
- Be clear, concise, and precise in your description of the problem.
- Open an issue with a descriptive title and a summary in grammatically correct, complete sentences.
- Report the versions of `rubocop-committee`, as well as the output of `rubocop -V`.
- Include any relevant code to the issue summary.

## Pull requests

1. Fork the project.
2. Create a feature branch.
3. Make sure to add tests.
4. Make sure the test suite passes (run `rake`).
5. Add an entry to the [Changelog](https://github.com/ydah/rubocop-committee/blob/master/CHANGELOG.md) by creating a file `changelog/{type}_{some_description}.md`. See [changelog entry format](#changelog-entry-format) for details.
6. Commit your changes.
7. Push to the branch.
8. Create new Pull Request.

### Changelog entry format

Here are a few examples:

```
- [#1514](https://github.com/rubocop/rubocop-rspec/issue/1514): Fix a false positive for `RSpec/PendingWithoutReason` when not inside example. ([@ydah])
```

- Create one file `changelog/{type}_{some_description}.md`, where `type` is `new` (New feature), `fix` or `change`, and `some_description` is unique to avoid conflicts. Task `changelog:fix` (or `:new` or `:change`) can help you.
- Mark it up in [Markdown syntax][1].
- The entry line should start with `- ` (an hyphen and a space).
- If the change has a related GitHub issue (e.g. a bug fix for a reported issue), put a link to the issue as `[#1514](https://github.com/rubocop/rubocop-rspec/issues/1514): `.
- Describe the brief of the change. The sentence should end with a punctuation.
- At the end of the entry, add an implicit link to your GitHub user page as `([@username])`.

### Spell Checking

We are running [codespell](https://github.com/codespell-project/codespell) with [GitHub Actions](https://github.com/ydah/rubocop-committee/blob/master/.github/workflows/codespell.yml) to check spelling and
[codespell](https://pypi.org/project/codespell/).
`codespell` is written in [Python](https://www.python.org/) and you can run it with:

```console
$ codespell --ignore-words=.codespellignore
```

### Linting YAML files

We are running [yamllint](https://github.com/adrienverge/yamllint) for linting YAML files. This is also run by [GitHub Actions](https://github.com/ydah/rubocop-committee/blob/master/.github/workflows/linting.yml).
`yamllint` is written in [Python](https://www.python.org/) and you can run it with:

```console
$ yamllint .
```

### Formatting Markdown files

We are running [mdformat](https://github.com/executablebooks/mdformat) for formatting Markdown files. This is also run by [GitHub Actions](https://github.com/ydah/rubocop-committee/blob/master/.github/workflows/linting.yml).
`mdformat` is written in [Python](https://www.python.org/) and you can run it with:

```console
$ mdformat . --number
```

## Creating new cops

- Document examples of good and bad code in your cop.
- Add an entry to `config/default.yml`. It's an ordered list, so be sure to insert at the appropriate place.
- Run `bundle exec rake`. This will verify that the build passes as well as generate documentation and ensure that `config/default.yml` is up to date (don't forget to commit the documentation).
- Add tests for as many use cases as you can think of. Always add tests for both bad code that should register an offense and good code that should not.

[1]: https://daringfireball.net/projects/markdown/syntax