@Trizek-WMF and @nettrom_WMF, a few questions for you before we start this work:

• Can you think of any other wikis whose experiment status should remain unchanged? For instance, I included German because @Christine_Domgoergen_WMDE recently told us that the community is interested in experiment results in the longer term.
• Do you think we should retroactively turn the Growth features on for legacy newcomer accounts who were in the control group in the past? If so, how far back in time should we go? Or should we turn the features on for all accounts? I can see pluses and minuses to that.
• What announcements would we need to make before and after doing this?

We also need to think about:

• not defaulting to the homepage when the user clicks on their username
• if the help panel button should be displayed all the time, or only when the user works on suggested edits

Personally, I do not recommend enabling the features for all accounts – part of the path to success we used is that we never changed anything for senior contributors -- they're able to contribute just in the way they were before. Suddently displaying features that assign them a "mentor" (who might be significantly wiki-younger than the contributor themselves) or interface to ask questions/view helppages, even when considered unnecessary by the user would be considered disruptive.

To be honest, I don't have the features enabled on my volunteer account (although I'm used to them as a Growth team member) – it's because they don't provide any benefit to me, and merely show some buttons I'll never click :-). Usually, if a senior contributor is asking question, it's not a question suitable for a general pool of mentors: instead, there's probably a quite small group of wikimedians that can answer it.

The edit-count approach described by @Trizek-WMF would likely work, but checking the editcount will require us to do the thing "manually" (by us writing a script that does the job). An easier approach would be to enable the features to users who registered after XX. As XX, I would select the Growth features deployment date (to simplify it, we can select one date for all the wikis). There might be users who registered after deployment, were in control and are now not in need of the features, but that should be fairly small group. @Trizek-WMF: Do you think the registration-date based approach would work too? Or do you think that we should commit the effort necessary and use editcounts instead?

A related issue is what to do with autocreated accounts, ie. accounts which have been created when a user who already had an account on one wiki visited another wiki. Very experienced users might have low-editcount accounts or recent registration dates on wikis they rarely visit. OTOH new users might visit multiple wikis and would then benefit from Growth features on all of them.

In T296702#7539582, @Tgr wrote:

A related issue is what to do with autocreated accounts, ie. accounts which have been created when a user who already had an account on one wiki visited another wiki. Very experienced users might have low-editcount accounts or recent registration dates on wikis they rarely visit. OTOH new users might visit multiple wikis and would then benefit from Growth features on all of them.

Hi @Tgr - we've filed this scaling idea at T292090: Research Spike: Enable Growth features for autocreated accounts (if the user already has Growth features) and IMO turning on for autocreated has a lot of potential for multilingual folks (based on welcome survey this seems fairly common) not only for greater potential to start editing on multiple languages, but also from a consistency perspective.

@MMiller_WMF - if we are looking to focus on MENA regions in pilot initiatives, would it potentially make sense to also add frwiki to the list of wikis with control?

Do you think we should retroactively turn the Growth features on for legacy newcomer accounts who were in the control group in the past? If so, how far back in time should we go? Or should we turn the features on for all accounts? I can see pluses and minuses to that.

Personally, I do not recommend enabling the features for all accounts – part of the path to success we used is that we never changed anything for senior contributors -- they're able to contribute just in the way they were before.

Growth features are intended to also help with retention, which is useful for experienced users as well. For example, the upcoming positive reinforcement project may be useful for editors of all levels, and the structured tasks are intended to be useful for users who want to edit on mobile devices (regardless of experience level).

I would propose that we consider (where I write "all user" below I mean "all users not in Growth features experiment group already"):

• Enable homepage for all users
  • Enable the preference for username-click-redirects-to-homepage for users < $SOME_EDIT_COUNT
• Enable the help panel for all users < $SOME_EDIT_COUNT
  • (The help panel is always available for users doing a suggested edit, even if that preference is disabled.)
• Set the mentorship feature to opt-out mode for all users
• Send an Echo notification to all users:
  • Users > $SOME_EDIT_COUNT -- "Special:Homepage is available to you, we'll notify you if there are new features potentially interesting for you. If you want to be a mentor to new users, here's how...". Disable the guided tours so the experienced users are not spammed twice.
  • Users < $SOME_EDIT_COUNT -- "Special:Homepage is available to you, we'll notify you if there are new features potentially interesting for you. Try structured editing, etc etc." Leave the guided tours on.

