docs(policy)_: Addressed additional feedback on overrides

_docs/policies/submitting-policy.md

@@ -5,6 +5,7 @@ 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
 
@@ -16,17 +17,11 @@ a voice in how the repository operates, including Core Contributors
  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
 
-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 among all contributors who wish to have a voice
-in how the `status-go` repository operates, including both Core
-Contributors (CCs) and external contributors. Policy submissions
-must aim to achieve broad contributor support and give key stakeholders
-a chance to gain context of the policy requirements.
-
 - 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
@@ -41,32 +36,27 @@ proposal PR.
 # Policy Overrides
 
 On rare occasions, circumstances may necessitate that an established
-policy is circumvented when merging a feature PR. This is considered
-an **override** and MUST follow the process outlined below to ensure
-transparency and collective agreement:
+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 textual form in the circumventing
-feature PR and MUST include:
+- 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
+  - The potential risks and impacts of the override, AND
   - Steps taken to minimise those risks.
-- Before proceeding, the override MUST be approved in writing in the
-circumventing feature PR by:
-  - At least one team lead from the Status Desktop or Mobile teams, AND
-  - At least one member of the @status-im/status-go-guild GitHub team.
-- In exceptional circumstances if an override MUST be executed
-immediately due to urgency, the action SHOULD be documented as soon
-as possible, and retrospective approval MUST be sought and recorded
-at the earliest possible opportunity.
+- 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
-these baseline requirements are also met.
+the above baseline requirements are also met.
 
 # Policy Amendments and Archival
 
-Policies can be amended or archived to ensure they remain relevant
-and aligned with contributor needs.
-
 - Amendments
   - Policies MAY be amended at any time.
   - Amendments MUST be submitted via a PR to the `status-go` repository.