GitLab: adjust lots of phrasing

wiki/src/contribute/Linux_kernel.mdwn

@@ -60,7 +60,7 @@ automatically if the ABI is bumped.
 # Process
 
 A Foundations Team member (generally the team lead, so far) creates
-a tracking ticket whenever:
+a tracking issue whenever:
 
  - A new major version of Linux is released. At this point, that
    version is generally available only in Debian _experimental_.
@@ -91,12 +91,10 @@ To learn how the new kernel works for us:
    back to the top level directory. `git diff` should show an updated
    `Subproject commit` accordingly, and that can be committed.
 3. Push this new branch to our CI.
-4. Set the _Feature Branch_ field on the ticket to the name of your
-   new branch.
 5. Quickly test a build from this branch on your hardware.
 6. Compare the Jenkins build and test results to the ones for our
    `stable` and `devel` branch.
-7. Report your findings on the ticket.
+7. Report your findings on the issue.
 
 ## Gather other data that will inform our decision
 
@@ -121,7 +119,7 @@ In there, look for:
    recently reported to Debian against this version of the kernel
  - Relevant hardware support improvements
 
-Take notes on the ticket of the most relevant bits or lack thereof.
+Take notes on the issue of the most relevant bits or lack thereof.
 
 ## Make a decision
 
@@ -144,7 +142,7 @@ several factors:
 
 If in doubt, ask your team-mates :)
 
-If the decision is "do nothing", close the ticket and stop reading here.
+If the decision is "do nothing", close the issue and stop reading here.
 Else, read on.
 
 ## Implement the decision
