Wikipedia:Pending changes/Request for Comment February 2011/Archive 3: Difference between revisions
Content deleted Content added
It's time to archive this thing properly. Keep the other page a summary, both for server load and for those only wanting to see the summary and not the entire third phase. |
→Response to History2007: fixing red link |
||
Line 487:
:* Reduce the amazing amount of duplicated/triplicated work in checking edits.
The 2nd point needs special attention and with further data can make a ''serious'' positive impact on Wikipedia for years to come. But you need more data. FYI, after our last discussion, [[User_talk:Sue_Gardner#The_next_chapter_of_Wikimedia_history| I wrote to the boss]] exactly 2 weeks ago to complain about quality and challenged her to produce policies that improve quality. The point you have brought up needs attention along with all the charts the paid consultants are producing there. But as I said you need data, showing the "overlap of diligence" by the patrolers. It is not enough to say that edits are checked "more than once". We need data. Are they on the average checked 3 times, 30 times, 300 times? Who knows. I think the next best thing to do is convince one of the data experts, say Mr MacBride, to run a few graphs. They are [[
:I suggest checking out [[WP:STiki]], which allocates review tasks from a queue to avoid duplication of effort. It even supports multiple edit rating engines. Most importantly, if an edit is flagged by rating engines A and B, it will only be shown to one reviewer. After it is accepted or rejected, the edit is removed from all queues. For general purpose use, we could add additional rating engines that cast a wider net, even all the way up to all recent changes. The tool still needs more work and bulletproofing, but I think this is the future for all patrolling. I would also like to see it integrated with pending changes in several ways. A user with the reviewer right should be able to accept a change using STiki. In addition, only edits flagged as high risk by one of the rating engines should be delayed from public view. This can be done by either automatically accepting all pending changes and then letting the tool "undo" the auto accept on the high-risk edits, or letting the tool perform an automatic accept on edits not classified as high risk. The risk threshold should clearly be lower for BLPs. —[[User:UncleDouggie|UncleDouggie]] ([[User talk:UncleDouggie|talk]]) 00:47, 31 March 2011 (UTC)
:I'll add that it's quite impressive to revert 30 day old vandalism with STiki. You don't need to work off the whole queue back to that point. You can get a 5 minute old edit followed by a 30 day old edit because the queue order is dependent entirely on risk. It currently doesn't handle well the cases in which there have been subsequent good edits, but it certainly is possible. —[[User:UncleDouggie|UncleDouggie]] ([[User talk:UncleDouggie|talk]]) 00:54, 31 March 2011 (UTC)
| |||