Clean up some word usage in release-process docs (#7291)

Say "labelling" instead of "tagging"

dev-notes/release-process.md

@@ -20,15 +20,15 @@ Before the major version, we publish "testing releases":
 ## edgedb-ui
 
 On release branches, `edgedb-ui` should be pinned to the associated branch.
-This can be done using `setup.py` with the variable `EDGEDBGUI_COMMIT`.
+This can be done in `setup.py` with the variable `EDGEDBGUI_COMMIT`.
 For example, on branch `release/4.x`, it is pinned to `edgedb-ui`'s branch `4.x`.
 This means any release off `release/4.x` will contain latest commits from
 `edgedb-ui`'s branch `4.x`.
 
 ## Preparing commits for a release
 
-For each major release `N`, we have two labels: `to-backport-N.x` and
-`backported-N.x`. PRs that need to be backported should be tagged with
+For each major release `N`, we have two GitHub labels: `to-backport-N.x` and
+`backported-N.x`. PRs that need to be backported should be labelled with
 `to-backport-N.x` for each of the target versions.
 
 Once a PR is backported, `to-backport-N.x` should be removed and
@@ -38,10 +38,10 @@ Tracking both states makes it easy to tell what needs to be backported
 and what has been backported.
 
 (Historical note: previously we had simply a `backport-N.x` label.
-This made it easy to ensure that everything that got tagged with
+This made it easy to ensure that everything that got labelled with
 `backport` actually got backported, but there was not an at-a-glance
 way to see if something *had* been backported. Even looking at the
-issue didn't always tell you, since sometimes we tagged things as
+issue didn't always tell you, since sometimes we labelled things as
 `backport` and then thought better of it.)
 
 ### Technical helpers
@@ -69,7 +69,7 @@ function cp-pr {
 
 
 ### What to backport?
-Sometimes, people will forget to tag the PR to be back-ported, so a good
+Sometimes, people will forget to label the PR to be back-ported, so a good
 practice is to list all commits since the last release:
 
 ```