@@ -160,8 +158,7 @@ Therefore, create a new
 `feature/NNNNN-linux-X.Y-stable+force-all-tests` topic branch forked
 off `stable` and transplant onto it the commits you had to create on
 your `devel`-based topic branch (`git rebase --onto` or `git
-cherry-pick`). Update the _Feature Branch_ field accordingly
-in Redmine.
+cherry-pick`).
 
 But the new resulting topic branch will likely not build: a bugfix
 release is built from our `stable` branch, that uses a set of APT
@@ -230,8 +227,9 @@ improvement:
  - Enabled by default: nothing to do, profit :)
 
  - Guarded by local configuration such as a sysctl or a kernel command
-   line option: file a ticket about it on Redmine and add this ticket
-   to the Foundations Team' radar. Optionally, do the work yourself:
+   line option: file a GitLab issue about it, with the
+   `Core work: Foundations Team` label.
+   Optionally, do the work yourself:
    once you've got CI results about your topic branch with this new
    option disabled, add a commit that enables it and compare the
    results (including test suite total run time, to spot important

wiki/src/contribute/how/code.mdwn

@@ -60,7 +60,7 @@ upstream... which sometimes implies to write a patch ourselves.
 We use [[!tails_gitlab "" desc="GitLab"]] to track
 our lists of tasks and bugs, as well as our [[!tails_roadmap]].
 If you already know which one of the listed tasks you want to tackle
-and it has the *Code* Type of work, then you can probably
+and it has the *T:Code* label, then you can probably
 safely skip to the next section.
 
 So you want to contribute code to Tails but do not know where to

wiki/src/contribute/how/code/HACKING.mdwn

@@ -44,7 +44,7 @@ you have something to contribute, please read our
 
 * `feature/XXXX-*`, `bugfix/XXXX-*`, `test/XXXX-*`: We use this naming
   scheme for the branches if new features, bugfixes and automated
-  tests, where `XXXX` refers to the Redmine ticket they fix.
+  tests, where `XXXX` refers to the GitLab issue they fix.
 
 We will sometimes talk about "base branches", which are `stable`,
 `testing`, `devel` and `feature/DEBIAN_NEXT`. When developing a new

wiki/src/contribute/how/documentation.mdwn

@@ -25,7 +25,7 @@ But there are still many ways you can start contributing:
   - We maintain a list of
     [[!tails_gitlab groups/tails/-/issues?label_name%5B%5D=T%3AEnd-user+documentation
     desc="documentation tasks"]].
-    You can start writing a draft in the corresponding ticket and then
+    You can start writing a draft in the corresponding issue and then
     [[ask us for review|contribute/merge_policy]].
 
   - Small fixes and enhancements to the current documentation are

wiki/src/contribute/how/documentation/release_notes.mdwn

@@ -56,7 +56,7 @@
         understandable by them.
       - What we are describing in non-technical language is
         understandable by more technical users.
-      - We point to more technical sources like tickets and design
+      - We point to more technical sources like issues and design
         documents.
       - Technical items are less proheminent.
       - *For example:* Harden our firewall by rejecting `RELATED` packets
@@ -77,14 +77,14 @@
     - Add regressions brought by the new release.
     - Remove older known issues that are fixed by the new release.
   - Format
-    - Link to ticket for fixed problems and changes that are well justified in Redmine
-    - Put the period before ticket number
+    - Link to issue for fixed problems and changes that are well justified in GitLab
+    - Put the period before issue number
       - "Bla bla. ([!tails_ticket 1234])"
   - Prepare a tweet with highlights:
     - Tails x.y is out: https://tails.boum.org/news/version_x.y/
 
       It bla bla bla, and more.
-    - Add it as a comment to the ticket for the release notes.
+    - Add it as a comment to the issue for the release notes.
   - If we release new major features ("New features" section),
     schedule tweets in the future to let the world know about it, even
     months after we release them.

wiki/src/contribute/how/input.mdwn

@@ -9,7 +9,7 @@ who lack the technical skills needed to actually implement the desired
 feature.
 
 Tasks that are currently stalled by the need for input have the
-the `Research`, `Discuss`, or `Test` *Type of work* on our
+the `T:Research`, `T:Discuss`, or `T:Test` label on our
 [[!tails_gitlab "" desc="TODO"]] list.
 You probably want to start looking at the ones that are also in the
 [[!tails_gitlab_starter]] first so that you can gain confidence...

wiki/src/contribute/how/sysadmin.mdwn

@@ -75,7 +75,7 @@ contribute usefully without having an account on the actual systems.
 ## If you don't know Puppet
 
 A few issues in GitLab can be fulfilled by testing something, and then
-reporting your results on the relevant ticket.
+reporting your results on the relevant issue.
 
 However, most tasks are a bit more complicated. Follow these steps to
 contribute useful bits, that someone else can then integrate into

wiki/src/contribute/merge_policy/review.mdwn

@@ -57,7 +57,7 @@ In particular, see
 - As reviewer, you are allowed to commit trivial fixes on top of the
   proposed branch to avoid round-trips: for example, fixing typos
   and improving phrasing of comments and strings.
-  Then, report back about these changes on the ticket.
+  Then, report back about these changes on the MR.
 
 ## Give feedback
 

wiki/src/contribute/release_process.mdwn

@@ -730,7 +730,7 @@ to verify that Jenkins reproduced your images:
          * Otherwise, if the fix looks time-consuming or difficult,
            let's release anyway. But let's add a known issue about
            "This Tails release does not build reproducibility" to the
-           release notes, linking to the ticket where
+           release notes, linking to the issue where
            the nature of the reproducibility failure is clearly
            described.
 
@@ -954,7 +954,7 @@ Else, if this verification fails, then:
 
    Else, if the parameters where correct, then follow the next steps.
 
-3. File a ticket about this problem.
+3. File an issue about this problem.
 
    Specify:
 
@@ -1294,7 +1294,7 @@ Testing
    suites are done in due time. Clock and report this work separately
    from your RM'ing work.
 1. Triage test results, reproduce bugs as needed, decide what the next
-   step is and make sure it happens: add to known issues? file ticket?
+   step is and make sure it happens: add to known issues? file an issue?
    release blocker? improve the test description (steps, expected outcome)?
 
 Prepare announcements and blog posts
@@ -1394,7 +1394,7 @@ Write the announcement for the release in
   [[!tails_gitweb_commit 9925321]] breaks all existing persistent
   profiles).
 - Document known issues.
-- This snippet can help to convert the copied changelog's ticket
+- This snippet can help to convert the copied changelog's issue
   references to links:
 
       sed -i 's@#\([0-9]\{4,5\}\)@[[!tails_ticket \1]]@g' \
@@ -1581,14 +1581,16 @@ you've just released:
 
 Then, do the same for MRs.
 
+Ideally we would [[!tails_ticket 17589 desc="automate this"]].
+
 Then, close the just-released [[!tails_gitlab groups/tails/-/milestones
 desc="milestone"]].
 
 ### Tickets linked from the website
 
-Go through the tickets linked from the documentation and support sections of the
-website and point our lead technical writer (sajolida) to the tickets that might be resolved in
-this release.
+Go through the issues linked from the documentation and support sections of the
+website and point our lead technical writer (sajolida) to those that might
+be resolved in this release.
 
     cd "${MASTER_CHECKOUT:?}" && \
     find wiki/src/{doc,support} -name "*.mdwn" -o -name "*.html" | xargs cat | \
@@ -1620,7 +1622,7 @@ span several lines, so finding the ones reported by the above code
 Twitter
 -------
 
-Check in the comments of the ticket for the release notes if the
+Check in the comments of the issue for the release notes if the
 technical writers have prepared a tweet. Otherwise tweet a simple link
 to the release notes:
 

wiki/src/contribute/release_process/tails-installer.mdwn

@@ -189,8 +189,6 @@ Also:
   package meant for the Tails APT repository, while the first package
   that will be uploaded to Debian will have `-1`;
 * Set the appropriate target release name.
-* Make sure every Tails ticket ID is of the form `Tails#NNNNN`, not
-  `#NNNNN` and definitely not `Closes: #NNNNN`.
 
 Commit the changelog:
 

