Merge bitcoin/bitcoin#25078: doc: Shorten explanation of "maintainers"

fa32ced49cf651b48e0a9cc165e45a27505a461f doc: Shorten explanation of "maintainers" (MacroFake)

Pull request description:

  GitHub has an extensive documentation about permissions ( https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role ), so I don't think we should be trying to mirror them here.

  Specifically, this pull makes three changes:

  * Clarify that all "merge maintainers" can merge pull requests. Obviously, while GitHub users with the `Maintain` permission can not force push to protected branches, and GitHub users with the `Admin` permission can, I don't think this is worthy to mention in the contribution guidelines. During the whole time I was working on the project, I think this permission was only used once or twice, when I accidentally pushed an unsigned draft commit directly to `master`. See https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2016-06-13#473584 . One could argue that there should be a list of maintainers in the doc. Though, as there is already a list of keys for verify-commits, this seems like unnecessary overhead.
  * Clarify that the release process is executed collectively by the developers. For example, release process code changes that are reproducible can be done by anyone without permission. Also, detached signatures are created by several people (see for example https://github.com/bitcoin-core/bitcoin-detached-sigs/commits/23.0), which (I believe) are also separate from the people that can push the binaries to the `bin` folder, which again are separate from the people who can release the snap/flatpak package.
  * Clarify that moderation is also done collectively by people with `Triage`, `Write`, `Maintain`, and `Admin` permission. I think it is fine to refer to everyone in that group as "maintainers", or at least don't clarify it further, as any attempt at that would start to duplicate GitHub docs.

ACKs for top commit:
  laanwj:
    ACK fa32ced49cf651b48e0a9cc165e45a27505a461f
  prusnak:
    Approach ACK fa32ced49cf651b48e0a9cc165e45a27505a461f
  fanquake:
    ACK fa32ced49cf651b48e0a9cc165e45a27505a461f

Tree-SHA512: ed87c2e538a32ff1611208a7262425160a4340a3112a1b2712d7e9a550fa191ddbebea0d8e45d3e578ead02d5ef17bddcaab3f6ee876f9018a5acbc65ffd0e1c

1 files changed, 4 insertions, 5 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ba78a20ae3..aec6995d3b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -10,10 +10,9 @@ First, in terms of structure, there is no particular concept of "Bitcoin Core
 developers" in the sense of privileged people. Open source often naturally
 revolves around a meritocracy where contributors earn trust from the developer
 community over time. Nevertheless, some hierarchy is necessary for practical
-purposes. As such, there are repository "maintainers" who are responsible for
-merging pull requests, as well as a "lead maintainer" who is responsible for the
-[release cycle](/doc/release-process.md) as well as overall merging, moderation
-and appointment of maintainers.
+purposes. As such, there are repository maintainers who are responsible for
+merging pull requests, the [release cycle](/doc/release-process.md), and
+moderation.
 
 Getting Started
 ---------------
@@ -293,7 +292,7 @@ projects such as libsecp256k1), and is not to be confused with overall Bitcoin
 Network Protocol consensus changes.
 
 Whether a pull request is merged into Bitcoin Core rests with the project merge
-maintainers and ultimately the project lead.
+maintainers.
 
 Maintainers will take into consideration if a patch is in line with the general
 principles of the project; meets the minimum standards for inclusion; and will