Page MenuHomePhabricator

Streamline the deployment process of Growth features even further
Closed, ResolvedPublic

Description

Background

Yesterday, I deployed Growth features to about 10 wikis (in dark mode, which is the challenging part). After finishing the deployment, I have a couple of suggestions how could we improve the process even further, saving time on my end.

Issues with the current deployment procedure

initWikiConfig.php overrides already existing config
The script @Urbanecm_WMF uses to prefill the configuration will happily rewrite already existing configuration when told to. This is not an issue if I remember that every time I run it, but it would be safer if it just yelled at me if I'm overwriting anything (if it's really the intention, it should be possible to overrule it, obviously).

Subtasked as T287973.

initWikiConfig.php needs Phabricator task ID
When the initWikiConfig script is executed to prefill the configuration, it wants me to tell it the Phabricator ID for the task where the deployment was requested. That's then used in the edit summary, to tell the communities why the change is made.

The issue is that with the latest deployment batch, the Phabricator ID varies for every wiki. This forced me to run the script ten times with different Phab ID. It's not a big issue with ten wikis, but with an even bigger deployment, this would definitely become a bottleneck.

This can probably be fixed by @Trizek-WMF – maybe we can create a task like "Round 4 deployment of Growth wikis", link that from the edit summary? I'm also open to other solutions, the goal is to have an edit summary like https://kk.wikipedia.org/w/index.php?diff=2899325 that is informative for the community.

Help panel label translations
With the current deployment procedure, the labels for help panel links are included in the deployment task, and then need to be copied manually to Special:EditGrowthConfig by...someone. That's not the easiest way to do it – can we improve this?

Suggestions:

  • Do not include them at all and leave communities/@Trizek-WMF to do it after wiki is promoted to a dark mode
  • Add them as messages to translatewiki.net, and only start the deployment after the messages are translated there
  • Something else?

Special page aliases

As of now, special page aliases need to be copied to our codebase, as they cannot be changed from TWN. There are two things we can do with it:

  1. if we want to keep translating them, add them to translatewiki as messages and write a script to update the file in Growth's codebase
  2. Stop caring about them, as they only affect the URL -- nothing else.

I'm claiming this, as I'll probably lead the simplification process -- however, input is appreciated here, especially from @Trizek-WMF as he takes care about scaling the features from community standpoint.

Also pinging @DMburugu to help with prioritizing the work here. I think it's more important than dashboard, but of course, it's completely your call.

Event Timeline

Thank you for starting this. Next time, we won't have to deal with translations, since I can't get enough of them to work properly.

I note that you prefer to have have one task for all wikis. Works for me as well! :)

Thank you for starting this. Next time, we won't have to deal with translations, since I can't get enough of them to work properly.

Good to know.

I note that you prefer to have have one task for all wikis. Works for me as well! :)

That's not fully correct. Single task per wiki is still useful to give an overview (in boards like Growth-Deployments), to see full deployment dates (which can differ by wiki, if one finds issues and others don't), etc. It's however nice to have a single task where communities can see "what is happening to their wiki, why, etc" in a centralized manner, that can be linked from the edit summary. An alternative would be a mediawiki.org page explaining how the deployment procedure works, or something to the same effect. Does that make sense?

Could also do something like

declare -A TASKS=( ["aawiki"]="T1" ["abwiki"]="T2" ["acwiki"]="T3" )
for WIKI in "${!TASKS[@]}"; do mwscript initWikiConfig.php --wiki $WIKI --phab ${TASKS[$WIKI]}

or make the script use a text file mapping wiki to task, etc.

Wrt special page names, I think having localized names for beginner-facing special pages is nice and we shouldn't give it up. Translatewiki should work well for this purpose.

For help links, maybe just default to the page name, and editors can customize on-wiki?

Single task per wiki is still useful to give an overview (in boards like Growth-Deployments), to see full deployment dates (which can differ by wiki, if one finds issues and others don't), etc. It's however nice to have a single task where communities can see "what is happening to their wiki, why, etc" in a centralized manner, that can be linked from the edit summary. An alternative would be a mediawiki.org page explaining how the deployment procedure works, or something to the same effect. Does that make sense?

I think it makes sense. At the moment, the deployment is tracked on T275069: Scale: deploy Growth features to a new set of Wikipedias.

A practical case will be the next deployment batch, where 42 versions of Wikipedia will get the features. They all have in common the fact that I can't get translations for them. Do you prefer to have a list of these wikis listed in a single task, or one task for each wiki?

Single task per wiki is still useful to give an overview (in boards like Growth-Deployments), to see full deployment dates (which can differ by wiki, if one finds issues and others don't), etc. It's however nice to have a single task where communities can see "what is happening to their wiki, why, etc" in a centralized manner, that can be linked from the edit summary. An alternative would be a mediawiki.org page explaining how the deployment procedure works, or something to the same effect. Does that make sense?

I think it makes sense. At the moment, the deployment is tracked on T275069: Scale: deploy Growth features to a new set of Wikipedias.

Noted, thanks.

A practical case will be the next deployment batch, where 42 versions of Wikipedia will get the features. They all have in common the fact that I can't get translations for them. Do you prefer to have a list of these wikis listed in a single task, or one task for each wiki?

If there aren't any wiki specific information (like translations), there can be just one task with all wikis from my standpoint (not sure if @MMiller_WMF would want them to still show in the dashboard separately).

@Urbanecm_WMF @Trizek-WMF -- it's fine with me to group wikis in one task. We do not need to have a separate task for each wiki.

Last large deployment batch went just fine. Closing.