Duties

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;

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

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

Meetings

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.

Assignee

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.

Contact

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

OpenPGP key (details).