The Growth team is planning to deploy its features to 100 wikis: T247507: Scale: deploy Growth features to 100 wikis.
Right now, deployment of suggested edits requires MediaWiki:NewcomerTasks.json to be pre-populated by the growth team (right now, only @Tgr has the permissions to do so). How are we going to handle this when we deploy to multiple wikis at once? Should we keep some sane defaults in the extensions's code?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T304052 Enable Growth features on Wikipedias upon creation | |||
| Resolved | Trizek-WMF | T246939 [Growth scaling] streamlined configuration | |||
| Resolved | Urbanecm_WMF | T270300 Scale: deploy without SuggestedEdits | |||
| Open | None | T271237 Consider to have links used in Growth features as standalones being treated as local configuration more than translations | |||
| Resolved | Urbanecm_WMF | T274009 Scaling: Open question: How should we deal with on-wiki configuration for dozens of wikis? |
In practice it's not so much about defaults as per-wiki configuration for things like maintenance templates. I'd rather avoid adding another huge blob like the help links configuration into mediawiki-config (moving that into a wiki page would be the better direction). Plus, eventually we want to get to the point where wikis can enable the feature without us doing a config change, just by on-wiki configuration changes.
Just getting staff or interface-editor rights to more people would be the way to go.
I obviously don't suggest moving this to mediawiki-config, on-wiki changes are probably better – I just identified this as a blocker to massive deployment, so I filled a task :-). Maybe making the extension automaticlaly consider SE disabled, if the config page does not exist, so it will survive just setting wmgUseGrowthExperiments=true is the way to go? Maybe that's already the case, will have to check.
Just getting staff or interface-editor rights to more people would be the way to go.
That's true as well.
It's already the case although it's treated as an error condition now (in terms of logging and caching) and we'd probably want to improve that at some point.
This was discussed in a triage meeting, and this will be handled by a maintenance script which will insert defaults with a system account.