Try out the new Bitbucket Cloud pull request experience today!

[Jon]

I ended up hacking together a chrome extension we use that adds a "resolved" button next to each comment thread so the entire thread can be marked as resolved (and given a transparency of 0.5) :)

It broke recently, but it was extremely useful.  Some of our larger PRs would have dozens of comment threads and it would be pretty much impossible to visually pick out which items had yet to be addressed without that.  Fortunately I haven't had such a PR since my script broke.

If you could filter on which comments were resolved that would be fantastic!

[sgautrin]

What's the status regarding the implementation of tasks support? I know it's been listed as not implemented yet and coming soon™, but really realised now that I'm back at doing pull request review on bitbucket that this is severly missing (although with the merge checks being gated behind the additional paywall of “premium”, I guess it's less useful).

Although it could be the occasion to remove the clunky task concept all together in favor of [resolvable pull request comments](https://bitbucket.org/site/master/issues/6535/resolveable-pull-request-comments) and finally catch up slightly to competitors on that front.

[Alastair Wilkes]

Hi @Tjerk W,

I see. Thanks for the extra info. We are working on improving that.

Alastair

[Tjerk W]

@Alastair Wilkes  I already did that initially.  This was the response, which i think is not good enough for Bitbucket.

The whole reason we have the exlcuding of files is to make sure it can load big Pull Requests:

We really apologize for the long wait.

Just to give you an update.

As per our developers, the exclude files feature was filtered out after computing the entire diff of your pull requests.
Apparently, the diff is too big to compute in your specific pull request.

Currently, in your pull request, the diff has 12,000 lines of code changes, I'm afraid this is too many for us to handle at the moment.

Our developers are currently looking for ways to work around this issue on our end.

Workaround

As a workaround on your end, we believe you can do the following:

1. Review the diff locally then merge the pull request in the UI or over API.
2. Decline the pull request, chunk it into smaller ones then view the merge.

Thanks, Tjerk.
Apologies for the inconveniences this is causing you and your team.

[Alastair Wilkes]

Hi Georgios,

Thanks for your question. This refresh primarily concerns updating the user experience of the pull request page itself, so those features are not considered part of this project.

That said, both are important improvements in our broader project backlog.

Thanks,

Alastair

[Alastair Wilkes]

Hi Francois,

We're planning to add support for external integrations in an upcoming update, but I don't have an ETA right now. Yes, it'll use the same locations as the classic UI for consistency.

I'd love to discuss what you're building! Shoot me an email if you're interested in chatting about it (awilkes at atlassian dot com).

Alastair

[Alastair Wilkes]

Thanks both for the additional feedback. We're continuing to iterate on the file tree experience, so this feedback is helpful.

[Alastair Wilkes]

FYI: this UX improvement has shipped along with some other improvements to expand/collapse behavior. Thanks!

[Alastair Wilkes]

Hi Jon -- thanks for the feedback. We're continuing to iterate on the activity feed and plan to add that improvement in a future update.

[Alastair Wilkes]

FYI: this feature shipped a while back, but I neglected to update this thread. Thanks!

[Alastair Wilkes]

Quick update: code context on outdated comments was added a little while ago. Thanks!

[Jiri Hana]

Re truncated files - you can make the side bar wider by pulling it with a mouse. Unfortunately bitbucket does not remember the settings.

Re vertical padding - that's a pain for me too. Would be nice to see configurable vertical padding as in gmail or Google drive.

[Deleted user]

Just want to echo this comment, after several attempts of real world use I had to disable the new experience because I was really lost without the old full width overview. I scan a lot of pull requests on which I might only be a secondary reviewer just check what areas have been touched.

The side tree is just visual noise at the side for even a moderate size pull request (the one I'm looking at now is 58 files):

• most of my filenames are truncated
  • the use of a tree in a narrow sidebar exacerbates this issue, but they'd still be truncated even if there weren't all indented half off the screen.
• the indenting is too hard to parse
• it's way too long vertically, there's too much vertical padding

None of those problems apply to the old flat file list. 

Happy to provide some side by side screenshots.

[Georgios Petrou]

How about https://bitbucket.org/site/master/issues/5814/repository-refs-for-pull-requests and https://bitbucket.org/site/master/issues/11976/labels-for-pull-requests ? Aren't these part of the "experience"?

[Tjerk W]

Same issue here, excluding files didnt work.

[Jon]

On the old PR experience, a querystring flag of w=1 would ignore whitespace.  I see the menu item to ignore or show whitespace, but it looks like it's not picking up on that flag.  Could it be made to?  Even better would be if a cookie could remember the setting across page refreshes so the user doesn't have to jump through that hoop first thing every time the page loads.

[Jon]

On one PR I have a binary file that a team member commented on.  In the new PR experience I am unable to see the comment.  It shows a word bubble icon next to the filename in the files card on the right, but when I expand the binary file it just shows a message saying the file can't be displayed, but no comment.

[Alastair Wilkes]

Hi Jeremie,

Thanks for trying out the new UI and for letting us know your feedback!

Quick question: what do you mean by "loads the unloaded files and teleports me"?

We've hearing a lot of requests for file-level reviews, and it's something we're considering (along with other workflow improvements) for the future once the new UI is generally available.

Thanks!

Alastair
Bitbucket PM

[Alastair Wilkes]

Hi Srirang,

Thanks for outlining your workflow! It helps us understand how we can improve.

Does your team use pull request tasks? Tasks let reviewers call out specific changes they expect PR authors to make, which alleviates the need to go through every single comment in the activity feed and the need to reply to comments with "addressed." I recognize the irony of suggesting a feature that isn't available the new UI yet, but I believe they'd help your workflow.

Aside from that, you're right -- the workflow needs to be improved with changes like you've suggested (review sessions to signal review completion and reduce notifications, and iterative review to let you view and comment on new changes since you last reviewed). Once the new UI is generally available, we plan to focus in this area.

Thanks again!

Alastair
Bitbucket PM

[Alastair Wilkes]

Thanks Jesse -- we'll check it out.

[Alastair Wilkes]

Hi Joao,

Thanks for your question. The definition of "most" features is going to depend on the team using them, because different teams use different features :) From our perspective, while we've added back most of the major features, we still have a few major ones left, notably

• Word diff
• Likes
• Tasks
• Merge checklist

We plan to implement them in roughly that order, but we can't share an ETA right now. Are there particular features that your team is interested in?

Thanks for trying out the new experience,

Alastair
Bitbucket PM

[Jesse]

I have also seen pull requests where the new view shows a different set of changes from the old view—in one case, wildly different (7 files changed in the new view, vs. 77 files in the old view).

I'm not sure how widespread the problem is, but I have found more than one pull request with this behavior.

I will file a ticket with support for investigation.

[Jeremie Rahm]

Hey,

This new PR tool is really fantastic, already so much better than the former one, great job!

I got one small problem, though: with a very large PR (600 files), if I scroll up from the bottom of the PR, it loads the unloaded files and teleports me which can get frustrating. But it's understandable, 600 files is a lot haha

Also, one feature is missing: a "Reviewed" button per file. Once the user clicks on it, the file is collapsed and stays collapsed by default, and it becomes Not Reviewed again if the file changes in a commit after. That helps to unclutter the PR while reviewing a big piece of code, this feature is in Helix Swarm (perforce)

Are you planning on adding that feature, that's the only one thing our team really misses with your tool

Again, fantastic work so far! Thanks, and looking forward to see what's coming next

[brahmana]

@Marco Bradley  Can you please describe your workflow? (Purely for my knowledge).

I described mine here

Just trying to understand if we can do things better.

[brahmana]

@Alastair WilkesBeen using this new PR UI ever since it came out. Liking it so far and definitely waiting for all those missing features you have already listed.

I have already given a bunch of feedback using the "Feedback" widget and also on twitter. I was then asked to post stuff here for large feedback. Not sure if all these would fall under the purview of the new PR UI, but here it is anyways.

So here is a very long comment. Brace yourself for impact.. :-)

