-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise GitHub templates #12574
Revise GitHub templates #12574
Conversation
@xavier2k6 technically, that issue should have been closed with the merging of the linked PR in the last comment (fixed that now). These new PRs are just follow-ups that improve on that original ones, that arose from my additional experience in managing the issue tracker. |
cd2f51c
to
b4e1015
Compare
@FranciscoPombal: Not strictly related to the PR itself, but I noticed that both the old template and this one do not seem to have a defined layout for "feature requests". For instance, submitting a log entry for a behavior that does not yet exist, does not seem viable to me. Any advice on this? |
b4e1015
to
83d80cf
Compare
Ok, I have changed things around a bit. Now there are separate templates for bug reports and feature requests, as well as links to the relevant support communities. Additionally, I threw in a simple PR template. When a user clicks "New issue", now they will get something similar to this this: https://github.com/microsoft/TypeScript/issues/new/choose As a bonus, GitHub will no longer complain about "You are using an old version of issue templates. Please update to the new issue template workflow. Learn more" (check this here: https://github.com/qbittorrent/qBittorrent/blob/master/.github/ISSUE_TEMPLATE.md) |
83d80cf
to
893dff8
Compare
I have pushed the changes to my master branch. Try it out here: https://github.com/FranciscoPombal/qBittorrent/issues/new/choose Here is what it looks like for a user: Note that the headers in the files like the following are metadata for github only and do not show up when the user is creating the issue:
As a bonus, feature requests get automatically labeled on creation. |
75aa23d
to
c901ec0
Compare
c901ec0
to
f2b43fa
Compare
f2b43fa
to
329caf8
Compare
How about something like this?? Result:qBittorrent version/architecture (32bit/64bit)Operating system/version(If on windows), please include (FULL version displayed in
|
The reason I included the For example:Windows 11
Windows 10
Windows 7 / 8 / 8.1
Windows Operating Systems no longer supported as of 4.2.0 Release (December 3rd 2019)Windows XP / Vista
|
Or maybe this? RESULT:qBittorrent version/architecture (32bit/64bit)Operating system/version(If on windows), please include (FULL version displayed in
|
Then their issue will be immediately closed and locked as invalid. This is a feature, not a bug, to filter out users who are not willing to put in the minimum effort. |
You have to take in to account that for some users - looking at that wall of text is basically double dutch & may know nothing about markdown etc so may not know how it's supposed to look etc. There have been users here, who have made issues & just pasted the
Keep it to bare minimum/essentials & it's followed up. |
This is
|
912af34
to
543ea63
Compare
👍, done.
I understand but I disagree (I have also thought of this in the past). I'm always concerned users will write inside the We already explicitly warn the user to delete each |
no. |
Well, if they do that & we are attempting to tighten up the issue tracker procedures in this PR then we can mark it as invalid can't we? (as they didn't follow our instructions correctly) One overall checkbox may be sufficient enough for compliance with the instructions set out in My opinion from #12574 (comment) would still be the best option & as I said previously this is something that should be looked at in the future. (Maybe 6 months from now?) I don't think I have any other issues with this PR. |
Well we should be strict, but not super strict in closing issues for being invalid. A user may make an honest mistake; with the
We can always change this in the future if users complain about it. Fortunately I doubt this will be the case. As I've demonstrated before, multiple other projects have been using the "multiple checkbox" method successfully for a long time. They keep the user engaged and alert as they are reading and fulfilling each requirement.
First we should see how this one does "in production". This might not be the perfect solution until the end of time, but it sure has a much better chance of being more effective than what we have now, and it is proven in other even bigger projects. Then sure, something based on google forms can be looked at in the future. However, I have expressed my reservations about it, and I'd like to add that some users might not like the fact that they have to interact with an external Google resource just to submit an issue...
👍 |
Cool, can we finally get this approved and merged then? I believe @xavier2k6 and @thalieht 's concerns have been addressed (but let me know if there is still some last minute change that you need!). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cosmetic comment: file names inside ISSUE_TEMPLATE seem to be inconsistent to me (namely using of _template
suffix).
Also why some *.md
files have UPPERCASE names but others not? Is there any general naming scheme/convention?
I followed the conventions/guidelines in GitHub's documentation. Basically,
References:
The |
- Separate templates into bug report and feature request - Add a checklist and guidance comments - Add a PR template - Add SUPPORT.md
543ea63
to
437769a
Compare
Thank you! |
Maybe when it's time to release 4.4.0 beta, you guys can add another part called something like "[4.4.0 Beta] Bug report" with its own checklist and relevant questions? |
These templates can be used without changes for such purposes. It is sufficient for the user to write "4.4.0 Beta" in the version field. If we really do need a clearer separation between issues from that version and others, we'll just label them differently as they're posted. |
--> | ||
|
||
- qBittorrent version: (type here) | ||
- Operating system(s) where the issue occurs: (type here) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading a few issues, these "qBittorrent version:" and "Operating system(s) where the issue occurs:" are disrupting the flow of reading. I can't easily filter them to get to the juicy part and furthermore i think they are unnecessary. A simple "(type here)" is sufficient IMO.
Same goes for the section below.
I think the 'bug report form' that you can find in the 'uBlock-issues' repository is interesting. No more template evading/removing or checkbox mistakes! It's worth looking into. PR: uBlockOrigin/uBlock-issues#1651 Check out how it looks here (start a issue, but don't submit) = |
@ArcticGems Thank you so much!!! @glassez this is a very useable option like what I had similarly suggested in #12574 (comment) I'll try to work on this/submit PR over the wknd. |
Add a checklist and guidance comments
Separated from #11896 for easier review.
Previews:
Selection screen after clicking "New issue"
Click to show
Bug report
Click to show
Feature request
Click to show