Contribute

How to add your knowledge to the Campaigning Wiki. This page is the contributor-facing entry point: what the wiki is, what kinds of pages it carries, how to write one, and how to send it in. Read it once before you open a pull request. If you are about to send a typo fix or a one-sentence addition you can skip straight to the Submit section; if you are about to write a new page, read the whole thing.

What the wiki covers

The Campaigning Wiki is a working field manual for organisers — strategy, organising, tactics and digital craft, with worked case studies and the sources behind every claim. It is built for people running real campaigns: advocates, organisers, union and movement staff, and the volunteers around them. The three pillars that organise the craft are strategy, organizing and tactics, with four smaller, growing areas — digital, training, legal and research & MEL; alongside them sit worked case studies that show how the craft has played out in the world.

The wiki distills material from practitioners and reference works, and paraphrases rather than republishes — see the About page for the long form of what this is and the editorial principle behind it. The corpus is multilingual: the English tree in Wiki/ is the canonical source, and parallel translations live under Wiki/de/, Wiki/fr/, Wiki/it/ and Wiki/es/. Translations inherit the citations of the page they translate, so a contributor who writes a new concept page in English is also seeding material the translation wave can carry into the other four languages.

This page covers the practical mechanics: what kinds of pages the wiki carries, what shape a new page should take, what the quality bar is, and how to send the contribution in.

How to propose a concept, case study, or source

The wiki has three kinds of page. Pick the one that fits what you have to contribute, copy the relevant template, fill it in, and open a pull request against github.com/gariwat/campaigning_wiki. Every new page goes in via a pull request — there is no other intake path for new content. Pull requests are reviewed in the order they arrive by a small group of volunteer editors who also run their own campaigns on the side.

• Concept — a piece of craft, a method, a framework, a term of art. Examples already in the wiki include power-mapping, coalition-building, and audience-segmentation. A concept page lives at Wiki/<slug>.md (one concept per file, lowercase, hyphen-separated; see the file naming rule in CONVENTIONS.md). Every concept page must end up grounded in cited sources — that is the rule that lets us publish it. Concepts are the wiki’s main spine; if your contribution is a reusable idea rather than a single campaign, it belongs here.
• Case study — a real campaign, told in enough detail that someone can learn from it. Examples already in the wiki sit under Wiki/case-studies/ and include hundreds of campaigns from the Swarthmore Global Nonviolent Action Database, the Commons Library, Oxfam and other sources. New case studies should use the case-study template (case-study — the worked-example worksheet in the templates directory) so the working sections (what happened, background, outcome, lessons) line up with what the rest of the wiki already does. A case study is the right home for a campaign that illustrates a craft technique, surfaces a useful counter-example, or fills a geographic or thematic gap in the existing collection.
• Source — a book, tool, website, video, podcast, course or organisation that the wiki draws on. Examples live under Wiki/sources/. New sources should use the source template (source — the worksheet in the templates directory for registering a new source the wiki draws on) and be grounded in the source’s own content — what the source actually says, not what a third party says about it. Sources are the wiki’s evidence base; if you are proposing a source that several existing pages should cite, that is the right place to register it.

All three go in the same way: fork the repo, add the file under the right path, fill the template, run the local quality checks if you can, and open a pull request against github.com/gariwat/campaigning_wiki. If you would like feedback on the idea before you write the page, open an issue first — the wiki’s editors will read it and tell you whether the contribution fits the existing scope.

Quality bar

Two things hold the wiki to a quality bar: a template and a grounding gate. The template is the shape of the page — the sections it must have, the fields its frontmatter must carry, the conventions it must follow. The grounding gate is the rule that no page goes public until its claims trace back to cited sources. Both are documented, and both are enforced at build time, which means contributors get the same quality pass whether they are an experienced editor or a first-time contributor.

The standards behind the gate are written up in QUALITY_STANDARDS.md — that file is the authoritative reference for what “grounded” means, what counts as a hard fact, and how citations work. The templates directory lists the fillable Markdown worksheets for each kind of page; the curation tier system on the sources side tells you whether a given source is Core craft, Reference, or Deprioritised. A contributor who reads the standards, picks the right template, and grounds their claims in cited sources is most of the way to a publishable page — the rest is the editorial review described in the next section.

The two-step model is what makes the wiki worth trusting: a template gives the page a shape other pages already have, and the grounding gate keeps the page honest. We would rather hold a page back than publish one whose claims we cannot stand behind. This is true even for pages that “feel” obvious — the gate applies uniformly, and it is the gate, not the editor’s gut, that decides whether a page goes live. A held-back page is not a rejected page: the page stays in the repo, the page’s wikilinks still resolve, and the editor who reviews your pull request will help you work out which citations or sections need another pass before the gate lets it through.

The templates

