Running the Wiki
This page is for reviewers and whoever holds the wiki together. Contributors do not need it — Review & approval covers the part that matters to them.
What review is for
Section titled “What review is for”Not for catching every mistake. For the changes where a mistake would matter: a new page nobody has read, or a rewrite where the reasoning behind it is not visible in the diff.
Small corrections publish by themselves, on purpose. A process that examines every typo fix stops being used within a month, and then it examines nothing.
Signing in
Section titled “Signing in”Review happens on a page that is not linked from anywhere, so it is not discoverable by accident:
/review-d4e1a9/You sign in with your name and your passphrase. The session lasts 14 days, then asks again. There is no password to forget and no account to create — the department lead adds you, and you choose your own passphrase.
Sign-in is a passphrase rather than a single sign-on. That is a deliberate trade-off, made because it works today, costs nothing, and needs no account with a third party. See Why a passphrase below.
The queue
Section titled “The queue”Two things land in it:
| What you did | Why it waits |
|---|---|
| Added a new page | Nobody has read it before, and it may duplicate something that already exists |
| Changed more than 100 characters | That is a rewrite rather than a correction, and the reasoning is not in the diff |
For each entry you get the page, who sent it, what they said, why it was held, and — for a rewrite — how many characters changed. Open the page, read it against its source, then approve or reject.
Approving publishes it in about a minute and records your name against it in the page’s history. Rejecting emails the contributor, with your name and the reason. Nothing is left in silence: silence after submitting is what makes people stop contributing.
Reviewing by system
Section titled “Reviewing by system”You can be scoped to the systems you actually review — cardiovascular, say — so the queue shows only what you are the right person for. You then see a count of what is waiting on somebody else, so it is obvious it is not sitting unnoticed.
Anyone who reviews everything can add a reviewer scoped to one system.
Adding and removing reviewers
Section titled “Adding and removing reviewers”Any signed-in reviewer can add another reviewer. This is the part that matters: it is what means the person who set the wiki up does not have to be involved for review to keep working.
To add someone: their name, a passphrase of at least 12 characters, and their systems. It takes about twenty seconds and needs no one else.
To remove someone: choose them on the same page. Their session stops working immediately, not when it expires. The last reviewer cannot be removed — the wiki will refuse, because that would leave nothing able to approve anything.
Who reviews what
Section titled “Who reviews what”| Kind of content | Reviewed by |
|---|---|
| A condition, a drug, a threshold | A physician or senior APP reviewer for that system |
| Red flags and escalation criteria | The curriculum owner for that system |
| Policy, logistics, contacts | The department lead |
| Navigation, structure, wiki mechanics | The wiki maintainers |
Each system’s owner is named in the Curriculum Map, so there is always a specific person to ask rather than a vague “the department”.
Marking a page reviewed
Section titled “Marking a page reviewed”Setting a page to Reviewed is a separate act from approving an edit, and it should be. The badge says a clinician has checked the whole page against its source — which is a different and bigger claim than “this edit looked fine”.
To do it: open the page, Suggest an edit, set the badge to Reviewed, publish. It is an ordinary edit, so it is attributed and revertible like any other.
Setting Ready for review needs no permission — any contributor may do it, and it is how a page gets your attention.
Why a passphrase, and not something cleverer
Section titled “Why a passphrase, and not something cleverer”Three alternatives were considered and rejected, and the reasons are worth keeping:
GitHub pull-request review. Would mean every reviewer needed a GitHub account and had to learn GitHub. The wiki goes out of its way so that nobody needs that, and a reviewer who cannot get through the door will simply stop reviewing.
Cloudflare Access — real email one-time codes, genuinely stronger than a passphrase, and auditable by an organisation that wants that. It needs a plan check and setup in the Cloudflare dashboard. This is the right upgrade if the department wants it, and the right thing to propose when somebody asks why review is not behind single sign-on. It is not switched on silently because it is a decision for the department, not a technical detail.
One shared passphrase in a group chat. Everyone knows it, so an approval cannot be attributed to a person and nobody can be removed without changing it for everyone. That recreates exactly the single point of failure that named accounts exist to remove.
When the review queue is empty
Section titled “When the review queue is empty”That is the goal, not a problem. Ordinary corrections do not wait, so a quiet queue means the department is editing the wiki and getting on with it. Pages waiting to be marked Ready for review are the ones worth your attention — the curriculum map shows what is still a skeleton.