Issue #12679 wontfix

Customer request: To see a checkmark for PR in the author's avatar under "Summary" similar to how it appears in the PR overview.

Gideon Koh
staff created an issue

It'll be great and helpful if we can have the checkmark appears in the author's avatar here:

pullrequest1.png

Similar to how it is already done here: pullrequest2.png

Official response

  • Alastair Wilkes staff

    Hi everyone, thanks for the feedback. We currently do not plan to implement this, but we'd love some more details as to what function self-approval serves in your individual PR workflows. Feel free to comment directly on this ticket or send me a message - thanks!

Comments (12)

  1. Alastair Wilkes staff

    Hi everyone, thanks for the feedback. We currently do not plan to implement this, but we'd love some more details as to what function self-approval serves in your individual PR workflows. Feel free to comment directly on this ticket or send me a message - thanks!

  2. Martin Garnier

    In my case, the person who creates the PR is not the person who made the code. In our process, every bit of code must be tested by another developer before code reviewing. When he's done testing, he creates the PR. And he approves the code.

    So when we're about to merge something and we're wondering which PR is ready to go, we have to open every PR to see if the creator approved it or not. Very annoying, I assure you :)

  3. Anshul Agrawal

    For us, raising a PR doesn't mean that developer is putting it up for a public review. We use PRs for showing off work in progress. That may still contain code which developer himself doesn't intend to ship and there is no point commenting on such a PR unless explicitly asked by developer.

    A developer approving his PR is considered a sign that the developer doesn't have anything to add and reviewers can go wild now :)

    Saves lot of efforts for everybody actually. Reviewers don't waste reviewing unfinished code. And, developer doesn't get bogged down by obvious things he was anyways going to work on.

  4. Jake Bishop

    Yep, we use pretty much the same approval system those above. Having to open up each PR to see if the author thinks it's ready to go is pretty annoying.

    @aldango : is the "wont fix" status a permanent decision? seems a bit flippant, especially when it appears a very easy change and it would very much help your users. or is it deceptively complicated to implement?

    Ps: it seems unusual that you feel it is important to show that everyone has approved, except for the author. However, it is deemed important information on the PR detail page. If authors should not approve the PR themselves, then why not prevent it? If it is a useful feature, then please let us see it on the overview :+1:

  5. Alastair Wilkes staff

    Hi Jake - thanks for the feedback. Sorry, I didn't mean for that change to come off as flippant.

    I agree that the "not ready for review" use case has become more common in the PR workflow. We're seeing more teams opening PRs in a not-ready-for-review state.

    However, we don't want you to have to rely on self-approval as a workaround for "ready for review" forever, so instead of adding this, we're looking at options for supporting that workflow more completely and clearly. This feedback is really helpful.

  6. Michael Markey

    Our flow is similar to the ones mentioned above. Assign/Be assigned an issue, open a PR to have a place to track conversation (probably should be done in the issue itself, but it's easier to comment/question directly in the diff). When the author is ready for review, clean up the commit history, and then Approve, which marks the beginning of the actual review stage.

    We have it set up so that it is reported that an author has approved their own PR in various ways through email, hipchat, etc... but in a typical day it is difficult to keep up with the constant flow of emails and messages. So the go to is to open the Pull Requests page, where it would be convenient to be able to see if the author is ready for review, instead of having to open the PR itself.

    However, we don't want you to have to rely on self-approval as a workaround for "ready for review" forever, so instead of adding this, we're looking at options for supporting that workflow more completely and clearly. This feedback is really helpful.

    Sounds great. Looking forward to it.

  7. Log in to comment