[Sugar-devel] Github issue tracking

[Daniel Narvaez]

On Tuesday, 14 May 2013, Manuel Quiñones wrote:

> 2013/5/13 Daniel Narvaez <dwnarvaez at gmail.com <javascript:;>>:
> >
> >
> > On Monday, 13 May 2013, Manuel Quiñones wrote:
> >>
> >> 2013/5/11 William Orr <will at worrbase.com <javascript:;>>:
> >> >
> >> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130514/8d8c12e8/attachment-0001.html>