... | @@ -115,36 +115,18 @@ This is just a proposal. Tomek's idea was to use dark colors for important thing |
... | @@ -115,36 +115,18 @@ This is just a proposal. Tomek's idea was to use dark colors for important thing |
|
|
|
|
|
# Reopens
|
|
# Reopens
|
|
|
|
|
|
**PROPOSAL ONLY (This section is being discussed)**
|
|
|
|
|
|
|
|
The usual issue life cycle is as follows: opened by a reporter, a dev looks at the problem and comes up with some code or doc changes, which are later reviewed. If reporter is part of ISC team, he/she is often also a reviewer, but these two roles in principles are different. Once reviewer and dev agree that the code is ready, the change is merged and ticket is closed. However, this process has one flaw: it doesn't take into consideration whether the proposed fix actually addressed the problem raised by the original reporter.
|
|
The usual issue life cycle is as follows: opened by a reporter, a dev looks at the problem and comes up with some code or doc changes, which are later reviewed. If reporter is part of ISC team, he/she is often also a reviewer, but these two roles in principles are different. Once reviewer and dev agree that the code is ready, the change is merged and ticket is closed. However, this process has one flaw: it doesn't take into consideration whether the proposed fix actually addressed the problem raised by the original reporter.
|
|
|
|
|
|
The alternative - to ask for confirmation - has many flaws. The reporter may not be skilled enough to know how to pull a branch from git, may be unwilling or unable to compile it or more likely be simply unresponsive. This would leave us with many tickets stuck in almost-done state. So we chose to use the approach of merging and closing, with reopen as an escape clause. Sometimes we also put a note "if the solution doesn't work, please reopen". This covers 99% of the cases. Let's talk about the remaining 1%.
|
|
The alternative - to ask for confirmation that the original problem is addressed - has many flaws. The reporter may not be skilled enough to know how to pull a branch from git, may be unwilling or unable to compile it or more likely be simply unresponsive. This would leave us with many tickets stuck in almost-done state. So we chose to use the approach of merging and closing, with reopen as an escape clause. If the reporter didn't confirm that the fix working, it's good to add something like "We think this should fix the original problem. If it doesn't work or you disagree with the solution, please reopen". This covers 99% of the cases. The text below discusses the remaining 1%.
|
|
|
|
|
|
Someone reports a problem, we look at it, come up with a solution that we think addressed the problem, merge it and close. The reporter looks at the solution and discovers it doesn't solve the problem and reopens. There may be several reasons for this:
|
|
There's the scenario: Someone reports a problem, we look at it, come up with a solution that we think addressed the problem, merge it and close. The reporter looked at the solution and discovered it doesn't solve the problem and reopens. There may be several reasons for this:
|
|
|
|
|
|
- the fix didn't work (or works in some cases, such as our unit-tests, but doesn't in the real life deployment as experienced by reporter)
|
|
- the fix didn't work (or works in some cases, such as our tests, but doesn't in the real life deployment as experienced by reporter)
|
|
- the dev didn't understand the core of the problem (this may be caused be inadequate or incomplete description of the problem)
|
|
- the dev didn't understand the core of the problem (this may be caused be inadequate or incomplete description of the problem)
|
|
- the reporter doesn't like the solution and would like to get something different
|
|
- the reporter doesn't like the solution and would like to get something different
|
|
|
|
- completely fixing the problem is too difficult or not reasonable (e.g. we will not rewrite whole parser just to improve an error message)
|
|
|
|
|
|
There may be other reasons. In all 3 cases, the major point is that the original problem remains unsolved and there is more to be done here. What should be done in such cases? Here are couple proposals:
|
|
There may be other reasons. In all cases the major point is that the original problem remains unsolved and there is more to be done here. What should be done in such cases? **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. Feel free to ask the third person depending on the situation - a dev that's expert in the area, maybe someone from QA or get a manager involved.
|
|
|
|
|
|
**APPROACH A** - In case of reopen, QA gets involved and determines whether the proposed solution is ok and sufficient or not. Once dev has his updated solution (after reopen) ready to go, QA has to verify it before it's merged. This is the safest approach, but it may become very tedious. QA is busy with their normal work, so this would in general slow down dealing with reopens.
|
|
|
|
|
|
|
|
**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.
|
|
|
|
|
|
|
|
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**
|
|
In any case, closing a ticket that was reopened can easily be considered as rude behavior and can damage the public image of the whole project. If there's really nothing reasonable to be done in the short term, perhaps moving to %Outstanding is a good alternative to closing?
|
|
|
|
|
|
- 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 |
|
|