Issue #11976 open
Lee Netherton
created an issue

It would be really useful to us to be able to add labels to pull requests, so that we can for example label which PRs should be accepted before a particular release (e.g. 3.2.1).

They would also be useful for seeing at a glance the status of the PR (for example PassedQA).

Finally they could be used to give a clue as to where a branch should be merged into (for example hotfix - some of our devs have been known to create PRs that are directed at the default branch, rather than selecting the correct hoxfix branch!) (this has been resolved in the PR view)

Comments (94)

  1. Adam Lacoste

    I'd love to have this feature working in BitBucket. It's the only feature that GitHub has that I miss using BitBucket. My team uses a develop branch to represent the next scheduled release, but often work will start on the release after that before the current one is complete. When these release-after-next tickets start coming in as pull requests, it's currently hard to distinguish them from PRs that should be merged right now. A way to label these PRs -- or even an explicit release tagging system along the lines of GitHub's milestones -- would be much appreciated.

  2. Corrie Allan

    I also agree this would be very useful. We just moved from github to bitbucket and it is the main thing I miss also. We need it mostly to distinguish which PR's are ready for review and which are ready for deployment etc. However the ability to create our own labels, in case we need others in the future, would also be welcome.

  3. Fabien Kruba

    Previous company, we used labels " waiting for review " , " work needed" , " ok for me" on github for statuses of a Pull Requests instead of just 'Approved and Declined' to allow a developper to amend his changes before approving. This allowing us to work iteratively on the review process ( and limit a review fatigue of reviewing many times the same humonguous PR )

    I personally think it you be an improvement for many people to allow labelling/tagging PRs in their day-to-day tasks ..

    For instance, as a dev lead on many different projets I have hard time checking every pr in every projet I supervise to check if a PR needs to be reviewed ( Declines are a bit too definitive .. )

  4. Hugo Campos

    This is indeed an essential feature that should be of extremely high priority for you guys. After the slow speed (Bitbucket always feels sluggish), this is the thing that leaves bitbucket behind the alternatives.

  5. Daniel Fredriksen

    I find this a very useful feature on GitHub as one can visually see the difference between a Work in Progress PR (useful for gatekeepers to conduct reviews of PR's before they are ready for prime time) and regular ready-to-merge PR's.

  6. Chris Werding

    +1 Nothing to add that hasn't been said before on this topic. Not having this feature actually brings us to reconsider other solutions that we previously turned down. Being very satisfied with the service that Bitbucket is providing us, we would be very sad to leave. Thank you for bringing this feature to life soon!

  7. Kuba Krzempek

    I can't believe it's sitting on the plate for two years already. Labels indicating where in the process PR is quite an essential thing, so one doesn't have to open each PR and look whether there is something new, whether the comments were resolved since the last time, whether the PR is in progress yet. Sure, you can substitute that by juggling cards in jira/trello.

    BitBucket is great, and labels could only make it better! :)

  8. Adam Elsodaney

    We finally decided to move all our organisations private projects to Github for which we had 11 members - of course labels wasn’t a core reason for moving, but it was definitely a factor.

    Although Github doesn’t have, for example, the Pipelines, first-class JIRA integration, or the more useful commits tree than Github’s “Network” tab, there are solutions out there that fill these voids.

    However with the labels, there’s no plugin or anything.

  9. ndudenhoefferN

    We have recently implemented some connectors with Microsoft Flow to link all Pull Requests to Trello cards, and automatically include comments, create and close cards, etc.

  10. Andy Kriger

    This is one of the most requested PR features - can we get an update as to whether this will ever happen? It's also a fundamental part of why Github PRs are manageable for a company with lots of developers and lots of PRs.

  11. Gábor Farkas
    1. For all those who comment "+1" please notice that the vote button at the top right is what you are looking for: all watchers are notified about your comments, but neither of them cares about your comments, but we would like to get noitified about actual progress. Thank you
    2. Otherwise, didn't someone create a chrome extension that adds this feature to bb? :)
  12. Josh Black

    This is a major issue with BitBucket for us right now and is seriously making us consider GitLab. It sounds like a very minor thing but it makes managing PRs so much more difficult when you don't have labels like 'Requires Rework' or 'Awaiting Review'.

    I'm honestly kind of amazed that people have been waiting for this feature for just over three years with not much visible progress. I totally understand there are other priorities on the platform, (we're devs, we know how business pressures can be) but this is a standard feature almost every other code-hosting platform has had for a while now

  13. Adrien Agripnidis

    Hello, This is an important feature missing from bitbucket cloud. We are thinking about moving on to GitLab, and I don't think we're the only ones.

    Can anyone give us a feedback on this request that has been open for 3 years?

    Thank you in advance


  14. Alastair Wilkes staff

    Hi everyone! Thanks for your feedback and votes on this issue. We are currently focused on improving the new PR experience (currently in beta). Labels for PRs (and other features that express state (like issue #13021) are high on the priority list in the backlog, but right now we don't have a timeline to share for delivery of this feature.

  15. Log in to comment