@Trizek-WMF -- @RHo and I were thinking about this. What do you think?

The welcome survey is obviously out of question as we cannot hijack the autocreation flow the way we can hijack normal account creation.

Discovery features should probably be disabled. They are annoying to veteran users who might need to visit large numbers of wikis in the course of e.g. cross-wiki anti-abuse work, and even new users have already seen the tour once and know where to find the homepage.

The homepage itself is harmless - if you don't like it, don't go there.

The help panel, and hijacking the various user page links, will probably be annoying to many experienced users. They can disable them in global preferences, but finding things in preferences is cumbersome. IMO if we do this, it should include a way to disable (preferably global-disable) those features right from their own UI.

In T292090#7388636, @MMiller_WMF wrote:

@Trizek-WMF -- @RHo and I were thinking about this. What do you think?

I'm for it. :)

Consistency across wikis is a nice thing to have.
Also, when you arrive at a wiki for any reason, it is nice to have someone greetings you. In the case of users who do cross-wiki patrolling, or maintenance, it is interesting to have someone to help you there.
Maybe we can also promote our features as a new way to practice a foreign language? I'd love to practice my Spanish by adding suggested links or images at Spanish Wikpedia.

I also second what Tgr says (as often ;)); we would have to work on T291084: Provide a Global preference for the Homepage and the help panel.

Thanks @Tgr and @Trizek-WMF. I'm a little worried about building in exceptions for these accounts, e.g. "homepage, but no help panel", or "homepage but not the username link". I think those will pile up and start becoming confusing to users and to us.

I could imagine (as you propose) something right on the homepage for autocreated accounts that is like, "Not all the features are on for you yet. Click this to enable the help panel".

Interested to hear what @RHo thinks!

In T292090#7400750, @MMiller_WMF wrote:

I could imagine (as you propose) something right on the homepage for autocreated accounts that is like, "Not all the features are on for you yet. Click this to enable the help panel".

There has been some related discussion in T284088: Merge preference "Enable the editor help panel" with "Display the newcomer homepage" together.

This task is assigned to me, but I'm not sure about the next steps, @MMiller_WMF. Is this not something we should discuss about during a team meeting?

In T292090#7400750, @MMiller_WMF wrote:

Thanks @Tgr and @Trizek-WMF. I'm a little worried about building in exceptions for these accounts, e.g. "homepage, but no help panel", or "homepage but not the username link". I think those will pile up and start becoming confusing to users and to us.

I could imagine (as you propose) something right on the homepage for autocreated accounts that is like, "Not all the features are on for you yet. Click this to enable the help panel".

Interested to hear what @RHo thinks!

I am really excited for the potential scale in enabling Growth features for autowiki accounts! This came up as an idea when we did recent user testing of Add images with Spanish participants, many who talked about being very familiar traversing other wikis, esp. seeing enwiki as the most reliable/complete version they will often consult alongside eswiki. The welcome survey data also suggests that the average newcomer knows more than 1 language, and this might help us learn whether multilingual newcomers are more likely to productively contribute than monolingual folks (an area that could be helpful for future tasks or driving more folks to try CXN).

In T292090#7400866, @Tgr wrote:

In T292090#7400750, @MMiller_WMF wrote:

I could imagine (as you propose) something right on the homepage for autocreated accounts that is like, "Not all the features are on for you yet. Click this to enable the help panel".

There has been some related discussion in T284088: Merge preference "Enable the editor help panel" with "Display the newcomer homepage" together.

