[Sugar-devel] Q on tracker cleanup / triage

[Sascha Silbe]

Excerpts from Tim McNamara's message of Sat Jul 03 23:11:42 +0000 2010:

> Some have been identified as upstream problems, but their resolution status
> remains open.
That's because they still affect users. Some might need Sugar changes
once they have been handled upstream.
The current status fields we use in Trac are inconsistent (probably for
historic reasons). There's a better way (called Workflow [1]) to handle
this now, but so far nobody had time to design a new set of status fields
and matching Workflow for our Trac instance. Help in that area would be
very welcome - especially if it has a good way of indicating that we
are waiting for some other party (reporter, upstream, whatever) to do
something.

> I suggest that we make more use of the "wontfix" resolution status.
I recommend to use wontfix sparingly. It tends to alienate bug reporters
(as you mention yourself further down).
If it needs fixing in some component other than Sugar and we don't need
to do anything once it has been fixed, please file a bug against the
other component (i.e. "upstream") and set resolution to NOTSUGAR.

> [...] or possibly something like  "Unfortunately, we have higher priority
> areas to work on right now.
Never close bugs because nobody has time to fix them. Rather use the
priority field to indicate the maintainer isn't interested in working
on the issue, but would welcome patches.

> wontfix - upstream
>  http://bugs.sugarlabs.org/ticket/1307
This isn't a clear one. Yes, Firefox also behaves this way - but that
doesn't imply Browse _should_ do it. If we decide we want Browse to
be different, there's a good chance we can add some code to achieve
that. Mozilla won't change their code to accommodate our UI design
decisions.

> wontfix - other priorities
>  http://bugs.sugarlabs.org/ticket/288
The original request should be easy to handle. Turtle Art (or Turtle
Blocks or whatever it's called now, can't remember) already has an icon
with a snake that symbolises Python code.

>  http://bugs.sugarlabs.org/ticket/292
#288 evolved into a more generic discussion, which is how to handle
"related" MIME types (sub types, sibling types). #292 was opened to
handle this broader issue.
We might add a milestone 1.0 (or even after-1.0) to indicate this will
need to be fixed eventually, but not right away.

> duplicates
>  http://bugs.sugarlabs.org/ticket/172
>  http://bugs.sugarlabs.org/ticket/394
Duplicates are something a bug master would handle (by resolving bugs as
duplicate and adding the reporter of the dupe to the CC list of the
first filed ticket) if we had one. A bug master also ensures tickets are
filed against the correct component and are (apparently) complete.
In this particular case however the maintainer himself filed a second
bug on purpose, so please don't mark it as duplicate.

> Also, I don't know if I have the permission to change resolution status when
> something hasn't been touched for 12+ months. If I were to change status on
> likely candidates, would this anger the other developers?
You're free to handle most bugs in a way that helps resolving them. But
I would advise against closing bugs as WONTFIX or similar unless you're 
sure the maintainer is of the same opinion.

Sascha

[1] https://bugs.sugarlabs.org/wiki/TracWorkflow
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100703/619b1068/attachment.pgp