mirror of
https://github.com/eko/pihole-exporter.git
synced 2024-11-24 11:37:03 +01:00
72 lines
3.5 KiB
Markdown
72 lines
3.5 KiB
Markdown
# Contributing
|
|
|
|
PI-Hole exporter is an open source project, completely opened to be a community-driven project.
|
|
|
|
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).
|