Currently, when one creates issues and then sends to rework, the participant shows as "Approved" in the Participants module, which is highly confusing to our team.
Obviously the review did not approve this review as s/he submitted issues and sent to rework. The participant status should be "Waiting" or some new status "Reviewed", but "Approved" doesn't make sense.
I agree this is confusing - it is unintuitive to click "Send to Rework" for users who approve the review even though they have logged trivial defects they trust the author to fix, and it is also not clear to users who click "Send to Rework" that they are actually approving the review. We have a separate set of user documentation to supplement Collaborator's online help & explain our customization, and I had to include a note clarifying that clicking “Send to Rework” actually means approve, and they should actually click “Waiting” if they don’t want to approve the review until they personally verify their defects are fixed.
Is it SmartBear's official position than clicking "Send to Rework" means you approve the review? It would be so counter-intuitive that it is tough to believe. I was assuming it's just a bug in the participant status display?
As far as I can tell, the approve button has been renamed to either send to completed or send to rework based on if there are open logged defects. Would be good to learn more from SmartBear on how it's intended to work and if there are any planned improvements in the workflow.
I like the idea of changing the status to "Reviewed." On the other hand though, If the person indicates that they are waiting until they are "poked," The tool carries their approval forward without them having to re-approve the document that has been updated. If they are fine with the simple defects identified and they don't want to be bothered again, they don't have to go back into the review to show their approval.
No change is suggested here to the workflow rules. It's only a label issue. If one sends a review for rework, it means that at least one issue is opened, therefore that person would have to take another look at the fix to mark the issue as fixed and the review is *not* "Approved" by definition. "Reviewed" would be a fine label as well.
The buttons are in the "Next Steps" section, so they aren't intended to be pressed until you have completed your review of the material - I personally think the original "Approve" and "Waiting" labels were less confusing. When you have finished your review, you either approve the review, or are waiting for something to happen before you can approve it.
There is a clear and important CTA "Send to Rework" in Next Steps which means you completed a review but found issues which needs to be addressed. It is a required step to transition the review from INSPECTION to REWORK phase and notify the author(s). While one is not required to use it, it is an integral part of the workflow.
Sure anyone not using this transition I guess does not experience the issue, but I understand most people do use Send to Rework.
This being said, "Waiting" label would be just fine as well.
The issue again is that a reviewer should not be listed as "Approved" after sending to rework as it's an oxymoron.
When people send review to a rework/completed state in code collab, i receive below message where default selection is till "File Activity Occurs".
My request is to change this default selection to "You are Poked".
Reason is currently people don't select "You are Poked" and once Author uploads a new version Reviwers need to re-approve (many times just click again) which causes unnecessary catch up cycle.
With default being "You are Poked" reviewers can choose to re-approve when they really feel the need.
radey - I also have users who complain that they have to re-approve the review, and I have to remind them that they need to change the default option. The problem is that no matter what option is set by default, there are consequences. The consequence of setting the default option to "You are Poked" would be that reviewers who did want to re-approve could miss the opportunity (because they weren't notified of new activity), and I think that consequence is more severe - I would rather be annoyed having to re-approve than be annoyed that I wasn't notified to re-review before the review was concluded.
It is interesting that the options are being overlooked because they are presented right under the send to completed button! Maybe that section is too "wordy" and people don't want to bother reading it. I wonder if a better solution to "force" the user to select an option before being able to approve - for example, when clicking "Send to Completed", the user is presented with the notification options via a popup window, and only by selecting the option and dismissing that window, the review would be approved by them? Just throwing out ideas.
There are clearly two very different usage workflows here. My group actually uses both at different times.
1) When bugs/defects are logged, reviewers click the wait button so they're notified on one of various conditions. Once all bugs/defects are resolved, they click the Send to Completed.
2) After looking over the code and logging any bugs/defects, reviewers immediately click the Send to Rework or Send to Completed button (name depends on whether there are bugs/defects open at the time). This is clearly the workflow SmartBear intended to be used.
As MrDubya pointed out, explaining why clicking the Send to Rework button when using workflow 2 changes the reviewer's status to "Approved" requires extra explanation and has caused no end of confusion to new users. For this specific feature request, just changing that participant status text to "Reviewed" instead of "Approved" would be sufficient. Any additional changes should be filed as separate feature requests.
