Giving Designer Git-like (super)powers


With version control systems like Git, one can do several things that are potentially interesting for questionnaire developers:

  • Commit changes
  • Work on a “feature” branch without affecting the main branch
  • Merge a “feature” branche into the main branch

Put in questionnaire developer terms:

  • Commit: make changes to questionnaire and describe both what changes were made and, more importantly, why.
  • Branch: work on questionnaire changes–for example, revising questionnaire structure, prototyping different ways to implement questions, testing validations, adding a new section–without either making changes to the main questionnaire or creating a new testing questionnaire.
  • Merge: bring changes from a testing branch into the main questionnaire–importantly, without the manual work of identifying all changes in the branch and applying those changes in the main questionnaire.

Affected subsystems

Will definitely affect Designer. May affect Tester/WebTester depending on whether branches are different than new questionnaires.


In general, questionnaire developers who want/need:

  • Readable record of what was changed and why
  • Easier means of testing questionnaire content and merging into the questionnaire

In particular, questionnaire developers working on survey initiatives that span several countries and that have harmonized questionnaires. When the main questionnaire changes, country implementers need to see what has changed and why, and implement/import those changes to their “fork” of the questionnaire.


For a large survey initiative in the West Africa Economic and Monetary Union, we had to manage changes to the questionnaire over time (and across countries). When changes occurred, we needed to compile them manually and communicate them carefuly (painstakingly) to implementing partners (e.g., big Google Sheets files that detailed which attribute of which question changed, how, and why). When any errors arose, we had to manually identify the source(s) (rather than do any diff-style comparisons or investigate commit-like change logs).

For other similar initiatives, this type of functionality would be equally useful. A few potential beneficiaries:

  • Other regional projects (e.g., East African Community harmonization initiative)
  • Other multi-national projects (e.g., 50x2030 initiative, Feed the Future, DHS, etc.)
  • Multi-year survey initiatives (e.g., LSMS panel surveys done consistently in Survey Solutions)


There are non-Survey Solutions workarounds for each issue:

  • Commits. A few complementary options:
    • Keep track of changes separately from Survey Solutions
    • Add comments to the Designer history.
  • Branches. A few steps:
    • Create a copy of the main questionnaire
    • Make changes on the copy
    • Keep track of all changes
  • Merge.
    • (Keep track of changes to branch questionnaire, as above)
    • Make all changes from “branch” questonnaire in main questionnaire

Market examples

For CAPI software whose questionnaires are built from plain-text files that questionnaire designers can (must) touch, one can simply use Git. For example:

  • CSPro
  • ODK/SurveyCTO that uses xml files
  • ODK/SurveyCTO that uses CSV to create questionnaire
  • Blaise (?)


Should not impact those who do not want to use this feature. Should be all benefit to “power” users without any cost for “regular” users.


Behind the scenes, Survey Solutions will likely be tracking changes to the JSON file that underly questionnaires. If the JSON files are not exported outside Designer, all is good. If the JSON files are exported outside Designer and may be changed there, this opens the door to several potential problems:

  • Designer now needs to ingest JSON from an external source and validate its contents, flagging any problems
  • Malformed JSON
  • Imported JSON has attributes that are incompatible with current version of Designer (e.g., attributes deprecated)