Page MenuHomePhabricator

Automatically review pages that were reverted to a previously reviewed state
Open, NormalPublic5 Story Points


When a redirect is converted to an article, it gets sent to the new pages feed (was recently broken and then fixed in T223828). We would like to expand on this logic:

  • If an article-from-redirect is reverted back to a redirect, it currently needs to be re-reviewed. It should automatically be marked as reviewed, since that version was already patrolled.
  • The opposite, where an article is converted to a redirect and back. Again it should be automatically marked as reviewed.

Essentially, the system should automatically detect that the page was reverted to a previously patrolled state. This is only applicable when a redirect becomes an article and vice versa.

Relevant investigation at T225239

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Swpb set Security to None.
Samwalton9 added a comment.EditedMar 13 2015, 1:50 PM

To elaborate on the caveat: It would also seem sensible that if an edit that creates a page from a redirect is reverted that the page not show up on the feed, in the same way that a deleted page is removed from it. I'm not sure if that's what swpb meant, I just wanted to make sure it was clear.

Swpb added a comment.EditedMar 13 2015, 2:07 PM

That's a good point, and one I'm glad you made explicit; that's a different consideration from the one I meant. I was talking about pages that had content, were subsequently redirected, and have been reverted to their former content. Such edits should be reviewed, so it's good that the filter catches them, but I think it would be stretching the consensus to treat them as "new" pages.

Swpb updated the task description. (Show Details)Mar 13 2015, 3:42 PM
Swpb updated the task description. (Show Details)
Swpb updated the task description. (Show Details)Mar 13 2015, 3:44 PM

Should AbuseFilter be in this task? My understanding is that this is a feature request for PageCuration extension, not abusefilter.

Fair point; I carried that over from the earlier ticket, but it doesn't really apply at this point.

Glaisher removed a subscriber: Glaisher.Mar 13 2015, 3:57 PM
Aklapper triaged this task as Lowest priority.Mar 13 2015, 4:18 PM
Mattflaschen-WMF raised the priority of this task from Lowest to Needs Triage.Mar 13 2015, 4:47 PM

We'll triage this today.

EBernhardson triaged this task as Normal priority.Mar 13 2015, 5:51 PM
EBernhardson added a subscriber: EBernhardson.

Not sure when this will fit into the collaboration team sprints, but if anyone writes a patch we will be happy to review and help push forward into prod.

Se4598 added a subscriber: Se4598.Mar 14 2015, 12:26 AM
Swpb added a comment.May 19 2015, 1:41 PM

Is there any change to the status of this patch? I'm not familiar with the mediawiki development workflow; what is a reasonable time frame for resolution of this kind of ticket? I'm not trying to push--clearly, there's a lot in the backlogs--I'm just curious.

There is no patch, as far as I'm aware. Please read @EBernhardson's comment. This is not an "Unbreak Now!" ticket and you should not expect a quick or scheduled resolution.

Swpb added a comment.EditedMay 19 2015, 3:20 PM

Ok, but that didn't really answer my question - how long do these sorts of resolutions typically take? Two months is already far from what I would call "quick". I know there's a big backlog and not enough people to do the work, I'm just wondering how things are kept from falling through the cracks indefinitely. Of course I read EBernhardson's comment; I'm looking for clarification.

Completely random amounts of time. Some easy tickets go un-patched for years, some hard things are dealt with just hours after they are reported.

Swpb added a comment.May 19 2015, 3:33 PM

That seems like a less-than-ideal prioritization strategy, no? Does level of community interest in seeing a fix play any role?

Some of the projects which are run by WMF teams have people actively prioritising bugs, presumably with different considerations. This one is marked normal priority, so I don't know if Collaboration-Team-Triage will get to it soon.

Mattflaschen-WMF lowered the priority of this task from Normal to Lowest.May 19 2015, 7:01 PM

As Erik said, we're unlikely to work on this, but we'll accept patches.

Change 190656 had a related patch set uploaded (by Cenarium):
Allow patrolling of tagged changes with minimalist RC patrol

Note that I've provided a way to patrol these from recent changes in core.
Doing this from Special:NewPages would require modifying the query, which might not be possible to do in a performance-friendly way, and show the patrol footer when relevant, which would also be problematic.

