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.


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

Once the #17935 is in place, we'll stop manually answering support requests that don't serve the main purpose of Help Desk.

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.

  2. Forward the WhisperBack report over email.

    In order to point the Foundations Team's "frontdesk" to a report, instead reply to it on, adding the [FT] tag in the subject.

  3. If the problem is big enough to warrant tracking it in GitLab, file a GitLab issue assigned to the relevant team, referencing the WhisperBack report ID.

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

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.


  • 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.

Mailing list moderation

Administer and moderate our general purpose public mailing lists:

Work organization

  • 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.