Screenshot
See the screenshot for an example page; NPT fixed an issue that pages created in say, userspace, and then moved into articlespace, would not appear in the article namespace for patrolling work.
Unfortunately it appears the fix means all articles moved at all are now listed as unpatrolled, rather than just all pages moved between namespaces.
Version: unspecified
Severity: normal
Attached:
bsitu wrote:
What about redirects left behind? if a page gets moved to a new title and there is a redirect left behind for the old title
Not seen it happen yet, but I have just noticed a doozy of a redirect bug I'm submitting now.
bsitu wrote:
I am just not sure what's the most useful behavior here for patrollers.
If a triaged/untriaged page in article namespace gets moved. The new title stays triaged/untriaged. What about the redirects left behind, should they get added to the feed list and stay triagged/untriaged as the new title?
So, you mean that when I move X to Y, the review status of X (regardless of what that status is) is transferred to Y?
If so; that is the ideal behaviour. For redirects left behind, ideally they'd take on whatever the review status of the now-moved page is. I appreciate this may be technically difficult :(
bsitu wrote:
Okay, I will summarize the behavior below:
(1). X in non-article namespace gets moved to Y in article namespace, X is redirect left behind, which is a new page
Y is added to the NewPageFeed queue with untriaged status, X is also added to the NewPageFeed queue with untriaged status
(2). X in article namespace gets moved to Y in article namespace, X is redirect left behind
Y is added to NewPageFeed queue with its original triage status, X is added to NewPageFeed queue with the triage status of Y. Do we really need to add them to the queue if they are triaged already?
(3). X in non-article namespace gets moved to Y in non-article namespace, X is redirect left behind
We don't care about moving between non-article namespace
There is no auto-patrol concept in here, articles moved by user with auto-patrol right don't get auto-patorlled, correct?
Not to my knowledge, but I'm not sure how the software treats that because it hasn't, previously, mattered - the pageID remains the same and so the software doesn't care.
On (2); if they're triaged already and within the 60-day limit, yes. There's a degree of oversight we want to promote, and we don't want a situation in which people can safely move obscure articles to offensive titles without any chance of review outside Special:RecentChanges. I'd suggest we discuss this in our meeting later today.
bsitu wrote:
Here is what we finally decided:
Thanks for writing these final notes, Benny, much appreciated! And thanks to the whole team for figuring out this puzzle together.
We are still having problems; see http://en.wikipedia.org/w/index.php?title=Smita_Singh&action=history for example. Also, any article that is deleted and then restored reappears in the list.
bsitu wrote:
I will look at the issue.
"Also, any article that is deleted and then restored reappears in the
list."
If a user creates a new article, deletes the article then restores it. The new article will get away with Special:NewPages. We try to capture it in the new system.
bsitu wrote:
Okay, this is not really related to page moving, take a look at this: http://en.wikipedia.org/w/index.php?title=Special:Log&page=Smita+Singh, the page got deleted then restored, that's why it's re-appearing on the list, :)
Aha; so it's just the delete/restore issue. It's definitely a bug, not a feature, really. Only admins can delete and only admins can restore, so if the issue is "what if someone deletes a new article, then it comes back, and now it isn't going to be patrolled by anyone" - the admin will have reviewed it on both deletion and restore.
bsitu wrote:
delete/restore bug is fixed in https://gerrit.wikimedia.org/r/#/c/16065/