Why are our pull requests PRs showing STALE?

[josh_hayden]

We started noticing yesterday when looking at our list of pull requests in Bitbucket that some of them have a STALE label next to them and the Created time is in a brown color. What does this mean? In what case does it show the STALE label? Is there the option to disable or change the criteria for something to be marked as STALE? Here's a screenshot:

[Eli Pleaner]

I'm wondering why this isn't a configurable option? Quite bizarre to assume this is wanted by all teams without any way to turn it off.

From the docs: "This is on by default and is not configurable."

[Patrik S]

Hello all,

The stale flag was a recently released change and means that this specific Pull Request has been open longer than usual, or hasn’t been updated recently. This is done by comparing each pull request’s age & latest interaction time to those of typical PRs in the same repository.

This is a small UI update to help Teams review Pull Requests that have been sitting for too long, as PRs can get lost (and therefore neglected) amidst all the other work that is going on.

You can find more details on how the stale pull requests are calculated in the following documentation : 

• Highlighting ‘stale' pull requests

Thank you!

Patrik S S 

[Stefan Pasel]

I think features, which are not thought through should be stuffed into some optional "beta" / "lab" and then survey users if they like it. Rolling out the green banana to public and wait for us to complain is NOT the way to go. 

I see only STALE branches except the most recent one.
We have PRs that have been "updated less than 24h ago", they have been created just 2 days ago. 

Whatever the internal "algorithm" is.. it is neither smart nor understandable.

Develop the idea, make it complete, then release it in production.

[Karen Dolan]

So we have to leave PRs open longer than we usually would to game the algorithm to not show as many stale? It sounds like we're penalized by quick merges.

[Niraj Kumar]

Same concerns as above. While this flag is useful, in the current scenario, it is giving incorrect information. PR raised 5 minutes earlier also got the stale flag.

[brett-structureit]

The tooling does not get to decide what "stale" in the context of the way my team works. 

I'm not pleased with tools that have an opinion that I can't silence.

Why is this not configurable? 

[Tim Hitchins]

You really need to add a tooltip to explain why it's stale. It needs to include the criteria which potentially contribute, and the final decision based on those criteria.

Because I have no idea what the criteria is, it's not a useful metric for the team because it almost certainly doesn't align with our own definition - in fact it's just an annoying distraction,

At minimum, we need to be able to turn this off.

[Jack Johnson]

+1

[wiikend]

I came here to ask exactly this question. 👀

It seems the STALE label is not tied to the commits of the branch itself, as we have a couple of pull requests with very recent commits that are still considered stale. My guess is that it's marked as stale because it's a certain amount of commits behind the destination branch (e.g. master or a main feature branch).

Have you tried merging in the latest version of the destination branch and pushing it to the pull requested branch to see if the STALE label goes away?

[Daniel Mescoloto]

My stale label says:

it's open for 7 days when usually PRs in this repo closes in 2 days

Well, I think it should be based on updated, not created

It's really weird something labeled as Stale and "updated 5min ago"

[Ionut Spalatelu]

+1

[Itso Slavchev]

As I actually care about PRs not going stale and have written a tool to post stale PRs for our team in Slack, I welcome the change. But this should absolutely 100% be configurable at least at org level (if not per repo), as the current default is quite laughable.