[Development] [QA] Suggestion -- Bug Reports' Assignment
416365416c at gmail.com
Tue Mar 19 00:44:37 CET 2013
On Mon, Mar 18, 2013 at 4:01 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> 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.
Sorry for misinterpreting your sentiments. Myself, I think it's better
to keep it long term so that there's always a clear point of contact
for the task. Since JIRA components do not match cleanly to the
maintainers list, and 'assignee' level can be even more accurate than
that anyways, and the maintainers list is an additional step removed,
I think it's best to have a 'most relevant person' linked to from each
task. Even if all they can say about it is "No-one's working on that
right now, no idea when anyone would".
> 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.
The difference between JIRA and gerrit here, in my opinion, is that
JIRA is much more organizable on an individual basis. My JIRA
dashboard is used as a link to various filters for when I'm looking at
various tasks. I don't often look at the 'all my assigned issues',
since I have more specific filters for common activities (such as
triage). This includes being able to look only at tasks with high
priority or recent activity, something that would clean up the gerrit
dashboard a lot (but shouldn't be added fully-blown to gerrit because
it would be immense feature creep).
>> 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.
>> > 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.
Yes, there are multiple ways of searching for "untriaged" bugs. I'd be
happy with any definitive filter that could be used to triage bugs for
the component, for which my current one is AssignedUser == Maintainer
&& Priority == Unevaluated.
That said, there's also the 'responsible' person aspect to having
tasks auto-assigned, as well as the triage aspects.
More information about the Development