The wiki ships a set of fillable Markdown templates for the recurring artefacts of a campaign. Each template is a complete, copy-and-edit worksheet — open it, duplicate it, fill it in, submit it. Pick the template that matches the kind of page you want to contribute.

• Action planning — the one-event or one-tactic worksheet a team uses to plan a specific action day, with the timing, roles, materials, comms and risks lined up.
• Campaign plan — the team’s operating plan for the next 3-12 months, with the goal, theory of change, targets, tactics, timeline and budget in one place.
• Templates directory — the full index of templates, including the case-study and source templates added in the same wave.
• Post-action review — the after-action-review worksheet a team fills in after an event to capture what happened, what worked, what did not, and what to change next time.
• Power analysis — the base / target / allies / opposition grid that runs before strategy work and feeds the campaign plan.
• Case study — the worked-example template for Wiki/case-studies/<slug>.md, with sections for what happened, background, outcome and lessons.
• Source — the worksheet for Wiki/sources/<slug>.md, with sections for what the source is, who runs it, how the wiki uses it, and what to cite when grounding a page in it.

The templates follow the wiki’s own conventions (see CONVENTIONS.md at the repo root) — frontmatter, ## Summary · ## Body · ## Use it for · ## Related — and are designed to be edited, not consumed. If a template does not fit your contribution, that is worth flagging in the pull request — the template set is small on purpose and grows only when a new recurring need shows up across multiple contributions.

Editorial review

Two pieces of plumbing keep the live site honest. The first is the publish gate — a Python pass that runs at build time and decides which pages may go public and which are held back. A page is held back if it lacks grounded sources, has a broken wikilink, is marked as a draft, or fails any other verifier check. The held-back pages are not deleted; they stay on disk and in the working index, they simply do not appear on the public site until their issues are resolved. The gate’s running output lives at PUBLISH_GATE.md in the wiki tree itself, so contributors can see at a glance what is being held and why.

The second piece is the status ladder — stub → emerging → established. A page starts as a stub (registered but not yet distilled), moves to emerging once it has partial method content, and reaches established only when it is distilled, sourced, cross-linked and reviewed. The grounding gate holds back any page that tries to climb the ladder without the citations to back the climb. The audit side of this — the running report of what the gate is doing and why pages are held — lives in QC_REPORT.md. The two reports are useful to read before opening a pull request: they show you which templates are well-exercised and which verifier checks most often catch new contributions.

In practice this means a contributor who opens a pull request should expect a short review cycle: an editor checks the template is filled in, the frontmatter is well-formed, and the claims trace back to the cited sources. Reviews are best-effort, not a service-level agreement — see the next section for turnaround and submission paths. Pull requests that only touch a wikilink or fix a typo typically merge in a single review pass; pull requests that add a brand-new concept page may take a couple of review cycles while the editor and contributor work through the citation set together.

License

The wiki is published under a link-only model for most of its source material: it summarises and links to original sources rather than republishing them. That keeps the wiki on the right side of copyright for sources whose licence is not explicit, and it means every factual claim is anchored to a source you can read for yourself. Pages grounded in Creative Commons-licensed sources may quote short passages with attribution; pages grounded in all-rights-reserved sources paraphrase and link. The full rule and how to report a rights question are written up in Copyright & Licensing.

The same rule is what you, as a contributor, should write under. When you draft a page, paraphrase the source in your own words and link out; do not paste long passages from sources whose licence does not allow it. If you are not sure whether a given source is link-only or cc-attribution, treat it as link-only until you have read the source’s own licence statement. The link-only rule is what lets the wiki draw on a wide range of practitioner material without depending on each source republishing rights; honouring it in your own contributions keeps the wiki’s overall licence position clean and avoids the need to retract a published page after the fact.

Submit

The primary way to contribute is a pull request against github.com/gariwat/campaigning_wiki. Fork the repo, add or edit the file under the right path (Wiki/<slug>.md for concepts, Wiki/case-studies/<slug>.md for case studies, Wiki/sources/<slug>.md for sources), fill the matching template, and open the pull request with a short description of what you have added and which sources you drew on. If the wiki’s local quality checks pass on your branch, the reviewer only needs to look at the content; if they fail, the reviewer will help you work through what is missing. If your contribution touches multiple files — for example, a new concept plus a new source plus a wikilink from an existing page — group them into a single pull request so the reviewer sees the change as one unit.

The fallback is feedback — the wiki’s feedback form and sidecar. Use it when you do not have a GitHub account, when the contribution is small (a typo, a dead link, a one-sentence addition), or when you would rather the editor write up the change themselves. Reviews are best-effort with no fixed turnaround — the wiki is maintained by a small group of volunteers alongside their own campaign work — but pull requests are read in the order they arrive and substantive contributions are answered to.

Thanks for helping make the wiki better — the field manual is built by the people who use it.