[IAEP] [Sugar-devel] triage meeting

[Walter Bender]

On Thu, Apr 10, 2014 at 6:52 AM, 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.

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 <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 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