+1 to check if are enhancements or defects. About priorities, we can make something like:
blocker: regressions, crashes, serious bugs major: bugs affecting the usability minor: other Just a idea to start to discuss. Gonzalo On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender <walter.ben...@gmail.com>wrote: > On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez <dwnarv...@gmail.com> > wrote: > > Something else to consider is what to do with priorities. It might make > > sense to set one when confirming bugs, it's hard to get right without > > spending a lot of time really but maybe helpful for contributors even if > not > > very accurate. > > I think we have too many categories for priorities: IMHO, either it is > a blocker or it is not. > > -walter > > > > > > On Thursday, 10 April 2014, Daniel Narvaez <dwnarv...@gmail.com> wrote: > >> > >> > >> > >> On Thursday, 10 April 2014, Gonzalo Odiard <godi...@sugarlabs.org> > wrote: > >>> > >>> > >>> > >>> > >>> On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez <dwnarv...@gmail.com> > >>> wrote: > >>>> > >>>> On Wednesday, 9 April 2014, Gonzalo Odiard <godi...@sugarlabs.org> > >>>> wrote: > >>>>> > >>>>> > >>>>> On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez <dwnarv...@gmail.com > > > >>>>> wrote: > >>>>>> > >>>>>> This is an interesting blog post with a paragraph about GNOME > triaging > >>>>>> > >>>>>> http://afaikblog.wordpress.com/2014/04/09/enabling-participation/ > >>>>>> > >>>>>> Interestingly it's pretty much exactly the same approach I followed > >>>>>> with the triaging I had done with 0.100. It would be good to have a > simple > >>>>>> set of rule like that written down before the meeting. I think the > way we > >>>>>> triage has a huge impact on lowering contribution barriers, > >>>>>> > >>>>> > >>>>> +1 > >>>>> > >>>>> We need at least verify all the "Unconfirmed" tickets. We can start > >>>>> now, don't need wait until the triage meeting. > >>>>> I assume, if the bug is confirmed, we should set: > >>>>> Milestone = 0.102 > >>>>> Status = New > >>>> > >>>> > >>>> I wonder about Milestone. It seems like it would only be useful if we > >>>> assign different milestones to tickets and I'm not sure we can do that > >>>> without being able to allocate resources to fix them. It's also a time > >>>> consuming task. > >>> > >>> > >>> True. > >>> > >>>> > >>>> > >>>>> > >>>>> or close them if are not longer present. > >>>>> > >>>>> Would be good if we can reset all the priorities to "Unassigned", > >>>>> in all the tickets with module=Sugar,the field content does not have > >>>>> any sense right now. > >>>> > >>>> > >>>> Do we want to use the field? Otherwise maybe there is a way to just > get > >>>> rid of it. > >>>> > >>>> > >>> > >>> Just to mark they have been triaged, and based in the querys used in > >>> bugs.sugarlabs.org home. > >>> Do you propose doing in another way? > >> > >> > >> The home queries uses status == unconfirmed for untriaged. The tickets I > >> set status = new (not that many left) have been confirmed. I had reset > >> everything to unconfirmed before starting to triage. > >> > >> > >> -- > >> Daniel Narvaez > >> > > > > > > -- > > Daniel Narvaez > > > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > -- Gonzalo Odiard SugarLabs - Software for children learning
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep