Closed Bug 1522342 Opened 6 years ago Closed 6 years ago

UX for indicating if a bug is a task, enhancement, or defect

Categories

(bugzilla.mozilla.org :: Bug Creation/Editing, task)

Product:
bugzilla.mozilla.org
Component:
Bug Creation/Editing
Version:
Production
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: emceeaich, Assigned: kohei)

References

Details

Assignee: nobody → kohei.yoshino
Status: NEW → ASSIGNED

Will this new field be called 'flavor'? 'bug.flavor' sounds fun. 😉

(In reply to Dylan Hardison [:dylan] (he/him) from comment #1)

Will this new field be called 'flavor'? 'bug.flavor' sounds fun. 😉

I know I am boring :) I vote for 'category'

Are we causing a war between 🇺🇸 (flavor) and 🇨🇦 🇬🇧 (flavour)?

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #4)

Are we causing a war between 🇺🇸 (flavor) and 🇨🇦 🇬🇧 (flavour)?

You have a point there. I think we have both American and Commonwealth spellings in bugzilla...

Trac has this exact feature, what word does it use?

The answer is 'type' which is a namespace nightmare. If not favor/favour, bug_type would fit the schema ok and not by a potential SQL keyword or clash with any existing thing.

Here’s a quick research of what other bug trackers are doing. Type is a clear winner.

Monorail (Chromium)

Type: Bug, Bug-Regression, Bug-Security, Compat, Feature, Launch, Task
https://www.chromium.org/for-testers/bug-reporting-guidelines/chromium-bug-labels

Jira

Type: Story, Bug, Epic (default)
https://confluence.atlassian.com/adminjiracloud/issue-types-844500742.html

Trac

Type: defect, enhancement, task
https://trac.edgewall.org/wiki/TracTickets

Redmine

Tracker: Defect, Feature, Patch

GitHub

No field for issue types, using labels instead

GitLab

Same as GitHub, using labels

Launchpad

No field for issue types, no labels

Maybe we can use type for the UI and API, and bug_type for the implementation.

Here are mockups of what we need. I think I’ve covered pretty much everything but let me know if you have any feedback, concerns, etc. Thanks!

https://drive.google.com/file/d/1l596C3yyE1if19SZqnDhYo8Wa2kSGget/view

Flags: needinfo?(sledru)
Flags: needinfo?(ehumphries)
  • Make type mandatory
  • Remove severity and re-label priority on the bug entry flows
Flags: needinfo?(ehumphries)

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #11)

  • Make type mandatory

This is a single-select dropdown list and the defect type is selected by default, so the red asterisk indicating a required field has not been added. UX-wise, It’s only needed for multi-select lists and text fields that can be zero selected item or empty state. I don’t know why the non-editable Product field has an asterisk. The field is mandatory anyway.

  • Remove severity and re-label priority on the bug entry flows

The Severity field itself is not going away, IIUC, so the label could simply say Importance, which is Priority + Severity on the bug detail page.

Looks great, bravo!

For the severity, I would prefer we do it later. We are already doing a lot of changes in bugs. I think it would be better to decouple things... And we still have to find a consensus on that.

I was wondering if we should not rename feature to feature request but no big deal.

Flags: needinfo?(sledru)

Yes, we could also think a bit more about the field values.

  • defect: I personally prefer bug which is a simpler word. Chromium and Jira use this term.
  • feature: I personally prefer enhancement because not all enhancement bugs may not exactly be feature requests, like UX enhancements, a11y enhancements, etc. Trac uses this term.
  • task: It's OK.
  • meta: I guess we need this because the type of meta bugs varies. Jira has Epic as mentioned above.

defect: I personally prefer bug which is a simpler word. Chromium and Jira use this term.

The word bug has too much connotation inside Mozilla.

I like enhancement

Or issue like github

I think the default type per component should be able to be edited by admins on the Edit Component page. Hardcoding these values in the BMO extension obviously decreases the maintainability. I’ll update the UX spec and implementation.

Both bug and issue sound vague after all 😅 Especially on Bugzilla, each report is called a bug, not an issue like Monorail or Jira, so using bug as a type may rather be confusing. The term defect is clear. How about feature/enhancement and meta?

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

One more thing that I want to do with the UX: Show the bug type column on search results by default, which will display coloured types just like labels on GitHub issues/PRs. See this prototype in action. Will update the UX spec and implementation.

This change makes it easier to remove [meta] or [tracking] from summary if the meta type is introduced.

The UX spec is now complete so I gotta close this bug. Let’s move on to the migration plan.

Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → FIXED
Summary: UX for indicating if a bug is a task, feature, or defect → UX for indicating if a bug is a task, enhancement, or defect
Depends on: 1527529
Type: defect → task
You need to log in before you can comment on or make changes to this bug.