NCSG

Content operations

Proposal process

How new guidance and changes to existing recommendations are proposed, debated and decided — in the open.

When a proposal is needed#

  • Adding a new guidance page
  • Reversing or materially changing an existing recommendation
  • Adding or changing a standardised term (e.g. the Nigerian English vocabulary table)

Typos, clarifications and new examples that support existing guidance go straight to pull request.

The process#

  1. Open a proposal issue using the proposal template: the problem, the proposed guidance, the evidence, and what it replaces.
  2. Community comment stays open for at least 14 days. Disagreement should engage the evidence, per the code of conduct.
  3. Editorial decision. Editors decide by consensus, in writing, in the issue: accepted, accepted with changes, or declined with reasons.
  4. Implementation PR turns the accepted proposal into a page that meets the editorial standards.
  5. Changelog entry records the change and credits the proposer.

What counts as evidence#

In rough order of weight: usability testing with Nigerian users; support and complaint data; established standards (WCAG, CBN guidance); analogous research (GOV.UK, Nielsen Norman Group); expert consensus. "Our team prefers it" is a starting point, not evidence.

Anatomy of a strong proposal

Problem: Products disagree on "reversed" vs "refunded" vs "returned", and our support data shows users don't trust "reversed" without a timeframe.

Proposal: Standardise on "returned to your account within [time]".

Evidence: 412 support tickets tagged 'reversal confusion' (anonymised summary attached); usability test of 8 participants, Lagos and Ibadan, March 2026.

Spotted a problem with this page? Suggest an edit on GitHub.