[IAEP] [Sugar-devel] triage meeting

[Gonzalo Odiard]

+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
> >>
> >
> >
> > --
> > Daniel Narvaez
> >
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>



-- 
Gonzalo Odiard

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