`codespaces at risk` report: Make report researcher-facing

[mikerkelly]

Why are we doing this?

The report currently goes to #team-rex and devs manually message individual researchers using the message template in the playbook. This works okay for a small volume of users, but doesn't scale so well.

We have some anecdotal evidence that the report is useful to some users (slack thread).

It would be nice to remove the manual element as far as possible to save dev time. Researchers only need dev intervention if they can't follow the instructions, which hasn't happened even once so far after a few weeks of running the process. We hope a bot notifying them in a public channel is just as useful for them.

How will we know when it's done?

• The bot prints a suitable report weekly to either #opensafely or #opensafely-users, or both, with sufficient information for researchers to act and notfying them.
• The Codespaces playbook has been updated to explain how we are now using the report.

What are we doing?

• Decided where the notification should be, in #opensafely, #opensafely-users or both.
  • Ideally just one, investigate which researchers are in which channel and if a sufficiently large proportion of them are in just one.
  • I don't know if the bot can be configured to send DMs instead without developing out that functionality, which seems too much work here for the benefit.
• The bot needs to learn how to map a researcher's GitHub username to their Slack username, so that it can notify them. Probably this lives in workspace/utils.py.
  • The onboarding process for researchers needs to somehow trigger updating that in-code knowledge. Probably this is useful for the bot to have anyway, so this seems okay, probably the onboarding process just needs to notify the tech team, maybe in batches?
• The message in the report to be more tailed to researchers as the audience
  • can include some of the text from the message template in the playbook.
  • should tell users how to act and how to seek help
• The Codespaces playbook to be updated to explain how we are now using the report.

---

Defining delivery tasks guidance

[mikerkelly]

REX's current thinking is this should become an automated process that operates by e-mail, probably it will reuse some code from the existing bot action but move it to Job Server where the e-mail data lives, as it's personal data and so sensitive. Leaving this open for now but it might get closed in favour of a https://github.com/opensafely-core/job-server ticket. See also opensafely-core/job-server#5187