Skip to content

GOVERNANCE.md

Latest commit

 

History

History
86 lines (65 loc) · 4.46 KB

GOVERNANCE.md

File metadata and controls

86 lines (65 loc) · 4.46 KB
Raw

Governance of HolmesGPT

Overview

HolmesGPT is an open-source project that uses AI and Large Language Models (LLMs) to automate root-cause analysis and troubleshooting in modern cloud-native environments. This governance document outlines the project's structure, decision-making processes, roles, and expectations for community participation.

Code of Conduct

All participants must adhere to the CNCF Code of Conduct in every interaction related to the project.

Roles and Responsibilities

Community Members

Welcome aboard! If you're reading this, you're already part of the community! 😄

Here are some ideas to get more involved and participate in the community:

  • Add yourself to ADOPTERS.md
  • Comment on an issue you’re interested in
  • Report a bug or idea to improve HolmesGPT
  • Submit a pull request to fix a bug or improve the project
  • Join our Slack and say hi

Community members must follow our Code of Conduct.

Contributors

Contributors are trusted community members. They may be assigned to:

  • Triage and reply to issues
  • Review pull requests assigned to them
  • Close, reopen, and assign issues and pull requests

How to become a contributor

To become a contributor, the maintainers of the project would like to see you:

  • Contribute pull requests.
  • Comment on issues with your experience and opinions.
  • Add your comments and reviews on pull requests.
  • Open issues with bugs, experience reports, and questions.

Contributors and maintainers will do their best to watch for community members who may make good contributors. But don’t be shy, if you feel that this is you, please reach out to one or more of the contributors or maintainers.

Maintainers

Maintainers are responsible for:

  • Ensuring code quality and project stability
  • Defining priorities and direction
  • Reviewing and merging PRs
  • Resolving conflicts within the community
  • Responding to reported vulnerabilities and security issues in a timely manner

How to become a maintainer

  • New maintainers can be approved by a simple majority vote at a quarterly Maintainer Meeting
  • Any contributor with at least 5 code contributions in the last 12 months may nominate themselves
  • Maintainers inactive (no code, reviews, or discussion for 12 consecutive months) are automatically removed

When evaluating a maintainer nomination, the following criteria should be considered:

  • Demonstrates a strong understanding of the project's architecture and how their work fits into the overall design
  • Contributes to reducing technical debt or performs refactors where appropriate
  • Considers performance, security, and testability in the design and implementation of their code
  • Is a trusted and constructive member of the community

Code Changes

All code changes must go through the Pull Request (PR) process:

  • PRs must be approved (via GitHub) by at least one other maintainer
  • We do not hold formal votes on every change, but merged PRs must reflect the same level of consensus as a formal vote
  • If a PR is merged without sufficient community support, it must be reverted until the matter is resolved through discussion
  • If consensus cannot be reached, any team member may call for a formal vote in the PR or via a related issue, following governance rules
  • If a change is very large or involves significant architectural decisions, we strongly recommend opening an issue first and presenting the proposed design for discussion and review before submitting a PR

Releases

Releases must be approved by at least two maintainers.

Non-Code Changes

Changes that are not made through pull requests—such as governance updates, policy shifts, or project-wide decisions—are handled through GitHub issues.

  • Maintainers should indicate their yes/no vote directly on the GitHub issue
  • After a suitable discussion period, votes will be tallied, and the outcome recorded in the issue
  • A simple majority of voting maintainers determines the outcome unless otherwise specified

Conflict Resolution

  • Contributors are expected to resolve conflicts through discussion
  • If resolution is not possible, the matter is escalated to the maintainers
  • Maintainers’ decisions are final in unresolved disputes, unless escalated to a formal vote via GitHub issue

Maintainer Meetings

  • Maintainer meetings occur every second Monday of every third month
  • These meetings are not public, but meeting notes and formal resolutions will be documented and published