Create Review per Request Hot

by Richard Prescott on September 30, 2015

We want the ability to configure Pulse so that reviews are created for each request, not each changeset.

  • We have a setup that dicates a request is used for a small, reviewable amount of change. Multiple developers could potentially deliver changes against that same request (especially when a review is rejected and sent for re-work).

    There are times when more than one small change can be delivered, each against a separate request, and ideally this would be done in a single delivery. Our setup triggers a Jenkins build per delivery so this means that instead of queing several builds, all are handled in a single go.

    The probglem with the default setup is that reviews are created per changeset, so having multiple requests in a single review in the case described above.

    This is a problem for reviewing as if you wanted to reject just one of the changes, you end up having to reject all the requests back to under work state. Also, those requests might have different reviewers so you end up with all of them having to look at a single review which contains information that isn't relevant.

    Ideas

    Status
  • Please login to view any attachments.

  • 1) Reviews are created per-(Request, User, Stream) tuple. So if two changesets are delivered by the same user to the same stream, they will both end up as part of the same review (as long as nothing causes that Review to be "published" to the "In Review" state).

    2) The reason for the qualification in the first paragraph is that a review is at state "In Review" or later is considered "frozen" - it won't be reused if additional changesets are delivered (only if the Review is in the Draft or Rework states can its content change).

    If you use one Request per delivery, and your "In Review" state in the Request lifecycle is at the frozen phase, then these two rules normally lead to one Review per-(Request, User, Stream) tuple, and allow a Review to have a single "Owner" (the User who made the deliveries against the Request) and single Stream (the Stream where the deliveries were made).

    We could consider allowing the rules mentioned above to be relaxed by administrators - so a Review could be delivered to by more than one User (I guess the first User would be the "Owner"?) OR we could allow Reviews to be delivered to after they are "published" (perhaps we'd automatically move the Review back to Rework, even if the Review had been Approved?). Both of these would mean less occasions where there was more than one Review per Request (basically only when you deliver using multiple requests or using the same request across multiple streams).

    Would these options help?
    David Conneely Commented by David Conneely June 08, 2018
    Top 50 Reviewer  -  

    1) Reviews are created per-(Request, User, Stream) tuple. So if two changesets are delivered by the same user to the same stream, they will both end up as part of the same review (as long as nothing causes that Review to be "published" to the "In Review" state).

    2) The reason for the qualification in the first paragraph is that a review is at state "In Review" or later is considered "frozen" - it won't be reused if additional changesets are delivered (only if the Review is in the Draft or Rework states can its content change).

    If you use one Request per delivery, and your "In Review" state in the Request lifecycle is at the frozen phase, then these two rules normally lead to one Review per-(Request, User, Stream) tuple, and allow a Review to have a single "Owner" (the User who made the deliveries against the Request) and single Stream (the Stream where the deliveries were made).

    We could consider allowing the rules mentioned above to be relaxed by administrators - so a Review could be delivered to by more than one User (I guess the first User would be the "Owner"?) OR we could allow Reviews to be delivered to after they are "published" (perhaps we'd automatically move the Review back to Rework, even if the Review had been Approved?). Both of these would mean less occasions where there was more than one Review per Request (basically only when you deliver using multiple requests or using the same request across multiple streams).

    Would these options help?

     

PrintEmail