On Thu, Apr 10, 2014 at 6:52 AM, Gonzalo Odiard <godi...@sugarlabs.org> wrote: > Well, maybe call iy "normal" or "low" instead of "minor", but we need a way > to separate the tickets we _need_ fix, the tickets we _want_ fix, > and the tickets _would_be_nice_ fix. > We have almost 250 tickets, if we can solve 50 tickets in these 2 months, > is important know what are the best candidates.
Maybe it is as simple as that: (1) need_to_fix (2) want_to_fix (3) nice_to_fix I cannot imagine we need more granularity than that. -walter > > Gonzalo > > > On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez <dwnarv...@gmail.com> wrote: >> >> This is probably going to be a bit controversial, but I think if something >> is worth marking minor then it's probably not worth tracking. We will never >> get to fix the minor but we will waste time triaging and retriaging them. >> >> >> On Thursday, 10 April 2014, Gonzalo Odiard <godi...@sugarlabs.org> wrote: >>> >>> +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 >>> >> >>> > >>> >>> -- >>> Gonzalo Odiard >>> >>> SugarLabs - Software for children learning >> >> >> >> -- >> Daniel Narvaez >> > > > > -- > Gonzalo Odiard > > SugarLabs - Software for children learning -- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep