[Bf-committers] How to Manage Incomplete Tasks that have the Requested Information

Sergey Sharybin sergey.vfx at gmail.com
Tue Mar 22 10:59:47 CET 2016


Is it a proposal to automatically change task status to "Needs Triage" when
a comment added?

It's a bit tricky, because:

- You can't rely on the fact that only author's comment gives required bit
of information -- other user and/or developer could provide needed info.
- More than one developer can give tips what to test or what to provide
additionally.

So i would say status will be more clear to be in a developers' control. We
should just keep an eye on the incomplete reports and triage them back once
new info is provided.

Am also not really sure about difference between New / Needs Triage. In
order to move tracker back under control workflow should be like:

- New reports gets `Needs Triage` status, meaning nobody knows if it's a
real bug, limitation or a TODO
- Developer checks on that reports, if it's a known limitation or a TODO
mentiones this on the wiki TODO list (if needed) and closes the report.
- If it's a non-trivial fix the report could be considered a TODO right
away.
- If all the info is in the report but the developer who triages not really
familiar with the area, he changes statsu to Normal and pokes the area
maintainer
- If the developer knows the area and confirms it's a real bug, the status
gets set to Confirmed.

We really shouldn't pile reports up in the tracker, move them to a TODO. If
report is opened for some time, it's more a TODO! ;)

On Sun, Mar 20, 2016 at 10:53 PM, Aaron Carlisle <carlisle.b3d at gmail.com>
wrote:

> In my mind Unbreak Now! are for things that are things to be solved ASAP
> (such as a day or two)
> and High are for things that should be resolved before the release.
> However, yes one should be enough.
>
> On Sun, Mar 20, 2016 at 5:22 PM, Julian Eisel <eiseljulian at gmail.com>
> wrote:
>
> > I was thinking about proposing a similar idea some time ago, so +1 from
> me.
> > The downside would be that we don't have a way to mark reports as
> > being new, which is useful information. So maybe adding a new priority
> > 'New' would make sense?
> >
> > Further, I think we should only categorize a report as 'Normal' if
> > it's actually assigned to a developer and if there's a chance that
> > she/he will investigate soon. Even if we improved here already, there
> > are still too many old reports set to 'Normal' either assigned to
> > nobody or without much hope the person assigned will investigate soon.
> > (We might also apply this rule for 'Confirmed' reports).
> >
> > Following this proposal, criterias for setting priority would look
> > something like this:
> > * New: Newly created reports, awaiting initial review
> > * Needs Triage: Waiting on developer action
> > * Incomplete: Waiting on author action
> > * Normal: Issue not confirmed yet but assigned to developer
> > * Confirmed: Issue confirmed (and assigned to dev?)
> >
> > BTW, I always wondered why we have both 'High' and 'Unbreak Now!' as
> > priorities? They both have the same meaning in essence, so one should
> > be enough.
> >
> > On 20 March 2016 at 19:38, Aaron Carlisle <carlisle.b3d at gmail.com>
> wrote:
> > > I have noticed that often tasks that are missing some information (a
> > .blend
> > > file for example)
> > > and marked as incomplete seem to be forgotten if the users gives the
> > > requested
> > > information.  I purpose that these task be changed back to "Needs
> Triage"
> > > priority.
> > > It seems that this priority has not been used for its purpose and just
> > used
> > > as a
> > > priority for new tasks.  However, if this priority is used for its
> > purpose
> > > I think it will
> > > help these tasks not get lost in the bug tracker.
> > >
> > > Sincerely,
> > >
> > > Aaron Carlisle
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin


More information about the Bf-committers mailing list