github/issue_template: rework issue templates with github forms #13953
Conversation
|
Download the artifacts for this pull request: |
| Make a log file made with `-v -v` or `--log-file=output.txt`, attach it to | ||
| the issue. | ||
|
|
||
| In the case of a crash, please provide a backtrace. | ||
|
|
||
| Without the log file, this issue will be closed for ignoring the issue template. |
There was a problem hiding this comment.
Due to the large amount of low-quality log files received, I suggest we add some checkboxes here:
- I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of
--log-file=output.txt. - I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
- I attached the full, untruncated log file.
- I attached the backtrace in the case of a crash.
- (optional, close the issue if checked) I ignored the issue template because I did not follow the above instructions.
There was a problem hiding this comment.
i added the first 4 checkboxes for now. i am not sure how to implement the last one, so i would leave it for a later time. also removed the "do not ignore the issue template" template, since this mechanism makes it obsolete imo.
though i am not sure if we want to keep it this way.
There was a problem hiding this comment.
as an example Akemi#26
a bit weird that it makes tasks out of it sadly.
There was a problem hiding this comment.
Thanks, looks good. I think this is a good change if this improves the quality of log files. More information is better than less.
i am not sure how to implement the last one, so i would leave it for a later time.
I considered this so that users who don't understand English and don't bother to translate them won't be able to blindly check everything, but it's OK for now.
There was a problem hiding this comment.
yeah i understand your intention. i am open for possible solutions. we probably need some extra action for that to auto-close issues if the checkbox was checked or something?
Akemi
force-pushed
the
master
branch
2 times, most recently
from
1a3dd90
to
2018929
Compare
|
updated the templates a bit with the suggestions. |
Akemi
force-pushed
the
master
branch
2 times, most recently
from
31c750e
to
10f4fe1
Compare
|
i think i addressed everything for now. so how do we want to go forward with this? i personally think this is a huge improvement over the status quo. though i don't want to force my opinion on the rest of the active maintainers. |
Akemi
force-pushed
the
master
branch
3 times, most recently
from
07bba7e
to
c25468f
Compare
Akemi
force-pushed
the
master
branch
6 times, most recently
from
659f342
to
1d29f5e
Compare
Akemi
force-pushed
the
master
branch
4 times, most recently
from
00fd5b0
to
87c37f4
Compare
| - Linux Version: `cat /etc/os-release | grep "NAME"` | ||
| - Kernel Version: `uname -a` | ||
| - GPU: `lspci -nn | grep VGA` or `lshw -C display -numeric` | ||
| - Mesa/GPU Driver Version: `glxinfo -B | grep "OpenGL version string"` |
There was a problem hiding this comment.
nit: this command doesn't work if X server isn't available, e.g. Wayland without XWayland, or DRM backend. But the version is already present in the log file at least for OpenGL, so not a huge problem.
There was a problem hiding this comment.
are there any alternative commands we could add as a suggestion, like on some of the other ones?
There was a problem hiding this comment.
There is also vulkaninfo | grep driverInfo if vulkan is installed. vulkaninfo also works on Windows.
Sadly I don't know about a good method for EGL-only setups, since eglinfo doesn't report version information.
There was a problem hiding this comment.
I think we can mention vulkaninfo. I hope users will not be too intimidated by all those requirements. High quality reports are important, but at the same time no reports is also bad.
Our log prints most of the important information, so it is not critical.
There was a problem hiding this comment.
yeah i agree with you @kasper93. if this doesn't work out well we should simplify it in the future.
mention our windows and macOS nightly builds and also link to our mpv.io installation page.
|
i addressed the additions of the recent review now. |
|
LGTM too, thanks. |
|
thanks for all the feedback. |
i would like to revisit the github forms for issue templates. we previously had a short discussion (#9938) which didn't lead to anything, and i still think the current issue templates are a bit lacking and confusing. even if we just settle with the minimum version, separating instruction from the issue template (description text above the text field), it would be a huge improvement over the current state.
this PR is a full blown suggestion of what could be done. it can be seen in action on my fork: https://github.com/Akemi/mpv/issues/new/choose and https://github.com/Akemi/mpv/issues
admittedly the changes here are quite extensive and might be a bit much, though i am open to simplify them if needed. though my general wish and goal is:
also see my comment, for my reasoning and additional suggestions.
since the question template was removed (2babe02), i added a short mention of the new Discussions on the issue template choose page with a link.
docs:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
Fixes #11515