Decide on structure for A/B test content - how are messages and templates stored inside the content repo: temporarily (only for the test, e.g. separate file) / permanently (inside the existing files; risk of forgetting it after end of test)

Questions for the fundraising team:

• Do you need a/b testing with buckets or more of a "theming" where the page design is decided by a parameter from a banner (which does the bucketing)?
• Do you need a "history" where you can display old themes?
• Do you need to automatically expire "tests" ? There can only be either theme history OR campaigns.
• Do you need multiple simultaneous tests on different parts of the page?

TODO rewrite the task description as a story with acceptance criteria (design only, no controller or JS changes).

@Tobias_Schumann_WMDE

• yes, we need buckets and random sampling for people coming from wikimedia.de (to the membership form, but in general also thinkable to the donation form); for tests of the donation laning page we also need the testing possibility via banner links
• no, we don't need a history
• tests should have campaign character, hence start and end date
• yes, we need multiple simultaneous tests; for instance a lading page test for users coming from donation banners and a randomly sampled confirmation page test after the donation

@kai.nissen : I just stumbled upon our "hack" for enabling/disabling Sofortüberweisung with an URL parameter (https://github.com/wmde/FundraisingFrontend/blob/master/src/Presentation/SofortToggleServiceProvider.php), which is kind of an A/B in itself. I think we might need to adjust the acceptance criteria to not only encompass skin changes but also "custom feature toggles" where functionality can be turned on/off.

Or you could put the removal of what I consider technical debt (special handling of a specific URL parameter) into a separate ticket.

Thank you, nice thinking! I added a sub-task to this.