microcks · yada · Sep 8, 2026 · Sep 8, 2026 · Sep 8, 2026
@@ -17,7 +17,7 @@ The Microcks project has four roles. All project members operate in one (or more
 
 | Level | Role | Responsibilities |
 | :---  | :--- | :--- |
-| 1 | **Maintainer** | Vote, Develop roadmap and contribution guidelines; Review, Approve/Reject, Merge, and Manage repositories. Maintainers are elected or removed by the current maintainers. A Maintainer has authority over the entire Microcks project: the organization and every project, sub-project and repo within the organization.|
+| 1 | **Maintainer** | Participate in governance votes; Develop roadmap and contribution guidelines; Review, Approve/Reject, Merge, and Manage repositories. Maintainers are elected or removed by the current maintainers. A Maintainer has authority over the entire Microcks project: the organization and every project, sub-project and repo within the organization.|
 | 2     | **Code Owner**| Have special expertise in a particular domain within the Microcks project. The domain may be a sub-project, repo or other responsibility as defined by the Maintainers. The maintainers grant a code owner (alias Domain Maintainers) a set of authorities and responsibilities for the domain. Code owners are expected to join maintainer and community meetings when required. A code owner has no responsibilities for the entire project, organization or projects outside their domain. Code owners role, refer to [GitHub CODEOWNERS](https://docs.github.com/fr/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) capabilities.|
 | 3     | **Contributor** | Contribute code, test and document the project. A contributor’s authority applies to one or more sub-projects. Microcks is a very welcoming community and is eager to onboard and help anyone from the open source community to contribute to the project. |
 | 4     | **Adopter** | Use the Microcks project, with or without contributing to the project. Adopters are encouraged to raise issues, provide feedback and participate in discussions on sub-projects within a public forum and community. |
@@ -27,6 +27,35 @@ The Microcks project has four roles. All project members operate in one (or more
 - Adopters (public) list: https://github.com/microcks/.github/blob/main/ADOPTERS.md
 > 📢 If you're using Microcks in your organization, please add your company name to this [list](https://github.com/microcks/.github/blob/main/ADOPTERS.md) 🙏 It really helps the project to gain momentum and credibility. It's a small contribution back to the project with a significant impact.
 
+## Decision Making and Voting
+
+Most day-to-day technical decisions, including pull request reviews, merges and releases, are made by Maintainers through lazy consensus. Discussions and decisions should take place in public GitHub issues, pull requests, discussions or community meetings whenever possible.
+
+A formal vote is required for:
+
+- Changes to governance policy or supporting governance documents,
+- Adding or removing a Maintainer,
+- Adding or removing a sub-project or repository,
+- Project-wide strategic direction or roadmap priorities,
+- Requests involving CNCF funds or resources,
+- Any other decision that the Maintainers explicitly designate for a formal vote.
+
+Formal votes use organization-balanced voting so that no single organization can control Microcks governance through Maintainer headcount. Each organization has one vote, regardless of how many Maintainers are affiliated with it. Each independent or unaffiliated Maintainer has one vote.
+
+A Maintainer's organization is the affiliation listed in the [centralized Maintainers and Code Owners list](https://github.com/microcks/.github/blob/main/MAINTAINERS.md). Maintainers employed by, sponsored by or working primarily on behalf of the same organization are treated as one affiliation. Parent companies and their controlled subsidiaries are also treated as one affiliation. Self-employed or independent Maintainers are each treated as a separate affiliation. Affiliation changes take effect as soon as they are disclosed and recorded in the Maintainers list. The Maintainers must document how any unclear affiliation is classified before a formal vote begins.
+
+When multiple eligible Maintainers share an affiliation, the position supported by a majority of all those Maintainers becomes the organization's vote. If no position has a majority, the organization abstains. An abstention does not reduce the number of organizational votes used to calculate the approval threshold.
+
+A formal vote must:
+
+1. Be opened in a public GitHub issue or pull request and clearly identified as a vote,
+2. Remain open for two weeks unless it can be closed early because the outcome can no longer change,
+3. Allow anyone in the community to comment, while only eligible Maintainers determine organizational votes,
+4. Be approved by at least two-thirds of all eligible organizational votes, rounded up to the next whole vote,
+5. Record each organization's position and the final result in the issue or pull request.
+
+Maintainers must disclose material conflicts of interest and recuse themselves when appropriate. Recused Maintainers do not participate in determining their organization's position. If every Maintainer from an organization is recused, that organization is not eligible for that vote. A Maintainer whose removal is under consideration must recuse themselves from that vote.
+
 ## Contributor ladder
 To become a maintainer, you need to get involved with the Microcks project on GitHub and demonstrate commitment and qualities:
 
@@ -37,15 +66,13 @@ To become a maintainer, you need to get involved with the Microcks project on Gi
 
 ### Voting in and voting out maintainers
 
-1. Maintainers make a public announcement during community meetings,
-2. During this meeting, a maintainer nominates to add a new maintainer or remove an existing maintainer,
-3. The nominator will open a PR to the [centralized](https://github.com/microcks/.github/blob/main/MAINTAINERS.md) Maintainer and Code Owners list,
-4. Maintainers vote via GitHub PR comments, with a 2 week deadline. Anyone in the community is welcome to comment. Community comments will be considered but not counted toward the vote,
-5. After two weeks, any maintainer who abstains from voting will not be counted towards the vote,
-6. Decision is approved with a super-majority: 66% 2/3) or more of maintainers who have voted within two weeks,
-7. If 66% (2/3) of all maintainers have approved within two weeks, the voting is closed early.
+1. A Maintainer publicly nominates a person to become a Maintainer or proposes removing an existing Maintainer during a community meeting,
+2. The nominating Maintainer opens a pull request against the [centralized Maintainers and Code Owners list](https://github.com/microcks/.github/blob/main/MAINTAINERS.md),
+3. The pull request is clearly identified as a formal vote and follows the organization-balanced voting rules defined above,
+4. Anyone in the community may comment during the voting period. Community comments are considered but are not binding votes,
+5. Once the result is approved and the pull request is merged, permissions are added or removed immediately.
 
-For maintainers voted in, permissions are immediately added. For maintainers, voted-out permissions are immediately removed.
+The candidate being nominated does not participate in the vote. A Maintainer whose removal is under consideration must follow the recusal rule defined above.
 
 ### Becoming a Code Owner 
 A Code Owner (alias Domain Maintainers) is appointed by the maintainers to recognize a contributor with expertise and authority in a specific domain. Code Owners are appointed to have elevated privileges, authority and specific responsibilities. The code owner role is part of the Microcks contributor ladder and is the primary path from contributor to maintainer. The roles and responsibilities of code owners are scoped. A person can have one or more code owner responsibilities.
@@ -62,7 +89,7 @@ Microcks maintainers have the authority to add or remove sub-projects or reposit
 When a sub-project is removed, it will be archived as-is within the Microcks-archive organization, along with its associated repositories, ensuring transparency and historical reference.
 
 ## Conflict Resolutions
-Typically, it is assumed that disputes will be resolved amicably by those involved. However, if the situation becomes more serious, conflicts will be resolved through a voting process. A supermajority of votes from project maintainers is required to make a decision, and the project lead has the final say in the ruling.
+Typically, disputes are resolved amicably by those involved through open discussion and lazy consensus. If a conflict cannot be resolved, a Maintainer may initiate a formal organization-balanced vote. If the vote cannot produce a resolution or the conflict cannot be handled impartially within the project, the Maintainers may request assistance from the CNCF and the Technical Oversight Committee.
 
 ## Community Meetings
 [Microcks](https://microcks.io/) hosts two monthly community meetings tailored for different time zones:
@@ -83,7 +110,7 @@ Detailed guidelines regarding the SC's composition, election process, and operat
 👉 [Microcks Steering Committee Charter](https://github.com/microcks/community/blob/main/steering/STEERING.md)
 
 ## Governance Changes
-Changes to governance policy and any supporting documents must be agreed upon and approved by 66% (2/3) of the maintainers either by vote or by review and approval of a PR on the document.
+Changes to governance policy and any supporting governance documents require a formal organization-balanced vote as defined in this document.
 
 This Project Governance is a living document. As the Microcks community and project continue to evolve, maintainers are **committed** to improving and openly sharing our governance model, ensuring transparency and collaboration every step of the way.
 

@@ -2,14 +2,15 @@
 > Microcks governance, roles and policies are defined in the [GOVERNANCE](https://github.com/microcks/.github/blob/main/GOVERNANCE.md) file.
 > This MAINTAINERS file applies to every sub-project, repository and file existing within the [Microcks GitHub organization](https://github.com/microcks/).
 > Please keep the lists sorted in ascending alphabetical order.
+> Maintainer affiliations determine organization-balanced governance votes and must be kept current. Any affiliation change must be recorded before a formal vote begins.
 
 ## Overview
 
 This document provides an alphabetical list of Microcks' maintainers and code owners. If you want to contribute and become a maintainer or code owner, please refer to [CONTRIBUTING](CONTRIBUTING.md).
 
 ## Maintainers
 
-The following members are Top-level [maintainers](https://github.com/microcks/.github/blob/main/GOVERNANCE.md#maintainers-code-owners-contributors-and-adopters) of the Microcks Parent Org, Parent Project, all repos, sub-repos, projects, sub-projects and forks contained within and under the entire Microcks parent org; with Full Binding Vote status.
+The following members are Top-level [maintainers](https://github.com/microcks/.github/blob/main/GOVERNANCE.md#maintainers-code-owners-contributors-and-adopters) of the Microcks Parent Org, Parent Project, all repos, sub-repos, projects, sub-projects and forks contained within and under the entire Microcks parent org. They participate in binding votes according to the [organization-balanced voting rules](https://github.com/microcks/.github/blob/main/GOVERNANCE.md#decision-making-and-voting).
 
 | Name | GitHub ID | Affiliation |
 |----------------------------------------------------------|--------------------------------------------------------------|-------------------|