Skara has a feature used by some projects to track the need for a CSR as an integration requirement. If a CSR is needed, a PR cannot be integrated until there is an approved CSR corresponding to the issue being fixed with the correct fixVersion.

A Reviewer in the project can indicate that a CSR is needed by using the `/csr needed` pull request command. Additionally, Skara will automatically detect a linked CSR for the issue.

If a CSR is required (via `/csr needed`) or found, but not yet approved, the "csr" label is added, blocking integration until the CSR is approved with a fixVersion that matches the fix version of the repo into which you are integrating.

Once a CSR issue exists, a pointer to the JBS issue for the CSR is added in the PR description.

There is a difference in how Skara tracks the need for a CSR in the case where a Reviewer used the `/csr needed` command vs the case where Skara discovered a CSR on its own.

In the case of using the `csr` command, the need for the CSR is "sticky" meaning that if a matching CSR is later withdrawn or is approved and the fix version later no longer matches, the bot will add the "csr" label and block integration of the PR until there is an approved CSR (or a Reviewer indicates that the CSR is not needed via the `csr unneeded` command).

In the case where Skara discovers an existing CSR issue, the need for the CSR is ephemeral: if the CSR is withdrawn or is later approved for a release where the fix version does not match, the bot will remove the CSR from the PR description and no longer block integration (no "csr" label is added).

This difference is confusing: when a Reviewer looks at a PR and sees an approved CSR they can't tell whether it will be a blocker if the fix versions later change to be mismatching.

I propose that the need for a CSR be "sticky" when an associated CSR is discovered in the same manner as it is when a Reviewer issues a `/csr` command.