docs(governance): add conflict resolution process

Governance/processes/CONFLICT_RESOLUTION.md

@@ -0,0 +1,162 @@
+# Conflict-Resolution Process
+
+| Field | Value |
+| --- | --- |
+| Status | Active |
+| Version | 1.0.0 |
+| Last Updated | 2026-09-28 |
+| Applies to | Contributors, maintainers, and project participants |
+| Related | [`COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md), [`OBJECTION_HANDLING.md`](OBJECTION_HANDLING.md), [`CHARTER.md`](../CHARTER.md) |
+
+## Purpose
+
+This process provides a fair, transparent, and consistent way to resolve
+disagreements before they harm collaboration, delay project work, or undermine
+trust. It gives contributors and maintainers a clear path to raise concerns,
+be heard, and reach a proportionate resolution while preserving the project's
+respectful, constructive, and professional standards.
+
+## Scope
+
+This process covers interpersonal or working disagreements involving project
+participants, including disagreements about contribution or review practices,
+project-process expectations, communication, collaboration, and maintainer or
+working-group decisions. It may also be used when a disagreement has moved
+beyond ordinary discussion on an issue, pull request, or governance thread.
+
+It does not replace the normal pull-request review flow, the objection-handling
+process for a proposed governance decision, security reporting, or urgent
+incident response. Use the applicable existing process first where it governs
+the matter; this process provides support when the disagreement itself remains
+unresolved. Conduct concerns may require a private maintainer response under
+[`COMMUNICATION_NORMS.md`](../policies/COMMUNICATION_NORMS.md).
+
+## Guiding Principles
+
+- **Respectful communication.** Discuss conduct, work, and evidence without
+  personal attacks, dismissiveness, or discriminatory language.
+- **Good-faith participation.** Participants should seek understanding and a
+  workable resolution, rather than assume improper intent.
+- **Transparency.** Project-related reasoning and outcomes should be visible
+  in the appropriate repository record unless confidentiality is needed.
+- **Neutrality.** Facilitation and decisions must be free from actual or
+  perceived conflicts of interest where possible.
+- **Project and community interests.** Resolutions should advance the health,
+  safety, and sustainable operation of the project and its community.
+- **Protection from harm.** No participant may be retaliated against for
+  raising a concern in good faith or participating in this process.
+
+## Resolution Steps
+
+1. **Direct discussion.** The involved parties should first discuss the
+   disagreement respectfully in the relevant issue, pull request, or other
+   appropriate project forum. They should state their concerns, evidence, and
+   the outcome they seek. A participant may skip this step when direct contact
+   would be unsafe, inappropriate, or unlikely to be productive.
+2. **Written clarification.** If direct discussion does not resolve the matter,
+   either party documents a concise, factual summary: the issue, relevant
+   context, points of agreement and disagreement, and proposed resolution.
+   Use the existing public record where suitable; use a private maintainer
+   route for sensitive information.
+3. **Neutral facilitation.** Either party may ask an uninvolved maintainer or
+   other suitable neutral project participant to facilitate. The facilitator
+   helps the parties clarify facts, communicate constructively, and identify
+   options; they do not decide the outcome at this stage.
+4. **Maintainer or community review.** If facilitation does not resolve the
+   matter, it moves to maintainers for review. Where the matter falls within a
+   working group's authority, maintainers may seek that group's input. A
+   disagreement about a proposal or governance decision follows
+   [`OBJECTION_HANDLING.md`](OBJECTION_HANDLING.md) and, when required, the
+   formal voting process.
+5. **Final decision.** If maintainers cannot reach consensus, the Lead
+   Maintainer uses the deciding role described in the
+   [`CHARTER.md`](../CHARTER.md). The final decision should state its basis,
+   any actions, and how it will be recorded or communicated.
+
+## Neutral Facilitator
+
+A neutral facilitator is an uninvolved person trusted to help the parties have
+a productive conversation. The facilitator:
+
+- keeps discussion focused on the stated disagreement, evidence, and possible
+  resolution;
+- gives each party a reasonable opportunity to be heard and checks that their
+  views are understood accurately;
+- sets respectful communication expectations and may pause or redirect an
+  unproductive discussion; and
+- identifies common ground, clarifying questions, and next steps without
+  favoring a party or preferred result.
+
+The facilitator must remain impartial. They must not investigate privately,
+make findings of misconduct, impose a decision, advocate for either party, or
+share sensitive information beyond those who need it to resolve the matter.
+
+Before accepting the role, a facilitator must disclose any conflict of interest
+that could reasonably call their neutrality into question. A facilitator with a
+material conflict, including direct involvement in the disagreement, must step
+aside. The parties may request another facilitator; if none is available, the
+matter proceeds directly to maintainer review with conflicted decision-makers
+recused where practical.
+
+## Escalation Path
+
+Either involved party may move the matter to the next step when a reasonable,
+good-faith attempt at the current step has not resolved it, when the other
+party does not engage, or when the current step is unsafe or inappropriate.
+The written clarification accompanies each escalation so reviewers do not have
+to reconstruct the disagreement from scattered discussion.
+
+Maintainer review is the normal final review level. A matter requiring a
+binding governance decision follows the established objection-handling and
+formal-voting processes. If maintainers cannot settle a matter within their
+authority, it is escalated to the Lead Maintainer under the charter. Participants
+must not use escalation merely to relitigate a resolved matter without material
+new information.
+
+## Documentation and Confidentiality
+
+Document the concern, relevant context and evidence, steps taken, participants
+in any facilitation or review, decisions, reasoning, and follow-up actions.
+For project-process or technical disagreements, the default is a public issue,
+pull request, or governance record, consistent with the communication norms.
+
+Keep documentation private when public disclosure could expose personal,
+sensitive, security-related, or otherwise confidential information, or could
+create a safety risk. Share sensitive information only with people who need it
+to resolve the matter, and do not include secrets, private contact details, or
+unnecessary personal information in the record.
+
+When a decision affects project policy, governance, access, or future
+contributors, maintainers should record an appropriately redacted outcome and
+reasoning publicly. Significant decisions are recorded in
+[`DECISION_LOG.md`](../DECISION_LOG.md) in accordance with that document; the
+public record must not reveal confidential details.
+
+## Outcomes
+
+Possible outcomes include:
+
+- an agreement between the parties, with any commitments recorded;
+- clarification of project expectations, responsibilities, or communication
+  practices;
+- a maintainer decision, including a decision to uphold or change an existing
+  project action;
+- a proposal to clarify or update a process or policy through the normal
+  governance process; or
+- other proportionate project actions consistent with existing governance and
+  communication norms.
+
+## Retaliation and Bad-Faith Behavior
+
+Retaliation, harassment, intimidation, or deliberate misuse of this process is
+not acceptable. This includes punishing a person for raising a concern in good
+faith, attempting to silence participation, knowingly making false claims, or
+using the process to harass another participant. Such behavior may be handled
+by maintainers under the applicable project policies.
+
+## Review and Maintenance
+
+Maintainers own this process and may review and update it as the project
+evolves, particularly when related communication, decision-making, or conduct
+processes change. Amendments follow the normal governance process in
+[`README.md`](../README.md) and take effect when merged.