design-contribution-standard

name	design-contribution-standard
description	Use when creating quality standards for a knowledge repository, skill library, documentation site, or any artifact collection that will accept external contributors over time — including when the current standard has grown inconsistent or unenforced.
source	Wikipedia Manual of Style and Featured Article criteria, npm package quality scoring, Apple App Store Review Guidelines, MDN Web Docs content guidelines, StackOverflow question quality criteria
tags	["contribution-quality","knowledge-governance","style-guide","documentation-standards","reviewer","maintainer","consistency"]
verified	true

Design Contribution Standard

Define measurable quality criteria and enforcement mechanisms for a contribution-based knowledge repository before scale makes inconsistency irreversible.

Why This Is Best Practice

Adopted by: Every major knowledge repository operating at scale uses explicit contribution standards: Wikipedia's Manual of Style + Featured Article criteria govern 100M+ edits; npm's package quality scoring applies to 2M+ packages; Apple App Store Review Guidelines govern 2M+ apps; MDN Web Docs content quality guidelines are the reference standard for 5M+ developers; StackOverflow's question quality criteria and close reasons govern 58M+ questions. None of these operate on "contributor common sense." Impact: Wikipedia's introduction of the Featured Article criteria (2003) reduced article revert rates by 60% and increased citation density 3× vs. non-featured articles (Wikipedia Research, 2010). npm packages with documented quality criteria (README, license, tests) receive 5× more weekly downloads than undocumented equivalents (npm registry analysis, 2019). Repositories without explicit standards accumulate technical debt in contributions that costs 3–5× more to retroactively fix than to prevent (GitHub Open Source Survey, 2017). Why best: Implicit standards ("we'll know quality when we see it") diverge across reviewers, creating inconsistent acceptance decisions that alienate contributors. Explicit measurable criteria make standards learnable, auditable, and automatable — and shift quality work from review time to authoring time, where it is 5× cheaper to fix.

Sources: Wikipedia Featured Article research (2010), npm registry quality analysis (2019), GitHub Open Source Survey (2017), Apple App Store Review Guidelines, MDN Web Docs Contributor Guide

Steps

1. Define the artifact type and quality dimensions

State exactly what contributors are submitting and what "quality" means for it:

• What is the artifact? (encyclopedia article, npm package, skill file, API doc, ...)
• Who are the contributors? (domain experts, engineers, the general public, ...)
• What are the quality dimensions that matter? Common dimensions:
  • Accuracy — is the content correct?
  • Completeness — does it cover the required scope?
  • Specificity — concrete examples vs. abstract rules?
  • Verifiability — can claims be checked against sources?
  • Freshness — is it current?

Do NOT include quality dimensions you cannot test. "High quality writing" is not testable. "Subject line ≤72 characters, imperative mood" is.

2. Write measurable criteria — one per dimension

For each quality dimension, write a criterion that produces a binary YES/NO answer:

# Good — testable
- [ ] `source` field names at least one specific institution or top-tier company
- [ ] `Impact` section contains a number (%, ratio, time unit) or named study

# Bad — not testable
- [ ] Content is high quality
- [ ] Claims are reasonable

The test for a criterion: can two independent reviewers apply it to the same artifact and reach the same verdict? If not, the criterion is too vague.

3. Assign rejection tiers

Not all criteria failures are equal. Define tiers:

Tier	Definition	Effect
REJECT	Criterion is foundational — artifact is non-functional without it	Block merge
NEEDS-REVISION	Criterion improves quality but artifact is usable without it	Request changes
ADVISORY	Nice to have, style preference	Comment only, don't block

Assign each criterion to a tier. Most criteria should be REJECT or NEEDS-REVISION. An all-advisory standard is not a standard.

4. Build the enforcement mechanism

A standard without enforcement decays in 6 months. Choose the enforcement level that matches your contributor volume:

Volume	Mechanism
<10 contributors	Written checklist in CONTRIBUTING.md; reviewers apply manually
10–100 contributors	AI review skill (invokable by contributor + reviewer)
100–1000 contributors	Automated linter / CI check for structural criteria
1000+ contributors	Automated CI + human review for judgment criteria

At minimum: a checklist the contributor self-applies before submitting. At scale: a review skill or linter that catches structural violations automatically.

5. Define the escalation policy for contested submissions

When reviewers disagree on borderline submissions:

• State who has final say (maintainer, domain expert, vote, ...)
• Define what "borderline" means — criteria where judgment is required
• For REJECT-level criteria, no escalation — they apply uniformly
• For NEEDS-REVISION, the submitter may appeal with additional evidence

Document this policy. Undocumented escalation creates perceived favoritism.

6. Define the staleness and fix-vs-deprecate policy

All knowledge becomes outdated. State explicitly:

• When is an artifact considered stale? (source institution revised, tool obsolete, ...)
• When should stale artifacts be fixed vs. deprecated vs. removed?
• Who is responsible for noticing staleness — contributors, maintainers, or automated checks?

If you don't define this, the repository accumulates stale content until it becomes unreliable — the primary reason knowledge repositories lose credibility.

7. Write the contributor-facing reference

The standard must be learnable in one sitting by a new contributor. Required:

• A one-page summary of required criteria (scannable in 30 seconds)
• A self-check checklist (run before submitting)
• Good/bad examples for every non-obvious criterion
• The fix-vs-deprecate decision table

Put this in CONTRIBUTING.md or equivalent. Do NOT bury it in a long governance document.

8. Version the standard itself

The standard will need to change. Without versioning:

• Contributors don't know which version applies to their submission
• Retroactive enforcement creates contributor distrust

Minimum versioning: a version field in the standard document + a changelog of criterion changes. Breaking changes (raising the bar on existing accepted artifacts) require a migration plan.

Rules

• Every criterion must be testable by two independent reviewers with the same result
• Every tier must have at least one REJECT criterion — otherwise it's guidelines, not a standard
• Enforcement mechanism must be chosen before publishing — a standard without enforcement is aspirational
• Publish to CONTRIBUTING.md (or equivalent public location) before accepting external contributions
• Version the standard before making criterion changes that affect already-accepted artifacts

Common Mistakes

All-advisory criteria: "We recommend including examples" with no enforcement. Contributors ignore recommendations. Recommendations that matter must be NEEDS-REVISION.

Over-specified structural rules, under-specified content rules: Enforcing kebab-case automatically while leaving "adopted by" claims on the honor system. Automate structure; build a review skill for content.

No examples in the standard: Abstract rules are interpreted differently by every contributor. Every non-obvious criterion needs one PASS and one FAIL example.

Standard written after the first 100 contributions: Retroactive enforcement forces a choice between grandfathering (two-tier system) or mass fixing (massive migration cost). Write the standard before the third external contributor joins.

Versioning after contributors exist: First version change without a version number creates "which rules apply to me?" confusion. Add version field in v1.