undees
Occasional Visitor
Joined 10 years ago
User Profile
User Widgets
Contributions
Closed-loop reviews
One of our teams would like to perform reviews where Collaborator prevents all the following scenarios: * Review is held up indefinitely because a reviewer never answers * Review is held up indefinitely because the wrong reviewer was invited * Author gets impatient with a held-up review and finishes it early (before it's had enough review) The first two problems are caused by too strict of a workflow, and the third is caused by not having a strict enough workflow. Ideally, we'd like the review to work like this: 1. Author sets two deadlines: one for accepting (i.e., agreeing to begin) a review, and one for completing it. 2. Author sends invitations. At this point, the review is locked; the author cannot make any changes. 3. If any reviewer refuses to begin the review, or if the acceptance deadline passes without everyone accepting, the review is unlocked and the author may go back to step 1 to choose new reviewers / deadlines. 4. If all reviewers agree to begin the review, the review starts. The review is still locked (author cannot make changes). 5. Reviewers read the code, make comments, etc. 6. When all reviewers have marked the review as finished, or when the completion deadline passes, the review is kicked back over to the author in either the Finished state or the Preparation state (depending on whether or not everyone marked it as Finished). With this workflow, no review would ever be held up because a reviewer ignored a review invitation, or accepted an invitation but dragged their heels reviewing it. Conversely, no author would be able to push a review through before everyone has had a chance to see it. The only way I can think to do this in the current Collaborator version is to use the Moderator role, and have that person perform all the gatekeeping manually (perhaps coupled with turning on review deadlines). That seems like overkill, though, and a lot of manual work. Is there a way for Collaborator to gate these steps in the process automatically?8.6KViews0likes2CommentsAllow reviewers to ignore rebased files that are not part of the review (UCM)
One of my co-workers had a long-running review open, and ended up rebasing his local changes several times (on top of remote changes performed by others in the stream). This caused unrelated changes (the code brought in as part of the rebase) to show up in the review. Reviewers were not sure which changes to comment on. If UCM-based reviews provided an option to filter out code that's part of the rebase, and only show changes made by the author, the reviewer experience would be much easier.6.4KViews5likes3Comments