... | @@ -134,3 +134,17 @@ There may be other reasons. In all 3 cases, the major point is that the original |
... | @@ -134,3 +134,17 @@ There may be other reasons. In all 3 cases, the major point is that the original |
|
**APPROACH B** - You can only close a ticket once. If there's a reopen, a third person needs to get involved and independently confirm that the solution is valid and complete. This is kind of natural extension of the process we have for review where if dev and reviewer cannot reach an agreement, they ask for a third opinion.
|
|
**APPROACH B** - You can only close a ticket once. If there's a reopen, a third person needs to get involved and independently confirm that the solution is valid and complete. This is kind of natural extension of the process we have for review where if dev and reviewer cannot reach an agreement, they ask for a third opinion.
|
|
|
|
|
|
**APPROACH C** - If you don't like A and B, write your proposal here.
|
|
**APPROACH C** - If you don't like A and B, write your proposal here.
|
|
|
|
|
|
|
|
There's also a related question of handling complex fixes. A ticket calls for something that's complex to do, e.g. ensure that new parameter is consistent with existing configuration. A dev comes up with a solution that improves the situation, e.g. does some extra checks that reject some, but not all invalid values. The full solution requires additional tickets. The question is whether to close the original one or not.
|
|
|
|
|
|
|
|
**CLOSE IT**.
|
|
|
|
|
|
|
|
- PRO: fewer open tickets
|
|
|
|
- CON: external references
|
|
|
|
- CON: the reporter may be frustrated
|
|
|
|
|
|
|
|
**KEEP IT OPEN**
|
|
|
|
|
|
|
|
- PRO: reporter more satisfied (his problem is being worked on)
|
|
|
|
- CON: more tickets open
|
|
|
|
- CON: potential for having multiple changelog entries with the same ticket (can be mitigated with new tickets perceived as extra sub-tasks) |
|
|
|
\ No newline at end of file |