I did one pass over the description of this task and it looks good to me.

Re sampling rate estimation: it's a tough one and it's roughly inline with what I would estimate, though my current estimate is that you will get less than 1K in 48 hours. :) When we had a sampling rate of 1:40 in enwiki (mobile and desktop) for a week, we got ~28K responses. If you sample at a sampling rate which is an order of magnitude less, I expect you to get no more than ~3K responses in a week. and that may put you closer to 800 responses in 48 hours. If you can tolerate that margin of difference, the current sampling rate you have is good. If not, you may want to change it.

@leila Thanks! A smaller than 1k sample is probably better. The primary purpose of this round of survey is to gather enough free text responses to create a taxonomy of reasons people trust Wikipedia articles (and/or don't). Secondary purpose is to get a very rough distribution of responses. Second round of survey will use the reason taxonomy, and pull a larger sample.

Hey all, can I please request a ping in phabricator whenever we enable QuickSurveys in future? They cause a large regression in performance on mobile which is scary to me and my team if we don't know the cause (and the fact its temporary).

@Jdlrobson I don't mind pinging you specifically, but is that the best option? Are there any other stakeholders who need to be alerted about mobile performance changes? Is there any better way to get that message out?

BTW we have decided to hold off on deploying QuickSurvey to production until mid-Jan.

Holding off on deployment until mid-Jan. We decided that deploying during fundraising would be disruptive and counterproductive, given the competing CTAs and the severely constrained screen real estate.

We are observing some interesting behavior on beta wikidata, both in desktop and mobile view.
A <div class="ext-qs-loader-bar mw-ajax-loader"></div> gets attached to what could be considered "the top of the page" in a traditional wiki - maybe the wikidata use case was not taken into consideration? What was the desired behavior in that regard?

I attached screenshots as the gray box does not to show consistently for everyone (maybe due to some A/B logic).

@Pablo-WMDE I think it's a case of messages not being created in the MediaWiki namespace. I probably should deploy QS only on enwiki on labs, if that's causing issues with your users. Please let me know.

@bmansurov Given the gray box appears right in the heart of a feature under active development, about to hit QA, I'd appreciate if it wasn't there.
I can't tell if solving this via configuration or by adding a check in the code (not to show on .wb-entitypage which generally don't seem to be compatible with it) is the better approach.
The latter would certainly act as a safety feature in case of accidental mal-configuration, too.

Im fairly confident that this may have caused a big spike in client side errors due to how cached HTML works. @bmansurov it seems the flag to disable the survey removed Extension:QuickSurveys from en.wikipedia.org, but didn't counter for the fact that calls to the following remained in the HTML:

mw.loader.load('ext.quicksurveys.init' )

Interestingly this throws a client side error which hits the statsv beacon. If nobody beats me to it i will restore the extension to enwiki, set enwiki to empty array and leave a large note for future survey deployers.