Create CONTRIBUTING.md

.github/CONTRIBUTING.md

@@ -0,0 +1,71 @@
+# 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).