summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/working_together/roles/foundations_team.mdwn
blob: 2beaf4d984c208746944c06980489b1ce1913a70 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
[[!meta title="Foundations Team"]]

[[!toc levels=2]]

<a id="duties"></a>

# 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|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 <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 [[contribute/calendar]] accordingly, and asking
  <tails-rm@boum.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";
  - the
    [Ready for QA, with no assignee](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=194)
    view;
  - [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
    Debian.
  - 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.

<a id="meetings"></a>

# 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|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
   following month(s).

 People only maintaining Debian packages but not doing any other work in
 the team are not required to attend the meeting.

<a id="tasks-management"></a>

# Tasks management

This section documents the principles and guidelines we use for
tracking [our
tasks](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=307).

This applies on top of the broader Tails project's tasks management
guidelines:

 - [[contribute/working_together/Redmine]]
 - [[contribute/working_together/document_progress]]

<a id="tasks-management-target-version"></a>

## 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](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=307)
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 [[!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.

<a id="tasks-management-assignee"></a>

## 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](https://www.benday.com/2016/10/21/scrum-dont-lick-the-cookie/).

A ticket [owned by the Foundations
Team](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=307)
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.

<a id="contact"></a>

# Contact

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

[[OpenPGP key|tails-foundations.key]]
([[details|doc/about/openpgp_keys#foundations]]).