This document is based on GOVERNANCE.md. We assume good faith and intend to keep all processes as lightweight as possible but as specific as required. In case of disagreements about anything in this document, GOVERNANCE.md applies.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119.
Git and GitHub terminology are used throughout this document.
Team members and their access to repositories is maintained through GitHub teams. Team maintainers add and remove team members as outlined in GOVERNANCE.md.
Examples of proposed changes are overarching architecture, component design, and specific code or graphical elements. Proposed changes SHOULD cover the big picture and intention, but individual parts SHOULD be split into the smallest possible changes. Changes SHOULD be based on and target the main branch. Depending on size of the proposed change, each change SHOULD be discussed, in increasing order of change size and complexity:
Significant changes MUST be discussed and agreed upon with the relevant subsystem maintainers.
Depending on the size and complexity of a PR, different requirements MUST be applied. Any team member contributing substantially to a PR MUST NOT count against review requirements. Commits MUST be merged into main using PRs. They MUST NOT be pushed to main directly.
PRs MUST be reviewed and approved via GitHub’s review system.
Once a PR is approved as per above, any team member MAY merge the PR.
Grafana uses trunk-based development.
In particular, we found that the following principles match how we work:
Releases MUST follow Semantic Versioning in naming and SHOULD follow Semantic Versioning as closely as reasonably possible for non-library software.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。