As for the question of whether to tailor the experience and not turn on all features for autocreated accounts, I wonder if that can be done as a later step if it turns out that this is annoying for more experienced folks that happen to visit a new language wiki? My concern is that a 'true' newcomer who autocreates is less likely to opt into the features (since they don't quite know what this is) and it's far easier to opt out for people who don't want the help panel and userpage links – but agree that we should do T291084: Provide a Global preference for the Homepage and the help panel first so that the opt-out is a one-time thing, and not something for every single wiki.

I'd like to make sure we have the same understanding about the people this would occur though: we would only be turning Growth features for newly auto-created folks, right? So for example, @Trizek-WMF would not get the features on eswiki, since the eswiki account was auto-created before Growth features were turned on. Assuming this understanding is the case, then wouldn't this not actually affect too many existing 10year+ editors?

Finally, I wonder if @nettrom_WMF has any research insight into multilingual vs monolingual editor productivity? And also if there's any estimates on how many more newcomers we would get this way?

In T292090#7422842, @RHo wrote:

I'd like to make sure we have the same understanding about the people this would occur though: we would only be turning Growth features for newly auto-created folks, right?

Yes. We have ~1000 projects though and some people regularly have to visit random wikis in the course of their volunteer work (e.g. because they follow spambots around, or respond to support requests).

I think we should provide the Growth features to anyone who has them being turned on at one wiki (because they get them when they register at one wiki, or because they turned them on manually at some point -- not sure about the latter). Then users can opt-out using the global preference.

Our features are not that much visible: you have to access the homepage on purpose, and the help desk is a relatively discreet button.

If we go this way, I think we should avoid pinging them about the features when they access a different wiki. It is implied that the experience is the same wherever you go. Have a tooltip that says "hey, the Growth features are available" each time you visit a different wiki should be a bit annoying.

Now that this task has some discussion, I'm moving it to Upcoming Work since we're not going to work on it now.

I wrote in more detail at T296702#7593237 but IMO the welcome survey and most discovery features are too obtrusive to just enable for everyone, and from the user's perspective it does not make much sense to be subjected to them multiple times, so those should not be enabled during autocreation. Enabling the homepage is fine; enabling the help panel (outside suggested edits workflows) will be annoying to experienced users, for whom it isn't really useful, so if we do that (since experienced and inexperienced users are hard to differentiate), we should make sure it's very easy to disable (via some button or configuration menu in the help panel itself).

That leaves the growthexperiments-homepage-pt-link user preference (hijacking user page links in the menu / personal toolbar); not sure what to do about that. I think it will be annoying to experienced users as the homepage is not really relevant to them; I also think it's useful to new users (whose user page is just an edit form); and there is no obvious place to put a configuration button. Maybe there could be a dismissable notice on the homapage whenever the user follows that link, telling them how to disable it?

I'm hoping to revise this task in a way that will work well for newcomers and more advanced users, while attempting to ensure a consistent and expected user experience across languages and wikis. What do you all think of the following proposal?

Given I'm logged in,
When I visit another wiki and an autocreated account is made,
Then the autocreated account has the same "Newcomer editor features" Preferences as currently set in the wiki where I originally registered.
And autocreated accounts should NOT receive the Welcome survey.

In T292090#8336360, @KStoller-WMF wrote:

I'm hoping to revise this task in a way that will work well for newcomers and more advanced users, while attempting to ensure a consistent and expected user experience across languages and wikis. What do you all think of the following proposal?

Given I'm logged in,
When I visit another wiki and an autocreated account is made,
Then the autocreated account has the same "Newcomer editor features" Preferences as currently set in the wiki where I originally registered.
And autocreated accounts should NOT receive the Welcome survey.

Sounds like a reasonable plan. We can imagine that experienced users will figure out how to turn the Homepage on if they like to.

Things would be easier if we have a way to turn everything on as the homepage is visited, see: T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]].

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?

Is it not possible to keep the ability to disable features in Special:Preferences as well to allow turning off per-wiki?

In T292090#8380364, @RHo wrote:

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?

Is it not possible to keep the ability to disable features in Special:Preferences as well to allow turning off per-wiki?

When a global preference is set, the local preference interface looks like this:

I updated the task description since we discussed the first question in a previous team meeting:

• How will this affect our experiments? We are only including accounts that are NOT autocreated in our analysis, so it shouldn’t impact experiment analysis.

In T292090#8449578, @Tgr wrote:

A little confusing I suppose if you have no idea what local preferences are, but not terrible.

Agreed. It's likely not very newcomer-friendly, but I don't think most newcomers do much in the way of customizing their preferences, so maybe that's OK.

Growth features are now part of the newcomer's experience. They have no idea of what existed before. They not even know that their account can be used elsewhere. And if they discover this, they will be surprised to have a different experience elsewhere.

Hence, a newcomer who wishes to have Growth features at this Wikipedia bot not at that Wikipedia is not a newcomer. It is someone who already understands how our ecosystem works. We can assume that the majority of these exceptional users will will find their way in GrlobalPrefs.

While thinking out loud with Kirsten, I realized that we could take the local preference for each user at the wiki they are most active as their default config for Special:GlobalPreferences. This would allow us to have a nice deployment, with people who opted-out our features or mentorship not getting any of these at another wiki.

We need to work on this before deploying Leveling Up. With Leveling Up, newcomers are guided to the homepage. So we need to provide an homepage for users who created their account at another wiki than the one they are editing when we show them the invite.

We discussed this task in our team meeting and determined to make this work more actionable, we should consider this task a Research spike, and try to approach this in smaller and more incremental way. I've updated the task title accordingly and changed the acceptance criteria to:

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).

Timebox: 3