[IAEP] [Sugar-devel] triage meeting

[Gonzalo Odiard]

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


-- 
Gonzalo Odiard

SugarLabs - Software for children learning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/iaep/attachments/20140410/24de90a1/attachment-0001.html>