I do not agree with this defect. If changed, please make it a (global) configuration point defaulting to the current behavior of remaining stuck if going from fail to unstable or unstable to fail.

This is a duplicate of JENKINS-15007.

If you check sticky it would most often mean that you would fix all problems until the build is successful or until you unclaim it.
Closing this as won't fix, adding a global configuration for it without changing the default behavior could be added as a feature request and I will accept an pull request for it.

In our case, when people check sticky it means that they will fix the problem that they caused, usually compilation problems caused by their code.

While it may means many things, an unstable build doesn't mean the same thing as a failed build. It is usually not the same people that fixes the code that is commited for a project than those who configure Jenkins and make sure there are no unstable builds.

Also, if a build is unstable then fails and is claimed, it is not the responsability of the user who broke the build to repair previous issues.

Just my opinion and I see it is not shared, I might do a pull request for a config change if I find the time.

Thanks for your answer.

I agree with Denis on this. The reason I no longer claim failed builds is because I know there are failing tests in them and I don't want all those pinned on me as well. Essentially it makes the feature of claiming builds pointless. (We still use claiming for individual tests, though.)