1. Main purpose
  2. Duties
    1. Triaging user support requests
      1. Information we are looking for
      2. Try to reproduce
      3. Problems that are frequently being reported
      4. Relaying information to the relevant teams
      5. GitLab issue description = the source of truth
      6. Sometimes, it's OK to stop answering users
      7. Standard replies
    2. Stay up-to-date regarding Tails changes
    3. Update the standard reply used by the auto-reply mechanism
    4. Mailing list moderation
  3. Work organization

Main purpose

The end-goal of Help Desk, when handling individual support requests, is to help improve Tails for a broad range of users — as opposed to merely helping one individual user solve the immediate problem they're facing, which does not scale and does not help anyone else.

The output of Help Desk work is then used:

  • by the Foundations Team, Technical writers, and UX designers, to prioritize their own work;

  • by the broader Tails community, to feed the thought process about our vision for Tails in the future, and help us build a relevant roadmap.

Duties

Triaging user support requests

Help Desk receives and triages user support requests by email:

Additionally, if Help Desk members feel like it, once the email part has been dealt with, they may triage user support requests on other communication platforms, such as XMPP or Reddit.

Information we are looking for

To achieve its main purpose, Help Desk treats WhisperBack reports and support requests as a source of information that can teach the project something that we don't know yet. In particular, we're looking for:

  • problems that affect many users:

    • software bugs
    • UX problems
    • feature requests

  • hardware support regressions that affect a broad range of hardware

  • workarounds for hardware support problems

Since we have an auto-reply mechanism in place, we have stopped manually answering support requests that don't serve the main purpose of Help Desk.

Try to reproduce

When all the following conditions are met, try to reproduce the reported problem, before you relay it to the relevant teams or create a GitLab issue:

  • The report is about new information that you think can be used to improve Tails.

  • You think the problem affects at least 1 of our personas.

  • You think you can reproduce the problem in less than 30 minutes.

Problems that are frequently being reported

Sometimes, Help Desk receives frequent reports (about 2-5 per week) about a problem that affects at least 1 of our personas. When this happens, even if Help Desk cannot reproduce the problem, a GitLab issue should be created to give the problem greater visibility. The GitLab issue should:

  • Describe the problem in detail, including references to relevant WhisperBack reports and support requests.

  • Include an estimate of how often the problem is being reported.

  • Mention the relevant team.

Relaying information to the relevant teams

If you have spotted new information that you think can be used to improve Tails, relay it to the relevant teams:

  1. Gather information about the context in which the problem occurs, how important it is, what known workarounds exist, and whether you could reproduce the problem.

  2. Forward the WhisperBack report over email.

  3. Create a GitLab issue that mentions the relevant team, referencing the WhisperBack report ID.

    If possible, provide statistics about how many people are impacted.

  4. If the problem is important and affects many users, also alert members of the relevant team on XMPP, to ensure they're aware of it ASAP, regardless of any latency in triaging forwarded reports.

The relevant team will take a look and decide what to do about the problem.

GitLab issue description = the source of truth

We use the description of GitLab issues that are relevant to Help Desk's work to share and maintain this information:

  • standard reply by Help Desk to affected users

  • list of information that we need users to provide

For example, see #13576#we-need-your-feedback.

Then:

  • Help Desk points the current bug reporter and future ones to the GitLab issue.

    This avoids having to write essentially the same answer multiple times, which lowers the workload of the Help Desk.

    This also ensures the affected users get up-to-date information.

  • Some users will find the information themselves on GitLab.

    This lowers the workload of the Help Desk.

  • Technical writers can improve the phrasing.

    This increases the chances affected users can workaround the problem or provide the information we need.

  • Developers can update the technical information.

    For example:

    • To ask affected users to test a nightly built image that may fix the problem.
    • To request more technical information from affected users.

Sometimes, it's OK to stop answering users

It's OK to stop answering users once we have done either one of:

  • gathered the information we will need to improve Tails

  • realized that we won't realistically be able to improve Tails in this respect

  • determined that the affected use case is low on our list of priorities

Standard replies

Hardware support problems

In general, our resources don't allow us to solve hardware support problems. This is why, in this area, we limit our ambitions to:

  • Identifying recently introduced regressions that affect a broad range of hardware.

  • Documenting workarounds our users have discovered themselves and reported to us.

Standard operating procedure: standard reply to hardware support reports for which we can't do anything

Other standard replies

Whenever possible, Help Desk should use one of our standard replies, because:

  • These answers are the best replies, to many common situations, that we collectively managed to produce so far.

  • Translators can translate these standard replies.

  • Technical writers can help keep terminology consistent between our documentation, software, and standard replies.

  • Developers can spot answers that are going to be outdated or broken by upcoming changes.

Stay up-to-date regarding Tails changes

In order to triage user support requests, Help Desk needs to remain continuously aware of changes that affect Tails users:

  • Read Tails news.

    In particular, when a new Tails was published, carefully read the release notes.

  • Scan the detailed changelog entry when a new Tails was released.

Update the standard reply used by the auto-reply mechanism

Help Desk has a mechanism that automatically replies to all emails sent to support@tails.net. The standard reply used by the auto-reply mechanism should be kept up to date with Help Desk hot topics.

Whenever changes are made to the standard reply, the sysadmins must be informed to update the reply sent by the auto-reply mechanism. The reply sent by the auto-reply mechanism is not automatically updated with changes to the standard reply. The sysadmins should also be informed if the subject header of the auto-reply needs to be updated.

Although Help Desk is responsible for maintaining the standard reply used by the auto-reply mechanism, anyone can suggest changes to the standard reply by creating a merge request.

Mailing list moderation

Administer and moderate our general purpose public mailing lists:

Work organization

  • When Help Desk resources don't allow doing everything, answering communications from other teams should take priority over triaging user support request.

  • When Help Desk resources don't allow covering every shift, it's OK to:

    • Skip some shifts entirely

    • Do some shifts in read-only mode: no answers, only skim over reports, looking for major new issues to report them back to the project.

    • Ask for help outside of the current Help Desk team.

  • Help Desk members are expected to follow-up on communications even when not on shift.