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 ISO build system;
    • doing the extra peer-review and release management work that corresponds to the above bullet points;
  • welcoming new code contributors, e.g. when enough mentoring is required to put it outside of the scope of the release manager's duty to review code contributions;

  • reviewing code contributions that are on nobody else's plate, e.g. those submitted by the release manager, and the translation merge requests sent to tails-l10n@boum.org;

  • checking how important each issue forwarded by Help Desk is, whether it's worth documenting it, and validating 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;

  • handling new tickets 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 ticket 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.
  • reviewing'n'merging proposed branches in a timely manner (1 week in general, up to 2 weeks if needed in exceptional cases). If a ticket is flagged Needs Validation, but nobody on the Foundations Team can take care of the review'n'merge, it's the Foundations Team's responsibility to ask for help. These tickets can be tracked using:

  • 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

    • 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.
    • Maintain a bunch of packages.
    • Review and sponsor a few more packages.
    • Track bugs related to these packages in Tails and forward them to Debian.
    • Track Debian bugs and forward them upstream.
    • Not in the scope of this work:
      • Debian AppArmor team's packages:
      • Perl libraries our custom software depends on: intrigeri does it 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.


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 tickets;
  • 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:

Target version

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

A ticket owned by the Foundations Team should have the Target version field 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 Target version should be a year, unless one of the above conditions makes us target a specific release.

Postponing a task to the next Target version 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 a Target version in the first place.


We use the Assignee field in a way that helps us organize share our work as a team, focus on what matters most currently, and avoid individual over-commitment & feelings of failure.

To this aim, most tasks should be up for grabs for anyone who has spare capacity and the required skills: Don't Lick the Cookie.

A ticket owned by the Foundations Team should not be assigned to anyone in general. But we do assign a ticket if at least one of these conditions is met:

  • The task is both important and urgent.

  • The Target version is set to the next Tails release. See the "Target version" section above for details.

  • We did all the work we could on this task already and now have to track progress on a blocker that we cannot address ourselves. For example, regularly tracking progress and pinging on patches we've submitted upstream.

  • Only one of us can complete the task. This helps identify bottlenecks, high bus factor, and over-commitment.

  • This task is the assignee's current top priority wrt. Tails work.

  • Sponsor deliverables that are managed under the "let's decide a long time in advance who exactly will do each task" paradigm.

  • It is about the parent ticket for a large project with several subtasks that will be tackled by different people, and we need someone to coordinate the project.

UX improvements

Our UX designers maintain a list of UX improvements that would be welcome, as tickets related to #14544.

From time to time, some Foundations Team members meet with UX designers and do a value/cost analysis of these tickets. 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 tickets 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 a ticket related to #14544, that was not added to our plate yet. It is an option to turn one such ticket into Foundations Team work, provided a few conditions are met. The Foundations Team lead maintains a list of tickets that meet these conditions, in the description of #14544.

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

  • It was marked as related to #14544 by our UX designers.

  • 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. A ticket 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 a ticket:

  • Assign it to yourself.

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


To get in touch with the Foundations Team, write to tails-foundations@boum.org.

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