1501114 - Allow a bug to have multiple Assignees

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, enhancement)

Description

[Kohei Yoshino [:kohei]]

Currently the bug Assignee field is mandatory and accepts only one person. When no one is set, it will be `[e-mail]` by default. Dylan has a PR to make it customizable [1] but ideally the field should be able to be empty.

Also, sometimes there are cases where 2 or more people have to work together. At this time you can only have the primary or first Assignee, which isn’t great.

Bugzilla should be allowing a bug to have multiple or no Assignees just like GitHub [2] or the Mentors field on Bugzilla itself.

This would be a post-Quantum action item. This also makes the integration with GitHub (as well as migrations from GitHub) easier.

[1] https://github.com/mozilla-bteam/bmo/pull/730
[2] https://blog.github.com/2016-05-27-multiple-assignees-on-issues-and-pull-requests/

Comment 1

[Kohei Yoshino [:kohei]]

A recent use case: Bug 1477931 Comment 15. I’m the original assignee and Dylan takes the backend part so he has to be added as the second assignee instead of replacing me.

Comment 4

[David Lawrence [:dkl]]

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

A recent use case: Bug 1477931 Comment 15. I’m the original assignee and Dylan takes the backend part so he has to be added as the second assignee instead of replacing me.

I feel like each bug/task should have one specific purpose and therefore one specific assignee. When you have bugs like bug 1477931 then it should be split out into two bugs with maybe a meta tracking bug or dependency chain and then each person would be assigned to their own task. That is just my opinion. I do agree though the assignee should allow to be blank, just not multiple values.

Comment 5

[Kohei Yoshino [:kohei]]

I tend to agree with :dkl in general, but

• GitHub already allows to have multiple assignees

• we should also think about the GitHub to Bugzilla migration support in the future
• Non-tech bugs, for example researches, may require multiple assignees

Comment 6

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I'm not convinced yet that we must have feature parity with GitHub on this.

I think allowing the field to be empty is fine. We have plenty of people creating 'nobody@' accounts to mess with autocomplete results.

I'm not sure we need multiple assignees, and we should think about product and component-level roles first.

Comment 7

[Kohei Yoshino [:kohei]]

There are potential use cases as mentioned earlier so we should fulfill that. There is only one assignee in most cases as seen on GitHub. GitLab does the same.

Comment 8

[Kohei Yoshino [:kohei]]

Another use case is meta bugs. I’d like to replace them with milestones (and project dashboards) in the future as mentioned elsewhere, but it probably won’t happen soon and people continue filing meta bugs, where sometimes multiple people are in charge of.

Comment 9

[Kohei Yoshino [:kohei]]

Yet another use case: project boards. Trello and several other Kanban tools support multiple assignees. Each card will be a bug on Bugzilla, so we have to add the support.

Comment 10

[David Lawrence [:dkl]]

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

I tend to agree with :dkl in general, but

• GitHub already allows to have multiple assignees


I agree with Emma that some features of GitHub don't always have to be ported to BMO unless there is a good case for helping Firefox developers get their jobs done.

• we should also think about the GitHub to Bugzilla migration support in the future
• Non-tech bugs, for example researches, may require multiple assignees

Seems like a lot of complexity added for something that will be rarely used. There is certainly other ways to handle this situation given how BMO currently works.

@dylan, thoughts?

Comment 11

[Dylan Hardison [:dylan] (he/him)]

Considering that people don't make use of the assignee field already (nobody is the most productive person in BMO) I'm not sure what value this adds.

Pretty much echo dkl's thoughts.

Comment 12

[Kohei Yoshino [:kohei]]

I see many cases on Trello and GitHub boards where multiple people are assigned to a single card/issue. Given that we have a plan to have a similar feature, we should think about it instead of the existing, traditional use cases on BMO.

Comment 13

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

We have rules in AutoNag for bugs without assignees.

https://github.com/mozilla/relman-auto-nag/blob/master/auto_nag/scripts/configs/tools.json

Comment 14

[Kohei Yoshino [:kohei]]

Mentors are already multiple but a BMO customization, so Assignees, Mentors and QA Contacts could all be merged into a single table bug_roles in the core. This potentially allows upstream users to have Reviewers as well, just like GitHub.

Comment 15

[Dylan Hardison [:dylan] (he/him)]

Doing this would be a big untertaking, and would require refactoring bug access policies as well, which has to be done in several places.

I'm not fully opposed, I just don't know what the priority on this would be.

Comment 16

[Kohei Yoshino [:kohei]]

Okay, let’s allow the Assignee field to be empty first to solve the headaches like Bug 1543652 and improve UX, mainly searchability. It should be done before Bugzilla 6.0 so we don’t have to ship [e-mail]/*.bugs email hacks with the upstream. Making the field multiple can be done later on.

Comment 17

[Kohei Yoshino [:kohei]]

Reopened Gerv’s 12-year-old Bug 369078.

Comment 18

[:glob ✱]

This will require a lot of work and add significant amounts of complexity for very little return.

We won't be doing this.