[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