Add governance document in the repository

GOVERNANCE.md

@@ -0,0 +1,79 @@
+# ReFrame Governance
+
+This document describes how the project is governed.
+It complements the [Code of Conduct](CODE_OF_CONDUCT.md), the [contribution guidelines](CONTRIBUTING.md) and the [list of maintainers](MAINTAINERS.md).
+
+## Roles
+
+- **Leadership team:** sets the direction of the project and has the final say when there is no consensus.
+- **Maintainers:** have write access to the repository and can review and merge pull requests.
+- **Contributors:** anyone who has contributed code, documentation, tests, reviews or bug reports.
+
+### Leadership team
+
+Responsibilities:
+
+- Roadmap and release planning
+- Decisions on major features and architectural changes
+- Adding and removing maintainers
+- Representing the project in HPSF
+
+Current members (alphabetically):
+
+- Victor Holanda Rusu ([@victorusu](https://github.com/victorusu)), CSCS
+- Vasileios Karakasis ([@vkarak](https://github.com/vkarak)), NVIDIA
+- Eirini Koutsaniti ([@ekouts](https://github.com/ekouts)), CSCS
+- Guilherme Peretti-Pezzi ([@gppezzi](https://github.com/gppezzi)), CSCS
+
+Members are added by an absolute majority vote of the leadership team.
+A leadership team member can step down at any time.
+A leadership team member can also be removed by a 2/3 absolute majority.
+The member to be removed is notified about the reasons and given the opportunity to respond.
+
+An "absolute majority" means more than half of the current leadership team members, regardless of how many participate in the vote.
+
+Formal votes related to membership take place during the regular development meetings, with the voting agenda announced at least 14 days in advance; a member unable to attend may submit their vote in writing beforehand. Voting agenda and results are announced in the development meeting minutes.
+
+### Maintainers
+
+Maintainers review and merge pull requests, triage issues, keep the CI and the release tooling working and take part in the development meetings.
+The current list is in [MAINTAINERS.md](MAINTAINERS.md).
+
+Any maintainer can propose a contributor as a new maintainer.
+The leadership team decides on an absolute majority basis.
+We look for a track record of good contributions, a good understanding of the code base and constructive participation in reviews and discussions.
+
+Maintainers can step down at any time.
+Maintainers can also be removed by the leadership team with an absolute majority vote.
+The maintainer to be removed is notified about the reasons and given the opportunity to respond.
+
+## How decisions are made
+
+Most decisions happen in pull requests.
+A pull request needs the approval of at least one maintainer other than the author, passing CI and documentation for any user-facing change.
+
+Bigger changes (such as new major features, architectural changes, changes to the public API or the configuration syntax, deprecations, release planning) are discussed in a GitHub issue first, in the development meetings or on Slack.
+We decide by consensus.
+If we cannot agree, the leadership team votes and a simple majority wins.
+
+Changes to this document need a 2/3 absolute majority of the leadership team.
+
+## Releases
+
+We follow [semantic versioning](https://semver.org).
+Major or minor releases come out typically twice a year.
+Patch releases come out when there are fixes to release.
+
+What goes into the next release is tracked in the [GitHub milestones](https://github.com/reframe-hpc/reframe/milestones) and the [release board](https://github.com/orgs/reframe-hpc/projects/1/views/1).
+
+## Meetings and communication
+
+- The maintainers meet regularly to go through open issues and pull requests and discuss the next release.
+- [GitHub issues](https://github.com/reframe-hpc/reframe/issues) and pull requests are where technical discussions and decisions should be recorded.
+- [Slack](README.md#contact) is for user support, announcements and informal discussion.
+- Documentation is at https://reframe-hpc.readthedocs.io.
+
+## Code of Conduct
+
+Everyone taking part in the project is expected to follow the [Code of Conduct](CODE_OF_CONDUCT.md).
+Reports are handled by the leadership team; a member involved in a report does not take part in handling it.