docs: add a governance document to the spec

On-behalf-of: Gergely Brautigam <gergely.brautigam@sap.com>

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

Author: Skarlso

.github/config/wordlist.txt

@@ -136,3 +136,9 @@ wget
 whitespace
 whitespaces
 yaml
+SIG
+SIGs
+TSC
+ANSI's
+Pre
+LF

GOVERNANCE.md

@@ -0,0 +1,63 @@
+# OCM Community Governance Policy
+
+Based on the [Community Specification Governance Policy 1.0](https://github.com/CommunitySpecification/Community_Specification/blob/main/5._Governance.md).
+
+This document provides the governance policy for the Open Component Model project and its Working Groups, including Special Interest Groups (SIGs). All participants must adhere to the requirements in this document.
+
+For governance specific to the Technical Steering Committee (TSC), see [TSC Governance](https://github.com/open-component-model/open-component-model/blob/main/docs/steering/GOVERNANCE.md).
+
+## 1. Roles
+
+Roles are defined in the following documents:
+
+- **TSC roles** (Chair, Voting Members, Code Owners, Contributors): [Project Charter, Section 2](https://github.com/open-component-model/open-component-model/blob/main/docs/steering/CHARTER.md)
+- **SIG roles** (Chair, Tech Lead, Voting Members, Maintainers, Contributors): [SIG Handbook](https://github.com/open-component-model/open-component-model/blob/main/docs/community/SIGs/SIG-Handbook.md)
+- **SIG Runtime roles**: [SIG Runtime Charter - Roles](https://github.com/open-component-model/open-component-model/blob/main/docs/community/SIGs/Runtime/SIG-Runtime-CHARTER.md#roles)
+
+Each Working Group may adopt additional roles so long as they are documented publicly.
+
+## 2. Decision Making
+
+**2.1. Consensus-Based Decision Making.** Working Groups make decisions through a consensus process ("Approval" or "Approved"). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the Maintainer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and the nature of support and objections. The Maintainer will document evidence of consensus in accordance with these requirements.
+
+**2.2. Appeal Process.** Decisions may be appealed via a pull request or an issue, and that appeal will be considered by the Maintainer in good faith, who will respond in writing within a reasonable time. If the appeal cannot be resolved within the Working Group, it may be escalated to the TSC.
+
+## 3. Ways of Working
+
+Inspired by [ANSI's Essential Requirements for Due Process](https://share.ansi.org/Shared%20Documents/Standards%20Activities/American%20National%20Standards/Procedures,%20Guides,%20and%20Forms/2020_ANSI_Essential_Requirements.pdf), OCM Working Groups must adhere to consensus-based due process requirements. Due process means that any person with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal.
+
+**3.1. Openness.** Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements.
+
+**3.2. Lack of Dominance.** The development process shall not be dominated by any single interest category, individual, or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.
+
+**3.3. Balance.** The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance.
+
+**3.4. Coordination and Harmonization.** Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.
+
+**3.5. Consideration of Views and Objections.** Prompt consideration shall be given to the written views and objections of all Participants.
+
+**3.6. Written Procedures.** This governance document and other materials documenting the development process shall be available to any interested person.
+
+## 4. Specification Development Process
+
+**4.1. Pre-Draft.** Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a "Pre-Draft" document.
+
+**4.2. Draft.** Each Pre-Draft document of a Working Group must first be Approved to become a "Draft Specification". Once the Working Group approves a document as a Draft Specification, it becomes the basis for all going forward work on that specification.
+
+**4.3. Working Group Approval.** Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will Approve that Draft Specification and progress it to "Approved Specification" status.
+
+**4.4. Publication and Submission.** Upon the designation of a Draft Specification as an Approved Specification, the Maintainer will publish the Approved Specification in a manner agreed upon by the Working Group Participants. The publication of an Approved Specification in a publicly accessible manner must include the terms under which it is being made available.
+
+**4.5. Submissions to Standards Bodies.** No Draft Specification or Approved Specification may be submitted to another standards development organization without Working Group Approval. Upon reaching Approval, the Maintainer will coordinate the submission. Working Group Participants that developed that specification agree to grant the copyright rights necessary to make those submissions.
+
+## 5. Non-Confidential, Restricted Disclosure
+
+Information disclosed in connection with any Working Group activity, including but not limited to meetings, Contributions, and submissions, is not confidential, regardless of any markings or statements to the contrary. Notwithstanding the foregoing, if the Working Group is collaborating via a private repository, the Participants will not make any public disclosures of that information contained in that private repository without the Approval of the Working Group.
+
+## 6. Code of Conduct
+
+All participants are subject to the [NeoNephos Code of Conduct](https://github.com/open-component-model/.github/blob/main/CODE_OF_CONDUCT.md).
+
+## 7. Amendments
+
+This governance document may be amended by a two-thirds vote of the TSC and is subject to approval by LF Europe.