-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
GitHub Issue Forms: Simplify the bug report form template #34007
Conversation
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.
Thanks for working on this @priethor! I've created an issue today and the current form felt kind of overwhelming 😄 .
I like all the changes here! I personally I thought that description
and current behavior
sections could be combined, but your proposal works well IMO too.
label: Step-by-step reproduction instructions | ||
description: Please list the steps needed to reproduce the bug. | ||
label: Description ands step-by-step reproduction instructions | ||
description: Please write a brief description of the bug and the steps needed to reproduce it. | ||
placeholder: | |
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.
Since this is now for both a description and steps needed to reproduce, I'd include something about the description in the placeholder section.
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.
Any copy suggestions? I feel that adding "When I do '...', it happens '...' is way too similar to the Expected vs Current behavior.
Does anybody have strong feelings about combining description and expected vs current behavior? Saying what you expect and what actually happens feels like THE description to me. 😄 cc @annezazu @ntsekouras |
I agree 😄 |
Updated the form to combine description, steps to reproduce, and expected vs actual behavior as part of the description, and updated the PR description accordingly. |
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.
Thanks, this is a great improvement! It makes total sense to combine description, expected and current behaviour because there's a lot of overlap in these fields. Steps to reproduce could still be its own field, but perhaps we can revisit this if we find folks aren't adding them in properly.
We could also leave the pre-checks at the top of the form, as a reminder that these are the first steps to take in troubleshooting a bug. I'm not sure whether they should be required or not. Do we get a lot of reports that are actually plugin conflicts and the like? My feeling is no, but perhaps it's just because I haven't been doing a huge amount of triage 😅
I have a slightly opposite opinion, and would like to keep the steps to reproduce separate from the description. The steps to reproduce are the most important part of the bug report, it's crucial for devs to be able to test and debug the incoming reports. Often without it, reports are too vague to be able to reproduce and we have to ask for more information. Most reporters are non-technical and don't quite understand what's important information and what isn't. I think combining them like this will lead to reporters only adding a description and skipping the steps to reproduce. |
Thanks for taking a stab. Can we revisit the question, "Have you tested with a default theme?". A few reasons:
The reports are still valuable, regardless of theme, but just checking the box of testing with a default theme doesn't ensure the issue is that much more valid. We could just ask people to specify which theme they were testing with, that would be valuable. |
I have to disagree with this and I'd like to suggest moving the pre-checks to a lower position (at the bottom of the form or at least under the description). Seeing the description right away is important. Otherwise, we'll need to scan the message and look for the description every time we land on an issue. Update: Also, the original format for that list was better than the one above |
If there was a way to have the checkbox visible on the form, but not in the published description, that would be ideal IMO. Probably not possible though. |
Good feedback! I have taken the reproduction steps to a different field but left description, expected and actual behavior together, as they seem part of the description. I've also removed the default theme checked and added it to the environment data, it did feel the default theme check was too constrained by the reasons above: |
After letting the last changes sit for a day, I'm merging this for now. If more changes/feedback seem fit, or some of these don't improve the form, I'm happy to iterate over! |
👌 |
This looks really good 👍 Thanks for taking the suggestions into account! |
Description
Followup to #33713. The first iteration on using form templates directly translated the markdown template to a form template. However, markdown templates allow for users to easily delete parts of it and adjust it to the report, whereas with the form template the report needs to be adapted entirely to the form. This leads to:
Proposed changes
Update after review feedback:
Update 2021-08-12:
You can try the proposed changes in this fork.
Screenshots
Current bug report result if fields are empty:
Proposed new form (updated with the last changes after review):