Skip to content

Review dismissal #36

Description

@zware

It appears that a 'request changes' review blocks merge even if another core-dev approves. I'm not sure whether two approvals would override a 'request changes', but it is possible to dismiss a review; we should decide criteria for dismissing another core-dev's review here and document it in the devguide.

For example, python/cpython#27 was blocked by my outdated review, even though @methane had made the changes I had requested and @ncoghlan had approved the change. Frankly, I had forgotten that I had reviewed that PR, so I would have had no problem with either of the other involved core-devs dismissing my review.

Activity

  1. methane commented on Feb 20, 2017

    @methane
    Member

    I tried "dismiss review" link. python/cpython#75

    When I clicked the link, one line textbox for writing reason to dismiss.
    I wrote "fixed" there.

  2. facundobatista commented on Feb 20, 2017

    @facundobatista
    Member
  3. ncoghlan commented on Feb 23, 2017

    @ncoghlan
    Contributor

    I think in our case, we need to assume that core developers losing track of a change request is going to pretty normal, and establish that in those cases it's socially acceptable for another dev to say "I've checked the requested changes were made" and dismiss the original review. (It's unfortunate that GitHub chose such a negative phrasing for their UI, but it makes sense in a less collaborative corporate context where reviewers don't issue an assumed delegation to their peers).

    I'd say the only time we shouldn't dismiss a review after the requested changes have been made is when the reviewer also assigns the PR to themselves - that's a more active "I'm handling this" claim than just requesting some changes.

  4. facundobatista commented on Feb 26, 2017

    @facundobatista
    Member

    +1

  5. brettcannon commented on Feb 27, 2017

    @brettcannon
    Member

    So do we want to write this down in the devguide? Is there anything specific that needs to happen to keep this issue open for?

  6. dstufft commented on Feb 28, 2017

    @dstufft
    Member

    Documenting it in the dev guide seems like a reasonable thing to do.

  7. zware commented on Feb 28, 2017

    @zware
    MemberAuthor

    If we're in agreement on what our convention should be, this issue should be replaced with an issue for documenting it in the devguide.

  8. brettcannon commented on Apr 10, 2017

    @brettcannon
    Member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions