Page MenuHomePhabricator

Growth features for new Wikipedias
Open, LowPublic

Description

User story & summary:

As the Growth team, I want new Wikipedias to have access to Growth features, so that newcomers receive the benefits of Growth features.

Background & research:

This task is important because we currently don't have any process to add Growth features to newly-created Wikipedias. This means we continuously drift from the "all Wikipedias have Growth features" end state, each time a new Wikipedia gets created.

Related:
T284485: Think about Growth features being used by non-Wikipedias
T294366: Think about Growth features being used by new wikis, deployed from the Incubator

Acceptance Criteria:
  • CRS to connect with newly created Wikipedias to decide if they are ready for Growth features, Mentorship, etc.

Engineering timebox to ~10 hours

  • If time allows check small wikis who have grown and may now be eligible for "add a link"
  • Coordinate with Growth's CRS to see if further wiki communication is needed
  • Deploy Growth features!

Event Timeline

@Urbanecm_WMF - I added this task in response to the topic you brought up earlier this week.
I realize this is a manual and imperfect solution, but perhaps good enough for now?
If this sounds good, we can simply take on a task like this once per quarter?

@KStoller-WMF: "Q1 2023" was Jaunary-March 2023, is that a typo?

KStoller-WMF renamed this task from Growth features for new Wikipedias: Q1 2023 to Growth features for new Wikipedias: Q1 FY23-24 .Jul 16 2023, 7:53 PM

@KStoller-WMF: "Q1 2023" was Jaunary-March 2023, is that a typo?

That should have read Q1 FY23-24, thanks for catching that!

@Urbanecm_WMF - I added this task in response to the topic you brought up earlier this week.

Thanks!

I realize this is a manual and imperfect solution, but perhaps good enough for now?

Probably, yes.

If this sounds good, we can simply take on a task like this once per quarter?

I think the frequency can be even lower, per https://lists.wikimedia.org/hyperkitty/list/newprojects@lists.wikimedia.org/latest and https://incubator.wikimedia.org/wiki/Incubator:Site_creation_log, there doesn't appear to be a lot of Wikipedias newly created in a quarter. From a technical perspective, deploying the features to handful of wikis at once is similarly difficult to deploying the feature to one wiki, so probably not necessary to do that often.

Urbanecm_WMF triaged this task as Medium priority.

This round of wikis includes the following projects:

urbanecm@wmf3345 mediawiki-config % php multiversion/bin/expanddblist 'wikipedia - closed - private - growthexperiments'
anpwiki
blkwiki
fatwiki
gpewiki
gucwiki
gurwiki
guwwiki
kcgwiki
pcmwiki
urbanecm@wmf3345 mediawiki-config %

None of those wikis have Add a link datasets at https://analytics.wikimedia.org/published/datasets/one-off/research-mwaddlink/ (that is to be expected). There's 1000+ articles on all wikis but fatwiki (~500), gpewiki (~700) , gucwiki (~500), gurwiki (~600), kcgwiki (~700) and pcmwiki (~800). So, might be small for Add a link, but I haven't actually tried to train the datasets to see for myself.

We can enable mentorship fairly easily, Suggested edits might be trickier. @Trizek-WMF @KStoller-WMF Any thoughts on which features to enable on those wikis in this round?

Hmmmm, I think we decided that it's worth enabling Mentorship, Help, and the Impact module even if we can't enable Suggested edits yet. @Trizek-WMF does that sound correct?

Is it possible to "enable" suggested edits with all of the tasks disabled (so communities can decide to enable in the future without engineering help)? Or does that create an empty / broken suggested edits module?

Is it possible to "enable" suggested edits with all of the tasks disabled (so communities can decide to enable in the future without engineering help)? Or does that create an empty / broken suggested edits module?

As of now, that is not possible. We can fully disable Suggested edits from our end (it happened at fr.wiktionary), but that's in server config and need to be changed by an engineer. When no tasks are defined, the module looks like this (which is not very inviting):

image.png (1×2 px, 364 KB)

There are two possible approaches we can go with:

  1. we can add "are Suggested edits enabled" (defaulting to false) to Special:EditGrowthConfig and ask admins to set it to true once ready (T332824: Make wgSuggestedEditsEnabled modifiable via Special:EditGrowthConfig)
  2. we can automatically enable Suggested edits once there are some suggestions available (T343221: Suggested edits: Disable Suggested edits when no suggestions are available)

I prefer the second approach (it removes the possibility of an admin [or us, when we deploy Add a link] forgetting setting the value to Enabled), but the first one is somewhat easier to implement. Also see related discussions in the two tasks above, plus T270300: Scale: deploy without SuggestedEdits (which is kind of an umbrella task for those two).

Do you have any opinions on which route to go with @KStoller-WMF?

These wikis have a minimum of content. We should define a threshold when Add an image and/or Add a link could work.

Mentorship is activated by the communities. If activated, then the homepage should be made available.
T343221: Suggested edits: Disable Suggested edits when no suggestions are available seems to be the best approach, as we would have the image module, the Help links module, and the Mentorship module.

How would we scale from this configuration, when the first tasks can become available?

I agree that T343221: Suggested edits: Disable Suggested edits when no suggestions are available sounds like a more ideal solution.

How would we scale from this configuration, when the first tasks can become available?

Maybe I'm misunderstanding the question, but my understanding is that newcomers on these smaller wikis would simply have suggested edits once more than N articles are available for Suggested edits. (I think N should likely be ~10 or higher, so suggested edits don't immediately disappear when one is completed).

@Trizek-WMF Do you think that would be problematic, since it would happen automatically without Growth posting an update for the Wiki admins?

Maybe I'm misunderstanding the question, but my understanding is that newcomers on these smaller wikis would simply have suggested edits once more than N articles are available for Suggested edits. (I think N should likely be ~10 or higher, so suggested edits don't immediately disappear when one is completed).

I don't recall us having a feature that does it puspusfully. IMO, we should have a way to "buffer" suggestions, so that newcomers have at least a few suggested edits to choose and work on.

@Trizek-WMF Do you think that would be problematic, since it would happen automatically without Growth posting an update for the Wiki admins?

I think it is fine, as far as it is well documented.

KStoller-WMF renamed this task from Growth features for new Wikipedias: Q1 FY23-24 to Growth features for new Wikipedias.Oct 16 2023, 8:33 PM
Urbanecm_WMF moved this task from Blocked to Backlog on the Growth-Team board.
KStoller-WMF lowered the priority of this task from Medium to Low.Oct 17 2023, 4:27 PM
KStoller-WMF moved this task from Backlog to Triaged on the Growth-Team board.

Updated, we won't prioritize this in the coming quarter.