GitLab

In passing, give ourselves another tool for ticket gardening: the
`missed:$VERSION` label. This will help us:

 - understand how we're using milestones at the moment;
   then, possibly decide we want to change that;

 - identify issues/MRs that have been postponed mechanically
   by the RM for a while, as opposed to being rescheduled
   by the responsible people.

We're using group milestones, not project milestones.

In passing, this commit starts making the submit/review/merge doc less focused
on code changes. This needs more work.

The "Assignee" section now sets up a workflow that attacks the over-commitment,
cookie-licking, and unclear-ETA problems at the root. In this workflow, issues
being left unassigned becomes the norm, rather than a problem to solve.

So I'm rephrasing the "Report progress or failure" section in a way that builds
upon this, and refers to it, while it was previously (implicitly) phrased in
a context when we would assign as many issues as we could, ahead of time.

It will always match the version of GitLab we're using,
as opposed to whatever is published on docs.gitlab.com.

I believe it's consensual in Tails these days, and has been for years, that "to
be reviewed and get more exposure" is not a strong enough reason to push changes
that break the build of our devel branch. In particular, since this exception
was written, we got ourselves a much simpler and reliable way to build
Tails locally (using Vagrant), and a CI system.

Technical writing is a trade of its own, that requires a set of skills
that most developers have not developed.

We point to this page for all sorts of contributions,
not only "code" contributions.

A branch forked off a tag will not build.

I realized only today that the implementation does not match the specs. It's too
late to figure out if there's a good reason for this or if that was a mistake.

What's implemented is good enough, so I'm adjusting the code to match it.

This list was primarily built while working on
https://salsa.debian.org/tails-team/gitlab-migration/issues/30,
which was a good opportunity to identify repositories
that we link to.

If we don't migrate them all, we'll need to special-case the non-migrated ones
in tails.git as they're linked to via the tails_gitweb* ikiwiki shortcuts.
Doing that work would likely take more time than migrating the repos,
so let's do it.

In passing, I'm removing a few obsolete ones.

In passing, remove a few unused ones.