From 30387245a4c864b774760b14dcab2b9a4eb13bcd Mon Sep 17 00:00:00 2001 From: Samuel Hawksby-Robinson Date: Tue, 10 Dec 2024 14:53:30 +0000 Subject: [PATCH] docs(policy)_: Addressed feedback from status-go guild --- _docs/policies/policy-zero.md | 81 +++++++++-------------------------- 1 file changed, 20 insertions(+), 61 deletions(-) diff --git a/_docs/policies/policy-zero.md b/_docs/policies/policy-zero.md index db1f7a216..14cc4d6b6 100644 --- a/_docs/policies/policy-zero.md +++ b/_docs/policies/policy-zero.md @@ -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).