Last modified: 2007-11-22 19:01:44 UTC
RC patrolling on en.wikipedia was shortly enabled, but was disabled again because it wasn't suitable to the fast-moving RC-list in that project (and maybe for other reasons). But one part of that feature which I liked was patrolling on special:newpages. That pages moves relatively slowly, and it is a great help to be able to mark which articles are checked. Therefore it would be nice to be able to enable patrolling on special:newpages only. The following patch does: *Split patrolling into RC-patrolling and NP-patrolling, with a new $wgUseNPPatrol configuration variable *add missing 'markedaspatrollederror' and 'markedaspatrollederrortext' texts (they were also missing before this patch) *Four combinations of RC and NP enabled are possible: **RC=0, NP=0: As before this patch with patrolling disabled. **RC=1, NP=0: Both edits and new pages can be patrolled, but there is no patrol markup at special:newpages, and pages visited from special:newpages does not have a patrol link. **RC=0, NP=1: Only new pages can be patrolled, and the patrol link is only shown when a page is visited from special:newpages. **RC=1, NP=1: As before this patch with patrolling enabled. It would also be nice to have the features implemented in Bug 1401 for new page patrolling.
Created attachment 227 [details] Split patrolling up into new page patrol and recent changes patrol
With the plan to re-enable anon page creation (Nov. 9) on the English Wikipedia, this would be an extremely useful tool to have on Special:Newpages.
I don't think that I am personally in favor of enabling this on English Wikipedia at the same time we allow anons to create pages again for the simple reason that it will disrupt our ability to measure the effect of allowing anons to create pages. However, this seems like an obvious and helpful change. As such, I've updated it against the current codebase and committed it: http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=27025
I would oppose re-enabling anon page creation until a feature such as this is live. Whether or not this skews your data is less important than making sure that all new articles are reviewed in a timely and efficient manner. We cannot afford another Seigenthaler incident, after all.
(In reply to comment #4) > I would oppose re-enabling anon page creation until a feature such as this is > live. Whether or not this skews your data is less important than making sure > that all new articles are reviewed in a timely and efficient manner. We cannot > afford another Seigenthaler incident, after all. > Please comment on the mailing list about that: <http://lists.wikimedia.org/mailman/listinfo/wikien-l>
