Align contribution process document

The contribution process document has some out of date sections, tweak
these to make it aligned to current expectations:

- Secure Boot document is now not a design document but an architectural
  document. Remove the reference as it's no longer helpful. Point to
  Concepts section instead.
- Designs is a section that's being removed. Point to Architecture and
  Guides for current implementations.
- We no longer tag releases manually, remove that as example of manual
  process.
- There's much less need for OBS accounts make this clearer.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/policies/contribution_process.md

@@ -240,15 +240,18 @@ either to the packages upstream or Debian. More guidance is provided in the
 
 Another way to contribute to Apertis is with design documents. A design
 document contains the description of all relevant aspects of a feature or of a
-requirement. As an example of a design document the
-[Apertis secure boot]( {{< ref "secure-boot.md"  >}} )
-describes what secure boot is, how it works, what are the threat models, the
-required infrastructure, and finally the integration with Apertis.
-
-Currently Apertis has [Concept Designs]( {{< ref "concepts" >}} ) that are
-documents covering topics that have been researched but not necessarily
-implemented, and [Designs]( {{< ref "designs"  >}}  ) which reflects what is
-currently implemented.
+requirement. The current design documents can be found in the [Concepts Designs
+section]( {{< ref "concepts" >}} ). These documents cover topics that have been
+researched but not necessarily implemented. They should provide a good
+understanding of the impact of the technology that forms the basis of the
+concept, what it is, how it works, what are the threat models, the required
+infrastructure, how it would be integrated with Apertis and anything else that
+is deemed relevant.
+
+Such designs should be updated when implemented to explictly cover the final
+implementation and moved to a suitable section of the site, typically the
+[Architecture]( {{< ref "architecture" >}} ) or [Guides]( {{< ref "guides" >}}
+) section.
 
 Project-wide impact is the metric used to decide if a contribution will be
 handled as a component or as a design. If the impact of the contribution on the
@@ -435,11 +438,9 @@ git commit -i -s
 
 ## Extra Actions
 
-* If other actions need to be manually taken when commits are landed (for
-  instance,
-  [triggering the `tag-release` pipeline](https://gitlab.apertis.org/infrastructure/ci-package-builder#landing-downstream-changes-to-the-main-archive))
+* If other actions need to be manually taken when commits are landed
   the developer accepting and merging the changes is responsible for ensuring
-  that those actions are taken, either by doing them themselves or by asking
+  that those actions are taken, either by doing it themselves or by asking
   someone else to do that.
 * If the merged commits need to be backported to other branches through
   cherry-pick or merges, those should go through merge requests as well:
@@ -485,14 +486,15 @@ described in section 11 of the
 
 Pushing commits to gitlab.apertis.org requires commit rights which are only
 granted to trusted contributors (see
-"[Getting commit rights]( {{< ref "#getting-commit-rights" >}} )" for how to get
--commit rights). All commits must have a
-[`Signed-off-by` line]( {{< ref "#sign-offs" >}} ) assigning responsibility for their open
-source licensing.
-
-Packaging up and releasing new versions of Apertis modules as Debian packages
-requires packaging rights on build.collabora.co.uk (OBS), which are issued
-separately from commit rights.
+"[Getting commit rights]( {{< ref "#getting-commit-rights" >}} )" for how to
+get commit rights). All commits must have a
+[`Signed-off-by` line]( {{< ref "#sign-offs" >}} ) assigning responsibility for
+their open source licensing.
+
+Some admin steps on the periphery of packaging and releasing new versions of
+Apertis modules as Debian packages may require access to build.collabora.co.uk
+(OBS). These are issued separately from commit rights, and are generally not
+needed for the main development workflows.
 
 Submitting automated test runs on lava.collabora.co.uk requires CI rights,
 which are granted similarly to packaging rights. However, CI results may be