If you'd like to contribute, you are free to do so.
## Why contributing?
The best way to start contributing is to help others. This includes:
- Reporting new bugs or adding details to existing ones
- Trying to reproduce unconfirmed bugs
- Quick typo fix or documentation improvement
- Participating in discussions
After becoming familiar with this project, you could contribute in other ways, such as:
- Helping fix bugs (issues)
- Implement new features you think it could be interesting for others
- Publishing guides, tutorials, and examples
## Questions
If you have a question, please feel free to open a new issue on this repository.
## Bug Reports
Search through [Github Issues](https://github.com/eko/pihole-exporter/issues) to see if the bug has already been reported. If so, please comment with any additional information.
New bug reports must include:
1. Detailed description of faulty behavior
2. Steps for reproduction or failing test case
3. Expected and actual behaviors
4. Platforms (OS **and** versions) affected
5. Any information you think it could help identifing the cause of your issue
Lacking reports may be autoclosed with a link to these instructions.
## Feature Requests
Search through [Github Pull Requests](https://github.com/eko/pihole-exporter/pulls) to see if someone has already suggested the feature. If so, please provide support with a [reaction](https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments) and add your own use case.
To open a new feature request, please include:
1. A detailed description of the feature
2. Why this feature belongs in project core, instead of your own application logic
3. Background of where and how you are using the project
4. The use case that would be enabled or improved for your product, if the feature was implemented
Features are prioritized based on real world users and use cases, not theoretically useful additions for other unknown users. Lacking feature requests may be autoclosed with a link to this section.
The more complete and compelling the request, the more likely it will ultimately be implemented. Garnering community support will help as well!
## Pull Requests
Non-code Pull Requests such as typo fixes or documentation improvements are highly encouraged and are often accepted immediately.
Pull Requests modifying source code, including backwards compatible additions, will undergo the most scrutiny, and will almost certainly require a proper discussion of the motivation and merits beforehand. Simply increasing code complexity is a cost not to be taken lightly.
Pull requests must:
1. Be forked off the [master](https://github.com/eko/pihole-exporter/tree/master) branch.
2. Pass the linter and conform to existing coding styles.
3. Commits are [squashed](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Squashing-Commits) to minimally coherent units of changes.
4. Are accompanied by tests covering the new feature or demonstrating the bug for fixes.
5. Serve a single atomic purpose (add one feature or fix one bug).
6. Introduce only changes that further the PR's singular purpose (ex. do not tweak an unrelated config along with adding your feature).
7. Not break any existing unit or end to end tests.
**Important:** By issuing a Pull Request you agree to allow the project owners to license your work under the terms of the [License](https://github.com/eko/pihole-exporter/blob/master/LICENSE).
