[Sugar-devel] Github issue tracking

[Walter Bender]

Shall we schedule something? What would be a good time to do this? I'm
pretty flexible.

-walter


On Wed, May 15, 2013 at 6:32 PM, William Orr <will at worrbase.com> wrote:

> 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 <Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/**listinfo/sugar-devel<http://lists.sugarlabs.org/listinfo/sugar-devel>
>> Walter Bender <mailto:walter.bender at gmail.**com <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 <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 <Sugar-devel at lists.sugarlabs.org>
>>     <mailto:Sugar-devel at lists.**sugarlabs.org<Sugar-devel at lists.sugarlabs.org>
>> >
>>     http://lists.sugarlabs.org/**listinfo/sugar-devel<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 <Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/**listinfo/sugar-devel<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
>>
>>


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