Some wikis are exiting the Incubator regularly. We need to figure our how Growth features could be deployed to these very new wikis.
The lasest two Wikipedia are:
At these Wikipedias, you are pretty sure to find motivated users who would start a Mentorship program. But since there is no much content, what would be the point of adding Suggested Edits, if it doesn't provide contents?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T284485 Think about Growth features being used by non-Wikipedias | |||
| Open | None | T294366 Think about Growth features being used by new wikis, deployed from the Incubator |
Is this about using Growth features in the incubator wiki, or using them on very small wikis (such as the newly created ones)?
It is about both:
@Trizek-WMF is it OK with you to move this to "triaged"? We can think about this in the meantime but it doesn't seem like something we need to discuss in the short term?
I think we should ship the code to all Wikipedias (even the very new ones), because this will simplify Growth's config. Currently, we enumerate all Wikipedias in the list of wikis where the extension should be enabled (while we can just say 'all Wikipedias have this').
This is, however, blocked by the "enabled to newcomers" flag. Currently, it defaults to 'deploy to 100% of newcomers' in server configuration, and is overriden to 0 (for wikis deployed in dark mode), to 80% (for wikis with a control group) or to an arbitrary value for special-treatment wikis. We can't let the variable to default to 100% on a freshly created wiki (our features require some configuration to happen).
To workaround those issues, I propose:
Once those changes are implemented, any new Wikipedia will be able to self-service enable the features by going to Special:EditGrowthConfig and filling out the form. The Growth team will also be able to prefill the form using a script, as we did for most of the wikis.
The potential downside for this is that we'd also let communities to remove features from newcomers. I don't think that's a terrible issue to have: we already granted volunteer administrators nearly full control over the features (and they can make the features super-disruptive to newcomers if they really want to). We also disable features if communites ask us to, to protect WMF <-> community relationship. The new option can be used as an emergency switch, and to reassure communities when needed.
@Trizek-WMF @MMiller_WMF Would we be fine with implementing the changes I described above?
What are the configuration settings which are required for GrowthExperiments to be useful? Basically a non-empty mentor list, I think? Can't we just detect that directly instead of adding another setting? Also, can we suggest to people to configure it as part of the incubator workflow?
As the Incubator is one wiki divided by namespaces (IIRC), we can only have one mentor list there, for all concerned languages. Dividing the mentor list by namespaces is not something we have considered yet.
Shouldn't we encourage new wikis to create the list when the deployment is done? The list of mentors would be the list of users involved in the creation of the wiki.
Title prefixes, not real namespaces; in any case, we might want to recommend people to create a mentor list while setting up the pages for their wiki. It doesn't have to act as a mentor list for Incubator; that's a completely unrelated purpose. Although...
Shouldn't we encourage new wikis to create the list when the deployment is done? The list of mentors would be the list of users involved in the creation of the wiki.
...probably easier that way, yeah.