survey questions: flexible implementation

Not urgent at all, but survey questions should not be hardcoded in tests, as is currently the case.

• They should be defined flexibly, either in a CSV or in the database, so that they can be modified (phrasing mostly), by a series of variables (label, labelNote, type, options...?)
• It should be possible to activate them separately depending on the test/survey (e.g., survey_id=1 could ask for birthyear + L1; survey_id=2 could ask for L1 + other languages, etc.)
• They should be easily translatable via JSON localization (that is the tricky part that might make it more difficult to combine i18n with database definition of the fields...

changed milestone to %0.4: Tests and studies improvements

added Studies & tests label

assigned to @dvanrossum

added Nice to have label

Just to be sure, you're talking about the extra-questions, and not the test's questions? If so, I think that localization shouldn't be a big issue, as the CSV/database could contain the text reference (i.e. surveys.questions.14.label) rather than the actual text (we may even deduce that from the question id). But in such case, adding new questions should be done carefully to ensure that the translation exist (and as it's fixed into a json file anyway and not the database, I would go for CSV here).

Yes, talking only about the extra-questions. Perfect solution. I agree with defining the reference in the CSV and then the text in the localization JSON.

How do you see the activation of some questions depending on the survey, would they still get a special group id? Or the CSV defines which survey has which question, or something else?

I suppose it would be more logical to define everything in the CSV, but I am not sure where/how to include open-ended questions (different types) in the survey.

Note: While preparing the CSV for the new test, I realised that combining survey_ids, group_ids and item_ids, which are all ±random numbers, tends to be difficult with only 2 surveys and 5-6 groups... I'm afraid that, in the long term, it will be really hard to maintain and to continue developing... So later, we'll probably need a more sustainable system (database?). Having the items in separate folders is not the problem, but maintaining groups and surveys is tricky.

We could go for a db-only suvey management, and it's probably a better final solutions. It shouldn't be that hard, as API rooutes are already there anyway. But the advantage I see for CSV over DB-only is creation time (especially bulk creation/edition). How would you imagine that?

Yes, I think DB survey management is the long-term solution.

Maybe it could be possible to have:

• all management (CRUD, in particular edit/update, delete...) via DB
• but creation could ALSO be done via a fast script (only creation, not edition or reset)

added Open for discussion label and removed Nice to have label

mentioned in issue #166

marked this issue as related to #166

unassigned @dvanrossum

Current to-dos (@bridubois, or re-assign to Danial):

• remove hard-coded survey questions from test
• implement flexibly as a different type of test and items, that can be added to other tests