Status: Resolved Later

[Jake]

At bmo, we've moved away from using the RESOLVED LATER status to using 
the "Future" target milestone. I can see how this isn't a fit in all 
organizations, however. For one, the bug will still count as open if 
it's NEW, REOPENED, or ASSIGNED. This will make the default reports 
pages look like there are lots of bugs when there really may just be a 
lot of stuff that's waiting on some outside influence.

The other reason this may not work as well as a PENDING type status is 
pretty much in my last sentence of the last paragraph. If a developer 
needed more information on how to reproduce a bug, the could set the 
status to PENDING MOREINFO, for example. This would no longer count as 
an open bug, per se, but also wouldn't be a closed one. Something kinda 
in the middle :).

Kevin Benton wrote:

> I’m wondering – does it make more sense to create a pending status 
> with a reason code than to change status to resolved later because the 
> issue (if set to resolved later) in my interpretation, really isn’t 
> resolved, but instead, put on the “back burner.” It seems to me that a 
> resolved status should point to the issue is resolved pending 
> verification, and no more work needs to be done to fix it. Pending as 
> a status, to me, says that work may still need to be done pending some 
> factor. Pending verification doesn’t seem like a good status either 
> because it suggests that the developers still have more work to do 
> after verification is done. If more work has to be done after 
> verification, then verification must be re-done. Anyway, just a few 
> musing/ramblings on that particular process…
>
> Kevin Benton
>
> Perl/Bugzilla Developer
>
> Advanced Micro Devices
>