This document defines governance policies for the Microcks project.
Last reviewed: September 11, 2026
The Microcks project community adheres to the following principles:
- Open: The Microcks community strives to be open, accessible and welcoming to everyone. Anyone may contribute, and contributions are available to all users according to open source values and licenses.
- Transparent and accessible: Any changes to the Microcks source code and collaborations on the project are publicly accessible (GitHub code, issues, PRs, and discussions).
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles.
- Vendor-neutral: Microcks is designed and maintained to be fully aligned with the principles of the Cloud Native Computing Foundation (CNCF).
Join us 👉 https://microcks.io/community/
The Microcks project has four roles. All project members operate in one (or more) of these roles:
| Level | Role | Responsibilities |
|---|---|---|
| 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 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. |
- Maintainer and Code Owners list: https://github.com/microcks/.github/blob/main/MAINTAINERS.md
- Contributors list: (DevStats) new contributors over the last 6 months / (GitHub) contributors on Microcks main repo.
- 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 🙏 It really helps the project to gain momentum and credibility. It's a small contribution back to the project with a significant impact.
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. 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:
- Be opened in a public GitHub issue or pull request and clearly identified as a vote,
- Remain open for two weeks unless it can be closed early because the outcome can no longer change,
- Allow anyone in the community to comment, while only eligible Maintainers determine organizational votes,
- Be approved by at least two-thirds of all eligible organizational votes, rounded up to the next whole vote,
- 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.
Promotion is based on sustained, public contributions and demonstrated trust, regardless of employment status. Meeting the minimum eligibility criteria does not guarantee promotion. Maintainers also consider the quality and impact of contributions, collaboration, judgment and the project's current needs.
A Maintainer candidate must provide public evidence of all the following:
- At least six months of sustained participation in the Microcks community, including at least three months as a Code Owner or in an equivalent position of scoped project responsibility,
- At least five significant contributions accepted during the previous twelve months. Contributions may include code, tests, documentation, design proposals, release work or community operations,
- At least five substantive pull request reviews or issue-triage decisions during the previous twelve months,
- Participation in at least three public project-wide discussions, decisions or community meetings during the previous twelve months. Synchronous meeting attendance is not required when equivalent participation is recorded asynchronously,
- Demonstrated collaboration, including incorporating feedback, helping other contributors and working constructively across project areas,
- Consistent alignment with the Microcks and CNCF Codes of Conduct and vendor-neutrality principles, and
- Reliable availability through at least one documented public project channel. Full-time availability and presence on every communication channel are not required.
The nominating Maintainer must link the evidence for these criteria in the nomination pull request so that the community and voting Maintainers can evaluate the candidate consistently.
- A Maintainer publicly nominates a person to become a Maintainer or proposes removing an existing Maintainer during a community meeting,
- The nominating Maintainer opens a pull request against the centralized Maintainers and Code Owners list,
- The pull request is clearly identified as a formal vote and follows the organization-balanced voting rules defined above,
- Anyone in the community may comment during the voting period. Community comments are considered but are not binding votes,
- Once the result is approved and the pull request is merged, permissions are added or removed immediately.
The candidate being nominated does not participate in the vote. A Maintainer whose removal is under consideration must follow the recusal rule defined above.
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.
A Code Owner candidate must have participated in the relevant domain for at least three months, with at least three accepted contributions and three substantive reviews or issue-triage decisions in that domain. The appointment must identify the domain and link this public evidence.
Code owners are enabled to act independently. They do not have responsibilities or voting rights over the entire project or organization. They are expected to participate with the community, but they are not expected to participate in maintainer meetings unless requested.
If a maintainer or code owner can no longer fulfill their commitments, they should consult with the maintainers and either take a sabbatical or step down from their role. All maintainers share the responsibility of ensuring the group operates with consistent dedication. If a maintainer or code owner fails to meet their commitments, they may be voted out by the maintainers and transitioned to emeritus status.
Microcks maintainers have the authority to add or remove sub-projects or repositories as needed. We follow a careful approach when making these changes: any new sub-project must serve a long-term purpose that is clearly distinct from existing ones, while sub-projects slated for removal must be shown to have either outlived their usefulness, become deprecated or unmaintainable.
The canonical inventory of Microcks projects and repositories, including their lifecycle status and responsible ownership, is maintained in SUBPROJECTS.md.
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.
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.
Microcks hosts two monthly community meetings tailored for different time zones:
- APAC-friendly Meeting: Second Thursday of each month
- Time: 9–10 a.m. CET / 1–2 p.m. Bengaluru
- America-friendly Meeting: Fourth Thursday of each month
- Time: 6–7 p.m. CET / 1–2 p.m. EST / 9–10 a.m. PST
Here’s how to join and participate: https://github.com/microcks/community/blob/main/JOIN-OUR-MEETINGS.md
Maintainers may hold closed meetings when needed to handle security reports or Code of Conduct incidents. Participation is limited to people needed to respond who do not have a material conflict of interest. Any Maintainer who is accused, directly involved or otherwise conflicted must recuse themselves and must not receive confidential information about the incident except as required for a fair investigation. Code of Conduct reports are handled or transferred according to the reporting and escalation process in the Code of Conduct.
To support sustainable growth and ensure the project remains responsive to high-scale users, Microcks features a Steering Committee (SC). The SC acts as a functional component of governance, focusing on strategic project orientation and incorporating the "adopter's voice" into the long-term roadmap.
Detailed guidelines regarding the SC's composition, election process, and operational mandate can be found in the: 👉 Microcks Steering Committee Charter
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.
Maintainers review this document at least once every twelve months and after any material change to project structure, roles, decision-making or repository scope. Each review is recorded in a public GitHub issue or pull request. A review that concludes no policy change is needed may update only the Last reviewed date through lazy consensus; any substantive change requires a formal organization-balanced vote.
Microcks follows the Code of Conduct, which is aligned with the CNCF Code of Conduct.
Thanks to Dawn Foster for the inspiring talk and valuable insights at KubeCon Europe 2022: "Good Governance Practices for CNCF Projects": Info, Recording and slide deck 👀
Sections of this document have been borrowed and inspired from the CoreDNS, Kyverno, OpenEBS and fluxcd projects.