[IAEP] [Sugar-devel] triage meeting

[Daniel Narvaez]

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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20140410/edf0a45c/attachment.html>