So you want to fix a bug or implement a new feature in Tails. Welcome aboard! Please read-on.
Every Free Software project is a bit different from the others. This page is meant to help you understand some basics of the Tails project, so that you can more efficiently and joyfully contribute to Tails.
Many, many Live system projects — including a few ones that aimed at enhancing their users' privacy — have lived fast and died young. We explain this by their being one wo/man efforts, as well as design decisions that made their maintenance much too costly timewise and energywise.
We want Tails to live as long as it is needed: Tails is not meant to be solely a pet project.
Since the early days of this project (i.e. early 2009), ease of maintenance in the long run has been a major factor in every decision we have made. Nowadays Tails is more alive and kicking than it has ever been, and we feel this would have been impossible without this mindset.
Our focus on low-effort maintainability has practical consequences.
First of all, we tend to carry the smallest possible delta with our upstreams (i.e. upstream software and Debian). For details about this, read our relationship with upstream statement. Moreover, we encourage you to improve Tails by working on Debian.
Second, we try not to reinvent the wheel, and we flee the Not invented here syndrome like the plague. Very little code is actually written specifically for Tails: most of what we call code work on Tails is more similar to system administration than it is to programming. We glue existing pieces together. When we need a feature that no software provides yet, we tend to pick the best existing tool, and do whatever is needed to get the needed feature upstream... which sometimes implies to write a patch ourselves.
We use Redmine to manage our lists of tasks and bugs, as well as our roadmap. If you already know which one of the listed tasks you want to tackle and it has the Code Type of work, then you can probably safely skip to the next section.
So you want to contribute code to Tails but do not know where to start? Our coding TODO list is huge and frightening, but...
Do not panic!
Let's see how we can help you picking up a task. A few tips:
- Choose something that matters for you, such as fixing that bug that annoys you so much or implementing this feature you are missing so much.
- Choose something where your singular skills and knowledge are put to work.
- Have a look to the list of easy tasks: there is something, in each of these tasks, that one can do right away since it does not require deep knowledge of the Tails internals.
On the one hand, you may want to start doing practical stuff
immediately. In this case, see list the tasks that have the
set. You probably want to start looking
at the few ones that are also in the list of easy tasks
first so that you can gain confidence and we can smoothly learn to
On the other hand, you may prefer picking up a task that requires
some initial thought and discussion before rushing to your
$EDITOR. In this case, you probably want to look at the guidelines
for providing needed input.
So you know what bug you want to fix, what feature you want to implement. At this point, we advise you to:
- Gather results of previous research and discussions on the topic you are interested in. Search this wiki, tickets on Redmine and the developers mailing-list archive.
- Tell us about your plans to make sure your idea fits nicely into the big picture, and nobody is currently working on the same task.
Tails is developed using a set of Git repositories.
If unsure, base your work on the
devel branch, or ask.
Every commit shall implement one change and be labeled with a commit message that clearly expresses the rationale of your changes. This is needed so that your work can be easily reviewed: explain every proposed change to us in the same way you would explain it to someone who would not get the background.
Before diving into technical details, please read our merge policy.
You can submit small, easy changes as Git patches (prepared with the
git format-patch command) over email.
For larger changes that will certainly require a few review/fix cycles before being merged, it's better if you push your work to a dedicated Git topic branch, and ask us to review it. If you already know where to host your personal repository in a public online place, this is great; otherwise, you can fork us on GitLab, or ask the Tails system administrators (firstname.lastname@example.org) to host your repository.
Still here? Good, please read on.
The specification and design document will help you understand better how Tails works.
You should subscribe to the tails-dev mailing list.
You should test your changes before contributing them back. Most often, this requires you to build an ISO image.
If you want to talk in public with other Tails developers and users:
- You can subscribe or write to the email@example.com mailing-list. Any message sent to this list is stored in a public archive, so beware of what your email content and headers reveal about yourself: location, IP address, etc.
- You can join our #tails and #tails-dev chatrooms; note: only a few Tails core developers hang out there, so email is preferred for anything that might be of interest for the larger Tails development community.
- For translation-related matters, you can subscribe or write to the firstname.lastname@example.org mailing-list. Any message sent to this list is stored in a public archive, so beware of what your email content and headers reveal about yourself: location, IP address, etc.
- For user experience and user interface related matters, you can subscribe or write to the email@example.com mailing-list. Any message sent to this list is stored in a public archive, so beware of what your email content and headers reveal about yourself: location, IP address, etc.