reassigning to support.

This can be addressed by asking the QA contact (via the comments
field) to check the "next independant build" has been verified, while
not changing the status of, the issue.  This will send emails to the
owner, all on the cc list and the QA contact.  This does not alter the
ownership of the item but it may serve the purpose.  Upon testing the
QA engineer can choose to verify the resolution or re-open.  Will this
suffice?

I suggest the previous option mainly becuase we are not doing any
"enhancement/feature" work on IZ now due to the soon-to-be-released
new issue tracking system.

Brian, thanks for the feedback.

I think your suggestion would not really solve the issue, because the
time between the request for verification and the actual verification
may be long enough to produce a lot of wrong statistics - finally, the
status is expected to reflect what needs to be done about an issue,
and if a issue is started, but contains a "fixed in real, QA please
verify" comment in the description, it does not fullfill this criterion.

However, if this brand new issue tracking system is to arrive in this
galaxy anytime this year :), I would be fine with resolving as LATER -
it's not really really really urgent (though I am pretty sure that it
is a one-liner :).

back to support

Frank - I'm not sure what statistics you are referring to when you
mention because of a time lag in verification.  So I cannot really
address that concern.

As to the status of an issue not reflecting its actual condition, IZ
is setup to provide for that.  A status of "resolved" only confirms
the claim that there is a resolution to the issue.  Once in that state
the issue still needs to be set as "verified" by another party,
presumably qa, and yet a third party (if so desired) can be
responsible for another sanity check and "close" the issue.  This
seems to provide for accurate statuses according to the issue's
condition.  No?

Finally, our new Issue Tracking software is already being tested on a
few sites and will be ready for general deployment soon.  So, it is up
to you if would like to resolve with a status of "later".  I don't
have an actual date for you on the new software.  You would have to
talk to the OOo folks (Stefan or Martin) as I think they have been
apprised as to the Collab roadmap.

Bonus footage - If you would like to submit a patch to IZ, feel free.
;)  Also, if you are curious the new issue tracker open-source project
is available at http://scarab.tigris.org/.

> I'm not sure what statistics you are referring to ...
Statistics which count the number of currently RESOLVED, VERIFIED,
STARTED, UNCONFIRMED, aso bugs, on a per-owner basis. This is a valid,
though sometimes overstressed :), approach to get an impression where
we are with a product.

> As to the status of an issue not reflecting its actual condition, IZ
> is setup to provide for that.  A status of "resolved" only confirms
> the claim that there is a resolution to the issue.

Yes, but the ownership is important, too. Provided that I checked in a
fix just a second ago, I can then

* - RESOLVE the issue as FIXED
  - verify myself in the next build/release
  - ask (in the description) the responsible QA engineer to VERIFY
or
* - RESOLVE the issue as FIXED
  - wait until the next build/release, verify myself
  - REOPEN the issue (!this is the step I would like to omit!)
  - assign it to the QA engineer, asking hin/her to VERIFY
or
* - leave the state STARTED
  - wait for the next build/release and verify myself
  - assign the issue to the QA engineer, asking him/her to VERIFY
  - ask the QA engineer to VERIFY
(I understood that this was your original suggestion, but I may be wrong)

In only the second process, the following three states, reflecting
actual reality, exist:
- RESOLVED FIXED, and owned by the developer
- <something>, and owned by the QA engineer
- VERIFIED, and owned by the QA engineer

In the other processes (and in all other processes I can imagine - am
I missing something? :), there are states which to not properly
reflect the real state of the issue and/or the person who is the next
to take action on the issue.

In the second, process, the additional step of REOPENING the issue
- is annoying
- resets the state to NEW, which, speaking strictly, is not correct -
it's still FIXED. Maybe "NEW FIXED" would be appropriate.

Thus, saving this REOPEN step, and allowing to reassign a bug which is
RESOLVED FIXED to the next person who needs to do something about it,
would solve this issue here :).

> So, it is up to you if would like to resolve with a status of
> "later"

No, sorry. Either you (@collab.net) say that it's a valid request,
then please you RESOLVE it - as LATER, if scarab will allow such a
workflow, or as FIXED, if you will implement it in IZ :))).
If you don't think that the RFE is valid, then _you_ please RESOLVE
this as INVALID. It's you decision @collab.net, not mine.

> Bonus footage - If you would like to submit a patch to IZ, feel
> free. ;)

Oh well, this is nothing I am capable of doing - much to less C++, for
my taste :).

> Also, if you are curious the new issue tracker open-source project
> is available at http://scarab.tigris.org/

will have a look, thanks

Thanks for the feedback, Frank.  The capability exists in the new
issue tracker software.  So, closing with a status of later.

seems to be fixed with CEE 3.5.1.