Page MenuHomePhabricator

Enable PageTriage on ruwiki
Open, Needs TriagePublic

Description

In preparation for rolling out the extension to more wikis, we need to test enable the extension in one of the projects.

For convenience, I suggest enabling the extension in ruwiki, where the active community can test the extension and provide useful feedback.

Deployment plan

  • get a fresh consensus (I see some open tickets for specific wikis that requested it, but they are probably years old): https://ru.wikipedia.org/wiki/Википедия:Форум/Предложения#Включить_PageTriage_в_нашем_разделе
    • does ruwiki want the NOINDEX feature? if so, need to confirm with WMF. WMF is hesitant to deploy that feature more widely, for SEO reasons: (not needed for now, will start discussion after deployment)
  • figure out how we want ruwiki PageTriage configured and test it on a localhost wiki. document your proposed config settings in this ticket
  • identify and do any ESSENTIAL code changes needed to PageTriage. I recommend keeping these minimal so as not to hold up the process. better to get a version of PageTriage deployed that has lots of stuff turned off, then later we can iterate one by one to turn stuff on or add features. ESSENTIAL code changes should be things like 1) bugs arising from interaction with other settings/extensions, 2) i18n problems / we forgot to translate something / stuff is showing up in English even when language is set to Russian, 3) adding feature flags to turn things off. this probably means looking into Community Configuration post-deploy, and doing the initial deploy with $wgPageTriageEnableExtendedFeatures = false (which turns off maintenance tags and deletion tags)
    • $wgUseNPPatrol = true on ruwiki, which is unusual. some testing reveals that this is breaking the "autopatrol" feature of PageTriage
    • FlaggedRevs is operated in "protection" mode on enwiki, and "neither" mode on ruwiki. these modes are different. some exploration may be needed to make sure everything interacts smoothly. for example, when clicking the pagetriage "mark as reviewed" button, should this also accept revision(s) in FlaggedRevs?
  • double check with Sam Walton, the product manager for the WMF Moderator Tools team, for WMF approval
  • work with DBAs to get the 3 pagetriage SQL tables created
  • work with deployers/SREs to get the pagetriage extension turned on on that wiki
  • work with deployers/SREs to get a cron job set up in puppet for that wiki

Configuration

Namevalue
$wgPageTriageDraftNamespaceId102
PageTriageLearnMoreUrl//ru.wikipedia.org/wiki/Википедия:Памятка_патрулирующему
PageTriageProjectLinkВикипедия:Патрулирование
PageTriageFeedbackUrl//en.wikipedia.org/wiki/Wikipedia_talk:Page_Curation
PageTriageEnableExtendedFeaturesfalse
PageTriageDraftNamespaceIdtrue

Event Timeline

I was nudged about this off-wiki.

"PageTriageDraftNamespaceId = true" looks wrong. May want to delete that from the top post in this ticket. I think you set that twice.

I think the next step is to test this in localhost. Someone should configure a localhost in the following way:

  • install PageTriage
  • set the wiki's language and the user's language to russian
  • configure it as specified in the first post of this ticket, i.e.
    • image.png (459×1 px, 68 KB)
  • go look at ruwiki's configuration files and program anything that might interfere with PageTriage into the localhost too. for example:
    • $wgUseNPPatrol = true
    • install FlaggedRevs and configure it with ruwiki settings
    • anything else?

Then, go click around in the localhost and test PageTriage out.

  • things to test
    • visit Special:NewPagesFeed, articles section
    • visit Special:NewPagesFeed, drafts section
    • visit articles, test out the page curation toolbar
  • things to look out for
    • any obvious bugs? if so, post a comment in this ticket and/or file a phab ticket and tag it PageTriage
    • anything else you need to configure? do you need to create a new user group for patrollers and/or autopatrollers?
    • any translations missing?
    • questions/comments/concerns?

Basically, we need to get this test localhost to a good state via 1) proper configuration and 2) patching any bugs we find. Once the localhost is in a good state, then we can move on to next steps.

Hope this helps :)