docs(GOVERNANCE.md): Replace the Peter Keller's private (PR) (#869)

* docs(GOVERNANCE.md): Content just copied from Peter Keller private repo

* fix: formating

* fix: Review finding

* fix: format

Author: aiAdrian

GOVERNANCE.md

@@ -1,42 +1,90 @@
 # Governance Policy
 
-This document provides the governance policy for the Project.
-Maintainers agree to this policy and to abide by all Project policies, including the [code of conduct](./CODE_OF_CONDUCT.md) by adding their name to the [`MAINTAINERS.md` file](./MAINTAINERS.md).
+This document provides the governance policy for the Project. Maintainers and Business Domain Stewards agree to this policy and to abide by all Project policies, including the [code of conduct](./CODE_OF_CONDUCT.md) by adding their name to the [`MAINTAINERS.md` file](./MAINTAINERS.md).
 
-## 1. Roles.
+## 1. Principles
 
-This project may include the following roles. Additional roles may be adopted and documented by the Project.
+The project operates according to established open source principles and values.
 
-**1.1. Maintainers**. Maintainers are responsible for organizing activities around developing, maintaining, and updating the Project. Maintainers are also responsible for determining consensus. This Project may add or remove Maintainers with the approval of the current Maintainers.
+- **Equal Access** - The project is run in a way that provides equal access to all contributors. Decisions are made based on the merit of a contribution and its alignment with the goals of the project, not on the status or affiliation of contributors.
+- **Transparency** - The project operates transparently in both development and decision-making. Planning takes place in public so that stakeholders understand the project direction, and roadmaps are openly available.
+- **Cooperation** - The project enables contributors to work towards a shared direction while supporting different sub-goals, motivations, and working styles. Coordination is designed to be as lightweight as possible, enabling asynchronous work, reducing coordination overhead, and encouraging individuals to take local responsibility.
+- **Clear Contributor Path** - There is a clear path to becoming a Committer or Maintainer. Not everyone will necessarily be appointed, but the process and criteria are transparent.
+- **Shared Ownership** - No contributing party holds exclusive rights over any part of the project through trademarks or other mechanisms. Ownership is shared among contributors.
+- **Effective decisions** - The project follows a policy of lazy consensus, allowing most decisions to be made without formal voting.
 
-**1.2. Contributors**. Contributors are those that have made contributions to the Project.
+## 2. Roles
 
-## 2. Decisions.
+### 2.1 Community
 
-**2.1. Consensus-Based Decision Making**. Projects make decisions through consensus of the Maintainers. While explicit agreement of all Maintainers is preferred, it is not required for consensus. Rather, the Maintainers will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Contributors and nature of support and objections. The Maintainers will document evidence of consensus in accordance with these requirements.
+The community consists of users, contributors, committers, maintainers, and business domain stewards. Open source projects thrive when supported by an active community. Anyone in the community may support the project and contribute to community building.
 
-**2.2. Appeal Process**. Decisions may be appealed by opening an issue and that appeal will be considered by the Maintainers in good faith, who will respond in writing within a reasonable time. If the Maintainers deny the appeal, the appeal may be brought before the Technical Committee, who will also respond in writing in a reasonable time.
+### 2.2 User
 
-## 3. How We Work.
+Users have a need for the project. They are essential to the project’s purpose and they are the business domain experts. There are no requirements or restrictions for using the Netzgrafik-Editor. As open source software, its license grants anyone the right to use it for any purpose.
 
-**3.1. Openness**. Participation is open to anyone who is directly and materially affected by the activity in question. There shall be no undue financial barriers to participation.
+The project encourages users to participate in the community as much as possible. Users are invited to get engaged with the project by:
 
-**3.2. Balance**. The development process should balance the interests of Contributors and other stakeholders. Contributors from diverse interest categories shall be sought with the objective of achieving balance.
+- promoting the project (e.g. linking from websites or raising awareness by word of mouth)
+- informing developers about strengths and weaknesses from a user perspective
+- providing community support
+- users may become Contributors
 
-**3.3. Coordination and Harmonization**. Good faith efforts shall be made to resolve potential conflicts or incompatibility between releases in this Project.
+### 2.3 Participants
 
