Page MenuHomePhabricator

Scale: streamlined configuration
Open, MediumPublic

Description

Growth features require wiki-specific configurations, i.e. it is not just push-button to deploy to a new wiki. They use links to local help pages, local templates, mentor lists, etc. For this reasons, as we deploy to many more wikis, we need to streamline the process of configuring each wiki.

We will use Wikidata to set up a default configuration for each wiki, but many communities may wish to improve or otherwise alter the configuration with better links, templates, etc. We don't want to do new deployments to handle those changes.

Furthermore, certain parts of the Growth feature set can't be turned on until communities have taken certain actions, like set up a mentor list.

Therefore, here is our idea:

  • The features can be deployed to groups of wikis, but in "dark mode".
  • They're dark until certain configurations have been set, which, once populated, turn the features on.
  • We can set those configurations with defaults from Wikidata, thereby turning the features on.
  • Parts that require community input (e.g. question asking on the help panel and mentorship module) stay dark until the necessary configurations for those are put in by community members.
  • The configurations would all be stored on some on-wiki page that moderately technical community members could edit.

We have these open questions:

  • How would community members populate and edit the configuration? Perhaps we wouldn't want them to edit JSON directly. The comments below mention an idea to make a Special page with a form for the purpose.
  • Which community members would be able to make edits to the configuration? Would this system make it possible for a single community member to essentially turn off the entire feature set by removing the values in the configuration? Or to easily break it by accident?
  • We hope we won't, but we may end up in a situation on a large wiki where mentors or help desks get overwhelmed with questions, either naturally or because of frequent vandalism. Would this system allow us to quickly turn off those features, like a safety valve?
  • For the purposes of our A/B tests, it's important to know exactly when features were and were not being shown to users. How would we do that with this system? Relatedly, would it be possible to tell in aggregate which features are and are not turned on in which wikis?
  • We think that communities may need to take additional time to get set up for the question-asking part of the help panel and for the mentorship module. Do we need to do work to de-couple those elements from the features that they sit in, so that they can be turned on separately? This is currently subtasked in T248193: Scale: ability to deploy without help desk and mentorship features, but may be able to be closed.
  • Is it important to automatically populate configurations with defaults from Wikidata, or should we just do that manually for each wiki?
  • Can we T270300: Scale: deploy without SuggestedEdits? This would be like sailing without our flagship, but it is better than have nothing to help newcomers.

Related Objects

StatusSubtypeAssignedTask
OpenTrizek-WMF
OpenTrizek-WMF
InvalidNone
OpenNone
ResolvedUrbanecm_WMF
OpenNone
OpenNone
OpenNone
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedNone
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
OpenUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedMMiller_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF
OpenUrbanecm_WMF
ResolvedUrbanecm_WMF
ResolvedUrbanecm_WMF

Event Timeline

MMiller_WMF renamed this task from Refine the process from a technical/engineering perspective, to avoid a huge amount of work for communities getting the features to Growth: technical work to streamline deployment process.Mar 6 2020, 4:48 PM
MMiller_WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.
MMiller_WMF added subscribers: Catrope, kostajh, RHo and 2 others.

I've listed Wikidata items the match the links we use on T234846#5960147. We need a technical solution to automatically get these links added to the Growth prototypes when we plan to deploy them, and also give a way to communities to override this choice locally.

@kostajh -- here is the task where we can record ideas for how to scale to more wikis. We want to do whatever this work becomes in Q4 (April - June).

The way I think about it is, deploying GrowthExperiments to a new community involves a one line configuration update that flips the extension to be on.

Then, there would be a protected configuration page on each local wiki, something like MediaWiki:GrowthExperiments.json where we store all the configuration: the title where the Mentors list is, all the help panel configuration links, Suggested Edits configuration. There could be a special page like Special:GrowthExperiments that provides a form that writes the contents of MediaWiki:GrowthExperiments.json, so that the privileged user on a local wiki who is setting the Mentor title can get validation in the form as to whether they put the correct title in place, if the page parses properly, etc.

Then, we will need to change some of our strategy in how we code GrowthExperiments. We would want the help panel feature to be "unlocked" for example once the community configures MediaWiki:GrowthExperiments.json with all the necessary values for the help panel links, path to the help desk, etc. Or Suggested Edits is "unlocked" when the community provides the maintenance templates, and then "topic matching" is unlocked when the relevant topic configuration is provided. If we build a Special page that provides a form for guiding community members in inputting this, this should be a lot more straightforward for people to do.

This isn't strictly about deployment, but was wondering if the wikis would also be opting into the instrumentation code. If so we will need to finish up with T226558: Performance review of hover-in/out event logging in GrowthExperiments Special:Homepage

