Agree with all of the above, it is nonsense for the app to mandate how a business chooses to establish its CICD workflows. Add this capability already.

We are a team of 2 developers where I'm the lead and the other is new in the company and quite junior. I want to approve his PRs before letting him merge, but I don't see the point of letting him approving mines, as he doesn't even know the code I'm working on.

Seems legit case to me and frankly I don't even understand all the fuss about it as it could/should be just a simple option.

It's so strange that Atlassian has such a great need for defining what pull requests should be for others and how other people should define their workflow.

Not being able to approve your own pull request is a huge limitation for us. Making vacation time a time where nothing can be done.

Yes we can solve our problems in other ways, but allowing a developer to approve their own pullrequest would be such a small thing. A lot easier then changing all of process - or convincing the company to drop Bitbucket all together...

In particular what is the nature of the work involved (is it lots of contributions from people, perhaps?)

A team of 3, requiring 1 approval for merge. Vacation time.... Dev 1 implemented something, pushed, but did not create a pull request. Then leaves for vacation. Dev 2 picks up the branch. Reviews it. Test it. Finds it ok, but finds and fixes a small bug. Dev 2 discuss this with Dev 3 and then leaves on vacation.  Dev 3 is now alone at work, but has written words from both Dev 1 and Dev 2 that the branch is mergable. But he can't. Cause non of the two others ever created a pull request for it. And If Dev 3 creates it, he can't approve it.

This is a scenario that repeats it self with small variations throughout the summer. Time after time. And it's just stupid that is is this way. Just because someone else decides that this scenario isn't 'for real'.

I'm just blocked because of this. Please fix it, it's a bug.

This feature would be very helpful to us as well. In our case the issue is that if two developers are working in the same branch, they need to review the changes of the other one for the PR to be approved.

The workaround being to have a third user create the PR is strange and borders on being wrong because that third person might have no stake whatsoever in that branch but is suddenly now the reponsible one for it? That's just ... weird.

In my opinion all this could be easily avoided so that the PR creator can be part of the review team, but cannot be the only one. This way, you can avoid people approving their own work while still allowing these edge case workflows.

In particular what is the nature of the work involved (is it lots of contributions from people, perhaps?)

We periodically pull from a development branch to a stable branch. (not necessarily the master branch) We don't require reviews of the development branch, but we do require reviews for the stable branch. In other words, the stable branch is a delayed version (with no changes) of the development branch, that has been reviewed by the team. I am the originator of the pull request, but the changesets can be by any number of authors: maybe me, maybe someone else, maybe any number of combinations. It doesn't matter. I am merely the facilitator who sets up the PR. So I am included in the review members. In Stash, what I have to do is put up a fake comment saying "I reviewed this", because I can't be part of the PR review team.

I am merely making this comment here, because I believe the assumption that a PR originator should be excluded from the set of reviewers, is wrong, and Stash can and should be improved. However, in my team's case I don't think we will be using an Atlassian project for future code reviews. We tried using Stash for reviews, we evaluated a trial of Crucible, and frankly both programs had shortcomings that got in our way.

jason.sachs, could you tell me more about these times where a PR creator is a facilitator? It sounds like a different kind of code review to the kind that lightweight pull requests are intended for. In particular what is the nature of the work involved (is it lots of contributions from people, perhaps?), why is it being reviewed, what is the merge that follows and how does this fit into your development process?

Boo. Please reopen. It's not just for supporting this use case:

I would like to configure this repo to require 3 approvals (2 independent and myself), to enforce that there are always at least 2 other people looking at the code, other than the originator)

There are times when the pull request creator is just a facilitator. In my team's case, we have periodic code reviews, and we want everyone in the team to review the code changes. The behavior of Stash is to disallow the creator as a reviewer, with the implicit assumption that a pull request has already been reviewed by the creator. This is NOT true in general.

If you want to make that the default behavior, that's fine, but let us override it and allow the creator to be a reviewer as well.

Hi Mike,

Allowing a PR creator to approve would address this unusual edge-case (which arguably can be addressed by good social conventions), but it would also open up the possibility for confusion in other circumstances and introduce unintended interactions with merge check rules. As such, this isn't something we are likely to add to Stash, I'm afraid.