I have some ideas about this:

• an extra field (string) in the session 'current_phase'
• This field will be copied in the comment field of each result (or if this field is already used in other experiments an new 'phase' field)
• A method in the session to collect the results per phase.
• A method in the session to determine round number based on the current phase

I personally think that the session.current_phase field might only make sense for a small portion of experiments, and will not add any information to the database that is interesting for users later -- they'll want to know which result is associated with which phase, and on session this field will be whatever value was set last. So I'm all for putting a phase field which is null=True, blank=True on the Result model. But if the comment field can be used for this for now, we might also just reuse this field, and perhaps give it a more descriptive name, e.g., "type"?

As far as I can see, all the reasoning will always go over the session.result_set anyway, or is there a direct advantage to knowing the session.current_phase which cannot be covered with the json_data? I know working with the json_data is unwieldy, but as far as I noticed, it's no bottle-neck to performance.

Again, if it's too inconvenient to work with existing fields (and I may be overlooking some problems!), go for it and add fields, but otherwise, I'd rather keep the models as lean and multi-purpose as possible.

I think you are right that we should only change this if it will make sense for a substantial number of future experiments. Working with the json_data as we do now does feel a bit counter intuitive, but indeed this doesn't seem to affect the performance, and does provide a lot of freedom to build whatever we want.

The comment field in the result is also fine as it is now, if we are not going to fill this with the current phase.

Maybe we can only make the comment field a bit easier to use then by adding it as an (optional) argument to prepare_result?
And also show the comment in the result in the django admin, cause I noticed it's not there.

I've made a subtask for the optional comment parameter in prepare results.

#248

I decided to still work on this issue. The rhythm experiments I originally implemented include some practice phase which has a lot of shared syntax, but the way it's implemented is pretty complex and depends on functions with a plethora of arguments: I'm afraid no-one will really know that the helper functions I implemented back then exist, or how to use them. I'm planning to move this to a dedicated practice.py rules file, from which experiments can inherit & perhaps piggy-back on some logic that's already been implemented.