I have some technical questions in order to streamline the process.

  1. Can we take a Wikidata item, check if there is a link for the wiki we target there and use this link to built configuration? Can we have fallback links?
  2. Can we pick a page name from these Wikidata elements? Like the local help desk title?
  3. Can we move aliases for the interface ("WelcomeSurvey", "Homepage", "Impact" and "View more") to translatewiki?
  4. The help panel is deployed on namespaces 0 "Main", 2 "User" and 4 "Help". Should we allow communities to change it? If so, where?
  5. Archiving the help desk is done via multiple ways. How can we automatically cover most cases? (AFACT, it is impossible query how it's done.)
  6. Pages listed in the help panel, and where the help panel search field searches should be customized by the communities. Where can it be done? (I guess that's the same file as on question 4.)

I have some technical questions in order to streamline the process.

  1. Can we take a Wikidata item, check if there is a link for the wiki we target there and use this link to built configuration? Can we have fallback links?

Yes, that can be done.

  1. Can we pick a page name from these Wikidata elements? Like the local help desk title?

I think so, yes.

  1. Can we move aliases for the interface ("WelcomeSurvey", "Homepage", "Impact" and "View more") to translatewiki?

I don't think this is possible. (What does "View more" refer to?)

  1. The help panel is deployed on namespaces 0 "Main", 2 "User" and 4 "Help". Should we allow communities to change it? If so, where?

This is what I am proposing in T246939#5977311, a protected configuration page per wiki with a Special page that makes modifying it easy and prevents errors while editing it.

  1. Archiving the help desk is done via multiple ways. How can we automatically cover most cases? (AFACT, it is impossible query how it's done.)

I think we should provide documentation about what we support, and explain that workflows outside of what we support will result in links for older questions (or potentially links to questions asked at the end of a month) not working properly.

  1. Pages listed in the help panel, and where the help panel search field searches should be customized by the communities. Where can it be done? (I guess that's the same file as on question 4.)

Same as my answer to question 4, this should be done on a per-wiki configuration page.

If I sum everything up:

  • we can get our information (both links and page titles) from Wikidata
  • we can have all local configurations (overrides) stored on MediaWiki:GrowthExperiments.json, which means:
    • help panel config:
      • namespaces where the help panel is deployed (we should keep ns:0 as mandatory)
      • pages listed in the help panel + their titles
      • on which namespace(s) the search field works
    • suggested edits
      • maintenance templates
      • maintenance help links

I've reported it to the future documentation page.

We still need to figure out:

  • how pages aliases can be handled ("WelcomeSurvey", "Homepage", "Impact" and "View more")
  • how we can support help desks archiving
  • how pages aliases can be handled ("WelcomeSurvey", "Homepage", "Impact" and "View more")

The nice way would be T109235: Re-enable Special:AdvancedTranslate on translatewiki.net, which is probably not something we can do. Short of that, I don't see how we could do better than adding faux system messages for these.

Could we add them to MediaWiki:GrowthExperiments.json too? Asking just in case we can to all the magic at once at one place.

Could we add them to MediaWiki:GrowthExperiments.json too? Asking just in case we can to all the magic at once at one place.

I don't think we want to take special page names from there, that would require some very fragile hacks. We could use it as a place to exposing the translation task (so admins would translate it there and then we'd manually add it to git - that manual step will be needed in some form whatever we choose), but I don't think there's any benefit to it: it locks out non-admins from translating, logically grouping it with other translations makes more sense, and the translation interface is much more user-friendly.

Thank you.

it locks out non-admins from translating, logically grouping it with other translations makes more sense, and the translation interface is much more user-friendly.

We just need to find a solution to fix this.

MMiller_WMF renamed this task from Growth: technical work to streamline deployment process to Scale: technical work to streamline deployment process.Apr 3 2020, 10:18 PM
MMiller_WMF renamed this task from Scale: technical work to streamline deployment process to Scale: streamlined configuration.Apr 15 2020, 12:39 AM
MMiller_WMF edited projects, added Growth-Team (Current Sprint); removed Growth-Team.
MMiller_WMF updated the task description. (Show Details)

@Trizek-WMF @kostajh @Tgr @Catrope -- after re-reading all the comments on this task, I tried to summarize the idea and the open questions in the task description. Though it's not a priority this week, or maybe not even next week, at some point it would be great if you read through it to make sure that I got this right, to add or change anything that's wrong, and maybe to start answering questions we know the answers to. At some point, this will be the highest priority in Ready for Development, and then the engineer working on it can dig into this stuff in earnest.

I created a separate task for the question about translating aliases: T250243: Scale: translation of aliases

Trizek-WMF triaged this task as High priority.

I'm going to review this task in order to review our plans there.

De-prioritizing off the sprint board in favor of other priorities.

Urbanecm_WMF raised the priority of this task from High to Needs Triage.Dec 17 2020, 12:07 PM
Urbanecm_WMF added a subscriber: Urbanecm_WMF.

Doesn't sound to be high anymore.

Trizek-WMF triaged this task as Medium priority.Jan 6 2021, 4:38 PM