Background
When CSR bot was initially introduced, it was added as a separate bot. I believe this choice was made for two reasons. First the general architecture of Skara is to split work into small independent WorkItems when possible. Second, the first implementation only polled PRs and not the IssueTracker, so to discover updates to a CSR issue, it needed to look a lot more often than when the PR was touched.

Since then, the functionality of the CSR bot has been expanded significantly, as has the amount of reporting and tracking that happens in the PR body (which is handled by the CheckWorkItem in the PullRequestBot). There is auto discovery of CSRs, matching of CSRs with the correct fixVersion, and the CSRBot is now polling the IssueTracker properly to trigger on updates to the CSR issue.

Problem
The current state of the CSR bot has become unwieldy. The relationship between the CSRBot WorkItems and the CheckWorkItem is unclear and inefficient and has a lot of overlap. The main responsibility of the CSRBot today is to react to updates to the CSR issue and mark the PR as "csr updated". Then the CheckWorkItem needs to react and properly update the PR body and check state.

Suggested solution
I think we would be better off by eliminating the CSRBot completely and moving most of the functionality into CheckWorkItem. We would need to add a version of the CSRIssueBot into the pr bot module to trigger a variant of the (csr) IssueWorkItem which would in turn trigger CheckWorkItem. Care needs to be taken to handle the handleRuntimeException calls for each of these WorkItems in a good way so retries are attempted correctly.

Possibly further improvements
As followup fixes for this, we should consider moving the JEP bot in the same way. We can also consider adding more general Issue polling to the pr bot, to trigger on things like issue subject change. This change would possibly also make SKARA-1830 solvable.