[Sugar-devel] Github issue tracking

[Walter Bender]

On Tue, May 14, 2013 at 9:06 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> On Tuesday, 14 May 2013, Manuel Quiñones wrote:
>
>> 2013/5/13 Daniel Narvaez <dwnarvaez at gmail.com>:
>> >
>> >
>> > On Monday, 13 May 2013, Manuel Quiñones wrote:
>> >>
>> >> 2013/5/11 William Orr <will at worrbase.com>:
>> >> >
>> >> > Hello,
>> >> >
>> >> > Sticking with a privately controlled bug tracker is probably a good
>> >> > idea.
>> >> > However, trac really needs to be cleaned up, as there are a ton of
>> 3-5
>> >> > year
>> >> > old bugs floating around that have long since been fixed. I've
>> started
>> >> > closing the few I can't reproduce in scm.
>> >> >
>> >> > As a new contributor, I initially had gotten the impression that no
>> one
>> >> > used
>> >> > trac, and I was discouraged from reporting/fixing bugs there.
>> >>
>> >> Things we can do to improve the poor state of trac:
>> >>
>> >> - make Milestone 1.0 the recommended trac view
>> http://tinyurl.com/ckuk7cq
>> >> - ask the infra team to make the above filter very visible in the trac
>> >> homepage
>> >> - bugs detected in sugar-build should be reported as 1.0
>> >> - add a note about this recommendations in sugar-docs
>> >>
>> >> I closed a lot of obsolete bugs filed in Browse component.  But I see
>> >> two problems trying to clean all trac:
>> >>
>> >> 1. it is a lot of work, who is going to do it?
>> >>
>> >> 2. it is used for several things.  There are many components, not only
>> >> for sugar or activities, but for infra, for funding, distros, etc.
>> >>
>> >> That's why I suggest to provide the right view for developers instead.
>> >
>> >
>> > I agree that we need to come up with the right query and publicize it
>> > (perhaps we can make it the default too?).
>>
>> The problem setting it as default is that trac is used for other
>> things, not just sugar or activity code.  There are "third party"
>> activities, funding requests, deploys stuff etc.  But yes the
>> "developers view" should be on top of the homepage, I think.
>>
>>
> I know but isn't that a good default view anyway? I mean, what most people
> going to bugs.sugarlabs.org will want to do is to report a sugar bug. The
> other stuff share the same tracker for convenience, but I'd say they are
> secondary. These other things could link to some query rather than to the
> homepage.
>
>
>> > Though I'm wondering, why a milestone instead of a list of components?
>> Is it
>> > because triaging existing bugs would be too much work? How are bugs
>> going to
>> > be added to the 1.0 list? Or is it only for developers-reported stuff?
>> Who
>> > is going to look at bugs not on 1.0?
>>
>> I was thinking in a milestone to cut-off the old/obsolete bugs.  We
>> already did for 0.98 .
>
>
> I tend to think the honest thing to do if we are not going to look at bugs
> is either to just close them or to mark them as needs-triage and exclude
> them from the main query.
>
> It might piss off reporters, but we can ask for help with triage when they
> complain. I mean it sucks, but just silently ignoring the bugs is even
> worst.
>
> Also we can ask everyone help with triaging before we go ahead and close.
> If people helps out great, otherwise well...
>
> My opinion is that a bug tracker is useful only if all the bugs it
> contains are active. Better to close very aggressively than to lose
> important stuff in the mess of things that you alreay know will never be
> looked at. Zero bugs should be the goal, not tracking everything for the
> sake of it (like most open source projects do :p).
>
> Ideally before submitting to 1.0 the reporter
>> should:
>>
>> - do a search to see if its not reported
>>     - if is not reported, file it as 1.0
>>     - if is reported, move it to 1.0 and add a comment that this bug
>> is still happening
>>
>
> I think this is asking too much to reporter. Very few people are likely to
> do it. IMO the most help we can ask to the reporter with triaging is to
> choose a component between sugar and a list of activity names, the version
> of sugar they was using, posssibly avoid duplicates. They are not going to
> know more than that.
>
>
> --
> Daniel Narvaez
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
I think what would really help, independent of where/how we host things, is
to institute more regular (and inclusive) triage meetings. I cannot think
of the last time we had one that was announced on sugar-devel.

-walter



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130514/3e800361/attachment.html>