mirror of
https://github.com/status-im/status-go.git
synced 2025-01-30 16:38:21 +00:00
docs(policy)_: Addressed first lot of feedback
This commit is contained in:
parent
c5ca78a0ae
commit
d83e4ab9ce
@ -1,36 +1,53 @@
|
|||||||
# Purpose
|
# Purpose
|
||||||
|
|
||||||
Policy Zero establishes the foundational guidelines for creating, reviewing, and maintaining policies in the `status-go` GitHub 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 repository.
|
Policy Zero establishes the foundational guidelines for
|
||||||
|
creating, reviewing, and maintaining policies in the `status-go`
|
||||||
|
GitHub 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 repository.
|
||||||
|
|
||||||
# Submitting a Policy Proposal
|
# Submitting a Policy Proposal
|
||||||
|
|
||||||
- Any individual MAY propose a new policy.
|
- Any individual MAY propose a new policy.
|
||||||
- Policy ideas SHOULD be discussed with Core Contributors (CCs) and other community members.
|
- Policy ideas SHOULD be discussed with Core Contributors
|
||||||
- All policies MUST be submitted to the `_docs/policies` directory as a pull request (PR) within the `status-go` repository.
|
(CCs) and other community members.
|
||||||
- All policies MUST be in Markdown format
|
- 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. `000-submitting-policy.md`
|
- 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. `000-submitting-policy.md`
|
||||||
|
|
||||||
# Review and Approval Process
|
# Review and Approval Process
|
||||||
|
|
||||||
The core function of the review and approval process for policy PRs is to reach consensus on any issue and to reflect the range of perspectives within the `status-go` community. Policy submissions must aim to achieve broad community support and give key stakeholders a chance to gain context of the policy requirements.
|
The core function of the review and approval process for policy
|
||||||
|
PRs is to reach consensus on any issue and to reflect the range
|
||||||
|
of perspectives within the `status-go` community. Policy
|
||||||
|
submissions must aim to achieve broad community support and
|
||||||
|
give key stakeholders a chance to gain context of the policy
|
||||||
|
requirements.
|
||||||
|
|
||||||
- Policy PRs SHOULD be reviewed by as many Core Contributors (CCs) as possible.
|
- Policy PRs SHOULD be reviewed by as many Core Contributors (CCs) as possible.
|
||||||
- Any CC MAY review, approve and / or request changes of a policy proposal PR.
|
- Any CC MAY review, approve and / or request changes of a policy proposal PR.
|
||||||
- For any policy PR to be eligible for merging, it:
|
- For any policy PR to be eligible for merging, it:
|
||||||
- MUST address all feedback provided during the review process.
|
- MUST address all feedback provided during the review process.
|
||||||
- MUST be approved by all team leads (of Status Desktop and Mobile).
|
- MUST be approved by all team leads (of Status Desktop and Mobile).
|
||||||
- MUST be approved by all members of the status-go Guild.
|
- MUST be approved by all members of the @status-im/status-go-guild
|
||||||
|
GitHub team.
|
||||||
- MUST receive a minimum of six approvals from CCs.
|
- MUST receive a minimum of six approvals from CCs.
|
||||||
|
|
||||||
# Policy Amendments and Archival
|
# Policy Amendments and Archival
|
||||||
|
|
||||||
Policies can be amended or archived to ensure they remain relevant and aligned with community needs.
|
Policies can be amended or archived to ensure they remain relevant and aligned
|
||||||
|
with community needs.
|
||||||
|
|
||||||
- Amendments
|
- Amendments
|
||||||
- Policies MAY be amended at any time.
|
- Policies MAY be amended at any time.
|
||||||
- Amendments MUST be submitted via a PR to the `status-go` repository.
|
- Amendments MUST be submitted via a PR to the `status-go` repository.
|
||||||
- Archivals
|
- Archival
|
||||||
- Policies MAY be archived if they are obsolete or replaced by newer policies.
|
- Policies MAY be archived if they are obsolete or replaced by newer
|
||||||
- Archival MUST be performed by submitting a PR that moves the policy to `_docs/policies/archived`.
|
policies.
|
||||||
- The PR MUST include a rationale for the proposed amendment or archival in the PR description.
|
- 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).
|
- The PR MUST follow the [Review and Approval Process](#review-and-approval-process).
|
||||||
|
Loading…
x
Reference in New Issue
Block a user