GitLab: update terminology

wiki/src/contribute/working_together/GitLab.mdwn

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

wiki/src/contribute/working_together/roles/foundations_team.mdwn

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

wiki/src/contribute/working_together/roles/sponsor_deliverables/team_manager.mdwn

@@ -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.

wiki/src/contribute/working_together/roles/sponsor_deliverables/worker.mdwn

@@ -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".