Both nawiki and pihwiki which are locked belong to group0 so I will monitor the script run today once the wmf.24 is fully deployed and confirm that it's running correctly.

Not sure if this task requires dedicated QA since it's only "internal code" for now, doesn't get exposed in any production code path yet. Should we resolve right away this kind of tasks once the related patches are merged? cc @Michael

Next step would be to actually run the migrate script. Given we just recently merged T406701 I'll wait until that runs for some days in production before running it. I'm gonna be working on adding a feature flag on the changes that start reading from config meanwhile.

QA notes cc @Edtadros

Status notes

The experiment is live since September 29th 22:30 UTC+2. The Growth KPI dashboard shows appropriate bucketing for each group. We are already seeing computed CTRs in the automated analysis dashboard but that traffic is still from notifications scheduled prior to the deployment that are all getting the "control" messaging. Traffic should be analyzed from October 1st ~22:30 UTC+2.

Thanks for catching this. The impact is bad for newcomers since they won't get the notification as re-enqueuing is deliberately omitted for this jobs and similar.

We don’t seem to need extra information on the client error schema because we haven’t used the m-dot domain much to discriminate errors. In many cases GrowthExperiments has specific code paths for mobile that make it obvious from the stack trace.

The relevant code has been removed. Declining this until Growthbook integration happens in xLab.

Is the expectation that the code produced is both compatible with the development setup and the production one? Or are you thinking of compiling a bundle with the outcome of modules/ext.growthExperiments.StructuredTask.PreEdit/common and App.vue? The import mechanism may be a problem for both JS and less files. I believe that's why we ended up with a build the last time we tried this. cc @Cyndymediawiksim @Michael

I've been discussing with @phuedx on the right steps to test the experiment enrollment for the specific feature of notifications. Here's a summary to clarify the enrollment expectations from Experimentation_Lab/Conduct_an_experiment#Test_and_debug. There are three enrollment authorities that xLab will prompt for user enrollment before MW initialization, the result of each enrollment may or not be overridden by the next authority. Below is a table

After discussing with Experimentation Platform team about the opportunities to build some automated dashboard for the CTR metric in Superset the conclusions were that the cost of building something custom in MW/xLab that would fit this use case would take 3-5 weeks of work as estimated by @mpopov and that the work would be redundant with the upcoming plans of EP to adopt (growthbook). That's because Superset lacks a concept of metric catalog and each metric monitored would require a new tab, manual setup, etc.