This post is meant to have a discussion on improving the quality of bug reports. This should be kept solely from the bug reporter’s perspective*. From the moment they encounter an error in Blender to the point where they receive the first triaging comment.
This and 2 are the pages of utmost importance for the reporter to read. Here are the improvements I suggest because of a concern that very few people read them at all.
- make them the landing pages and keep the system info in the URL or cookies etc, till the user reads the proceeds to the next page. Very similar to a License Agreement.
- Or make them open close with a dropdown/ overlay to reduce resistance and jumping between the pages.
- Treat this as the canonical guide and take concise messages onto the bug report page itself**, 8.
Since this video is also present on page 1, the text should hint the optional nature of the same, preferably on both pages. Instead of the video, an example, a perfect bug report can be linked here.
This section should be expanded in the view of erroneous reports(not knowing how a feature works) or support requests. The text should also shun duplicate reports (** thus borrowing page 1’s content ). And it’d be good if we directly link websites like right click select, feedback forum, hiring, and blender.SE here, instead of on another page.
This section should be split into three: with the developer part on the top, as a welcome note; the careful instruction line can appear on the right side of the form when user is filling out the form; the seven-day ultimatum should be shown after the user has posted the report, and if possible in the mail too. They should also be advised to keep checking email, remove blender from spam, but this is a very low priority. see 8.
“Title” should be renamed to “Short description of the error” to avoid titles like “Cycles > Volume > Alpha Channel” or, “blender crashes”. See 7, 8. @lichtwerk
HTML comments. @sybren
one thing I would love to see is (HTML) comments in the bug report form. In the GitHub tracker you can have comments like and it won’t show up in the final report. That way we get rid of all the people who keep the literal “as found on the splash screen” in their bug reports.
And a complete transformation of the box by @iss
This separation of boxes makes filling them organized, later reading them neat too.
The exact steps to repro are preferred in a list, should be highlighted in the placeholder/ HTML comments/ 8.
Use expected behavior and outcome (or better terms than that) to
- help people who don’t always work in those areas triage.
- Help developers understand what user is actually trying to do, and close the report if they are mistaking some feature with a bug.
The whole empty part on the side can be used as very simple “DOs” “DON’Ts”, based on where the cursor is.
Is the windows-point still useful? Genuine question, not being snarky.
Instructions for including text files for crash, screenshots (videos optional), .blend files etc are transferred to form box. See 6.
Always test if the bug has been fixed with the latest releases…
sounds better. No one would not love having the bug fixed, and avoiding a bug report.
This is not in the screenshot. @Harleya :
We need to put a page of our own in between. A page we can edit that can then have some dropdown lists of choices and less freeform text. Then we just post into the Pham form. In fact we could later make it multi-pages, or multilingual. Or short-circuit out to support pages depending on responses. … the page “in between” would be the URL used for bug reporting from inside blender and for Report Bug website link. It could start off being nothing but a redirection, but could grow into anything we wanted without needing to change anything else from that point on. Could become a multibranching wizard thing.
*: https://developer.blender.org/T70658 this post addresses developers’ concerns, feature requests to help with commenting, etc.
Catch up on discussion in chat. Starts here: https://blender.chat/channel/blender-coders?msg=fHnwqwu9mJs6kE5tD