cyril4j
Member
Joined 9 years ago
User Profile
User Widgets
Contributions
Re: Create new participant status for send to rework
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.36KViews0likes0CommentsRe: Create new participant status for send to rework
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.36KViews0likes0CommentsAllow customization of review title generated from GitHub Pull Request
In our case the PR# info logged along with our JIRA# in the PR name and Collab Review# is a lot of confusing/noisy numbers and make email notification subjects too long so we'd like to be able to shorten it.4.1KViews0likes1CommentRe: Create new participant status for send to rework
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?37KViews0likes0CommentsRe: Allow reviewers to ignore rebased files that are not part of the review (UCM)
We have the same issue with GitHub. Merge commits pollute the reviews and Rebasing breaks Collaborator. I worked with the dev team to try to exclude merge changes, but it gets tricky when there are conflicts. Not sure how UCM works but for GitHub it'd make more sense to show a diff of the dev branch vs. latest master rather than keeping track of incremental commits on the dev branch. That's what GitHub pull request diff does.6KViews0likes0CommentsCreate new participant status for send to rework
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.38KViews14likes11Comments