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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 > > > [email protected] > > > http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
