Version control for surveys
Most survey tools keep one live copy of a questionnaire. You edit it, the edit takes effect, and the previous state is gone. That is tolerable until someone asks which version of question 14 the first 300 respondents actually saw — and there is no way to answer.
Putting the instrument under version control answers that by construction. A Siamang project is a real git repository: the questionnaire is a Python module in it, and every change is a commit with an author, a timestamp and a diff.
What that buys you
A diff of the instrument
Because the questionnaire is code, a change to it is a diff. Adding a screener, reversing a scale, changing a routing condition — each shows up as lines added and removed, reviewable before it reaches a respondent. Not a changelog someone remembered to write.
Branches, pull requests, a protected main
Two people can work on the same study without overwriting each other. Work happens on a branch; a pull request shows the diff; a merge brings it in. Branch protection stops anyone pushing straight to the branch you field from.
A history you can hand to someone else
Clone the repository over SSH or HTTPS and you have the whole study: instrument, analysis scripts, the configuration that says where the data goes. Mirror it to GitHub or GitLab if your institution wants a copy elsewhere.
Validation before fieldwork, not during
Each push runs the questionnaire through a sandboxed check and writes the result back onto the commit, so a broken instrument is visible in the history rather than in your data.
What the validation pass looks for
duplicate variables and question ids- Two questions writing to one variable silently overwrite each other in the data.
skip_to targets that do not exist- A typo in a routing target sends respondents nowhere, and you find out in the field.
unreachable pages and navigation cycles- A page no path reaches collects nothing; a cycle traps the respondent.
REQUIRED_CONDITIONAL- A required question that a condition can hide is a dead end for whoever hits it.
CATEGORICAL_WITHOUT_LABELS- A categorical variable with no value labels exports as bare integers.
MISSING_CODE_NOT_IN_LABELS- A missing code with no label becomes an unexplained 99 in the analysis.
quota cells against the questionnaire- A quota naming a variable that does not exist matches no response, so its cell never fills and fieldwork runs past the target it was meant to cap.
The quota check is the one that pays for itself. A quota naming a misspelled variable matches no response at all, so the cell never fills and the field keeps running past the cap it existed to enforce — expensive, and invisible until the data arrives.
Version control is the mechanism, not the point
Reproducibility is why anyone cares. Once the instrument has a commit history, an analysis run can be pinned to a specific commit, which is what makes a result checkable later — see reproducible survey research.
And once the data has somewhere to go, the same repository declares that too: connectors to your warehouse or database, or exports that keep the codebook intact.
Questions
Is this a real git repository or a version-history feature?
A real repository. Every project is backed by git, you can clone it over SSH or HTTPS, and branches, tags, diffs, pull requests, merges and branch protection all work the way they do in any repository.
What does 'validated on every commit' actually check?
Four things: the questionnaire's structure (duplicate variables, skip targets that do not exist, unreachable pages, navigation cycles), the quota definitions against the questionnaire, a strict lint pass, and policy checks on the packages a script declares.
Can two researchers work on the same questionnaire at once?
Yes — that is what branches are for. Each works on a branch, opens a pull request, and the diff shows exactly which questions and routing changed before anything is merged. Protected branches stop a direct push to main.
What happens if a commit breaks the questionnaire?
The commit is still recorded — history is not rewritten — but its validation status is red, on the commit itself, so you see it before deploying rather than during fieldwork.
Do I have to know git to use it?
No. The web editor commits to a branch for you, and there is a console for the same operations. Git is the substrate, not the interface — but it is there when you want to clone the study or wire up CI.
Look at a versioned study
The demo is a complete project with real commit history — questionnaire, validation status, analysis runs. No account needed.