Closing a bug is a 2-step process?
Let's say I have an issue of type Bug. The bug has now been fixed, so I want to close the issue. I go to the issue and change its Status to Closed. But the Resolution is still marked Assigned, so I change it to Complete.
Is this two-step process the canonical way of marking a bug as fixed? I just want to make sure I'm doing it right; the documentation doesn't say much about closing issues.
Trevor Harmon
· 1 |
|
Sunday, August 22, 2010, 10:17:56 PM |
0
|
Actually, maybe it's a 3-step process! I forgot about the "Percent Complete" setting. I need to set that to 100% when closing a bug, right? What exactly is the effect of skipping that step? |
||||
|
0
|
Yes, as you might close the issue but the resolution will be "won't fix" for example. |
||||
|
0
|
[quote user="MarkWing"]Percent complete is just an indicator to show the progress made on the issue.[/quote] Yes, I know what it is, but I'm still not clear on how it's used. Does it show up on any of the reports or project summaries, or does it appear only when viewing a particular issue? Even if it's the latter, it would be nice if Gemini could automatically set Percent Complete to 100% when marking an issue as Complete. Is that possible? |
||||
|
0
|
It can appear in the issue grtid(s) if you customize the columns. |
||||
|
0
|
Okay, it sounds like Percent Complete isn't very useful to me then. How do I hide it completely? I thought I could do so by editing the Field Visibility Schemes, but "Percent Complete" does not appear there as an option. |
||||
|
0
|
This comes under the estimated effort field. |
||||
|
0
|
You know, I'd swear that earlier versions calculated the Percent Complete automatically using the time estimate and logged time. This, to me, makes sense, but I don't get manually setting it - how else other than time would a user be able to calculate it? Handling it manually also means it's yet another step in a too-long series to keep tasks up-to-date. |
||||
|
0
|
We have gone against that as if you estimated 2 hours and worked 1, it does not mean that the issue is 50% complete. This gives you better control over the progress of an issue / version. |
||||
|
0
|
I think that's only true if the user doesn't update the estimated time value, which, IMHO, they should be doing whenever they know their time estimate is too high or too low. With the assumption that the time estimate is updated, and given the information tracked in Gemini, what better measure is there for portion completed than to compare that value against the time committed? I suppose for those cases where the time is either not being used, or the completion percentage is being tracked using data beyond the scope of the individual task, it makes sense to let the user defeat the auto-update. Perhaps this could be accomplished by having an option in the time recording UI to not update the completion percentage (with its default state controlled at the project level)? This would be very helpful where it's applicable, but I suspect that in most cases, an auto-updating value is what makes most sense. |
||||
|
0
|
Make sense (project level), feel free to add it to our list: http://gemini.countersoft.com/Default.aspx?GEM |
||||
|