I disagree. While is true manage the tickets have cost, is good have a record of things we want to do, even when we don't have the resources today to do it. More in the context of a project where we have volunteers some times more, some times less.
Just my two cents ...of pesos :) Gonzalo On Thu, Apr 10, 2014 at 9:27 AM, Daniel Narvaez <dwnarv...@gmail.com> wrote: > What I'm saying is that the "would be nice" to fix will never be fixed, > they will keep accumulating and we will waste triage time on them over and > over. Better to just wontfix them, people can always send patches if they > care. Plus we tell them clearly it's up to them to do something if they > need them fixed. > > IMO it's really really important to aggressively close stuff we are not > realistically going to fix soon. Otherwise either we waste more time > triaging than fixing or we don't triage enough and the bug tracker becomes > useless. > > Just my two cents. We could also keep "low" for now and see if it really > grows too much to be worth retriaging over time. In my experience it's > always does but it would be nice to be proven wrong. > > On Thursday, 10 April 2014, 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. >> >> 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 w >> >> > > -- > Daniel Narvaez > > -- 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