# Contributing to Ringme.js

First of all, thanks for reading this and taking time to contribute! :+1: We need volunteer developers to help this project grow.

The following is a set of guidelines for contributing to Ringme.js, which is hosted in the [Savoir-faire Linux organization](https://github.com/savoirfairelinux) on GitHub.
Feel free to propose changes to this document in a pull request.

## Useful resources

* [Creating a Pull Request on GitHub](https://help.github.com/articles/creating-a-pull-request/)

## How can I contribute ?

### Code contribution

#### Issues

If you are unsure where to begin contribution to Ringme.js, you can start by looking through the issues page.
Numerous issues are created and waiting for your love on the [issue board](https://github.com/savoirfairelinux/ringme.js/issues).

Please refer to the issues labels and topics for more information on how categorizing the issues.

#### Pull Requests

Contributions will be accepted through the creation of Pull Requests. Here is the workflow:

* Fork the repository into yours and work from there
* Commit and push your changes into your fork
* When you are done, create a [Pull Request](https://github.com/savoirfairelinux/ringme.js/compare) in Ringme.js repository on the **master** branch

A template is provided to create your Pull Request. Try to fill the information at the best of your knowledge.

#### Pull request checklist

For your pull request to be merged, the answer to the following questions must be 'yes':

##### General

* Can the branch be merged automatically?
* Can you run ESLint (`npm run lint`) without any warnings/errors?
* Did you avoid any [dark patterns](https://darkpatterns.org/)?
* Did you avoid adding any network requests to third parties (e.g. <abbr title="Content delivery network">CDN</abbr>)?

### Documentation

Documentation is important and can always be improved:

* Installation instructions
* Test procedures
* How to help translating the project

The prefered syntax is Asciidoc. Markdown is also accepted.

### Reporting bugs

Bugs are tracked as [GitHub issues](https://guides.github.com/features/issues/).

#### How to submit a good bug report

Please include as many details as possible. An issue template is automatically loaded when you create an issue.

* Use a clear and comprehensive title for the issue
* Describe the expected behaviour in as many details as possible
* Describe the actual behaviour in as many details as possible
* Detail the steps which reproduce the problem
* Include screenshots and animated GIFs. You can use [this tool](https://github.com/colinkeenan/silentcast) on GNU/Linux.

## Additional notes

### Issue labels

| Label name | Description |
| --- | --- |
| `enhancement` | Feature requests. |
| `bug` | Confirmed bugs or reports that are very likely to be bugs. |
| `question` | Questions more than bug reports or feature requests (e.g. how do I do X). |
| `duplicate` | Issues which are duplicates of other issues, i.e. they have been reported before. |
| `wontfix` | The core team has decided not to fix these issues for now, either because they're working as intended or for some other reason. |
| `help wanted` | Issues on which help is wanted (e.g. you had enough time to draft something but can't complete the patch). |

### Issue topics

When applicable, the issue topics help us filter and group issues even more.

| Label name | Description |
| --- | --- |
| `accessibility` | Related to [accessibility](https://www.w3.org/WAI/) problems. |
| `markup` | Related to rendered HTML markup. |
| `documentation` | Related to any kind of documentation. |
| `ux/ui` | Related to user experience, user interface, design. |