wiki/src/contribute/release_process/test/automated_tests.mdwn

@@ -388,10 +388,8 @@ could either:
 * remove a complete feature, if the complete feature is broken for the
   same reason.
 
-Each such commit *must* have a ticket created, referencing the commit
-to revert, have an assignee and an appropriate milestone set so they
-are not forgotten. Bonus point: push a branch that reverts the commit,
-and then set it as the ticket's _Feature Branch_.
+Each such commit *must* have an issue created, referencing the commit
+to revert.
 
 (Once [[!tails_ticket 10198]] has hit Cucumber we can solve this,
 i.e. [[!tails_ticket 7233]], in a much better way.)

wiki/src/contribute/release_process/test/reproducibility.mdwn

@@ -6,8 +6,8 @@ After accepting to be the <i>Trusted Reproducer</i> you should have been
 instructed to go here immediately and read the "Preparation"
 section. For a planned release you should be doing this weeks before
 the release you are about to reproduce; for emergency releases you
-likely only have days or even hours. If you were not, file a
-ticket about this, since an important part of process must have been
+likely only have days or even hours. If you were not, file an
+issue about this, since an important part of process must have been
 missed by the RM.
 
 </div>
@@ -63,8 +63,8 @@ following variables as instructed:
 <!--   variable|contribute/release_process#prepare-iuk]] and double-check -->
 <!--   that it makes sense! Note that exceptions happen (e.g. there could -->
 <!--   be a bug in some old versions upgrader so we skip it). -->
-<!-- * If the release notes have already been written (generally there is a -->
-<!--   ticket about it) it should list which versions have automatic upgrades. -->
+<!-- * If the release notes have already been written (generally there is an -->
+<!--   issue about it) it should list which versions have automatic upgrades. -->
 
 ## Inputs from manual testers
 

wiki/src/contribute/tor.mdwn

@@ -32,8 +32,6 @@ the upgrade:
 2. On that branch, bump `config/APT_snapshots.d/torproject/serial` to a snapshot
    that's recent enough to include the relevant new version of `tor`.
 3. Push this new branch to our CI.
-4. Set the _Feature Branch_ field on the tracking issue to the name of your
-   new branch.
 5. Compare the Jenkins build and test results to the ones for our
    `stable` branch. What follows assumes that these CI results look good.
    If they don't, more work is needed.

wiki/src/contribute/working_together/GitLab.mdwn

@@ -128,7 +128,7 @@ met:
  - Sponsor deliverables that are managed under the "let's decide
    a long time in advance who exactly will do each task" paradigm.
 
- - It is about the parent ticket for a large project with several
+ - It is about the parent tracking issue for a large project with several
    subtasks that will be tackled by different people, and we need
    someone to coordinate the project.
 

wiki/src/contribute/working_together/criteria_for_starter_tasks.mdwn

 [[!meta title="Marking a task as Starter"]]
 
-We think that having issues flagged as *Starter* on Redmine is a great tool
+We think that having issues labeled *Starter* on GitLab is a great tool
 to help new contributors getting into Tails. Here are a few criteria to
 help us determine which issues to put in this category.
 

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

@@ -33,7 +33,7 @@ User support
     1. Gather information about the context in which the problem
        occurs, how important it is, what known workarounds exist.
     2. Forward the WhisperBack report over email.
