Change Details

For the TempAccount rollout, @TAndic has raised the issue of how [[ https://www.mediawiki.org/wiki/User_account_types | the new user type ]] will affect the [[ https://www.mediawiki.org/wiki/Extension:QuickSurveys#Defining_an_audience | "anons" audience configuration ]] for quicksurvey. Open questions: - find/confirm how the "anons" config is currently implemented (presumably using `User::isAnon()`?) - is there an owner of this code (Trust & Safety Product, Readers Web) that is also part of the rollout? - How does/should the new temp user account affect audience selection? Does Research have a preference? - `User::isAnon()` == only reader - `User::isTemp()` == user has edited - `User::isNamed()` == permanent user (previously `! User::isAnon()`) - Some approaches: - leave "anons" config as is: only readers, where as previously users that ip edit were also considered anonymous - switch to using `User::isNamed()` to keep previous semantics (temp editors are also considered "anon", which would make the config name incorrect) - add new config param (e.g. user_type with values `reader`/`temp`/`named`). # Requirements Context: T376206#10541192 [] This change is ideally done when no surveys are active. if this is not possible please coordinate with existing survey authors to make sure you don't cause disruption. [] Solution should be minimal and only add isTemp to the existing audience configuration. [] Given the existing `anon` boolean SurveyFactory::validateSpec should throw a InvalidArgumentException if a survey is created where “isTemp” is true and “anon” is true (as this is impossible scenario)

For the TempAccount rollout, @TAndic has raised the issue of how [[ https://www.mediawiki.org/wiki/User_account_types | the new user type ]] will affect the [[ https://www.mediawiki.org/wiki/Extension:QuickSurveys#Defining_an_audience | "anons" audience configuration ]] for quicksurvey. # Requirements Context: T376206#10541192 [] This change is ideally done when no surveys are active. if this is not possible please coordinate with existing survey authors to make sure you don't cause disruption. [] Solution should be minimal and only add isTemp to the existing audience configuration. [] Given the existing `anon` boolean SurveyFactory::validateSpec should throw a InvalidArgumentException if a survey is created where “isTemp” is true and “anon” is true (as this is impossible scenario) # Q and A > find/confirm how the "anons" config is currently implemented (presumably using `User::isAnon()`?) Correct. Surveys define a boolean `anon` field. > is there an owner of this code (Trust & Safety Product, Readers Web) that is also part of the rollout? No but my understanding is we are identifying someone to work on this task. > How does/should the new temp user account affect audience selection? Does Research have a preference? > - `User::isAnon()` == only reader > - `User::isTemp()` == user has edited > - `User::isNamed()` == permanent user (previously `! User::isAnon()`) > - Some approaches: > - leave "anons" config as is: only readers, where as previously users that ip edit were also considered anonymous > - switch to using `User::isNamed()` to keep previous semantics (temp editors are also considered "anon", which would make the config name incorrect) > - add new config param (e.g. user_type with values `reader`/`temp`/`named`). New config parameter seems like the least disruptive approach here for now.

For the TempAccount rollout, @TAndic has raised the issue of how [[ https://www.mediawiki.org/wiki/User_account_types | the new user type ]] will affect the [[ https://www.mediawiki.org/wiki/Extension:QuickSurveys#Defining_an_audience | "anons" audience configuration ]] for quicksurvey. Open questions: - find/confirm how the "anons" config is currently implemented (presumably using `User::isAnon()`?) - is there an owner of this code (Trust & Safety Product, Readers Web) that is also part of the rollout? - How does/should the new temp user account affect audience selection? Does Research have a preference? - `User::isAnon()` == only reader - `User::isTemp()` == user has edited - `User::isNamed()` == permanent user (previously `! User::isAnon()`) - Some approaches: - leave "anons" config as is: only readers, where as previously users that ip edit were also considered anonymous - switch to using `User::isNamed()` to keep previous semantics (temp editors are also considered "anon", which would make the config name incorrect) - add new config param (e.g. user_type with values `reader`/`temp`/`named`). # Requirements Context: T376206#10541192 [] This change is ideally done when no surveys are active. if this is not possible please coordinate with existing survey authors to make sure you don't cause disruption. [] Solution should be minimal and only add isTemp to the existing audience configuration. [] Given the existing `anon` boolean SurveyFactory::validateSpec should throw a InvalidArgumentException if a survey is created where “isTemp” is true and “anon” is true (as this is impossible scenario) # Q and A > find/confirm how the "anons" config is currently implemented (presumably using `User::isAnon()`?) Correct. Surveys define a boolean `anon` field. > is there an owner of this code (Trust & Safety Product, Readers Web) that is also part of the rollout? No but my understanding is we are identifying someone to work on this task. > How does/should the new temp user account affect audience selection? Does Research have a preference? > - `User::isAnon()` == only reader > - `User::isTemp()` == user has edited > - `User::isNamed()` == permanent user (previously `! User::isAnon()`) > - Some approaches: > - leave "anons" config as is: only readers, where as previously users that ip edit were also considered anonymous > - switch to using `User::isNamed()` to keep previous semantics (temp editors are also considered "anon", which would make the config name incorrect) > - add new config param (e.g. user_type with values `reader`/`temp`/`named`). New config parameter seems like the least disruptive approach here for now.