Whatever we end up doing, having simple rules so it's easy to reason about what state a particular user is in would be helpful.

In T296702#7538822, @Urbanecm_WMF wrote:

Do you think the registration-date based approach would work too? Or do you think that we should commit the effort necessary and use editcounts instead?

It is an interesting approach. The only case where a user would be disturbed by the apparition of some new features they would not benefit from would be a user who turned into an experienced user in a short time. I think it is very unlikely to happen (or it would be a particular case, such as a sock puppet user -legit or not- or a fresh new start).

In T296702#7540117, @RHo wrote:

IMO turning on for autocreated has a lot of potential for multilingual folks (based on welcome survey this seems fairly common) not only for greater potential to start editing on multiple languages, but also from a consistency perspective.

I totally agree with this.

In T296702#7540151, @RHo wrote:

@MMiller_WMF - if we are looking to focus on MENA regions in pilot initiatives, would it potentially make sense to also add frwiki to the list of wikis with control?

Volunteer me screamed a loud "noooo", since he is waiting the 100% to change the entire onboarding experience at his home wiki, but yeah, we have to be realistic and consider this approach.
To have some data to compare, stats.wikimedia.org gave me the following numbers:

These are page views, I think we can extrapolate a proportional number of edits from it. And I'm afraid that French Wikipedia may not be an interesting target here. (Shut-up, volunteer me; I know you are happy.) A more precise exploration would be nice there.

In T296702#7540152, @kostajh wrote:

Growth features are intended to also help with retention, which is useful for experienced users as well. For example, the upcoming positive reinforcement project may be useful for editors of all levels, and the structured tasks are intended to be useful for users who want to edit on mobile devices (regardless of experience level).

This is not something we have considered yet, since experienced users aren't one of our user-types target. We only consider them as potential mentors.
Usually, when we change something on the interface, we only hear from vocal users who aren't happy about a cosmetic change, no matter what could be the benefit of it. But we have a few experienced users (as in "more than 500 edits and 30 days of presence" users) who add links (fr.wp example).

If we decide to turn the features on for all users, we need to be sure that experienced users understand the benefit of the Growth features. And I think that the current state of Growth features at most wikis is not yet composed of tools experienced users would benefit from.

Here are the notes from the Ambassador meeting, with @Urbanecm_WMF, @Dyolf77_WMF, @ANKAN and @Zapipedia:

• Turn Growth features on for all accounts?
  • Overall agreement on not push it to all accounts to avoid experienced/old users not being happy of a change in the interface/experience.
  • Have a notification to inform experienced users that the features are available.
    • Features are not designed for experienced users, so we need to be careful on the phrasing (like considering them as newcomers could be perceived as offensive).
    • Encourage them to test; invite people to become mentors, hence to test the features.
• Turn it on for accounts with low numbers of edits?
  • direct activation is realistic, could be a way to encourage people to return to editing. Maybe sent emails to people who haven't edited since a while, inviting them to try a new way to edit Wikipedia.
  • could be a benefit for people who speak another language and who are less experienced at this wiki.
  • the idea would be to provide the tools to accounts with less than 500 edits. Consider not providing the tools to older account (by registration date) to avoid a too important gap in learning the interface.

Turn Growth features on for all accounts?
Overall agreement on not push it to all accounts to avoid experienced/old users not being happy of a change in the interface/experience.

To clarify what I was proposing above – enabling the homepage for all accounts would have zero impact on experienced users, because they would have to know to go to Special:Homepage, which we don't advertise anywhere. That would also fix tasks like T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]].

In T296702#7542988, @kostajh wrote:

Turn Growth features on for all accounts?
Overall agreement on not push it to all accounts to avoid experienced/old users not being happy of a change in the interface/experience.

To clarify what I was proposing above – enabling the homepage for all accounts would have zero impact on experienced users, because they would have to know to go to Special:Homepage, which we don't advertise anywhere. That would also fix tasks like T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]].