My Workflow

I just wanted to put forth my workflow and wanted to see if I am doing it right or if I can get more efficiency out of the system.

1. On getting a new PR for review, start reviewing and commenting
2. We have a Slack integration which will post each comment to a repo-specific channel (Sub-optimal but better than individual emails)
3. On large PRs I tend to pause after some time and come back to it later. Currently I use the collapse feature in the new UI to mark which files are done.
   1. Initially all files are open. As and when I finish reviewing a file, I collapse it.
   2. The next time I come back to the same PR, I start from the first open file.
   3. It's great that the collapse status is remembered by the system across reloads. Thank you for that.. :-)
4. Once I am done with the PR, I add a comment saying "Review complete" and @ tag the developer.
   1. @ tag helps with Slack notifications.
5. The developer addresses the comments (or asks for clarifications) and updates the PR
6. As and when the developer addresses a comment (or may be after updating the PR), the developer replies to each comment with the text "Addressed"
   1. This is just a safety check to ensure that all comments are addressed. An acknowledgement system.
7. The slack integration notifies me that a PR has been updated.
   1. I  might also get a nudge (on Slack or in real) from the developer. :-)
8. When I start reviewing the updated PR, "Activity Tab" (of the old UI) is my starting point.
   1. I find the last commit made before I started my previous commenting session and check that all comments after that have been addressed satisfactorily. If not, add more comments / follow up comments (in the new UI)
   2. Currently I have the activity tab from the old UI in one tab and the PR diff of new UI in another tab for this.
   3. I then view the diffs for all new commits, i.e. commits added after my last commenting session - to make sure that I am not missing changes not related to my previous comments.
   4. For the previous step also, I use two tabs. One for the commit and one for the PR. I do not comment on commits because they do not appear in the PR.
9. The above process might repeat for multiple iterations till the PR is good to be merged. I then approve it and merge it.

Deficiencies or my wish list :

1. Activity Tab - There has been a large discussion in this comment. I just wanted to do a +1 on the importance of the activity tab and reiterate that the current one in the sidebar is not actually useful. It does not have the full activity. Very common for me to breach the activity count limit on most PRs because of the number of comments I end up adding. In general I would like to see what all has changed since my last commenting session.

2. Review Session - Notification per comment is noisy. Having to write a comment saying "Review Complete" is also somewhat rudimentary. If there can be something like a "Review Session" which I start, add comments, may be delete or edit those too and finally end it, then at the end of the session there is one single notification saying "PR #123 reviewed. 12 comments added" - that would really help.

3. File Review Status - Using the collapse status as a flag to know which file is reviewed and which is not works. But "within a session" if I can have such a file explicitly it would allow me to use the collapse feature for what it was designed - To get a concise view of the PR and navigate easily.

4. Comments as Tasks with status - The "Addressed" reply by the developer to reviewer's comments are again a workaround and rudimentary. If we have an option to mark a comment as "Addressed" and then an option for the reviewer to un-mark it (or reopen it) possibly with a comment or mark it resolved - that would be great. If there is another solution or product in the ecosystem for this, please suggest.

5. Tale of two tabs - For the two use cases above where I mention I use two tabs, if I can do the same (or achieve the same result) without switching tabs, that would be great. I do not have any ideas as to how that can be done though.. !!

If these deficiencies can be met with a change in workflow or the workflow can be changed for the better in general - I am more than happy to hear.