Swpb added a comment.May 27 2015, 1:47 PM
This comment was removed by Swpb.
-jem- added a subscriber: -jem-.Aug 6 2015, 1:22 PM
Swpb added a comment.Nov 10 2015, 3:33 PM

I noticed that pages like this one are appearing on NewPagesFeed (as redirects) after being un-redirected, but with the date the page was originally created. Could we simply list these pages by the date they are un-redirected?

Swpb added a comment.Jul 8 2016, 7:22 PM

It's been 15 months since this request started, with no apparent action in over a year. Why is no priority given to community-requested changes?

Swpb raised the priority of this task from Lowest to Normal.Jul 8 2016, 7:22 PM
joeroe added a subscriber: joeroe.Feb 2 2017, 4:08 PM

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

And the latest status of this is.......... ?

@Kudpung: There are no news, otherwise they could be found here.
The patch linked in needs a manual rebase; that seems to be the next step anyone could perform.

This will continue to be an issue until it gets fixed. Essentially the issue is that when a redirect is converted to an article, it gets sent to the new page feed. But if this action is reverted back to a redirect, it stays in the new page feed (but shouldn't).

The opposite, where an article is converted to a redirect and back, is also an issue. Essentially the system should automatically detect when it has been reverted back to a previous revision and correctly assume that no further action is needed.

A related bug is T157048, where Redirects converted into articles appear in the New Pages Feed indexed by the date that the redirect was created, but should instead be indexed by the date that they were converted from a redirect into an article (this would stop them piling up at the back of the feed, or worse dropped in the middle of the feed where they won't be noticed for some time).

Restricted Application added a project: Growth-Team. · View Herald TranscriptOct 23 2018, 6:22 AM
JTannerWMF moved this task from Inbox to External on the Growth-Team board.Mar 19 2019, 6:09 PM
JTannerWMF added a subscriber: JTannerWMF.

It appears the CommTech team is working on this.

Until this is implemented (if it is), a work around is using Special:NewPages (not Special:NewPagesFeed) filtered with the tag mw-new-redirect and hiding redirects. This will only show pages that were initially created as redirects, but no longer are.

srishakatux added a subscriber: srishakatux.
aezell added a subscriber: aezell.May 23 2019, 5:17 PM

I'm summarizing what I understand the request here. Please correct if I've missed something.

If a redirect is converted into an article and then reverted to the original redirect, the redirect should not appear in the feed for patrol. The redirect itself should have been reviewed/patrolled before. If not, it should appear in the feed. So, there are two checks here: 1) Was this article a redirect previously and is now being reverted to that redirect and 2) has that redirect been reviewed before.

@aezell I think that is the uncontroversial part of this request. Articles being turned into redirects and then back into articles appears to be part of the original request from 2015 but I think consensus on this has changed and should not be implemented at this point. Handling clear vandalism is easy enough these days and some number of articles are redirected in AfD discussions these days and thus need patrolling if restored to articles.

@Barkeep49 Thanks. My comment was a summation of a discussion we had within the team earlier today. I'm glad to read that we likely understood the request well enough.

MusikAnimal renamed this task from Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed to Implement addition of un-redirected pages to Special:NewPagesFeed.Jun 17 2019, 9:38 PM
MusikAnimal updated the task description. (Show Details)
MusikAnimal renamed this task from Implement addition of un-redirected pages to Special:NewPagesFeed to Automatically review pages that were reverted to a previously reviewed state.Jun 17 2019, 9:49 PM
MusikAnimal added a subscriber: MusikAnimal.

Hopefully the revised title and description make it more clear what is being requested. If I've got it wrong, please feel free to correct it.

Per our internal discussion, getting this to work for Special:NewPages is a rather radical change to Core that is unlikely to happen from our team. Tracking of redirects-to-articles is already built into PageCuration, so we will build on that.

I removed Developer-Wishlist (2017) as this isn't really a developer feature.

MBinder_WMF set the point value for this task to 5.Tue, Jul 2, 11:35 PM

See T225239#5251954 for results of the investigation. In short, we'll use a reviewed_sha tag in order to determine whether a page was reverted to a previously reviewed state.

ifried added a subscriber: ifried.Wed, Jul 17, 6:12 PM