@VirginiaPoundstone you should have editing rights - lmk if not

hi @phuedx I think I was thrown off by the GrowthExperiments' implementation of overriding bucketing assignments. They use UserOptionsManager to set variants for their users. And actually just very recently Growth team introduced a new class ExperimentUserDefaultsManager which leverages $wgConditionalUserOptions in order to apply variants to existing users without having to store that info in the database.

just curious if we should limit allowable options? in @Sfaci's feature branch, there is no limit to how many OKR chips can be added

@VirginiaPoundstone Based on product prioritization from https://docs.google.com/document/d/1B5OfJfBiSfa19IRm-dohZuzAHNYOqXdLw2mhHqJh7Dg/edit?tab=t.0#heading=h.b9g0gh3wsg1f, should this task still be worked on in this sprint? Or should we spin up whatever tickets are needed after the high + medium priority line items are left?
cc @Sfaci

@VirginiaPoundstone Is this task on hold then until we have design resource again?

hi @EChukwukere-WMF i'm having trouble duplicating this error on the latest upstream main and on staging -- lmk if we should schedule some time to step thru

In T375227#10163654, @Sfaci wrote:

It seems slug validator is much stricter than the function we use to generate the slug for instruments. At this time "spaces" are the only restriction we have to build the slug and all special characters are included while the user types the human readable one, but validator doesn't allow punctuation marks (? ! , . . . .). Should they be allowed? Should we be more restrictive and remove punctuation marks when building the slug?

hi @EChukwukere-WMF I can't recreate this error either - I tested locally and it appears to be working.

@VirginiaPoundstone is it ok to spin off the corresponding Java lib updates AC into another task for a later sprint? since we narrowed scope to MW as the primary use case for Growth's experiment, we're focused on the JS/PHP libraries for now.

It's that naming time again - what should we call this stream?

@Sfaci - sounds good re: stores -- whatever you think is the most expedient makes sense to me

Per discussion with @Sfaci I think we agreed that it makes sense to have 2 separate pinia stores - one for instruments and one for experiments.

In T373467#10125438, @Sfaci wrote:

fields we consider as excluded for experiments are the ones that we should consider as optional in the database (so far these fields were defined as mandatory)

hi @Sarai-WMF hi @Sfaci -- I agree with Santi's inline responses to Sarai's questions.

hi @EChukwukere-WMF cc @WDoranWMF @Sfaci @SGupta-WMF - I added a lot more info to the ticket description (tried to give a succinct overview of the various parts of the system) and increased the scope of the task (and hence bumped estimate) to include a plan for end-to-end testing of the whole system rather than and/or including testing pieces in isolation.