| dr0ptp4kt added a comment. |
It doesn't seem like a good idea that operators all around the world will be sending us surveys and configuration changes that will need to be modified and deployed by engineers.
I believe this would be facilitated by @DFoy on a case by case basis.
They could probably be exposed, if it was really necessary, or checked on the server and only send the relevant surveys to the client. Tying QuickSurveys to explicitly depend on ZeroBanner doens't seem like a good idea technically though.
I'd estimate this to be an 8 pointer if we really wanted to work on it. Maybe more (it may take some time to come up with a reasonable approach).
It occurred to me I could maybe check this with a live connection. I added my IP to a test configuration and it looks like the interstitial that comes in by way of ResourceLoader goes directly after an encoded JSON object. Does that change the tenability of accessing a variable or change the point value materially?
- How would sampling and eligibility work to ensure that a large percentage of ResourceLoader capable UAs on a given zero-rated network would be presented with the survey, but repeated survey presentation would be avoided?
I don't see what the issue would be here, normal QuickSurvey bucketing and selection mechanisms apply. Any thoughts on why this could be problematic @dr0ptp4kt?
No. Based on your note in T137151#2457107 it sounds like first the check for whether the user could in principal be surveyed is determined, and then the eligibility is calculated to determine whether to show the survey, with a session cookie or its like helping to avoid repeat sampling. In practice it seems like this would imply surveys would probably be run best over a short period to avoid showing the same survey too many times to a user (and an analyst looking at the data should be aware of the possibility of a user answering multiple times if the eligibility rate is cranked up).
Cc: bmansurov, atgo, DFoy, Lydia_Pintscher, Aklapper, dr0ptp4kt, Zppix, Winter, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, Yurik, jhobs, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
