Difference between revisions of "IssueHandling"
(→responsible owner paradigm) |
|||
| Line 43: | Line 43: | ||
should have target 3.x to get fixed in a reasonable time frame. | should have target 3.x to get fixed in a reasonable time frame. | ||
| + | == default ownership == | ||
| + | Currently in most project there is _one_ owner assigned to be the default owner. The work load can be divided by introducing an alias (Database already has dba_needsconfirm for this). The responsibility that this queue get reviewed on a regular basis is up to the project lead ( and the QA lead for this project is applicable). | ||
| + | |||
| + | == closing issues == | ||
| + | |||
| + | Currently the issues get reassigned to an QA person to verify the issue in the child workspace. This person also has the duty to verify and close that issue once integrated in the master (latest at release time). | ||
| + | |||
| + | Proposal: Do the verification of these issues on master in justified cases. The Project owner / QA Lead can decide to do mass closing of issues if they think that this is reasonable. Anybody is able to reopen those issues in case of mistaken. | ||
[[Category:Releases]] | [[Category:Releases]] | ||
[[Category:To-Do]] | [[Category:To-Do]] | ||
Revision as of 13:04, 13 February 2008
Contents
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 |
Proposal: Introduce owner "unassigned". all issue with P3-P5 and target Office Later are candidates to get assigned to that owner. The target OOoPleaseHelp will become obsolete then.
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.
default ownership
Currently in most project there is _one_ owner assigned to be the default owner. The work load can be divided by introducing an alias (Database already has dba_needsconfirm for this). The responsibility that this queue get reviewed on a regular basis is up to the project lead ( and the QA lead for this project is applicable).
closing issues
Currently the issues get reassigned to an QA person to verify the issue in the child workspace. This person also has the duty to verify and close that issue once integrated in the master (latest at release time).
Proposal: Do the verification of these issues on master in justified cases. The Project owner / QA Lead can decide to do mass closing of issues if they think that this is reasonable. Anybody is able to reopen those issues in case of mistaken.
