1. Duties
  2. Meetings
  3. Tasks management
    1. How to pick your next task
    2. Milestone
    3. Assignee
    4. UX improvements
    5. Useful links
  4. Internal tools
    1. Team mailing list
    2. Public wiki
    3. Private wiki
  5. Contact

Duties

The Tails Foundations Team is responsible for:

  • Release Management

  • 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

  • Front Desk duties

  • 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 [email protected] 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 [email protected] 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:

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

  • Maintain AppArmor in Debian

    Scope:

    • maintenance work that is necessary to keep the status quo working and up-to-date wrt. packaging best practices;

    • maintainer due care, such as forwarding bug reports upstream (even for bugs that don't affect Tails);

    • work on specific improvements that Tails would particularly benefit from;

    • onboarding and mentoring new co-maintainers.

  • Track bugs related to the aforementioned packages in Tails and forward them to Debian.

  • Maintain the backend of the verification JavaScript that is used on our download pages. For example, update it to new versions of the Forge library. See its release process.

  • Help maintaining the configuration of our Jenkins jobs

    See the documentation of the setup in the sysadmins area.

Meetings

See https://gitlab.tails.boum.org/tails/team/-/wikis/meetings.

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. Has a $YEAR label, 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)

Milestone

Status: this is not the case anymore.

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.

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.

Assignee

See GitLab.

UX improvements

We have a list of UX improvements that qualify as Foundations Team work.

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.

Process

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 the list of Foundations Team tasks.

Useful links

Internal tools

Team mailing list

Foundations Team members are on the [email protected] Schleuder mailing list.

Public wiki

Tails Team's public wiki

Private wiki

Only Foundations Team members have access to the team's private wiki.

Contact

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

  • write to [email protected];

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