We’re adding Type, Regressions and Regressed by shortly. It’s time to reorganize the modules and fields. My information architecture homework.

See Also: The Details tab on BzDeck

Here’s a draft:

(Header)

• [ID] [Alias]
• Summary
• [Open/Closed] [Reported] [Updated/Resolved]

Triage — set and corrected by a triage owner

• Product
• Component
• Version
• Platform: Hardware + OS
• Type
• Importance: Priority + Severity + Rank
• Points

Tracking — what’s happening now and next

• Status & Resolution
• Milestone (currently Target)
• Iteration
• Due Date
• Project & Tracking Flags

People

• [Reporter]
• [Triage Owner]
• Assignee
• Mentors
• QA Contact
• NeedInfo
• Subscribers (currently CC)

References — internal and external links

• Depends on
• Blocks
• Regressions
• Regressed by
• [Duplicates]
• URL
• See Also

Details — other aspects

• Alias
• Keywords
• Whiteboard
• QA Whiteboard
• Votes
• Other Flags
• Has Regression Range
• Has STR

Crash Data

• Signature
• Stats

Security

User Story

Phablicator Requests

Attachments

Emma, wdyt?

Thanks, I like this.

I'm wondering about the order of the Triage and Tracking modules and if we want to define which order they are in depending on the user. I can get that answered in interviews.

Maybe we could allow everyone to reorder these modules. There is a separate bug Emma filed 2 years ago 😁

By default, let's keep all the sections, people & below, collapsed.

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

By default, let's keep all the sections, people & below, collapsed.

+1

Since Crash Data now comes with a big table, I’ve moved the signature and stats to a separate module like this.

What's the status of this work?

Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?

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

What's the status of this work?

Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?

It is next up in my review queue.

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

Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?

Yes. It will be visible when Priority != -- OR Severity != normal, as well as in the Edit mode of course. Bug 1548506 has a screenshot for this.

Actually I would like glob to also review this as the original author of the modal page. glob thoughts on screenshot in comment 3?

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

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

Also, I don't see severity and priority in the sample attachment? Is that because those are at defaults?

Yes. It will be visible when Priority != -- OR Severity != normal, as well as in the Edit mode of course. Bug 1548506 has a screenshot for this.

Since our policy is that an open bug is not considered triaged when it's priority is -- then I think we should display Priority regardless.

(In reply to David Lawrence [:dkl] from comment #14)

Actually I would like glob to also review this as the original author of the modal page. glob thoughts on screenshot in comment 3?

Note that the page layout will be changed soon once we move to a 2-column layout on desktop.

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

Since our policy is that an open bug is not considered triaged when it's priority is -- then I think we should display Priority regardless.

How about showing a label like Not set like the Assignee field’s Unassigned because -- is unclear and can be easily overlooked.

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

How about showing a label like Not set like the Assignee field’s Unassigned because -- is unclear and can be easily overlooked.

Yes, that's a great idea.

Updated PR to always show the Priority field.

What happens on bugs which have Program/Project flags as well as status and tracking flags?

Both are displayed in the same Tracking section like this.

(In reply to David Lawrence [:dkl] from comment #14)

Actually I would like glob to also review this as the original author of the modal page. glob thoughts on screenshot in comment 3?

Most of these look great.

Triage

Triage is the act of assigning an order of treatment, bugzilla tracks the outcomes of the triage. While it's true that field in that section generally contain the results of triage it doesn't make sense for the fields to be labelled as such. None of the other section headers are verbs; "Triage" really stands out as out of place.

This section should be renamed.

(In reply to Byron Jones ‹:glob› 🎈 from comment #22)

Triage is the act of assigning an order of treatment, bugzilla tracks the outcomes of the triage. While it's true that field in that section generally contain the results of triage it doesn't make sense for the fields to be labelled as such. None of the other section headers are verbs; "Triage" really stands out as out of place.

This section should be renamed.

"Next Actions" or "Decisions Made"?

How about "Categories"? or "Status"?

I really see that section as "Descriptive Metadata" but that's a horrible name.

Classification is the right term in this case but we are already using it. If possible, I’d like to change the current Classification label to (Product) Category, and use Classification here. But probably we can’t do it.

So just Categories (= Triage Categories) maybe.

So I’ve renamed the Triage section to Categories (thanks :glob for the input!) Plus, (can’t be seen in this screenshot but) the read-only Duplicates field is now displayed even in the Edit mode, as requested by :adw in Bug 1539277.

This change has been deployed to https://bugzilla-dev.allizom.org for testing and feedback. Please take a look.

https://bugzilla-dev.allizom.org/show_bug.cgi?id=39 has an empty Details section (both when logged in and when logged out).
You can expand it but there's no visible fields within it until you switch to edit mode.

The only thing I find a little strange is that the Alias is set in the Details section but displayed in the bug header. I'd have expected it to be edited and displayed in the header since it relates to overriding the bug number.

(In reply to Byron Jones ‹:glob› 🎈 from comment #28)

https://bugzilla-dev.allizom.org/show_bug.cgi?id=39 has an empty Details section (both when logged in and when logged out).
You can expand it but there's no visible fields within it until you switch to edit mode.

It’s a known issue, and it seems a bit hard to solve it due to the current static way to hide the section. Most bugs have the Vote field so it won’t be empty. Will figure out how to solve it later.

(In reply to Mark Banner (:standard8) (afk 9 - 18 Aug) from comment #29)

The only thing I find a little strange is that the Alias is set in the Details section but displayed in the bug header. I'd have expected it to be edited and displayed in the header since it relates to overriding the bug number.

Most bugs don’t have an alias, and it’s like a keyword when it’s used, that’s why I’ve moved to the minor field to the Details section. But yeah, it may confuse some existing users.

I notice that the "Tracking flags", which is called "Firefox tracking flags" in the current production BMO, is no longer a heading and thus more difficult to find for a screen reader user among all the information modules. I also notice that it is now a link. Was that an intentional change to get rid of the heading assignment?

Yes, that’s an intentional change. All status/tracking information is now grouped in the same module for convenience, and this also solves Bug 1347009. I know each field name is not a header at this time, which will be solved soon in Bug 1350424.

From a quick look, it would make more sense to me if the "has regression range" field was in the "Tracking" section, as it's usually used together with the relevant branch flags that are also there. (I'm assuming we're intending to move away from the regression/regressionwindow-wanted keywords in favour of the newer field at some point in the near-ish future.) Does that sound sensible?

(In reply to :Gijs (he/him) from comment #33)

From a quick look, it would make more sense to me if the "has regression range" field was in the "Tracking" section, as it's usually used together with the relevant branch flags that are also there. (I'm assuming we're intending to move away from the regression/regressionwindow-wanted keywords in favour of the newer field at some point in the near-ish future.) Does that sound sensible?

We can revisit that once the new Is Regression field is added. It won’t be a blocker for this, and for now we may want to keep the Has Regression Range in the Details section as it’s often used together with the regression or regressionwindow-wanted keyword.

Merged to master. Feel free to file a new bug if something seems wrong.