-    3. File a ticket assigned to a Foundation Team member, referencing
+    3. File an issue assigned to a Foundation Team member, referencing
        the WhisperBack report ID.
     4. Ideally, provide statistics about how many people are impacted.
     5. The Foundations Team will take a look and decide what to do

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

@@ -45,7 +45,9 @@ and filing tickets for the Foundations Team as needed.
     `README`
   - follow the instructions in `keyringer/README` in the RM team's Git
     repository then make sure you can `keyringer tails-rm decrypt credentials`
-  - _Manager_ status on Redmine
+  - _Reporter_ status on
+    [[!tails_gitlab groups/tails/-/group_members
+    desc="the `tails` GitLab group"]]
 - Check when our OpenPGP signing key expires.
   If that's before, or soon after, the scheduled date for the release
   _after_ the one your shift is about, then shout.
@@ -59,8 +61,8 @@ and filing tickets for the Foundations Team as needed.
 
 - Ensure you have found a _Trusted Reproducer_ and write who this is
   in the [[contribute/calendar]].
-- Create a Foundations Team ticket about upgrading Tor Browser
-  in the release your shift is about.
+- Create an issue with the `Core Work: Foundations Team` label,
+  about upgrading Tor Browser in the release your shift is about.
 - Check if you have enough manual testers registered.
   If not, ping the usual testers.
 

wiki/src/contribute/working_together/roles/sysadmins/automated_tests_in_Jenkins.mdwn

@@ -91,7 +91,7 @@ use the ISO being tested instead of the last released one:
    ISO being tested (instead of the last released one) to
    `run_test_suite`'s `--old-iso` argument.
 
-2. File a ticket to ensure this temporarily change gets reverted
+2. File an issue to ensure this temporarily change gets reverted
    in due time.
 
 ## Restarting slave VMs between test suite jobs

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

@@ -24,6 +24,6 @@
 - This does not cover the UX work related to deliverables for
   grants which have a dedicated budget.
 
-- Handle new Redmine tickets that are about feature requests and the
+- Handle new GitLab issues that are about feature requests and the
   scope of Tails. Reassign to whoever is on Help Desk duty any new
-  ticket that's really a support request.
+  issue that's really a support request.

wiki/src/support/known_issues/graphics.mdwn

@@ -92,7 +92,7 @@ $FAMILY_NAME
 ------------
 
 $LT!--
-Tickets: #XXXXX #XXXXX
+Issues: #XXXXX #XXXXX
 --$GT
 
 ### Affected graphics cards
@@ -114,7 +114,7 @@ AMD Radeon HD
 -------------
 
 <!--
-Tickets: #11095 #12482
+Issues: #11095 #12482
 -->
 
 ### Affected graphics cards
@@ -149,7 +149,7 @@ AMD Radeon R9
 -------------
 
 <!--
-Tickets: #12218 #11850
+Issues: #12218 #11850
 -->
 
 ### Affected graphics cards
@@ -171,8 +171,8 @@ Intel
 -----
 
 <!--
-Ticket: #12219
-Ticket: #16224
+Issue: #12219
+Issue: #16224
 -->
 
 ### Affected graphics cards
@@ -207,7 +207,7 @@ Intel 855GM
 -----------
 
 <!--
-Ticket: #11096, Debian #776911
+Issue: #11096, Debian #776911
 
 -->
 
@@ -224,7 +224,7 @@ Nvidia NV50 family (Tesla)
 --------------------------
 
 <!--
-Ticket: #15491
+Issue: #15491
 -->
 
 ### Affected graphics cards
@@ -317,7 +317,7 @@ Nvidia NV110 family (Maxwell)
 -----------------------------
 
 <!--
-Ticket: #15116
+Issue: #15116
 -->
 
 ### Affected graphics cards
@@ -389,7 +389,7 @@ Nvidia NV130 family (Pascal)
 ----------------------------
 
 <!--
-Ticket: #15116
+Issue: #15116
 -->
 
 <!--
@@ -530,7 +530,7 @@ There are several possible workarounds for this issue:
 
          sudo passwd
 
-For more details, see our ticket on [[!tails_ticket 7505 desc="Video is broken with switchable graphics"]].
+For more details, see our issue on [[!tails_ticket 7505 desc="Video is broken with switchable graphics"]].
 
 <a id=sg-segfault></a>
 
@@ -554,7 +554,7 @@ Intel GM965/GL960
 -----------------
 
 <!--
-Ticket: #12217, Linux #187001
+Issue: #12217, Linux #187001
 -->
 
 ### Affected graphics cards