Last modified: 2012-08-09 21:42:15 UTC
Created attachment 10542 [details] 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.
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.
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 :(
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.
Pertinent references: bug #16705 bug #12636
(In reply to comment #8) > bug #12636 Err, no, bug #12363
Here is what we finally decided: 1. Page from non-article namespace gets moved to article namespace, the new page will be added to NewPagesFeed queue with untriaged status 2. We don't take any further action on new redirect page left behind. If a redirect page gets edited with non-redirect content, the page will be added to NewPagesFeed queue with untriaged status
Thanks for writing these final notes, Benny, much appreciated! And thanks to the whole team for figuring out this puzzle together.
Fix in: https://gerrit.wikimedia.org/r/#/c/7068/
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.
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.
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.
delete/restore bug is fixed in https://gerrit.wikimedia.org/r/#/c/16065/
Sweet; thanks!
