Difference between revisions of "BugSquad/Bug Triage"
< BugSquad
Jump to navigation
Jump to search
(New page: One key process in any software development project is the triaging of bugs and new features. The Sugar project has been part of the triage process used by the OLPC team (See http://dev.la...) |
m (moved BugSquad/ContentToEdit/Triage to BugSquad/Bug Triage: promote one level) |
||
| (26 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
| + | <noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude> | ||
One key process in any software development project is the triaging of bugs and new features. The Sugar project has been part of the triage process used by the OLPC team (See http://dev.laptop.org). The tool, [http://trac.edgewall.org/ trac], seems more than up to the task. The challenge is to define unambiguous category tags in order to make the job of triage containable and to bring clarity to what is expected of developers. | One key process in any software development project is the triaging of bugs and new features. The Sugar project has been part of the triage process used by the OLPC team (See http://dev.laptop.org). The tool, [http://trac.edgewall.org/ trac], seems more than up to the task. The challenge is to define unambiguous category tags in order to make the job of triage containable and to bring clarity to what is expected of developers. | ||
| − | Undoubted, a key is to define a clear [[Roadmap]] and decision-making process. | + | Undoubted, a key is to define a clear [[Development Team/Release/Roadmap|Roadmap]] and decision-making process. |
| + | |||
| + | |||
| + | Please see the [[Talk:BugSquad/ContentToEdit/Triage|'''discussion page''']] for ideas about how to improve the Triage process. | ||
| + | |||
| + | ---- | ||
Currently, the OLPC trac system uses the following property categories and actions: | Currently, the OLPC trac system uses the following property categories and actions: | ||
| Line 55: | Line 61: | ||
** accept | ** accept | ||
| − | + | [[Category:BugSquad]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | [[Category: | ||
Latest revision as of 10:39, 1 April 2010
One key process in any software development project is the triaging of bugs and new features. The Sugar project has been part of the triage process used by the OLPC team (See http://dev.laptop.org). The tool, trac, seems more than up to the task. The challenge is to define unambiguous category tags in order to make the job of triage containable and to bring clarity to what is expected of developers.
Undoubted, a key is to define a clear Roadmap and decision-making process.
Please see the discussion page for ideas about how to improve the Triage process.
Currently, the OLPC trac system uses the following property categories and actions:
- Type
- defect
- enhancement
- task
- Milestone
- Update.1
- Update.1.1
- xs-03
- Update.2
- Gen-2
- Future release
- Future features
- Never Assigned
- Opportunity
- Retriage, please
- Version
- a seemingly almost random list
- Priority
- blocker
- high
- med
- low
- Component
- a long list...
- CC
- Keywords
- Verified
- Blocking
- Blocked by
- Action
- leave as new
- resolve as
- fixed
- invalid
- won't fix
- duplicate
- works for me
- reassign to
- accept