Bug Report Wizard Formatting Breaks Bullet Points

Reproduction Steps

  1. Navigate to bug report wizard
  2. Create bug report
  3. Include bullet points as the first text in a text field
  4. Submit bug report
  5. Notice that an asterisk replaces the first bullet point
  6. Press edit to see that it is prefaced with <br>

Expected Behavior
All leading asterisks should be formatted as bullet points

Actual Behavior
The first leading asterisk is prefaced with <br> due to automatic formatting, which prevents the asterisk from displaying as a bullet point

<br> HTML formatting prefaces the text each text field and is a hinderance, as it is only added after the bug report has been submitted. This means that users must go back to their report and edit it to correct any inconsistencies.

Issue Area: Bug Report Wizard
Impact: Moderate
Frequency: Constantly
First Experienced: Approximately one year ago
Last Experienced: 02/06/2023

1 Like

Why does the wizard output HTML pagebreaks instead of newlines in markdown or anything else, anyway? Seems this is preventable simply by not doing that.

1 Like

Thank you for pointing out this issue! We will take a look.

2 Likes

@Bobytoeburrito This should be resolved, give it a try the next time you report a bug. We removed the bug that was causing these HTML artefacts.

We also greatly simplified the wizard down to make it easier to use at the same time.

The new wizard looks nice, and the issue seems to be resolved; however, I would like clarification on the bug severity dropdown being removed. With the severity level now removed, how are users supposed to indicate how severe a bug is? I feel that this was a rather crucial bit of info for the creator of a bug report to include. I assumed that it was sent into a spreadsheet or alike where severity could be easily assessed by staff. If a bug is present that is resulting in users to permanently lose data, how can we ensure it is mitigated in a timely manner and prioritized over low-severity bug reports?

The user-submitted severity field was only used internally as an initial visual indicator of something being high/low priority, we didn’t sort by it or address issues in order based on this value.

There were some issues with it:

  • It is user-generated, so it is generally speaking not very accurate.
  • Different reporters have different understandings of what is high/low priority.
  • Only the initial reporter can set the priority even if many users have the issue. A low impact issue may be high priority if it’s affecting all creators consistently, but the reporter may not know this when posting the report.

We already are just reading the post and using some other signals to determine how urgent something is. Generally speaking we judge the initial priority based on what the issue actually is (your written text).

Rest assured, this doesn’t affect how we triage issues internally whatsoever.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.