status-im/status-go
2
0
Fork 0
mirror of https://github.com/status-im/status-go.git synced 2025-01-30 08:26:54 +00:00
Code Issues Projects Releases Wiki Activity

docs(policy)_: Addressed feedback from status-go guild

Browse Source
This commit is contained in:
Samuel Hawksby-Robinson 2024-12-10 14:53:30 +00:00
parent 67b1430c7f
commit 30387245a4
1 changed files with 20 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
_docs/policies/policy-zero.md
View File

@ -1,77 +1,36 @@
# 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.
# Starting and Drafting a New Policy
## **Starting a New Policy**
# Submitting a Policy Proposal
- Any individual MAY propose a new policy.
- Policy ideas SHOULD be discussed with Core Contributors (CCs) and other community members.
Note. Drafting can be done collaboratively in an external document editor if preferred, allowing for more flexible brainstorming and iteration before submission.
## **Submitting a Policy Proposal**
- All policies MUST be submitted to the `_docs/policies` directory as a pull request (PR) within the `status-go` repository.
- Submitting a policy via a PR is required to maintain proper version control, visibility, and record of changes within the repository.
## Policies Location and Naming
- 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.
`policy-zero.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
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 seek approval from as many Core Contributors (CCs) as possible.
- All team leads MUST be invited to review the PR.
- Reviewers SHOULD give constructive feedback where applicable.
- For any policy PR to be eligible for merging it:
- MUST receive a minimum of six approvals from CCs.
- MUST be approved by a member of each team.
- MUST be approved by each member of the status-go Guild.
- 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.
- 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 and Mobile).
- MUST be approved by all members of the status-go Guild.
- MUST receive a minimum of six approvals from CCs.
# Policy Review and Archival Process
# Policy Amendments and Archival
This section outlines how existing policies are maintained, reviewed, amended, and archived to ensure ongoing relevance and alignment with the `status-go` community.
Policies can be amended or archived to ensure they remain relevant and aligned with community needs.
## Annual Policy Check Ups
The annual policy check up ensures policies remain relevant, clear, and aligned with current practices while fostering transparency and inclusivity across the `status-go` community.
- All policies in `_docs/policies` MUST undergo an annual review.
- The status-go Guild SHALL be responsible for coordinating the review process.
- The review MUST be conducted via a video call, open to all Core Contributors (CCs).
- During the call:
- Policies MUST be assessed for effectiveness, clarity, and applicability.
- Feedback and action items SHOULD be discussed collaboratively.
- Outcomes of the review, including feedback and recommended changes, MUST be documented in `_docs/policies/check-ups`.
## Policy Amendments
Policy amendments enable updates and clarifications while maintaining alignment with community needs.
- Any policy MAY be amended at any time.
- Amendments MUST be submitted via a PR to the `status-go` repository.
- Each amendment PR MUST include a rationale for the proposed changes in the PR description.
- The PR MUST follow the [Review and Approval Process](https://www.notion.so/Review-and-Approval-Process-1368f96fb65c804eb706ea667e75c14f?pvs=21)
## Policy Archival
- Any policy MAY be archived if they are obsolete or replaced by newer policies.
- The status-go Guild MUST submit a PR moving the policy to `_docs/policies/archived`.
- The archiving PR MUST include a rationale for the proposed archival in the PR description.
# Scope of Policies
Policies created under this structure should:
- Focus on establishing rules and etiquette for interacting with the `status-go` repository.
- Avoid overlapping with technical code standards or engineering guidelines unless they directly impact repository interactions.
- Uphold the core values of inclusivity, transparency, and consensus within the `status-go` community.
- Amendments
- Policies MAY be amended at any time.
- Amendments MUST be submitted via a PR to the `status-go` repository.
- Archivals
- 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).