Document the Foundations Team's principles and guidelines for tasks management.

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
+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 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