Difference between revisions of "IssueHandling"
(→responsible owner paradigm) |
|||
| Line 25: | Line 25: | ||
== y.x Targets (2.x, 3.x, etc) == | == y.x Targets (2.x, 3.x, etc) == | ||
| + | |||
| + | Issues which is not being actively worked on but is intended to do so, will have target 3.x. Once a child workspace have been created and issue has been registered the target milestone will be set to the actual release target. In the current situation more issues are already set to the actual release target, this leads to the situation, that just before release those issue will be re-targeted to the next release. | ||
| + | |||
| + | Proposal: | ||
| + | |||
| + | Issues (Defects) with | ||
| + | * keywords "regression", "crash", "loop", "usability", "release_blocker", | ||
| + | * issues of Priority P1, P2, | ||
| + | |||
| + | can set to the next release target even with no assigned cws or even owner. | ||
| + | |||
| + | Issues (Defects) which | ||
| + | * have P3-P5 priority | ||
| + | * not assigned to living cws | ||
| + | should have target 3.x to get fixed in a reasonable time frame. | ||
| + | |||
[[Category:Releases]] | [[Category:Releases]] | ||
[[Category:To-Do]] | [[Category:To-Do]] | ||
Revision as of 12:53, 13 February 2008
Proposal for a changed issue handling
responsible owner paradigm
Currently every issue is assigned to an owner. There are default owners defined per project. The default owner reviews the incoming issues and is assigning the issues the the correct owners in engineering. In most cases also the target milestone will be set (next release, 3.x, Later, PleaseHelp). So some engineers have several hundred issues assigned which is an unreasonable high amount of issues. Idea is to introduce a new owner "unassigned" (nobody is already occupied in OOo) to which issues can be reassigned to indicate that anybody else is able to jump on this issue.
| Name | Pros | Cons |
|---|---|---|
| dedicated owner | There's every time a responsible owner to ask | there is only one owner, people dont care about issue assigned to others |
| clear responsiblity | unclear responsibilty, the project group is in charge | |
| assigned to the right person | unclear transparency, it's is unclear if the owner really intend to work on this issue in the near future | |
| issues with owner unassigned | transparency: owner do not intend to work on issue in reasonable timeframe | |
| a developer has an reasonable amount of issues | ||
| a developer is not blocking issues |
y.x Targets (2.x, 3.x, etc)
Issues which is not being actively worked on but is intended to do so, will have target 3.x. Once a child workspace have been created and issue has been registered the target milestone will be set to the actual release target. In the current situation more issues are already set to the actual release target, this leads to the situation, that just before release those issue will be re-targeted to the next release.
Proposal:
Issues (Defects) with
- keywords "regression", "crash", "loop", "usability", "release_blocker",
- issues of Priority P1, P2,
can set to the next release target even with no assigned cws or even owner.
Issues (Defects) which
- have P3-P5 priority
- not assigned to living cws
should have target 3.x to get fixed in a reasonable time frame.