-**3.4. Consideration of Views and Objections**. Prompt consideration shall be given to the written views and objections of all Contributors.
+Participants form a broad group, ranging from users contributing documentation and requirements to engineers contributing to the platform’s codebase, infrastructure, and architecture. Participants may act on behalf of an organisation or independently. Participants may create issues, comment on issues.
 
-**3.5. Written procedures**. This governance document and other materials documenting this project's development process shall be available to any interested person.
+### 2.3.1 Contributors
 
-## 4. No Confidentiality.
+Contributors provide any material that becomes part of the project, including code, documentation, or other content integrated into the code base. They do not have direct write access to the main repository. Instead, they may submit pull requests or work through a fork of the repository.
+
+### 2.3.2 Committer
+
+Committers are trusted contributors with recognised expertise in their domain and in the project’s infrastructure. They have permission to modify source code or documentation and may commit directly to the main repository. However, they are not allowed to merge changes without an approved pull request. All modifications must pass the review process under the four‑eye principle.
+A Contributor may be nominated for Committer status by an existing Committer. Appointment requires confirmation by a Maintainer.
+
+### 2.4 Maintainer
+
+Maintainers are responsible for the quality, technical direction, and governance of the project. They actively contribute to development, manage contributions, and ensure overall quality and alignment with the project vision. A Committer may be nominated for Maintainer status by existing Maintainers. Appointment must be confirmed by the Project Steering Committee (PSC).
+
+### 2.5 Business Domain Steward
+
+The business domain stewards are responsible to bring the expertise of the real-world business into the open source project. They understand the value the software provides, how it is used in practice, and which needs matter most to users. They guide feature prioritisation based on business relevance, refine requirements, validate releases from a business perspective, and contribute to documentation, training, and enablement. Business Domain Stewards are accountable for artefacts directed at users. New Business Domain Stewards are appointed by existing Stewards and confirmed by the PSC.
+
+### 2.6 Project Steering Commitee (PSC)
+
+The PSC addresses strategic directions and makes decisions as a collegial body. It develops a long-term vision, defines roadmaps and milestones, offers guidance, mediates differing views, and supports effective implementation.
+
+The PSC consists of Maintainers and Business Domain Stewards and includes between three and seven members. It appoints new members from the group of maintainers and business domain stewards. The PSC strives to make decisions by consensus. If consensus cannot be reached, decisions are made by vote, with each member holding one vote. In the event of a tie, the longest-serving PSC member casts the deciding vote.
+
+### 2.7 Technical Committee (TC) of the OpenRail Association
+
+The Technical Committee (TC) provides guidance to help the project achieve its objectives. It ensures the project adheres to open governance principles and the goals and values of the association. The TC may support governance implementation and mediate conflicts when required.
+
+## 3. Decisions
+
+### 3.1. Lazy Consensus-Based Decision Making
+
+The project makes most decisions through lazy consensus among the Maintainers. Consensus is determined in good faith, taking into account the dominant view of contributors and the nature of support and objections. Evidence of consensus should be documented.
+
+### 3.2. Appeal Process
+
+Decisions may be appealed by opening an issue. Maintainers will review the appeal in good faith and respond in writing within a reasonable time.
+If the appeal is rejected, it may be escalated to the PSC, which will also respond in writing. If a decision contradicts the stated principles or is deemed to endanger the project, the TC may be asked to provide mediation.
+
+## 4. No Confidentiality
 
 Information disclosed in connection with any Project activity, including but not limited to meetings, contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary.
 
-## 5. Amendments.
+## 5. Amendments
 
-Amendments to this governance policy may be made by affirmative vote of 2/3 of all Maintainers, with approval by the Technical Committee.
+Major changes to this governance policy require a decision by the Project Steering Committee (PSC).
 
 ---
 
-Based on [GitHub's Minimum Viable Governance (MVG)](https://github.com/github/MVG). Licensed under the [CC-BY 4.0 License](https://creativecommons.org/licenses/by/4.0/).
+Based on inputs from:
+
+- [GitHub's Minimum Viable Governance (MVG)](https://github.com/github/MVG)
+- [Kopia Governance](https://github.com/kopia/kopia/blob/master/GOVERNANCE.md?plain=1)
+
+Licensed under the [CC-BY 4.0 License](https://creativecommons.org/licenses/by/4.0/).