Commit e4234d04 authored by intrigeri's avatar intrigeri

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

parent 6ec6253a
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment