Page MenuHomePhabricator

Scale: refine the process to avoid a huge amount of work for communities getting the features
Closed, ResolvedPublic

Description

Over this process, we've found that getting the features requires a lot of work. This task is to think about the next steps, to have a good balance between what we ask, and the time and workload needed to achieve it.

During the last quarter, we've changed some elements in the process, like refining the needs by clarifying the request, or marking some pages as optional.

There is some incompressible work to do when the communities get the features

  • translations for the interface
  • legal document to to translate

Some possible leads for further investigation:

  • get the features one at the time
  • deploy everything without translations so that the communities can see how they work and be motivated by translations (only flagged on for people testing/translating -- not for newcomers)
  • only ask for the "optional" translations after all the non-optional things are complete

Event Timeline

Trizek-WMF triaged this task as Medium priority.Oct 7 2019, 6:04 PM
Trizek-WMF created this task.
MMiller_WMF updated the task description. (Show Details)Oct 8 2019, 4:11 AM

On our side: translating all the legal documents can be really tricky for languages that lack a legal writing standard. And it is extremely lenghty.

Trizek-WMF added a comment.EditedOct 10 2019, 8:17 AM

On our side: translating all the legal documents can be really tricky for languages that lack a legal writing standard. And it is extremely lenghty.

Makes sense: we have the same standard issue in Breton. Would displaying the Legal information in Spanish (or French) be accepted?

Samat added a comment.EditedOct 14 2019, 9:39 PM
  1. There was a specific request during the community discussion, that we should not deploy a new feature where the interface is not yet translated.
  2. "only ask for the "optional" translations after all the non-optional things are complete" sounds reasonable for me.

It was deterrent for me that several hundreds of sentences of the privacy policy are untranslated according to the translation tool, while the page is 100% translated. This is a "bug", which is misleading and can demotivate translators.

Or this page shows partly the English original text, while the translation is 100% ready. (Probably a kind of cache problem or similar, and rather a minor issue, but part of the preparation experience.)

MMiller_WMF updated the task description. (Show Details)Jan 8 2020, 7:26 PM

Some work has been done about it during AllHands. Since I wasn't there, I let @marcella, @Catrope or @Tgr, who worked on it, provide details.

Tgr added a comment.Feb 5 2020, 3:04 AM

I think there was some planning but we ended up working on the mentor dashboard instead. There seemed to be an appetite for getting back to this later, though.

I worked on it for a separate request.

Overall, deploying Growth features may request the minimum work from communities: the process should be the same as any other product deployment, and every option should have a default option provided. Community motivation is really important since we rely on mentors.

Possible leads on it are:

  • Eligibility
    • not all wikis are eligible. Only the ones with enough activity are eligible, and this threshold have to be defined. this doesn't exclude non-Wikipedias.
    • We need to avoid both newcomers’ frustration when they won’t get a reply and active users fatigue, if they have to handle too many newcomers.
  • Translations
    • have everything that requests a translation - even page aliases - being stored on Translatewiki
  • Links personnalisation
    • provide help links using Wikidata interwiki links, and provide a way for communities to change them through Mediawiki messages overrides or a JSon file editable by admins/interface admins.
    • have a list of default namespaces based on previous experiences, and provide a way to change them through a config file (no way to change default sensitive namespaces will be provided)
  • Mentorship & Help desk
    • existing mentorship lists should be re-used since we assume that these users are ready to help. Don't break these tasks since they may be used by other processes.
    • if there is no mentors list, we fallback on the help desk and invite the community to create a list of mentors
    • define a few ways to have help desk archiving being handled, and encourage communities to use one of them (pending talk pages archiving improvements).
    • If there is no help desk, we fallback to the village pump
  • Documentation
    • Everything must be clearly documented on one page, where people would have access to simple definitions of each tool, how to translate its interface and to customize it.

have everything that requests a translation - even page aliases - being stored on Translatewiki

I don't think it's possible for the page aliases to be on translatewiki, but for what it's worth, I don't think it's a problem to deploy GrowthExperiments without the page aliases defined. It just means users will see Special:Homepage in their URL rather than the localized name.

If we can provide communities an easy way to define an alias for Homepage, that's fine.

Tgr added a comment.Feb 24 2020, 8:51 PM

Translating page aliases on translatewiki is trivial. It won't automagically apply them like it does other translations, but it's still easier than other methods of translating. We could export the results once a quarter or something.
Of course if we decide to not make them translatable at all, that's even simpler.

Tgr added a comment.Feb 24 2020, 9:30 PM
  • not all wikis are eligible. Only the ones with enough activity are eligible, and this threshold have to be defined. this doesn't exclude non-Wikipedias.
  • We need to avoid both newcomers’ frustration when they won’t get a reply and active users fatigue, if they have to handle too many newcomers.

This seems more relevant for some features than others. Specifically, mentorship and the question poster will tax the wiki community and work poorly if they are not responsive; for something like suggested edits or the impact module, it is unlikely to make much difference.

Trizek-WMF raised the priority of this task from Medium to High.EditedMar 11 2020, 1:32 PM

Since we are on our way to deploy to more wikis, we need to refine the process so that we can offer to communities some default reliable options.

Here are the Wikidata items for the links used on the Growth prototypes:

It is a bit more complicated to provide default options for the Help panel pages. Here are the pages used by out pilot wikis:

Other help contents listed on Arabic Wikipedia Help panel are local, with apparently no connexion to other equivalent pages.

My recommandation is to use the following items:

Concerning Help desks, we have 3 Wikidata items. I suggest to target the following ones by order of priority:

  1. Teahouse-like places https://www.wikidata.org/wiki/Q11059110
  2. Ask a question places https://www.wikidata.org/wiki/Q5621643
  3. Village pumps https://www.wikidata.org/wiki/Q16503

Technical help desks are out of scope, since they are really about technical questions. https://www.wikidata.org/wiki/Q4026300

MMiller_WMF renamed this task from Refine the process to avoid a huge amount of work for communities getting the features to Scale: refine the process to avoid a huge amount of work for communities getting the features.Apr 3 2020, 10:18 PM

The experience we have so far (for instance with T249760) proves that the involvement of communities concerning translations is a challenge. We need to figure out how to address it.

Trizek-WMF closed this task as Resolved.EditedApr 17 2020, 1:12 PM

Everything communities need to know has been grouped on one page, and Growth-Scaling regroups all blockers and improvements needed to scale. So I'm closing this task.