doc: document the approval process in this repositroy (#144)

<!-- markdownlint-disable MD041 -->
#### What this PR does / why we need it

Because of the new license it might not be immediately clear how the
approval process works for maintainers. I'm adding a MAINTAINERS.md file
to clarify that process and why it's needed and which sections of the
license are relecant for it.

#### Which issue(s) this PR is related to
<!--
Usage: `Related to #<issue number>`, or `Related to (paste link of
issue)`.
-->

Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>

Author: Skarlso

.github/config/wordlist.txt

@@ -154,3 +154,4 @@ enablement
 stichting
 collegial
 Hyperledger
+dco

MAINTAINERS.md

@@ -0,0 +1,12 @@
+# Maintainers
+
+## Approving spec changes
+
+This repository follows the [Community Specification License 1.0](./1._Community_Specification_License-v1.md) and its [Governance Policy](./5._Governance.md).
+Two things are required to merge a spec change:
+
+1. **Proof of contribution rights (DCO).** Every commit must be signed off (`Signed-off-by:`), per the [Contributor License Agreement / Section (d) under "In addition"](./.0_CS_Contributor_License_Agreement.md). This is enforced automatically by the DCO check.
+2. **Recorded maintainer consensus.** Per [Governance §2.1](./5._Governance.md#2-decision-making), Maintainers determine consensus in good faith and document it. A maintainer review, approval, and merge is that documented evidence.
+
+Consensus is a good-faith judgment, **not** a numeric vote threshold. There is no required percentage and no voting tool
+to run. For specification status transitions (Pre-Draft, Draft, Approved) see [Governance §4](./5._Governance.md#4-specification-development-process).