The Tails Foundations Team is responsible for:

  • maintaining the core Tails system, which includes e.g.

    • porting Tails to the new version of its upstream foundations, such as a new Debian, Tor or Tor Browser;
    • keeping our core code base up-to-date and maintainable, e.g. refactor or clean up stuff that has bit-rotted, migrate code that would otherwise rely on obsolete technologies;
    • maintaining the Tails ISO and USB images build system;
    • doing the extra peer-review and release management work that corresponds to the above bullet points;
  • welcoming and mentoring new code contributors;

  • reviewing code contributions in a timely manner (1 week in general, up to 2 weeks if needed in exceptional cases). If nobody on the Foundations Team can take care of a given MR, it's the Foundations Team's responsibility to ask for help: Merge Requests (MRs), and in particular unassigned Merge Requests (MRs) that are not marked as drafts

  • triaging issues forwarded by Help Desk.

    The members of the Foundations Team who share the "frontdesk" workload are subscribed to the mailing list that receives bug reports: tails-bugs@boum.org. In order to raise FT's attention on a specific report, Help Desk replies to it on that mailing list, adding a [FT] tag in the subject.

    Then, Foundations Team "frontdesk" checks how important each issue forwarded by Help Desk is, whether it's worth documenting it, and validates the workarounds. If it's worth documenting the problem and possibly the workarounds, either put it on our Technical Writers' plate, or draft something directly, or merge a draft proposed by Technical Writer apprentices;

  • triaging newly created issues when they are more technical than feature request (those are handled by the UX designers) or about bugs; reassigning to whoever is on Help Desk duty any new issue that's really a support request;

  • ensuring that development discussions started on tails-dev@boum.org are followed-up;

  • proposing a release schedule for next year once Mozilla's own schedule is available (generally during Q3), ensuring everyone affected is aware of it and OK with it (e.g. team managers for sponsor deliverables), leading this discussion to a conclusion, updating the calendar accordingly, and asking tails-rm@boum.org to decide between themselves how they will share the release manager shifts; things to keep in mind:

    • An emergency release is often needed shortly after Pwn2Own.
  • deal with last minute emergency fixes needed during release process, e.g. #14962;

  • if time allows, do whatever code task the project sees as top-priority, such as fixing Holes in the Roof, important bugs, or implementing a feature that is needed to keep Tails relevant.

  • Maintain Tails relevant Debian packages in Debian

    • Role: being the fallback, on behalf of Tails, to ensure these packages are well maintained in Debian (it's OK, and even great, if other pkg-privacy members do part of the work).
    • Tasks:
    • Duration:
      • as long as we ship these packages in Tails
      • until the EOL of the last Debian stable release (including LTS) we put it in, even if we drop the package from Tails: including a package in a stable Debian release implies a commitment to maintain it during its lifetime.
    • In order to communicate expectations to the person who wears this hat, Tails contributors can:
      • use the Debian BTS
      • mention @debian-packages-maintainers on our GitLab
    • Not in the scope of this work:
      • Debian AppArmor team's packages, Perl libraries our custom software depends on: intrigeri does it as a volunteer with his Debian hat.
      • torbrowser-launcher: we only use its AppArmor profiles, that we could easily take from upstream if the Debian package was not maintained.
  • Track bugs related to the aforementioned packages in Tails and forward them to Debian.


Each month the Tails Foundations Team gathers for an online meeting.

  • Date:
    • The 3rd day of the month if it's a day between Monday and Thursday (inclusive)
    • The 6th day of the month otherwise
  • Time: 16:00 Berlin time (14:00 or 15:00 UTC, depending on the date)
  • Location: tails-meeting XMPP chatroom

As a Foundations Team member, if you cannot make one of these meetings, please send the team before the meeting:

  • a brief status update about life, work and issues;
  • information about how much more or less work you want for the following month(s).

People only maintaining Debian packages but not doing any other work in the team are not required to attend the meeting.

Tasks management

This section documents the principles and guidelines we use for tracking our tasks.

This applies on top of the broader Tails project's tasks management guidelines:

How to pick your next task

This is an initial draft, to be refined while learning from experience :)

Among the Foundations Team issues, in decreasing order of priority :

  1. Milestone is the upcoming version, for good reasons.
  2. Grant deliverable with a deadline.
  3. Milestone is the version that follows the upcoming release, for good reasons.
  4. Milestone is a year, which means this issue is on our roadmap.
  5. UX debt
  6. Priority is high (P:High label)
  7. Priority is elevated (P:Elevated label)


The Foundation Team treats the Milestone field as a commitment. Other Tails teams, contributors, and users should be able to rely on the value of this field.

An issue owned by the Foundations Team should have a milestone set if, and only if, at least one of these conditions is met:

  • External constraints determine the timeline of our work. For example, we have to upgrade to the next Tor Browser major release.

  • We are very confident we will complete the task in time for a specific release and we have a good reason to focus on it. For example, work in progress tasks can be good candidates, as opposed to starting work on a new task.

  • The task is on the Tails roadmap. In this case, the milestone should be a year, unless one of the above conditions makes us target a specific release.

Postponing a task to the next milestone more than once is not business as usual — it's a red flag. Such a change should be justified. The underlying problem should be identified and addressed: for example, the assignee might need help or be over-committed; the team could be under-staffed; or perhaps the task should simply not have any milestone in the first place.


See GitLab.

UX improvements

Our UX designers maintain a list of UX improvements that would be welcome, using the "UX:debt" label.

From time to time, some Foundations Team members meet with UX designers and do a value/cost analysis of these issues. Then, those with the best value/cost, that we can work on without waiting for lots of UX design work to be done, are added to our list of tasks. That is, working on them automatically qualifies as Foundations Team work.

In general, before looking for other UX improvements we could work on, we should first focus on these selected issues and on the most important or urgent of our other duties.

Still, while keeping this in mind, you might personally be particularly interested in working on an issue that has the "UX:debt" label, but that was not added to our plate yet. It is an option to turn one such issue into Foundations Team work, provided a few conditions are met.

The Foundations Team lead maintains a list of issues that meet these conditions:

These tickets are not part of the top ones in terms of value/cost but could nevertheless be turned into Foundations Team work if you are particularly interested in working on them:

You can check yourself if a particular issue meets all these conditions:

  • Our UX designers added the UX:debt label.

  • It is possible work on it without waiting for lots of UX work to be done first. To determine whether that's the case:

    • Look at the "UX" cost column in the spreadsheet attached to #14544. An issue with a UX cost of 2 or more probably does not qualify.
    • In doubt, ask our UX designers.
  • The P×S/Cdev value is 1.0 or greater, in the spreadsheet that's attached to #14544.

When you start working on such an issue:

  • Assign it to yourself.

  • Notify our UX designers with a @sajolida mention on the issue: then they can explain what kind of work they have to do before you can complete your part of the work.

Useful links

Internal tools

Team mailing list

Foundations Team members are on the tails-foundations@boum.org Schleuder mailing list.

Private Git repository

To set it up:

  1. Install needed tools

     apt install git-remote-gcrypt
  2. Clone it the repo

     git clone gcrypt::git@gitlab-ssh.tails.boum.org:tails/foundations.git
  3. Follow the setup documentation: README.md in the Git repository.


To get in touch with the entire Foundations Team, you can:

  • write to tails-foundations@boum.org;
  • mention @foundations-team on GitLab: GitLab will send an email notification about it to every member of the Foundations Team, and add it to their To-Do list.

You can encrypt your email with our OpenPGP key (details).