[Sugar-devel] Github issue tracking

[William Orr]

I can definitely help triage whenever you have this next meeting, 
depending on when it is.

> Daniel Narvaez <mailto:dwnarvaez at gmail.com>
> Tuesday, May 14, 2013 4:39 PM
> On Tuesday, 14 May 2013, Walter Bender wrote:
>
> Might make sense to do one earlier this time to clean up the mess. 
> Especially if a non coder is willing to take the lead :) Anyone??
>
>
> -- 
> Daniel Narvaez
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> Walter Bender <mailto:walter.bender at gmail.com>
> Tuesday, May 14, 2013 10:21 AM
>
>
>
> On Tue, May 14, 2013 at 9:23 AM, Daniel Narvaez <dwnarvaez at gmail.com 
> <mailto:dwnarvaez at gmail.com>> wrote:
>
>     On Tuesday, 14 May 2013, Walter Bender wrote:
>
>         I think what would really help, independent of where/how we
>         host things, is to instituteA more regular (and inclusive)
>         triage meetings. I cannot think of the last time we had one
>         that was announced on sugar-devel
>
>
>     How did they go when they was organised? I think they would very
>     helpful if the community participates. If its just the same people
>     which writes code, then I think their time is better spent fixing
>     bugs, reviewing and writing automated tests.
>
>
> We would have them in association with the release process. As I 
> recall, we held them after feature freeze and again closer to the 
> release date. It was in large part the coders, but not exclusively, 
> and it gave others a chance to chime in regarding priorities. We'd 
> generally meet for about 3 hours on a weekend.
>
> -walter
>
>
>
>     -- 
>     Daniel Narvaez
>
>
>
>
> -- 
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> Daniel Narvaez <mailto:dwnarvaez at gmail.com>
> Tuesday, May 14, 2013 9:23 AM
> On Tuesday, 14 May 2013, Walter Bender wrote:
>
> How did they go when they was organised? I think they would very 
> helpful if the community participates. If its just the same people 
> which writes code, then I think their time is better spent fixing 
> bugs, reviewing and writing automated tests.
>
>
> -- 
> Daniel Narvaez
>
> Walter Bender <mailto:walter.bender at gmail.com>
> Tuesday, May 14, 2013 9:14 AM
>
>
>
>     On Tuesday, 14 May 2013, Manuel Quiñones wrote:
>
>     I know but isn't that a good default view anyway? I mean, what
>     most people going to bugs.sugarlabs.org
>     <http://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.
>
>     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).
>
>
>     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
>     <mailto: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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
> Daniel Narvaez <mailto:dwnarvaez at gmail.com>
> Tuesday, May 14, 2013 9:06 AM
> 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 <http://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
>