So it looks like @kostajh did part of this in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/446517 , but not all of it. I'll do the rest now.

In T202041#4508772, @gerritbot wrote:

Change 453308 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/PageTriage@master] Add an API module for tagging a revision as copyvio

https://gerrit.wikimedia.org/r/453308

In T201538#4507024, @Esanders wrote:

The instance appears to be working now, thanks to @Catrope for his help. I'll probably need to automate some of the custom configuration used to get restbase & parsoid working on cloud VPS. The dependency on these services is probably 90% of what makes keeping a VE test instance so much more complex than for most other extensions/features.

While writing this, I realized that the most awkward parts were that the client needs to specify a reportId that is then interpreted by code on the server to generate a report URL, and that we don't support storing scores for different providers so the client can't meaningfully indicate what type of score this is (what provider it came from) and by extension what code the reportId->reportURL mapping should be delegated to (since that lives in the provider).

In T201972#4503663, @Jdforrester-WMF wrote:

Or even "most of"? Time to start punishing code that's not switched over?

Or rather, time to stop punishing code that has switched over?

In T201253#4495808, @Etonkovidova wrote:

Checked in betalabs - old drafts that had 'Mark as patrolled' link do not disappear anymore from AfC feed.

However, newly created drafts (created after the fix was merged) will not appear in AfC feed until 'Mark as patrolled' link is clicked.

In T164860#4495353, @aaron wrote:

Can this task be closed?

@SBisson ARGH you're right, I did it exactly backwards. Lemme fix that.

@alexhollender @MMiller_WMF What should the "That:" category in NPP be called in this summary? It contains two page property things ("orphans" and "no categories"), but the others are all "created by". So we could, for example use either "Created by (newcomers)" or "Type (no categories)" depending on which kind of thing is selected.

Now that seccheck is non-voting, this no longer blocks merges in Thanks.

This is strange. The offending code in ThanksLogFormatter is:

If we had a real org chart solution that'd be one thing, but the old staff page was the closest thing we had to an accurate org chart (Namely has a built-in org chart feature, but it's very broken, at least right now). I don't much care whether we make the new staff page useful for this purpose, or make something else, but right now it's impossible for even staff to discover what team someone's in, or who is in a team.

Relatedly, T201636: The staff page does not show teams/sub-teams anymore which makes it considerably less useful means that the "teams" as advertised by the new staff page (particularly under Audiences) aren't necessarily entities for which it makes sense to have a team page. Most of the Audiences sub-teams that are no longer listed separately on the staff page do have team pages, and most of the teams that are listed don't.

In T201409#4484469, @Krinkle wrote:

Added see also: T193050: Include request id (if present) in a comment in DB queries and T147101: Uniform performance insight for different services (tracking)

In T201253#4489312, @SBisson wrote:

I agree. Did you look at the patch? https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageTriage/+/451182/

In T198997#4481811, @gerritbot wrote:

Change 450392 merged by Halfak:
[mediawiki/services/ores/deploy@master] Add wp10 and draftquality for testwiki

https://gerrit.wikimedia.org/r/450392

I think I prefer the front-end approach to the back-end approach, but I agree neither is especially great. What I don't like about the back-end approach is that I think that keeping the data in the DB "correct" (i.e. make sure drafts never become reviewed) when there are many code paths writing to it feels futile, and it feels safer to instead ignore bad things at render time (ignoring the reviewed field for drafts).

Untagging PageCuration since it has a separate task covering this issue: T154719: PageTriage opens master connection on GET for ArticleMetadata cache misses

At one point early on, the back button did this (it went to the previous filter setting), but people hated it because 1) they expected the back button to take them to the previous logical page, away from the RC page and 2) it went through filter changes one by one, so undoing three filter changes took three back button clicks

It looks like this was broken when Echo was rECHOd66771523c23: Add extension.json, empty PHP entry point

Part of the reason it exists is probably T48670: Email address for sending notifications from Email address for sending notifications from En-wiki and rOMWC2451b60ac08e: Set up email addresses for sending notifications from Echo for enwiki and…

We did, it just took a little while to catch on. I believe it should be fixed now.

@SBisson is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ORES/+/444252 related to this task?

In T197012#4407757, @Acamicamacaraca wrote:

@Catrope What are you thinking about restarting edits review. Maybe we can get better-quality filters in second try?

Correction: I think this is a regression from @kostajh's changes to highlight handling on initialization. If you choose a color then choose no color, the pencil comes back. So it looks like this code isn't getting run on init: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.rcfilters/ui/mw.rcfilters.ui.FilterItemHighlightButton.js#L67-L70

This seems to happen because the mw-rcfilters-ui-filterItemHighlightButton-circle class is always there, even when no circle is displayed, and that class sets background-image: none. Looks like a regression from the recent changes to how highlight circles work.

That sum query is probably not gonna be great performance-wise. You could also do this with something like LEFT JOIN ores_classification ON oresc_model=33 AND oresc_rev=rev_id AND oresc_is_predicted=1 WHERE oresc_probability IS NULL, it's possible that that would be more performant, but it would also flag all unscored revisions as attacks.

I've -1ed the patch in the meantime, and I'll work on one of the possibilities I described on Wednesday.

As Pau says as T196136#4275129 , you can reproduce this in production by translating 1936 Cansiglio earthquake from English to Italian in production (using version=2) and converting the first ~5 paragraphs until you encounter a reference that's reused from a previous paragraph.

I've seen this error before when encountering when references are inserted in buggy ways. I'll investigate this in depth later (Wednesday at the latest), but for now I'll just ask: are you doing anything unusual in CX with multiple documents, or sharing the same InternalList object between documents, or anything like that?

It turns out the article creation wizard is already imported on beta labs, but it's an old version. I imported the current version and am now trying to get the current version of the gadget to work.

Right, I guess we won't have the Article Wizard set up to create drafts in the expected form, but we probably don't really need that to test PageTriage's functionality, we could just manually create pages in the Draft namespace, and manually set the state categories. I'll try to get that going first, then look into the wizard setup.

@MusikAnimal: I heard from @Mooeypoo that this isn't as easy as just enabling the config var on beta, and that you would know why. Does this require importing pages/templates or something?

If there are no objections, I'm going to deploy this on Monday July 9th at 18:00-19:00 UTC.

If there are no objections, I'm going to deploy this on Monday July 9th at 18:00-19:00 UTC. (cc @Acamicamacaraca )

https://grafana.wikimedia.org/dashboard/db/betafeatures