A workshop should be a text file

We have published six workshops as Markdown files. Not decks, not facilitator guides, not a booking form. Six text files you can download, edit and run, at impactmojo.in/facilitator-kits. This post is about why that format, which sounds like a technical detail, is the part that matters.

What normally happens to a workshop

A good session gets built once, by somebody who knows the material, usually under time pressure. It ends up as a deck of forty slides and a Word document called facilitator notes v3 FINAL. Both go into a shared drive.

Six months later a colleague needs to run something similar. She opens the deck. Slide 11 refers to a 2019 figure that has been superseded. Slide 23 has an animation that only works in the original template. The notes document explains slides 1 to 14 and then stops, because the person writing it ran out of afternoon. She has no way to tell which parts were load-bearing and which were filler, so she rebuilds most of it, badly, and the cycle repeats.

Nothing in that story involves anyone doing their job poorly. It is what happens when knowledge is stored in a format that resists editing.

A deck is a bad container

Three specific problems, none of them about aesthetics.

You cannot see what changed. Two versions of a deck sit side by side and tell you nothing. A text file diffs: three lines changed, here they are, this is who changed them and when. That sounds like a programmer's concern until you have tried to work out whether the version you are about to teach from contains a correction somebody made in March.

The content and the presentation are welded together. In a deck, moving an argument means moving boxes. Reordering a session means dragging slides and fixing what breaks. The structure of the thinking is mixed up with the layout of the rectangles, and you cannot change one without disturbing the other.

Nobody can pick it up. The reason facilitator guides go unread is that they are a second document explaining a first one. Keeping them in sync is work nobody is paid for, so after the second revision they stop describing the deck they accompany. A single file has no second document to fall out of step with.

What a workshop file looks like

The tool we built these for is Workshopy. Its format is close to the smallest thing that could work: a # heading starts a step, and #[quiz] makes that step a graded quiz. Inside a quiz, ## is a question and the options are ordinary Markdown checkboxes, with the correct one marked [x].

That is the entire specification. Here is a real fragment from one of ours:

# Work out both ratios

Do the arithmetic yourself. It takes thirty seconds and it lands
better than being told.

1. Divide women's minutes per participant by men's.
2. Divide women's minutes per person by men's.

#[quiz] Check yourself

## What does "3.2 times" condition on?

- [ ] Rural households only
- [x] Only the people who did any unpaid work that day
- [ ] The whole population aged 15 to 59

A facilitator can read that and know exactly what happens in the room. So can a participant. So can a person deciding whether this session is worth an hour of their team's time, which is a group that almost never gets to see inside a workshop before committing to it.

The constraint we designed around

Workshopy's free tier runs sessions up to 45 minutes with up to 30 participants. We wrote all six kits to that limit rather than writing longer ones and hoping.

This is worth saying plainly because the alternative is a small dishonesty that the sector commits constantly: publishing a resource that technically exists on the free tier but cannot actually be used there. A 90-minute workshop you can only run by paying is a lead magnet, not a resource. Ours stop at 45 minutes because that is the room you are actually going to get.

The limit also improved the sessions. Forty-five minutes for eight steps means roughly five minutes each, which rules out lecturing. Every kit has participants doing arithmetic, sorting their own indicator table, or writing a sentence about their own programme within the first ten minutes.

What is in the six

Each one comes out of a free course we already have, and each ends by pointing back at it.

The denominator decides hands people four numbers from India's Time Use Survey 2024 and asks them to divide. They get 3.2 and they get 5.9, from the same table, for the same year, and then they work out why: 94.2 per cent of women did some unpaid work on the reference day against 51.5 per cent of men, and one of the two denominators quietly deletes that fact. It is a better argument for stating your denominator than any amount of methodology training, because they derived it themselves.

The assumption you didn't write down asks people to find the arrow in their own theory of change they would least like to defend, then write what they would see early if it were failing. Most cannot answer the second part, which is the point: an assumption with no observable failure signal is not being monitored, whatever the logframe says.

Indicators beyond the headcount makes people sort their own indicator list into delivery, reach and change, and count the three piles. The shape of the answer is usually the whole diagnosis.

What an attribution claim can carry puts three sentences about identical data next to each other, each claiming more than the last, then has people grade a real claim from their own reporting and rewrite it at the level their design supports. It is normally one level lower.

What your dataset refuses to count goes after the residual category — Other, NEC, Not stated — and who is structurally absent from a frame built on households.

The question that can do harm is for teams asking about violence, debt, caste or status. It works through the WHO safety provisions that constrain the sampling design rather than the ethics annexe, and then why a falling disclosure rate is the wrong thing to reward.

A guard, because the format has a silent failure

One practical note for anyone doing this themselves. The format's failure mode is invisible in a Markdown preview.

If you forget to mark the correct option with [x], the file looks completely normal. Every checkbox renders, the question reads fine, and the first you learn of the problem is a room full of people who have all been graded wrong. Similarly a ## outside a quiz step looks like a question and is not one, and a stray # mid-paragraph silently splits a step in two.

So we wrote a checker, scripts/check-workshop-kits.py, that reads the six files and fails if a quiz has no correct answer, if a question has fewer than two options, if a heading level appears that the format does not use, or if a kit grows past twelve steps and stops fitting in the room. It runs on every commit. We tested it by deliberately breaking a file three ways and confirming it caught all three.

It took about twenty minutes to write and it protects against the class of error that is otherwise discovered in public.

The part we are least sure about

Giving away material that people currently pay us for is not obviously correct, and we should not pretend it is.

We run three-day team workshops at a flat cohort rate, and some of what is in these six files has appeared in them. The bet is that a person who runs the 45-minute version with their own team, and finds it useful, is a better prospect than a person who read a brochure — and that the ones who decide they do not need us after running it were never going to book anyway.

That is a bet, not a finding. Ask us in a year.

What we are more confident about is narrower and does not depend on any of that: a workshop stored as a text file survives contact with the next person who needs it, and a workshop stored as a deck mostly does not.

The files are at impactmojo.in/facilitator-kits. Take them, change them, run them, and do not feel obliged to say where they came from.