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/
signature.asc
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel