Make a design / plan for the Great Refactor

[drikusroor]

Order of renaming models, routes and other classes

1. ExperimentCollectionGroup => Phase - This model doesn't have too much logic and references yet, so it should be fairly straight forward. I think we can do this step independently. 2. Experiment => Block - This rename is probably best to do before doing the rename from ExperimentCollection to Experiment to avoid conflicts. See also: #1145 and #1146 3. ExperimentCollection => Experiment - Once we are absolutely sure all renames from step 2. are completed, we can do this step.

Routes?

And what to do with routes? Right now we have the following routes (in the frontend):

• /collection/{collectionSlug}
• /{experimentSlug}

Will we follow the same pattern and do it like this?

• /{experimentSlug} (formerly collectionSlug)
• /block/{blockSlug} (formerly experimentSlug)

Or will it also mean a "rule" cannot be independent anymore and is always part of an "experiment" (formerly collection)? In that case, it would probably have to look more like this:

• /{experimentSlug} (formerly collectionSlug)
• /{experimentSlug}/block/{blockSlug}

## Rule model / class

As the plan is to rename "experiment" to "rule", what will we do with the original "Rule" (sometimes aka "ruleset") class? If we allow both the model and the class to be named "Rule", instantiating a new Rule model would look like this:

UPDATE: Rule (fka Experiment) will be called Block. See also #1131

new Rule(name="Categorisation", rule=RULE_RULES[Categorization.ID])~~

Should we rename this to "RuleLogic" or "Logic" perhaps? Instantiating it like this:

new Rule(name="Categorisation", logic=RULE_LOGICS[Categorization.ID])~~

Further configurationability

In case we want to give the admin user more freedom in configuring the rules (formerly experiment), will this have implications for this renaming project? Let's take Toontje Hoger as an example:

• Toontje Hoger => Experiment
  • has a Group with Grouped Rules (formerly aka ExperimentGroup & GroupedExperiment)
  • Mozart => Rule
    • Introductions
    • Instructions
    • Questions
    • Trials
    • Outro / Debriefing (often the Final component)

to be continued...

Related to #928

[BeritJanssen]

928 has some of the plans of how models should be moved. It would be good if we could identify

• an order in which to move models and migrate data
• steps which depend on other steps
• conversely, steps which can be done independently
• also think the consequences through for the admin.py and forms.py, i.e., how would the setting up an experiment wiki look like after the refactor?