diff options
authorintrigeri <>2019-04-05 14:35:24 +0000
committerintrigeri <>2019-04-05 14:36:57 +0000
commite4234d04393f875b353d432560bf1ff3bc5deab5 (patch)
parent6ec6253a11496c495db0d8caf4916f4816accf01 (diff)
Document the Foundations Team's principles and guidelines for tasks management.
1 files changed, 83 insertions, 0 deletions
diff --git a/wiki/src/contribute/working_together/roles/foundations_team.mdwn b/wiki/src/contribute/working_together/roles/foundations_team.mdwn
index e86af3d..6c44910 100644
--- a/wiki/src/contribute/working_together/roles/foundations_team.mdwn
+++ b/wiki/src/contribute/working_together/roles/foundations_team.mdwn
@@ -110,6 +110,89 @@ meetings, please send the team before the meeting:
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
+This applies on top of the broader Tails project's tasks management
+ - [[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
+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
+A ticket [owned by the Foundations
+should have the _Assignee_ field set if, and only if, at least one of
+these conditions is met:
+ - It is the parent ticket for a large project that need someone to
+ coordinate our efforts.
+ - 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.
+ - Sponsor deliverables that are managed under the "let's decide
+ a long time in advance who exactly will do each task" paradigm.
<a id="contact"></a>
# Contact