Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed
Open, NormalPublic


Per consensus here, en-wiki's Samwalton9 activated the relevant abuse filter on March 7th. After monitoring the filter log for a week, we are satisfied that the behavior is ready to be implemented on Special:NewPages and Special:NewPagesFeed, with two caveats:

  1. Edits that revert a redirect to a prior state with content should not appear on these patrol pages.
  2. Pages where a redirect has been restored should disappear from the patrol pages, by analogy with new pages that have been deleted.

It's our understanding that this behavior can be implemented in the PageCuration extension. Thanks!

Swpb created this task.Mar 13 2015, 1:20 PM
Swpb updated the task description. (Show Details)
Swpb raised the priority of this task from to Needs Triage.
Swpb added a subscriber: Swpb.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 13 2015, 1:20 PM
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