docs: rewrite "reporting bugs" guide

This commit is contained in:
bastimeyer 2024-04-16 19:31:35 +02:00 committed by Sebastian Meyer
parent ea7159b897
commit 3c496eea91
1 changed files with 22 additions and 7 deletions

View File

@ -9,17 +9,33 @@ A bug is a *demonstrable problem* that is caused by the **latest version** of th
Please read the following guidelines before you [report an issue][issues]:
1. **See if the issue is already known** — check the list of [known issues][known-issues].
1. **Use the GitHub issue search**
2. **Use the GitHub issue search** — check if the issue has already been reported. If it has been, please comment on the existing issue.
Check if the issue has already been reported. If it has been and is still unresolved, then please comment on the existing issue.
3. **Check if the issue has been fixed** — the latest `master` or development branch may already contain a fix.
Please avoid comments like "+1", "me too", etc., as they don't contribute to solving the issue and instead unnecessarily notify users subscribed to the issue or activities of the entire repository. Instead, use GitHub's notification feature on specific issues or pull requests via the sidebar on the right in order to receive status updates, or click the watch button at the top.
4. **Isolate the demonstrable problem** — make sure that the code in the project's repository is *definitely* responsible for the issue.
2. **Check if the issue has been resolved**
5. **Format your issue report** — [well formatted texts][mastering-markdown] will make it much easier for developers to understand your report.
The `master` branch may already contain a fix, so please have a look at the recent commit history first. Don't comment on commits and instead open a new thread on the issue tracker if you have found a mistake in a code commit.
Please try to be as detailed as possible in your report too. What is your environment? What steps will reproduce the issue? What would you expect the outcome to be? All these details will help people to assess and fix any potential bugs. The various issue templates will aid you in structuring your report when submitting a new issue. Thank you!
Resolved issues or merged pull requests should never be commented on and a new issue should be opened if something is still not working or has stopped working again. But before opening a new issue, check that you are indeed using the latest stable or development version.
3. **Isolate the demonstrable problem**
Make sure that the code in the project's repository is *definitely* responsible for the issue by excluding external factors which may influence the results.
These external factors can be specific configurations in the used environment, the connection to a specific website or streaming service, the usage of VPNs or proxy servers, and many other things. Please keep that in mind when reporting issues.
The project maintainers must be able to reproduce the issue you're trying to report, which is the reason why **a full debug log is required** when reporting plugin issues or general bugs, as it includes important information about the environment Streamlink is run in.
4. **Format your issue report**
[Well formatted texts][mastering-markdown] will make it much easier for developers to understand your report.
Please at the very least put your (additional) log output or code snippets into markdown code-blocks (surrounded by triple backticks - see the link above).
The various issue templates will aid you in structuring your report when submitting a new issue. Thank you!
## Feature requests
@ -173,7 +189,6 @@ This contributing guide has been adapted from [HTML5 boilerplate's guide][ref-h5
[issues]: https://github.com/streamlink/streamlink/issues
[known-issues]: https://github.com/streamlink/streamlink/blob/master/KNOWN_ISSUES.md
[mastering-markdown]: https://guides.github.com/features/mastering-markdown
[howto-fork]: https://help.github.com/articles/fork-a-repo
[howto-rebase]: https://help.github.com/articles/interactive-rebase