Remove onward journeys AB test

[domlander]

What does this change?

Removes the Onward Journeys AB test.

Why?

We have collected enough data.

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

[cemms1]

@domlander if you've collected enough data but haven't finished analysis, you could turn the test "OFF" before removing it?
If you're happy to tear this down now that's totally fine but just double checking what you mean to do here

[domlander]

@domlander if you've collected enough data but haven't finished analysis, you could turn the test "OFF" before removing it? If you're happy to tear this down now that's totally fine but just double checking what you mean to do here

Hey Charlotte, yes my intention is to remove the test and all the associated code rather than to switch the test OFF. I prefer to do it this way for two reasons:

1. Code written for an AB test typically prioritises speed of release over long-term health of the code. When the feature is implemented permanently, the new PR will contain all of the code relevant to the feature. This ensures any shortcuts taken when implementing the AB test are not missed by developer or reviewer when making the feature permanent. An example.
2. It has the benefit of keeping the codebase tidy in case this test is forgotten about. For example, if the feature is deprioritised or it takes a long time to decide whether the feature should be made permanent.

[cemms1]

@domlander if you've collected enough data but haven't finished analysis, you could turn the test "OFF" before removing it? If you're happy to tear this down now that's totally fine but just double checking what you mean to do here

Hey Charlotte, yes my intention is to remove the test and all the associated code rather than to switch the test OFF. I prefer to do it this way for two reasons:

1. Code written for an AB test typically prioritises speed of release over long-term health of the code. When the feature is implemented permanently, the new PR will contain all of the code relevant to the feature. This ensures any shortcuts taken when implementing the AB test are not missed by developer or reviewer when making the feature permanent. An example.
2. It has the benefit of keeping the codebase tidy in case this test is forgotten about. For example, if the feature is deprioritised or it takes a long time to decide whether the feature should be made permanent.

Yep great points! I was just checking that you knew you could do that. Whether you should is a different question all together 😄