HTS Bioinf - Process for the bioinformatic helpdesk
Description of implementation and use of bioinf-helpdesk.
Responsible person: tbd
General terms and definitions
The terms that are key to the helpdesk process are briefly introduced in this section. In general, we use the term "user ticket" or simply "ticket" for requests coming into and tracked in the helpdesk, whereas any derived repository/project tasks are termed "issues".
- Helpdesk 1st line support: all individuals trained in production
- Helpdesk 2nd line support: entire bioinformatics group in GDx and NorSeq
- Helpdesk reviewer: main production responsible bioinformatician
All end-users of our services are eligible. In general, they can be divided in a few distinct roles:
- Lab doctors
- Lab engineers
Priorities and timeframes
To agree on acceptable timeframes for resolution of user tickets, we use priorities, corresponding to
priority:: labels that should be applied to every helpdesk ticket in Gitlab:
- Urgent (
priority::urgent) - drop everything and focus on the ticket until resolved
- High (
priority::high) - evaluate within half a work day, then set a tentative deadline for resolution
- Normal (
priority::normal) - evaluate within 2-3 work days (max one week), then set a tentative deadline for resolution
- Low (
priority::low) - evaluate backlog regularly; tickets should not stay in the backlog for longer than 6 months, after which the ticket should be dropped (upon agreement with the user) or escalated, i.e. elevated in priority
Types of user tickets
We organize user tickets in four different types, corresponding to
type:: labels that should be applied to every user ticket in Gitlab:
- Delivery notifications (
type::delivery): standing routine notifications of project deliveries
- Development requests (
type::development): features, improvements
- General inquiries (
type::general): can be answered by email/ad-hoc meetings/docs changes
- Incidents (
type::incident): bugs, things going down, missing files, etc.
The helpdesk process
In general, the helpdesk reviewer should:
- Review new tickets as they come in and assign
- Aim to resolve tickets themselves whenever possible
- If immediate resolution is not possible, ensure tickets are assigned to relevant colleagues:
- Urgent/high priority: discuss assignment during standup, or if necessary (time-critical) with the relevant coordinators as soon as possible
- Normal priority: discuss assignment during the end-of-the-week review (Fridays)
- If necessary, create proper issues in relevant repositories/projects, with a link back to the ticket
- Ensure all tickets that are actively worked on have the
in progresslabel (e.g. derived issue and MR has been created and is being worked on)
Special considerations for incoming sequencing projects (delivery):
- Delivery tasks should be assigned
priority::urgentwithin the project and downgraded to
priority::normalwhenever urgent samples have been delivered
- Close when all samples are delivered
At the end-of-the-week review (Fridays), the helpdesk reviewer should discuss with the group:
in progresstickets; if stalled, decide on further action
- Priority upgrades / downgrades
- Assignment of normal priority tickets / derived issues
- Evaluate follow-up of tickets of
type::generalwith improvement to our docs or helpdesk knowledge base (FAQ)
In general, helpdesk tickets should be closed only on confirmation from the user that they are actually resolved, except for:
- Tickets related to delivery of sequencing projects, which can be closed when all samples have been delivered (see above);
- Tickets labeled
priority::low, which may be closed after evaluation (see description of this priority).
Helpdesk implementation in Gitlab
Labels and boards
We use labels on the project level (these can be promoted to global if needed). The labels we use for helpdesk tickets are:
helpdeskfor ease of filtering
in progressfor tickets that are assigned and actively worked on
Board for helpdesk:
in progress -
closed labels are applied automatically on creating / closing tickets.
- Gitlab users with “Watch” notification level for a project will receive notifications about issues, merge requests, and epics
- The notification level can be chosen by clicking on the bell sign to the right on the main project page
Creation of helpdesk tickets
Helpdesk tickets are created automatically upon email receival at the address firstname.lastname@example.org.
- On ticket creation: template with short process description - we will figure it out once we've got some experience and statistics.
- All relevant users must send their sequencing project announcements to the helpdesk's email following a specific template (to be provided).
Creation of derived project-level issues
Whenever appropriate, issues to resolve the helpdesk ticket should be created by the helpdesk reviewer in relevant repositories/projects. These issues should be linked back to the relevant helpdesk ticket (under "Linked issues").
Derived issues need not be created for tickets that are promptly resolved by the helpdesk reviewer and do not require further follow-up.
Automated Issue Triage
To automate labeling new issues with the
helpdesk label, a webhook solution has been set up, i.e. triage-bot. The bot solution utilises a Gitlab API project token to edit issue labels, which is generated under the settings tab of the helpdesk DPIPE repository: Settings -> Access Tokens. These access tokens are set with an expiry date, which defaults one month (maximum 365 days). To do this, we need to (this will disrupt triage bot service, so it should be done outside of business hours):
- Delete old token on Gitlab
- Create new token on Gitlab, with role Reporter (to handle confidential issues), and scope Issue Event.
- Add the newly created token to the
:gitlab -> :api-tokenkey in the secrets file of the triage bot on live server.
- Restart triage bot service on our remote server.