(tresa_lead)=

# TRESA Lead responsibilities

The lead member of TRESA has the responsibility to monitor the service area activities and keep records up to date.

As the lead, ensure you have completed all the steps in the {ref}`tresa_onboarding`. You will then be able handle the following respsonsibilities:

## Monitor the TRESA email inbox

If you have completed the {ref}`tresa_onboarding`, you should be able to access `trustedresearch@turing.ac.uk` and respond to emails from project teams and others. Most requests will relate to one of the {ref}`tasks`, but there could be requests from new projects wishing to set up a TRE.

This inbox will receive automated emails for Azure Subscriptions set up for TREs from the Research Computing Platforms (RCP) team, for example when a subscription is running low on credits. See {ref}`track_budget`.

## Keep the project boards updated

The SRE project board is accessible at `https://github.com/orgs/alan-turing-institute/projects/25/views/1?layout=board` and contains issues that have been created via the TRE deployment issue template (see the `.github` folder in the trusted research repo), with one issue per SRE (and SHM).

For each new project, an issue will be opened at the {ref}`create_tre_github_issue` step of the project lifecycle. As the TRESA lead, you should ensure that at least one member of TRESA is assigned to (and therefore responsible for) each of these issues and tracks the progress through the project lifecycle by checking the boxes that relate to the {ref}`tasks` as they go.

The management project board is accessible at `https://github.com/orgs/alan-turing-institute/projects/52/views/1?layout=board` and is a place for general issues for the service area.

## TRESA fortnightly meetings

1. TRESA lead should update TRESA on any changes to the project boards (see above) and assign issues as appropriate.
2. TRESA lead should discuss any issues the team is having with deployments
3. For any new upcoming projects, it should be discussed who will take responsibility for handling the TRESA {ref}`tasks` for that TRE. Assign this person to the GitHub issue once it has been made.
4. Coordinate Data Study Groups when they are upcoming
    - Consult the DSG team or check the [Turing website](https://www.turing.ac.uk/search/node?keys=data+study+groups) on dates
    - Coordinate annual leave of the TRESA team and who is available to cover the DSG - see {ref}`dsg`
5. In every other meeting (every 4 weeks) assign someone from TRESA to carry out the {ref}`tresa_regular_tasks` in their own time
    - Encourage the person who did this last to report any changes that were made as a result of these checks

## Coordinate with project teams

Make sure the project teams for each active SRE are aware of this documentation and link them to pages as appropriate. It's the job of TRESA to track the project lifecycle, but many of the individual tasks will need to be carried out by the {ref}`role_project_team`. Where time is critical for any given task, TRESA should send email reminders to the project team representative(s).

## Prepare for Data Study Groups (DSGs)

See the {ref}`dedicated DSG page <dsg>` for more details.

## Make sure training is up to date

Ensure that everyone in the centralised record of all users has up-to-date training. This record can be found in the spreadsheet on the TRESA Sharepoint at `Documents` -> `information_governance` -> `all_users_and_projects`. Note that "all users" means all regular research users, members of the TRESA team, IT and DSH developers. Depending on their role, users will need to have completed different training courses (see {ref}`tresa_onboarding` and {ref}`monitor_user_access_requirements`). The training certificates of all TRESA members, DSH developers and members of the IT team who have admin access to relevant Azure resources should be saved in `Documents` -> `information_governance` -> `TRESA certificates` on the TRESA Sharepoint.