@Prtksxna is the question "Were you able to find the editors you were looking for?" still valid? Since there will no longer be the yes/no checkboxes.

@STran I've updated the mock and the question. In a meeting with @Tchanders we discussed that the question might change before deployment but we can use this for the performance and security(?) reviews.

From the description:

a 'freeformTextLabel' with the label "What factors do you look for when you're trying to find similar editors"

Does this mean the placeholder of the textarea? If yes, can keep this empty for now.

In T307025#7890883, @Prtksxna wrote:

@STran I've updated the mock and the question. In a meeting with @Tchanders we discussed that the question might change before deployment but we can use this for the performance and security(?) reviews.

Here's a deployment-blocking task: T307215: Update survey wording and privacy statement link

Change 787793 had a related patch set uploaded (by Tchanders; author: Tchanders):

[operations/mediawiki-config@master] Add QuickSurveys survey for the SimilarEditors feature

https://gerrit.wikimedia.org/r/787793

Notifying @Krinkle from Performance and @Jdlrobson from the Web team, as outlined in: https://www.mediawiki.org/wiki/Extension:QuickSurveys/Deploying_surveys

Are there any more steps we should take? Thank you!

There's an outstanding question for @Niharika about how long the survey should be up for, and where.

Moving this task to Stalled, since we won't actually merge this until the deployment date.

I had the chance to discuss this task with @Niharika and @Tchanders last week. Surveys are usually aimed at the general public through insertion on articles, which usually means surveys are sensitive to the performance budget of our tier-1 traffic. In this specific case, of using the QuickSurveys framework to programmatically invoke a survey within the experience of a special page, this is not neccecarily the case.

I don't know off-hand whether QuickSurveys makes some of its decisions server-side, if it does, and it ensures no added payload takes place on pages in content namespaces, then indeed you may consider us notified with no concerns.

If it currently makes this decision only client-side and after it loads significant code unconditionally, then we may want to take new measurements of how this works, and then decide together whether this warrants improvement by scoping the impact to special pages. Either by improving how QuickSurveys applies the conditions, or by possibly advising a workaround (e.g. don't register the survey completely, and invoke it fully programmatically such that it acts the same way as if it wasn't installed/registered as far as article pageviews are concerned).

Thanks for the heads up! It's my understanding that given this survey is shown only on a certain special page, the code will need to be modified to make sure the survey code is only loaded on that page. When surveys are active, they tend to skew a lot of our performance metrics as they add a cumulative layout shift. I think a small modfication would satisfy @Krinkle's request above and any concerns web have, while also being a really valuable improvement to the codebase:

• The hook only adds the module if isAnySurveyAvailable is true https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/master/includes/Hooks.php#L49 so an update to the logic in https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/8af021bf539f9106381e0a075a407b0c700105d5/includes/SurveyContextFilter.php#L37 could restrict the survey to this one page.

Thanks @Krinkle @Jdlrobson. The ext.quicksurveys.init module is loaded manually by the SpecialSimilarEditors PHP class. We're essentially using a workaround to ensure the survey isn't available on any other pages by setting the audience config: page ID 0 will never match - or if it does, it won't exist.

(Arguably it's fragile to control this via that config, but the freeformTextLabel and embedElementId configs are similarly used to control the appearance/choice of surveys, so it's not a new pattern. It would be nice to update some of these things, and similarly to add a way to display surveys on special pages, but I think it would need a bit of consideration, e.g. what would happen to surveys enabled everywhere, all vs some special pages, etc. I think doing this properly is a bit beyond the scope of our SimilarEditors work.)

I've updated the task description to add a time estimate of when the survey will be enabled. I notice that the QuickSurveys extension is only enabled as and when needed (e.g. it's currently not available on English wikipedia: https://en.wikipedia.org/w/index.php?title=Special:Version) - I suppose we'd enable the extension on English Wikipedia when we deploy our config, then disable it when we undeploy?

Change 787793 merged by jenkins-bot:

[operations/mediawiki-config@master] Add QuickSurveys survey for the SimilarEditors feature

https://gerrit.wikimedia.org/r/787793