Draft for governance model

GOVERNANCE.md

@@ -0,0 +1,41 @@
+# Score Goveranance
+
+This document defines the governance framework for the Score project, encompassing all repositories within the https://github.com/score-spec organization.
+
+All project participants must adhere to our [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+## Maintainers
+
+Maintainers of Score have write access to the project GitHub repositories, allowing them to merge their own contributions and those from others. A list of current maintainers is available in the [MAINTAINERS](./MAINTAINERS.md) file. Collectively, maintainers oversee the project's resources and contributors.
+
+Being a maintainer is a privilege accompanied by responsibilities. Maintainers are expected to demonstrate a strong commitment to the project, collaborate effectively, seek comprehensive reviews for code and documentation, contribute high-quality code, and resolve issues diligently.
+
+## Becoming a Maintainer
+
+To be considered for a maintainer role, a contributor must demonstrate the following:
+
+- Commitment to the project through active participation in discussions, contributions, and reviews for at least six months.
+- Conducting reviews for at least 20 non-trivial pull requests.
+- Contributing and successfully merging at least 20 non-trivial pull requests.
+- The ability to write quality code and/or documentation.
+- Effective collaboration with the team.
+- A solid understanding of team workflows, including policies, testing processes, and code review procedures.
+- Familiarity with the project's codebase and coding and documentation standards.
+
+A new maintainer must be proposed by an existing maintainer and approved through a simple majority vote by the current maintainers.
+
+## Removing a Maintainer
+
+Maintainers may resign at their discretion if they are unable to continue fulfilling their responsibilities.
+
+A maintainer may also be removed due to inactivity, failure to meet responsibilities, violation of the [Code of Conduct](./CODE_OF_CONDUCT.md), or other significant reasons. Inactivity is defined as minimal or no participation in the project for over a year without a planned return to active status.
+
+## Meetings
+
+Where feasible, maintainers are expected to attend public developer meetings and community calls.
+
+Closed meetings will be held to address security issues or Code of Conduct violations. Any maintainer can schedule such a meeting upon receipt of a relevant report. All current maintainers, except those implicated in a Code of Conduct violation, must be invited to these closed meetings.
+
+## Voting
+
+While the majority of project decisions are made through "lazy consensus," there may be instances where maintainers need to vote on specific actions or changes. Votes can be conducted during developer meetings, and any maintainer has the right to request a formal vote.