[Sugar-devel] triage meeting

[Daniel Narvaez]

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 <godiard at 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 <dwnarvaez at 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 <godiard at 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.bender at gmail.com>wrote:
>
> On Wed, Apr 9, 2014 at 9:21 PM, Daniel Narvaez <dwnarvaez at 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 <dwnarvaez at gmail.com> wrote:
> >>
> >>
> >>
> >> On Thursday, 10 April 2014, Gonzalo Odiard <godiard at sugarlabs.org>
> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Apr 9, 2014 at 7:29 PM, Daniel Narvaez <dwnarvaez at gmail.com>
> >>> wrote:
> >>>>
> >>>> On Wednesday, 9 April 2014, Gonzalo Odiard <godiard at sugarlabs.org>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On Wed, Apr 9, 2014 at 11:53 AM, Daniel Narvaez <dwnarvaez at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140410/3fa4a903/attachment.html>