Change Details

Now that Growth features are on all Wikipedias, we can consider whether //autocreated// accounts should get them. Right now, if an account is created on wiki A (and gets the Growth features), and then the user goes over to wiki B (which creates them an account there), they don't have the Growth features on wiki B. ==== Implementation To ensure the enablement of Growth features is the same on all wikis, the easiest solution is to make use of [Extension:GlobalPreferences](https://www.mediawiki.org/wiki/Extension:GlobalPreferences). In other words, instead of enabling Growth features //locally// on account creation, we will enable the features //globally// in GlobalPreferences. That way, Growth features will either be enabled on all wikis for that user, or on none of them. On the database level, this can be done by adding rows to `centralauth.global_preferences`, using the user's global ID as `gp_user`. It seems doable via `GlobalPreferencesFactory::setGlobalPreferences`. I think we should keep the current mechanism as a fallback, in case GlobalPreferences is not available. **Autocreated accounts should NOT receive the Welcome survey.** ==== Open questions [X] How will this affect our experiments? - We are only including accounts that are NOT autocreated in our analysis, so it shouldn’t impact analysis. [ ] The place where users can disable our features will move. Instead of Special:Preferences, it will be possible on Special:GlobalPreferences. Can this confuse our users? [ ] How should we handle legacy users? Should we migrate everyone to global preferences? Should we only address this for new autocreated accounts? Should we notify legacy users that this is an option? ==== Acceptance Criteria This is a research spike that covers: - the engineering research needed to help make this work actionable. Especially determining how Growth preferences should work on Special:Preferences and Special:GlobalPreferences. - writing up subtasks to cover the work needed. Please break this work up so we can approach this in a more iterative way (and potentially only work on the lower-effort tasks if we determine a migration for legacy users is too much of an effort). In other words, likely we need separate tasks for the handling of new autocreated accounts and the handling of legacy autocreated accounts (for users with Growth features enabled).

Now that Growth features are available on all Wikipedias, we should evaluate whether they should also be enabled for autocreated accounts. Currently, if a user creates an account on wiki A, they receive Growth features on that wiki. If the same user later visits wiki B and an account is autocreated there, Growth features are not enabled on wiki B. This leads to an inconsistent and confusing experience. ####Background When a new account is manually created on a Wikipedia wiki, Growth’s Newcomer editor features are enabled by default. {F71079791} When the same user navigates to another Wikipedia language version and an account is autocreated for them, those preferences are disabled. {F71079803} This creates several user experience issues: - The Homepage is not available on secondary wikis, even though the user already has access on their home wiki. - Navigation is inconsistent. On the home wiki, the username links to the Homepage, while on other wikis it links to the local user page. - The overall navigation and newcomer affordances vary from wiki to wiki in ways that are difficult for users to understand. Longer term, this inconsistency is expected to be addressed by a centralized Dashboard available to all Wikipedia accounts. However, that work may be months or years away. In the meantime, we should explore whether there are incremental improvements we can make with reasonable effort. This work has become higher priority due to findings from the we1-5_contributor-metric-development_fy25-26 workstream, which shows a significant number of users create an account on one wiki but become active editors on a different wiki. ####Scope and constraints Autocreated accounts should not receive the Welcome survey or the guided tour that introduces the Homepage. This task is a research spike focused on understanding technical feasibility and effort, not on implementation. ####Approaches to investigate The goal of this spike is to assess the technical complexity, tradeoffs, and rough effort required for each option below. #####Approach 1: Mirror Growth preferences from the home wiki for newly autocreated accounts - When an autocreated account is created on a secondary wiki, enable the Newcomer editor features if they are enabled on the user’s home wiki. - This approach: - Applies only to newly autocreated accounts. - Preserves local preferences on existing accounts. - Requires detecting the user’s home wiki and reading its Growth-related preferences at account creation time. - Key questions include where this logic would live, how reliable preference lookups are at that moment, and how edge cases would be handled. #####Approach 2: Use GlobalPreferences for Growth features - Instead of enabling Growth features locally at account creation, store them as global preferences using Extension:GlobalPreferences. - Under this approach: - Growth features would be either enabled or disabled consistently across all wikis for a user. - Preferences would be stored in centralauth.global_preferences using the user’s global ID. - The features could be set via GlobalPreferencesFactory::setGlobalPreferences. - The current local preference mechanism would remain as a fallback if GlobalPreferences is unavailable or disabled on a given wiki. #####Approach 3: TBD If engineers can help identify another solution that would be simple (and not result in frustration for existing editors) please feel free to suggest a different approach! ####Acceptance criteria This research spike should produce: - An assessment of the engineering work required for each approach listed above. - A short written summary describing the technical complexity, risks, and tradeoffs of each option. - A rough effort estimate for each approach, for example whether it appears to be a small task or likely to require multiple sprints. - A recommendation, if possible, on which approach appears most viable given effort, risk, and user impact.

