Data Study Groups (DSGs)#

Periodically the Turing runs Data Study Groups, which normally require SREs attached to our production Safe Haven. This will involve around three to four SREs needing to be deployed, used and then shut down within a relatively short time frame. TRESA need to coordinate with the DSG team (part of the Applied Skills Team), on dates for DSGs and the number of SREs required. The DSG team will work closely with the DSG project PIs and together will act as the project team, meaning the project lifecycle can be followed in the same way as other projects.

Planning for upcoming DSGs#

  • Consult the DSG team or check the Turing website on dates

  • Coordinate to ensure that TRESA members are available to cover tech support during the DSG (we recommend 1.5FTE for the project week)

DSG setup#

  • You should set up a Sandbox SRE SRE (i.e. one with no project data) and add all the DSG participants to this at least a week in advance of the DSG start date (the DSG team may have an official setup week)

    • Due to the large volume of users to be added in one go, you’ll need to follow Add users in bulk.

  • Set up the DSG SREs at least 2 weeks before the DSG, so data ingress can be done the week before.

  • When you get to the “Build TRE” task, consult the Data Study Group (DSG) TRE setup guide which describes typical TRE setups (but deviate from this if needed).

  • Plan to tear down the DSG SREs the week after the DSG (but the storage accounts can be left up until egress is complete).

During the DSG#

The DSG team should provide access to a slack channel called tech-help where TRESA can respond to queries regarding the TRE from DSG participants and facilitators.

  • Many of the initial requests are likely to relate to incorrect login details. Refer them to the Data Safe Haven user guide.

  • All DSG participants should have completed the DSH Moodle course before the DSG starts, so they should be familiar with the basics of the TRE.

Encourage users to post issues they encounter with the TRE on Slack

  • Provide a solution or request more information in the same thread if appropriate

  • If the researchers are asking for general help with programming in Python or other queries not specific to the TRE, it’s ok to give general pointers, but it is not the responsibility of TRESA tech support to help with this

A guidance document for DSG participants on how to ask for help in the tech-help channel can be found here. This should be shared with the DSG team before the DSG starts so that they can share it with the participants.

Process for handling tech support for TRESA operators#

  1. Prepare a schedule for monitoring the Slack tech-help channel. There should be two people monitoring the channel at the same time. We have found that half-day shifts work well.

  2. Once a problem is reported in the Slack channel by a participant, a person monitoring the channel should emoji it with the ⚙️ emoji to let others know that this is being looked into.

  3. Look at the existing troubleshooting docs to see if a solution is already available in our documentation.

  4. If not, head over to the GitHub Project Board specifically designed for this purpose.

  5. Search the project board to see if a similar problem has already been logged in the past. If it has, the issue should suggest a solution that might be helpful.

  6. If the problem has not been logged previously, go to the relevant column on the project board (e.g. To do) and create a new issue in the trusted-research repo using the DSG Tech Support Issue template.

  7. Follow the instructions in the template to fill in the required sections.

  8. Avoid duplicating issues: before making a new issue, use the project board’s search bar to see if that problem has already been logged in the past. If it has, copy the new Slack message link into the existing issue.

  9. The DSG Slack Support label will be automatically added to the issue, but you should add the current date to the Date field so that it can be easily filtered.

  10. The issue is assigned to a TRESA member for it to be handled. The assignment can be decided ad-hoc, but typically the person who created the issue will assign it to themselves.

  11. Copy the issue link and paste it back into the Slack message thread where the problem was reported. This is for TRESA records as DSG participants will not have access to the GitHub project board.

  12. Only move an issue to the Done column once you have checked with the DSG participant that their problem has been solved. Once the problem has been solved, add the ✅ emoji to the Slack message to let others know that the problem has been resolved.

  13. If you encounter a problem that you can’t solve, and other problems are piling up in the Slack channel, leave it in the In progress column and tag it with the won't fix label. Ask for help by mentioning other people (e.g. @alan-turing-institute/data-safe-haven-code-contributors to get the DSH team involved) on a comment in the issue.

  14. The solution to the problem should be logged in the issue description so that it can be referred to in the future. If the problem is a common one, consider adding it to the TRESA docs or discussing it with the DSH development team to see if it can be fixed in the codebase.

Process for unexpected urgent “black swan” problems that derail the DSG progress#

  • Initiate an urgent meeting with a representative from TRESA, a representative from DSH development team and a representative from the DSG team (e.g. the project manager) to discuss the problem and possible solutions/timelines

  • If this is a problem that might reoccur in future, ensure the solution is documented