Commit 7be29798 authored by intrigeri's avatar intrigeri
Browse files

GitLab: update terminology

parent 5bf480a2
......@@ -114,8 +114,8 @@ 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.
- The milestone is set to the next Tails release.
See the [[milestone|GitLab#milestone]] section 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.
......@@ -142,14 +142,14 @@ Different teams and contributors use the _Milestone_ value differently:
contributors should be able to rely on.
- Others use it as a pool of tasks they want to have on their short-term radar.
For issues that are on the Tails [[!tails_roadmap]], the _Target version_ is set
For issues that are on the Tails [[!tails_roadmap]], the milestone is set
to a year, until it makes sense to target a specific release.
Postponing to the next _Target version_ more than once is not business
Postponing to the next milestone more than once is not business
as usual — it's a red flag. Ideally, 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.
any milestone in the first place.
## Priority
......
......@@ -134,7 +134,7 @@ An issue
[[!tails_gitlab
groups/tails/-/issues?label_name%5B%5D=Core+Work%3AFoundations+Team
desc="owned by the Foundations Team"]]
should have the _Target version_ field set if, and only if, at least
should have a milestone set if, and only if, at least
one of these conditions is met:
- External constraints determine the timeline of our work.
......@@ -147,15 +147,15 @@ one of these conditions is met:
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
milestone 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
Postponing a task to the next milestone 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.
have any milestone in the first place.
<a id="tasks-management-assignee"></a>
......
......@@ -17,7 +17,7 @@ While working on a deliverable
==============================
- Ensure that the workers on your team actually do the work on time.
Help them as needed in whatever way you see fit, e.g. create tickets,
Help them as needed in whatever way you see fit, e.g. create issues,
organize meetings, organize feedback sessions.
- Regularly check the status of work vs. deadlines.
......
......@@ -6,16 +6,16 @@ a sponsor, you must:
- Ask any information you lack to your
[[sponsor_deliverables/team_manager]].
- Track which ticket corresponds to which deliverable.
- Track which issue corresponds to which deliverable.
Ensure each of your deliverables has a ticket in Redmine with the
correct _Deliverable for_ value.
Ensure each of your deliverables has an issue in GitLab with the
correct _Deliverable for_ label.
- Schedule your work in advance to meet deadlines:
- Plan for surprises such as tasks that are unexpectedly harder
than planned.
- Use the _Target version_ field in Redmine to track your own plans
- Use the milestone field in GitLab to track your own plans
and timing goals. Keep this information up-to-date at all times.
- Check how good you're doing wrt. their deliverables and deadlines.
......@@ -24,13 +24,13 @@ a sponsor, you must:
- Report your progress on deliverables when requested.
Summarize the tickets and achievements of each deliverables since
Summarize the issues and achievements of each deliverables since
the last report. This information will then be transmitted to the
Accounting Team for invoicing. Clarify the matching between tickets
Accounting Team for invoicing. Clarify the matching between issues
and deliverables; for example, you can report:
- "B.3.7 completed: #nnnn, #mmmm, etc.": all these tickets must
have the _Resolved_ status in Redmine.
- "B.3.7 completed: #nnnn, #mmmm, etc.": all these issues must
be closed in GitLab.
- "C.4.2 (#nnnn, #mmmm) in progress but not completed because of
$reasons".
......
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