status-go/_docs/policies/introduce-policy.md

72 lines
3.3 KiB
Markdown
Raw Normal View History

# Purpose
Policy Zero establishes the foundational guidelines for creating,
reviewing, and maintaining policies in the `status-go` Git repository.
This policy aims to create a collaborative, inclusive, and transparent
process for defining repository policies, specifically regarding how
developers engage with and contribute to the `status-go` repository.
For a more detailed description, please refer to [the README.md](./README.md).
# Submitting a Policy Proposal
- Any individual MAY propose a new policy.
- Policy ideas SHOULD be discussed with contributors who wish to have
a voice in how the repository operates, including Core Contributors
(CCs) and external contributors.
- All policies MUST be submitted to the `_docs/policies`
directory as a pull request (PR) within the `status-go` repository.
- All policies MUST be in Markdown format.
- Policy file names MUST follow [File name conventions for ADRs](https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file#file-name-conventions-for-adrs), e.g. `submitting-policy.md`.
- A policy MUST include a brief justification, addressing the question:
"Why has this policy been introduced?"
# Review and Approval Process
- Policy PRs SHOULD be reviewed by as many contributors as possible
who wish to engage in the process.
- Any CC MAY review, approve, and/or request changes to a policy
proposal PR.
- For any policy PR to be eligible for merging, it:
- MUST address all feedback provided during the review process.
- MUST be approved by all team leads (of Status Desktop, Mobile and Waku Chat).
- MUST be approved by all members of the @status-im/status-go-guild
GitHub team.
- MUST receive a minimum of six approvals, regardless of the number
of team leads or members of the @status-im/status-go-guild GitHub team.
# Policy Overrides
On rare occasions, circumstances may necessitate that an established
policy is intentionally circumvented. This is considered an **override**
and MUST follow the process outlined below to ensure transparency
and collective agreement:
- Any override MUST be documented in a public and permanently
referenceable form (such as a forum post, or GitHub comment or issue),
and MUST include:
- The specific policy being overridden,
- The rationale for taking this action,
- The potential risks and impacts of the **override**, AND
- Steps taken to minimise those risks.
- Before executing the override of any policy, the override:
- MUST be approved in writing by at least one team lead from the
Status Desktop or Status Mobile teams, AND
- MUST be approved in writing by at least one member of the
@status-im/status-go-guild GitHub team.
- Policies MAY define additional rules for handling overrides, provided
the above baseline requirements are also met.
# Policy Amendments and Archival
- Amendments
- Policies MAY be amended at any time.
- Amendments MUST be submitted via a PR to the `status-go` repository.
- Archival
- Policies MAY be archived if they are obsolete or replaced by
newer policies.
- Archival MUST be performed by submitting a PR that moves the
policy to `_docs/policies/archived`.
- The PR MUST include a rationale for the proposed amendment or
archival in the PR description.
- The PR MUST follow the [Review and Approval Process](#review-and-approval-process).