hey @HFan-WMF and @Sneha, there's some disagreement between the description in the parent task T421999 and the figma file about what should happen when a user in the treatment group logs in. Specifically, should they see:

• The popover indicating where they can view their reading list
• The popover indicating that the watchstar has moved

Confirming that the experiment is turned on in test kitchen with data collection beginning tomorrow as the related code rides the train to all wikis

Thanks @aude for your help in the above comments; I've updated the patches accordingly and am assigning this task to you for code review

Thanks, @aude - I did something similar to what QuickSurveys does, although I'll welcome your feedback in code review on how I designed the storage token to handle both impressions and survey completion.

hey @Jdlrobson, I'm writing a testing strategy and am looking into how we can discover currently running surveys. So far, I'm looking at $wgQuickSurveysConfig in mediawiki-config and other codebases, plus searching for uses of showSurvey(). Is there anything I'm missing?

I'm assigning this to myself as the responsible person, but this will be a collaborative effort between the REx engineers and @egardner

The Reader Experience team decided to decline this task.

Thanks @SToyofuku-WMF! Yeahhhh not being able to label the text input is a big problem :/ The radio buttons also look pretty silly IMO. Curious what @Sneha thinks!

Got it, thanks @kostajh and @Jdlrobson-WMF. I also wrote my comment before seeing that the patch has been merged - since it's already done and makes the Vector and Minerva experiences consistent, I'm good with it.

+1 to Volker's comment; is this needed? Would be nice to avoid more differentiation between regular and temp UIs than necessary

hey @SToyofuku-WMF, @Jdlrobson has some feedback on how we might handle this that differs from what I've suggested, so let's discuss before you get too far on this task (sorry if you already have!)

Confirmed that this warning is no longer being logged on beta or mediawiki.org; resolving for the sake of communicating that this is no longer a train blocker

FWIW I think it would be easier for us to show it to users with at least one article currently saved, vs. users who have saved an article at some point but may not have any saved now. I'm also not 100% sure how we'll handle the criterion about seeing the survey 10 times but determining whether that's feasible can be part of this task!

Thanks for identifying this, @Etonkovidova! I've pushed a patch and will follow up with the team on whether we should backport the fix.

This feels like a pretty destructive action that could cause problems if done accidentally. Should we confirm that the user actually wants to remove the article from all lists, or offer an undo option?

IMO, that "beta" is different than the tag for ReadingLists. For the Codex docs site, we want to warn people that the site represents the beta version of Codex, not the canonical, released version, which is documented at a different web address.

Sample config for local dev and testing:

We need to finalize the audience criteria cc @Sneha and @HFan-WMF

@Sneha good news - the "progressive" InfoChip type just landed in Codex and will be included in the next release, if we want to make the chip blue instead of green (blue/progressive indicates something of importance or interest, green/success is usually a response to a successful action)

Oof, good point @DSmit-WMF. I think this warrants its own task so we can find a solution that doesn't require a breaking change. I've created T419474 to cover this (feel free to add screenshots; some of the ones you posted are private so I didn't include them)

@DSmit-WMF I agree it looks a bit funky, maybe @bmartinezcalvo has another idea? I just want to avoid this on desktop:

Moving to "Needs QA" so we can review the TypeaheadSearch bugfix (T418172) on beta