[Reporting Issues] Add a page on reporting issues#54
[Reporting Issues] Add a page on reporting issues#54AThousandShips wants to merge 1 commit intogodotengine:mainfrom
Conversation
AThousandShips
added
enhancement
feedback/issue_report_writing.rst
Outdated
| unavailable in previous versions to the ones tested, please mention this in the tested versions | ||
| for ease of testing. | ||
|
|
||
| .. TODO: A basic description of each part of a report. |
There was a problem hiding this comment.
Will be elaborating on versions tested etc. here, ensuring people test on up-to-date versions when possible, and report if they have tested different versions (without encouraging testing many versions unnecessarily, but making it clear an issue report should mention different versions if tested with them, where appropriate)
Calinou
left a comment
Calinou
left a comment
There was a problem hiding this comment.
Looks good to me, some stylistic changes.
|
Thank you for your feedback! Will look through tomorrow! |
AThousandShips
force-pushed
the
issue_minmaxing
branch
2 times, most recently
from
1b6d4af to
c74daf9
Compare
|
I'll work on filling in more of this next week |
AThousandShips
force-pushed
the
issue_minmaxing
branch
from
c74daf9 to
4bf4a43
Compare
feedback/issue_report_writing.rst
Outdated
| about a bug in how add-ons or plugins. Generally, issues caused by add-ons or plugins should be reported to the | ||
| creator of the add-on or plugin first. Only if the issue is a problem in Godot should a report be made for Godot. |
There was a problem hiding this comment.
| about a bug in how add-ons or plugins. Generally, issues caused by add-ons or plugins should be reported to the | |
| creator of the add-on or plugin first. Only if the issue is a problem in Godot should a report be made for Godot. | |
| about a bug in the interaction between Godot and add-ons or plugins. |
Missing some words. Also, I think the latter part is clear from the former part.
There was a problem hiding this comment.
I'd say the clarification of what to do if a bug is caused by an add-on is important to keep here
|
Thank you for your review! I'll take a look at the suggestions later today or tomorrow! |
AThousandShips
force-pushed
the
issue_minmaxing
branch
2 times, most recently
from
59a3ca9 to
2a30f58
Compare
AThousandShips
force-pushed
the
issue_minmaxing
branch
from
2a30f58 to
49fb4e3
Compare
AThousandShips
changed the title
|
Made some changes to the structure and added some more content, ready for review now and I think it covers what I had planned Will add the "how to grab triager attention" in a follow-up PR |
| feedback/issue_report_writing | ||
| feedback/reporting_issues |
There was a problem hiding this comment.
I wonder if it would make sense to merge these two pages, or to specifically separate them?
reporting_issues currently holds just a link to the issue report form, and then explains how to test Godot development builds.
Going by the mantra of "Every way to contribute to Godot should have an entry in the sidebar" i guess suggests two separate pages: One for people who ran into an issue and want to report it, and one for people who want to go out of their way to find (and report) issues.
Your current split is coherent with this idea, but maybe we should rename the other page too, to avoid confusion?
There was a problem hiding this comment.
Will look next week at how to organize it!
|
Thank you for the feedback! Will check on Monday |
|
Thank you for all the feedback! Will hopefully get the time to apply some of these and the suggestion about a checklist today or tomorrow! |
AThousandShips
force-pushed
the
issue_minmaxing
branch
from
49fb4e3 to
493e016
Compare
|
Addressed most of the feedback! Thank you! Will look at the remaining details and do some proof reading today and tomorrow, but new feedback appreciated! |
AThousandShips
force-pushed
the
issue_minmaxing
branch
from
493e016 to
035b8ad
Compare
4 participants
Still very much a work in progress, but wanted some feedback on the areas I've already filled in, the rest will be added before too long
This is part of a larger ongoing process to improve our triage processes and reduce friction and workload for triagers by providing good information and clarification for how to fill in an issue report well (and arguably more importantly why certain areas are necessary or important)
I genuinely believe that a large reason for low quality and low effort issue reports is less contributor laziness (though there are some) but more a lack of knowledge of how to fill in a report properly, and more broadly a lack of understanding of why certain parts of the issue report needs to be filled in
The goal of this addition (when finished) is to provide something to point to when asking people to improve their issue reports, as well as something contributors can reference to improve how they write (and evaluate) issue reports
The second part (which is largely unfilled right now) is meant as a way to "gamify" writing good issue reports, and a way to help people to apply their effort in writing an issue report in the right place, and to write issue reports that we triagers will want to triage, and not reports that we dread to test because we feel it'll take hours to even figure out what the issue is aboutThis will be added in a future PRPart of the goal of this is to reduce the complexity of the issue report template and simply direct people to this page for all the details
tl;dr; This is a new page designed to help people not write bad issue reports that triagers will avoid even looking at