This is only (almost) true if "Default to newcomer homepage from username link in personal tools" will be unchecked (at that point, we'll lose the accesspath not only for experts, but also for junior contributors). If that setting is enabled, then your username will lead to a different place.

Even with the setting disabled, this will add the "Homepage" tab to your user page, which is a change. It's a tiny change, admitted, but in my experience, wikimedians are very conservative.

In T296702#7543322, @Urbanecm_WMF wrote:

It's a tiny change, admitted, but in my experience, wikimedians are very conservative.

Let's be careful there: some wikimedians are very conservative. They look like being the majority, but it is because they have the privilege of knowing where to report changes they dislike and affirm that their opinion represents the majority. We shouldn't forget that they are a tiny proportion of all our active users.

We need to think about the ones left outside of this privileged group, ones that who would benefit from our features. We never hear from these users, who do background job without any community involvement. These users aren't well known, but they exist.

This being said, let's not push too hard by saying that we are going to turn the features on for everyone. ;)

Re: Tech News - What wording would you suggest as the content, and When should it be included? Thanks!

In T296702#7543322, @Urbanecm_WMF wrote:

In T296702#7542988, @kostajh wrote:

Turn Growth features on for all accounts?
Overall agreement on not push it to all accounts to avoid experienced/old users not being happy of a change in the interface/experience.

To clarify what I was proposing above – enabling the homepage for all accounts would have zero impact on experienced users, because they would have to know to go to Special:Homepage, which we don't advertise anywhere. That would also fix tasks like T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]].

This is only (almost) true if "Default to newcomer homepage from username link in personal tools" will be unchecked (at that point, we'll lose the accesspath not only for experts, but also for junior contributors). If that setting is enabled, then your username will lead to a different place.

That's what I am proposing to do for experienced users.

Even with the setting disabled, this will add the "Homepage" tab to your user page, which is a change. It's a tiny change, admitted, but in my experience, wikimedians are very conservative.

For what I suspect will be a very small number of people annoyed by this, they could switch off the preference.

Summary of discussions

Things we agreed on

• After the configuration change, 100% of new accounts get our features, except at the pilot wikis listed in the task description.
• Autocreated accounts, attached from other wikis, should have the features being available as default features at these wikis (T292090)
• Experienced users shouldn't get the features, except:
  • Experienced users at one wiki should get the features at other wikis. Being opted-out should be the non-default option.
• T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]] is a good solution to help people who don't benefit from our features to access them (to discover them, especially for mentors).
  • in this case, clicking on the username shouldn't default to the Homepage
• send an Echo notification to all users

Open questions we still have

• Should we define Experienced users, as lested above based on:
  • people who have made more than 500 edits at a wiki? (most successful option)
  • people who are active since $date?
  • both?
• For these users, should the help panel be visible only when users work on suggested edits?

My recommendation

Overall comments

• This applies to all wikis, except the pilot wikis listed in the task description.
• In the case of users who already have Growth features being activated (got them when they signed-in for $reason or because they turn them on): we do not change anything to their configuration.
• We target all accounts, including:
  • Experienced users' autocreated accounts attached from other wikis
  • users who were in the control group
  • users who created their account before the deployment of Growth features at the concerned wiki.
• The following recommendation is a one-time change. The goal is to have all users having the same experience, except experienced users who will be invited to opt-in. We would replicate this process if we decide to scale our pilot wikis.

New accounts

• 100% of all accounts created after we change the configuration get our features.

Accounts with less than 500 edits at a given wiki

• We are talking of all accounts created before we change the configuration.
• These should have the features being available as default features T292090: Research Spike: Enable Growth features for autocreated accounts (if the user already has Growth features)
• They should get a notification about the features being available at the wiki they edit mostly.

Accounts with more than 500 edits at a given wiki

• This covers the case of the group we called "experienced users" in the discussion.
• Experienced users shouldn't get the features being activated as default. They have to opt-in.
• They should get a notification about the features being available at the wiki they edit mostly.
  • For activation, we should work on T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]]. It is easier to just access the page instead exploring of preferences.
  • The help panel should only be visible only when these users work on suggested edits T297806: Provide an option to only display the help panel when the user works on Suggested edits

