[Development] [QA] Suggestion -- Bug Reports' Assignment

Thiago Macieira thiago.macieira at intel.com
Tue Mar 19 00:01:54 CET 2013


On segunda-feira, 18 de março de 2013 14.39.14, Alan Alpert wrote:
> I'm not fond of this distinction because it's not very practical. I
> have plenty of low priority bugs assigned to me which I'm intending to
> fix "sometime". Does this count as "someone is going to work on the
> item"? Because it's certainly viable for someone else to take over if
> they wanted it done sooner than "sometime", just as viable as an
> unassigned bug. But there's the advantage that they know who to ask if
> they have questions about the task.
> 
> I much prefer the distinction like Thiago suggested, where assignee is
> a person "responsible" for the bug even if they aren't necessarily
> going to ever find time to work on the item. At least then you have
> someone to ask if you want to take it over but have questions.

Wait, wait.

I never suggested that long-term. I am ok with having a default assignee, who 
is responsible for *triaging* the bug. As soon as the triaging is complete, 
you can unassign.

I highly recommend that you keep yourself in the Watchers list after you 
unassign. I do that too, unless I reassigned to a very different domain (like 
"Core: Event System" -> "GUI: Window Management").

I do that and would like to continue doing that. One thing I hate is to have a 
very long dashboard, which is the same thing as not having a dashboard. The 
very long Gerrit dashboard is definitely impacting my efficiency -- and everyone 
who depends on me is suffering. Please don't force me to have a very long 
dashboard in JIRA too, it will just mean I won't look at JIRA, ever.

> I disagree, because JIRA is supposed to be a tool that allows the
> different groups to work together. It's going to be confusing for even
> dedicated triagers to follow a variety of conflicting rules, and it
> certainly can't be asked of the bug reporters (who don't want to need
> special training based on the component which they're bad at picking
> anyways...). Even if the default assignee is "Unassigned" for some
> modules, the meaning of assigned vs unassigned should be consistent
> throughout the Qt project.

Agreed.

> 
> > Personally, I'm happy to have testlib bugs auto-assigned to me so that
> > I get an email for each new bug to prompt me to go and triage it.  I
> > prefer the email notification to having to poll Jira frequently.  The
> > volume of new bug reports in testlib is low enough that this works
> > well for me.  I also happen to be the default assignee of the Other
> > component and getting those bugs auto-assigned to me prompts me via
> > email to have a look and figure out which component the Other bugs
> > really belong to.  Unless I mark something as In Progress, I'm happy
> > for anybody else to take it off my hands by assigning it to
> > themselves.
> > 
> > On the other hand, I can see that maintainers with a larger throughout
> > of Jira tasks might prefer to default to Unassigned and poll Jira for
> > high-priority items.  Jira supports both options on a per-component
> > basis, so we can be flexible.
> 
> Except that you need to triage the bugs *before* you can be confident
> in the component or priority, so that approach doesn't work.

Agreed too.

But doesn't JIRA have a feature that mails you of new activity (including new 
entries) in a search term? You should be able to watch components and be 
notified, just as if you had been assigned a new bug.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130318/49a91277/attachment.sig>


More information about the Development mailing list