[[!meta title="Foundations Team"]]
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|release manager]] 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 <firstname.lastname@example.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;
* help triage new tickets that are on nobody else's plate when
frontdesk isn't in a good position to do it;
* ensuring that development discussions started on
<email@example.com> 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 [[contribute/calendar]] accordingly, and asking
<firstname.lastname@example.org> to decide between themselves how they will share
the [[roles/release_manager]] shifts; things to keep in mind:
- An emergency release is often needed shortly after [[!wikipedia 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 *Ready for QA*, 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:
- the "Release Manager View: VERSION";
[Ready for QA, with no assignee](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=194)
- [Ready for QA](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=117);
* deal with last minute emergency fixes needed during release process,
e.g. [[!tails_ticket 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](https://udd.debian.org/dmd/?email1=&email2=&email3=&packages=libgsecuredelete+libotr+mat+nautilus-wipe+onioncircuits+onionshare+pidgin-otr+seahorse-nautilus+tails-installer+torbirdy+torsocks&ignpackages=&format=html#todo).
- [Review and sponsor a few more packages](https://udd.debian.org/dmd/?email1=&email2=&email3=&packages=bilibop+keyringer&ignpackages=&format=html#todo).
- Track bugs related to these packages in Tails and forward them to
- Track Debian bugs and forward them upstream.
- Not in the scope of this work:
* [Debian AppArmor team](https://qa.debian.org/developer.php?email=pkg-apparmor-team%40lists.alioth.debian.org)'s packages:
* Perl libraries our custom software depends on: intrigeri does it
with his Debian hat.
* [[!debpts 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.
- The **3rd** day of the month if it's a day between Monday and
- 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|contribute/chat]]
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
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
This applies on top of the broader Tails project's tasks management
## 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
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
- 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 [[!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
A ticket [owned by the Foundations
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.
To get in touch with the Foundations Team, write to