Edgewall Software
Modify

Opened 16 years ago

Closed 15 years ago

Last modified 9 years ago

#301 closed enhancement (duplicate)

Add new status "Review Ready"

Reported by: anonymous Owned by: Jonas Borgström
Priority: normal Milestone:
Component: ticket system Version: 0.6.1
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:

Description (last modified by daniel)

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

Attachments (0)

Change History (15)

comment:1 by cmlenz@…, 16 years ago

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.

comment:2 by daniel, 16 years ago

Milestone: 0.70.8
Priority: normallowest

comment:3 by dana@…, 15 years ago

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.

comment:4 by kdlee@…, 15 years ago

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.

comment:5 by ojilles@…, 15 years ago

Priority: lowestnormal

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

comment:6 by daniel, 15 years ago

Description: modified (diff)
Milestone: 0.80.9

comment:7 by anonymous, 15 years ago

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…

comment:8 by anonymous, 15 years ago

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.

comment:9 by anonymous, 15 years ago

Priority: normalhighest

comment:10 by Christopher Lenz, 15 years ago

Priority: highestnormal

comment:11 by Christopher Lenz, 15 years ago

See also #869.

comment:12 by Christopher Lenz, 15 years ago

Resolution: duplicate
Status: newclosed

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

comment:13 by Christopher Lenz, 15 years ago

Milestone: 0.9

comment:16 by anonymous, 9 years ago

nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn

in reply to:  16 comment:17 by Christian Boos, 9 years ago

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Jonas Borgström to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.