[llvm] [Docs] Update Maintainer in Developer Policy (PR #154687)

[Jacques Pienaar via llvm-commits]

================
@@ -143,54 +143,76 @@ to take on additional community responsibilities beyond code contributions.
 Community members can find active and inactive maintainers for a project in the
 ``Maintainers.rst`` file at the root directory of the individual project.
 
-Maintainers are volunteering to take on the following shared responsibilities
-within an area of a project:
-
-* ensure that commits receive high-quality review, either by the maintainer
-  or by someone else,
-* help to confirm and comment on issues,
-* mediate code review disagreements through collaboration with other
-  maintainers (and other reviewers) to come to a consensus on how best to
-  proceed with disputed changes,
-* actively engage with relevant RFCs,
-* aid release managers with backporting and other release-related
-  activities,
-* be a point of contact for contributors who need help (answering questions
-  on Discord/Discourse or holding office hours).
+Maintainers are volunteering to take on shared responsibilities
+within an area of a project, not to exert power through that status.
+Actions and opinions of maintainers have equal weight to those of other contributors.
+Conflicts are resolved by the area teams (defined in `LP0004
+<https://github.com/llvm/llvm-www/blob/main/proposals/LP0004-project-governance.md>`_).
+
+The main responsibilities of a maintainer are to:
+* **Code Review**: ensure that commits receive high-quality review, either by the
+maintainer or by someone else,
+* **RFC Engagement**: actively engage with relevant RFCs, provide feedback, and
+help drive discussions to conclusion,
+* **Mediation**: mediate code review and RFC disagreements through collaboration
+with other maintainers (and other reviewers) to come to a consensus on how best
+to proceed with disputed changes, by finding a common ground,
+* **Triage**: help to confirm and comment on issues, aid release managers with
+backporting and other release-related activities,
+* **Point of Contact**: be a contact for contributors who need help (answering questions
+on Discord/Discourse or holding office hours),
+* **Behaviour**: ensuring that they, and the community members they interact with,
+abide by the :ref:`LLVM Community Code of Conduct`.
 
 Each top-level project in the monorepo will specify one or more
-lead maintainers who are responsible for ensuring community needs are
-met for that project. This role is like any other maintainer role,
-except the responsibilities span the project rather than a limited area
-within the project. If you cannot reach a maintainer or don't know which
-maintainer to reach out to, a lead maintainer is always a good choice
-to reach out to. If a project has no active lead maintainers, it may be a
+**lead maintainers** who are responsible for ensuring community needs are
+met for that project.
+
+This role is like any other maintainer role, except the responsibilities
+span the project rather than a limited area within the project.
+The hierarchy creates clear points of contact for contributors, where local
+maintainers should be contacted first.
+If you cannot reach a maintainer or don't know which
+maintainer to reach out to, a lead maintainer is always a good choice.
+
+Lead maintainers do not have additional privileges over other maintainers,
+for example overruling another maintainer's decision if consensus has been reached.
+They also don't need to know _everything_ that happens in the project.
----------------
jpienaar wrote:

But along with the above, I believe this means they have to be comfortable with much of the it (reviews, debugging, design discussions) then. I think here it is about having the general ability to operate over large parts of the project, especially ones not covered. That is, I don't see good motivation for having a lead maintainer cover only what is already fully covered by component, they have to be filling the gaps too. Especially as not hierarchy, there is no level difference between component and lead maintainer. So someone that only cares about a component should focus on the component else it gives a false sense of coverage to have N lead maintainers where only M are working between the already covered bits.

https://github.com/llvm/llvm-project/pull/154687