Now that Growth features are on all Wikipediasavailable on all Wikipedias, we should evaluate whether they should also be enabled for autocreated accounts. Currently, if a user creates an account on wiki A, they receive Growth features on that wiki. If the same user later visits wiki B and an account is autocreated there, Growth features are not enabled on wiki B. This leads to an inconsistent and confusing experience. ####Background When a new account is manually created on a Wikipedia wiki, Growth’s Newcomer editor features are enabled by default. {F71079791} When the same user navigates to another Wikipedia language version and an account is autocreated for them, those preferences are disabled. {F71079803} This creates several user experience issues: - The Homepage is not available on secondary wikis, even though the user already has access on their home wiki. - Navigation is inconsistent. On the home wiki, the username links to the Homepage, we can consider whewhile on other //autocreated// accounts should get them.wikis it links to the local user page. Right now,- The overall navigation and newcomer affordances vary from wiki to wiki in ways that are difficult for users to understand. Longer term, this inconsistency is expected to be addressed by a centralized Dashboard available to all Wikipedia accounts. However, that work may be months or years away. if an account is created on wiki A (and getsIn the Growth features)meantime, and then the user goes over to wiki B (which creates them an account there)we should explore whether there are incremental improvements we can make with reasonable effort. This work has become higher priority due to findings from the we1-5_contributor-metric-development_fy25-26 workstream, they don't have the Growth featurewhich shows a significant number of users create an account on one wiki but become active editors on wiki Ba different wiki. ==== Implementation####Scope and constraints To ensure the enablement of Growth features is the same on all wikis, the easiest solution is to make use of [Extension:GlobalPreferences](https://www.mediawiki.org/wiki/Extension:GlobalPreferences). In other words, instead of enabling Growth features //locally// on account creation, we will enable the features //globally// in GlobalPreferences. That way, Growth features will either be enabled on all wikis for that user, or on none of themAutocreated accounts should not receive the Welcome survey or the guided tour that introduces the Homepage. On the database level, this can be done by adding rows to `centralauth.global_preferences`, using the user's global ID as `gp_user`.This task is a research spike focused on understanding technical feasibility and effort, It seems doable via `GlobalPreferencesFactory::setGlobalPreferences`not on implementation. I think we should keep the current mechanism as a fallback, in case GlobalPreferences is not available.####Approaches to investigate **Autocreated accounts should NOT receive the Welcome survey.**The goal of this spike is to assess the technical complexity, tradeoffs, and rough effort required for each option below. ==== Open questions#####Approach 1: Mirror Growth preferences from the home wiki for newly autocreated accounts - When an autocreated account is created on a secondary wiki, enable the Newcomer editor features if they are enabled on the user’s home wiki. [X] How will this affect our experiments? - We are only including accounts that are NOT autocreated in our analysis, so it shouldn’t impact analysis. - This approach: [ ] The place where users can disable our features will move. Instead of Special:Preferences, it will be possible on Special:GlobalPreferences. Can this confuse our users? - Applies only to newly autocreated accounts. [ ] How should we handle legacy users? Should we migrate everyone to global preferences? - Preserves local preferences on existing accounts. - Requires detecting the user’s home wiki and reading its Growth-related preferences at account creation time. - Key questions include where this logic would live, Should we only address this for new autocreated accounts?how reliable preference lookups are at that moment, Should we notify legacy users that this is an option? ==== Acceptance Criteriaand how edge cases would be handled. #####Approach 2: Use GlobalPreferences for Growth features This is a research spike that covers: - Instead of enabling Growth features locally at account creation, store them as global preferences using Extension:GlobalPreferences. - the engineering research needed to help make this work actionable. Especially determining how Growth preferences should work on Special:Preferences and Special:GlobalPreferences. - Under this approach: - writing up subtasks to cover the work needed. - Growth features would be either enabled or disabled consistently across all wikis for a user. - Preferences would be stored in centralauth.global_preferences using the user’s global ID. - The features could be set via GlobalPreferencesFactory::setGlobalPreferences. - The current local preference mechanism would remain as a fallback if GlobalPreferences is unavailable or disabled on a given wiki. #####Approach 3: TBD If engineers can help identify another solution that would be simple (and not result in frustration for existing editors) please feel free to suggest a different approach! ####Acceptance criteria This research spike should produce: - An assessment of the engineering work required for each approach listed above. - A short written summary describing the technical complexity, risks, and tradeoffs of each option. - A rough effort estimate for each approach, for example whether it appears to be a small task or likely to require multiple sprints. - A recommendation, Please break this work up so we can approach this in a more iterative way (and potentially only work on the lower-effort tasks if we determine a migration for legacy users is too much of an effort).if possible, In other wordson which approach appears most viable given effort, likely we need separate tasks for the handling of new autocreated accounts and the handling of legacy autocreated accounts (for users with Growth features enabled).risk, and user impact.