@nettrom_WMF, could you please weigh in here based on the discussions that took place since November 30th and the final summary write-up made by @Trizek-WMF?

When it comes to whether we define French Wikipedia as part of the pilot list, I'm unsure about that and defer to @MMiller_WMF, @LWyatt and the Newcomer pilot folks to discuss. I'm all for digging more deeply into data to understand more about where traffic and edits to frwiki comes from (e.g. a quick aggregation suggests editing is more frequent from some African countries but the magnitudes compared to page views are on par). Sticking with Spanish and Portuguese seems like a reasonable choice too.

I couldn't think of any other wikis to add or remove from the pilot list.

I think our overarching goal should be to turn the features on for as many users a possible and the suggestions from @Trizek-WMF are good.

500 edits is a lot of edits given how few folks stick around and the long-tailed distribution of edits, but setting it there aligns with the goal and I'm unsure whether we'll really annoy users by doing so. I like that we'll make sure autocreated accounts also get the features. Lastly, I think that turning the feature on for autocreated accounts is good. We currently ignore them from all analysis so it won't affect our experiments, and as Rita points to there might be interesting opportunities for studying multilingual users down the line.

@nettrom_WMF For the purposes of the 'newcomer experience' pilot program - French is ''not'' a target language. But, that shouldn't get in the way of any other efforts to get the tool able to be used by more people in more languages :)

I don't think it's useful to define experienced users as users with N+ edits at the local wiki - experienced users visit other wikis more often then newcomers, and don't need newcomer features when they do so. Certain roles (stewards, global admins etc.) involve visiting new wikis all the time and we should take care of making the features non-obtrusive for those people.

We have some non-obtrusive features: the homepage itself, showing the homepage tab when viewing the user or user talk page, suggested editing workflows, being a mentee. There is no reason not to enable these to everyone (there might be technical limitations for mentees and mentor UX limitations for the mentee dashboard, but that's a separate dicussion).

We have some highly obtrusive features that are linked to the registration: the welcome survey and the various discovery notices. We should not do these on account autocreation - the user only needs to be told once how to e.g. find the homepage. The welcome survey is more borderline - we might want different questions for different wikis, even for the same questions the user might have different answers, and for features which try to make use of the user's answers, retrieving them from another wikis is complicated. That said, showing the welcome survey on autocreation is highly infeasible, both technically and in terms of UX. If we want answers on non-home wikis, we should instead show a call to action on the homepage for filling out the survey.

The remaining features, which are fairly obtrusive for experienced users: the help panel (outside suggested editing workflows) and hijacking the user page link. One approach would be to disable those to experienced users (including autocreations and accounts with <500 edits, as long as there are enough edits elsewhere); I'm not sure about the technical feasibility though. The other approach would be to not disable it when that's technically non-trivial, but make it very easy to disable globally. (Anything involving Special:Preferences is not easy; we learned that the hard way during MediaViewer deployment. The same is even more true for Special:GlobalPreferences. We would have to show a disable button within the affected workflow. That approach works well for the help panel; not so much for user page link hijacking.)

In T296702#7593237, @Tgr wrote:

I don't think it's useful to define experienced users as users with N+ edits at the local wiki - experienced users visit other wikis more often then newcomers, and don't need newcomer features when they do so. Certain roles (stewards, global admins etc.) involve visiting new wikis all the time and we should take care of making the features non-obtrusive for those people.

Agreed. A GlobalPreference is a must have for these profiles. (T291084)

The welcome survey is more borderline - we might want different questions for different wikis, even for the same questions the user might have different answers, and for features which try to make use of the user's answers, retrieving them from another wikis is complicated. That said, showing the welcome survey on autocreation is highly infeasible, both technically and in terms of UX. If we want answers on non-home wikis, we should instead show a call to action on the homepage for filling out the survey.

We can go with the scenario where people browse multiple wikis for the same reason they had when they registered.

While I really appreciate the discussions we have here, I think we should have a real meeting about this scaling task soon. :)

Please note some thoughts from @Parkywiki on how we could think about exposing the Growth features to legacy accounts: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Growth_Team_features&type=revision&diff=1069867564&oldid=1069854978&diffmode=source