<div dir="ltr">Well, maybe call iy "normal" or "low" instead of "minor", but we need a way <div>to separate the tickets we _need_ fix, the tickets we _want_ fix,</div><div>and the tickets _would_be_nice_ fix.</div> <div>We have almost 250 tickets, if we can solve 50 tickets in these 2 months,</div><div>is important know what are the best candidates.</div><div><br></div><div>Gonzalo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"> On Thu, Apr 10, 2014 at 3:52 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<div> <div class="h5"><br> <br>On Thursday, 10 April 2014, Gonzalo Odiard <<a href="mailto:godiard@sugarlabs.org" target="_blank">godiard@sugarlabs.org</a>> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div class="h5"> <div dir="ltr">+1 to check if are enhancements or defects.<div><br></div><div>About priorities, we can make something like:</div><div><br></div><div>blocker: regressions, crashes, serious bugs</div><div><br></div><div>major: bugs affecting the usability</div> <div><br></div><div>minor: other</div><div><br></div><div>Just a idea to start to discuss.</div><div><br></div><div>Gonzalo</div><div><br></div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div> On Wed, Apr 9, 2014 at 10:24 PM, Walter Bender <span dir="ltr"><<a>walter.bender@gmail.com</a>></span> wrote:<br> <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez <<a>dwnarvaez@gmail.com</a>> wrote:<br> > Something else to consider is what to do with priorities. It might make<br> > sense to set one when confirming bugs, it's hard to get right without<br> > spending a lot of time really but maybe helpful for contributors even if not<br> > very accurate.<br> <br> </div>I think we have too many categories for priorities: IMHO, either it is<br> a blocker or it is not.<br> <span><font color="#888888"><br> -walter<br> </font></span><div><div>><br> ><br> > On Thursday, 10 April 2014, Daniel Narvaez <<a>dwnarvaez@gmail.com</a>> wrote:<br> >><br> >><br> >><br> >> On Thursday, 10 April 2014, Gonzalo Odiard <<a>godiard@sugarlabs.org</a>> wrote:<br> >>><br> >>><br> >>><br> >>><br> >>> On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez <<a>dwnarvaez@gmail.com</a>><br> >>> wrote:<br> >>>><br> >>>> On Wednesday, 9 April 2014, Gonzalo Odiard <<a>godiard@sugarlabs.org</a>><br> >>>> wrote:<br> >>>>><br> >>>>><br> >>>>> On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez <<a>dwnarvaez@gmail.com</a>><br> >>>>> wrote:<br> >>>>>><br> >>>>>> This is an interesting blog post with a paragraph about GNOME triaging<br> >>>>>><br> >>>>>> <a href="http://afaikblog.wordpress.com/2014/04/09/enabling-participation/" target="_blank">http://afaikblog.wordpress.com/2014/04/09/enabling-participation/</a><br> >>>>>><br> >>>>>> Interestingly it's pretty much exactly the same approach I followed<br> >>>>>> with the triaging I had done with 0.100. It would be good to have a simple<br> >>>>>> set of rule like that written down before the meeting. I think the way we<br> >>>>>> triage has a huge impact on lowering contribution barriers,<br> >>>>>><br> >>>>><br> >>>>> +1<br> >>>>><br> >>>>> We need at least verify all the "Unconfirmed" tickets. We can start<br> >>>>> now, don't need wait until the triage meeting.<br> >>>>> I assume, if the bug is confirmed, we should set:<br> >>>>> Milestone = 0.102<br> >>>>> Status = New<br> >>>><br> >>>><br> >>>> I wonder about Milestone. It seems like it would only be useful if we<br> >>>> assign different milestones to tickets and I'm not sure we can do that<br> >>>> without being able to allocate resources to fix them. It's also a time<br> >>>> consuming task.<br> >>><br> >>><br> >>> True.<br> >>><br> >>>><br> >>>><br> >>>>><br> >>>>> or close them if are not longer present.<br> >>>>><br> >>>>> Would be good if we can reset all the priorities to "Unassigned",<br> >>>>> in all the tickets with module=Sugar,the field content does not have<br> >>>>> any sense right now.<br> >>>><br> >>>><br> >>>> Do we want to use the field? Otherwise maybe there is a way to just get<br> >>>> rid of it.<br> >>>><br> >>>><br> >>><br> >>> Just to mark they have been triaged, and based in the querys used in<br> >>> <a href="http://bugs.sugarlabs.org" target="_blank">bugs.sugarlabs.org</a> home.<br> >>> Do you propose doing in another way?<br> >><br> >><br> >> The home queries uses status == unconfirmed for untriaged. The tickets I<br> >> set status = new (not that many left) have been confirmed. I had reset<br> >> everything to unconfirmed before starting to triage.<br> >><br> >><br> >> --<br> >> Daniel Narvaez<br> >><br> ><br></div></div></blockquote></div>-- <br></div></div><div class=""><div dir="ltr">Gonzalo Odiard<br><br><div>SugarLabs - Software for children learning <br></div></div> </div></div><span class="HOEnZb"><font color="#888888"> </font></span></blockquote><span class="HOEnZb"><font color="#888888"><br><br>-- <br>Daniel Narvaez<br><br> </font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Gonzalo Odiard<br><br><div>SugarLabs - Software for children learning <br></div></div> </div>