Line 16: |
Line 16: |
| :* For 0.82, the next Sugar release, we are going to work mainly on OLPC [http://wiki.laptop.org/go/Priorities-2008 Update.2 priorities]. I need to extract the major Sugar features and changes from there and add to the [[Roadmap]]. Other than that 0.82 will be mostly bug fixes. --[[User:Marcopg|Marcopg]] | | :* For 0.82, the next Sugar release, we are going to work mainly on OLPC [http://wiki.laptop.org/go/Priorities-2008 Update.2 priorities]. I need to extract the major Sugar features and changes from there and add to the [[Roadmap]]. Other than that 0.82 will be mostly bug fixes. --[[User:Marcopg|Marcopg]] |
| * What are the big annoyances/obstacles to making the above happen? | | * What are the big annoyances/obstacles to making the above happen? |
| + | :* I don't see big obstacles. Involving the community more and better would certainly get us faster though. --[[User:Marcopg|Marcopg]] |
| * Do we have a sense of what makes a good Sugar bug report? (What does?) | | * Do we have a sense of what makes a good Sugar bug report? (What does?) |
| + | :* Some of your notes are actually very good in this respect. What about starting a [[BugReport]] page and put your notes there? I can step in and add my ideas. --[[User:Marcopg|Marcopg]] |
| * Some assigned bug reports are written in an opaque (to outsiders) shorthand that may make sense for the developer involved, but could forestall anyone else from being able to pop into and contribute towards. | | * Some assigned bug reports are written in an opaque (to outsiders) shorthand that may make sense for the developer involved, but could forestall anyone else from being able to pop into and contribute towards. |
| + | :* This is a very good point actually and I would like to see it our bug reporting guidelines. --[[User:Marcopg|Marcopg]] |
| * Do we have a team of verification volunteers? (Should they be recruited?) | | * Do we have a team of verification volunteers? (Should they be recruited?) |
| + | :* We don't have one but we should totally recruit it. See my and Walter notes about the verification process on [[Talk:Triage]]. |
| * Do we want to make it easier to cross-reference bugs with each other by using something like the [http://trac-hacks.org/wiki/TracBacksPlugin TracBacks plugin]? (Full disclosure: I wrote this.) Also potentially helpful if there will be a separate Sugar Trac: [http://trac-hacks.org/wiki/TrashTalkPlugin the TrashTalk plugin], which does external trackbacks to tickets (useful for monitoring upstream/downstream trac instances, for instance). | | * Do we want to make it easier to cross-reference bugs with each other by using something like the [http://trac-hacks.org/wiki/TracBacksPlugin TracBacks plugin]? (Full disclosure: I wrote this.) Also potentially helpful if there will be a separate Sugar Trac: [http://trac-hacks.org/wiki/TrashTalkPlugin the TrashTalk plugin], which does external trackbacks to tickets (useful for monitoring upstream/downstream trac instances, for instance). |
| * Do we have a "trac" component on trac (to report something's broken, to request plugins, etc)? Should we? | | * Do we have a "trac" component on trac (to report something's broken, to request plugins, etc)? Should we? |