Add new status "Review Ready"

[anonymous]

So, defect can be moved to the review stage. It can be per-to-per review, or
group review. So, it is kind of logical to have dedicated defect state.
It also would be good idea to somehow automatically move to review state from
in SVN hook scripts. It will save time for developer. i.e. During a commit
developer just add something like this to the commit description:

Status: Review-Ready
...

Dmitry

[cmlenz@…]

Bugzilla and Scarab do this sort of thing with an additional "verified" status. I.e. when the developer thinks the issue is fixed, she sets the status to "resolved". Then the test team can check all "resolved" issues and set the ticket to "verified" when they think the fix is good.

[dana@…]

I would like to see this added as well. This would involve a workflow change (which would bring trac more in line with standard Software Lifecycle processes).

new->assigned->resolved (with a resolution)->verified->closed

reopening a ticket would put the ticket at the assigned stage.
also, a QA person needs to reject a resolution, so there could be an alternative assigned->(resolved->rejected)*->verified->closed->assigned->... process.

[kdlee@…]

I also would like to see this added. On the large projects that I have worked on in the past, having a state that is a toll gate for QA to their thing before the ticket is really

closed was a requirement. I would not be able to switch my project to using Trac until this kind of functionality was available.

[ojilles@…]

I'll second the above opinions! Without a 'review ready' or 'tovalidate' status, the issue tracking system is not usefull for me.

[anonymous]

First of all, I definetely "second/third/fourth" the need for that feature. Without it working with QA department would be very difficult. Please note, that it would be also important to have 'QA assigned' field - it would function just like 'Assigned' field for developers: developer would "suggest" a QA person (or leave the field blank) when they mark the bug as 'fixed'. The QA person then has discretion of either 'accepting' this bug, or re-assigning it to another QA person.

I also want to suggest another usefull extension of the bug life-cycle. I have frequently had a problem with developers marking something as 'wontfix' or 'invalid' without proper thought. It would be extremely usefull to have a "manager" role for each component and have this manager "approve" the 'invalid' or 'wontfix' resolution.

Finally, it would be useful to provide some form of 'worksforme' approval. Again, a frequent case I have seen is when QA writes a bug, but the developer misunderstands it and marks as 'worksforme'. It would be very nice to have the bug either go back to the original person who filled it (if that was QA engineer) or to the "manager" (see above) if there is no obvious person to re-assign it to.

The 'invalid'/'wontfix'/'worksforme' is not nearly as critical as the 'fixed'/'verified', since it can be handled through reports, but anytime workflow can be automated and structured, it cuts down on mistakes...

[anonymous]

I also consider adding this feature to be vital.

One note however-- in my opinion (relating to the last comment) 'QA Assigned' is not necessary-- once the developer has resolved the ticket (or 'fix_implemented' in our terminology) they can just reassign the ticket to 'QA'-- however this needs sensible handling of users and groups of users (I will enter another ticket on this matter, unless one already exists).

I think that for the moment I will be asking people to use the keywords field.

[cmlenz]

See also #869.

[cmlenz]

Superseded by #869, which has a patch. Go there for further comments.

[anonymous]

nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

[cboos]

Replying to anonymous:

nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

Ok, great, now stop this. The next step will be a mail from us to your provider (abuse @ wanadoo.fr), citing all the spam p*rn you're trying to feed here.