-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I remember, a while ago, some was bold and enabled patrolling edits for Wikipedia. It was shortly disabled. I think the main problem with this was that anyone could mark edits as patrolled. I have something akin to a feature request, which basically reinvisions how the patrol thing should work. The basic thing is that the software will provide hooks for people to make patrols, but won't make it mandatory for everybody. A patrol is a group of editors who have a mutual trust of each other's judgments. Whenever one person on that patrol marks an edit checked, everyone else knows about it. Preferably, each patrol should specialize (like check edits that are +-500 and anon), but some overlap is good. Eventually, there should be patrols covering all areas of changes. To create a patrol, you'd have to meet certain requirements (like being an admin). You register the patrol on Wikipedia, mark down which areas of the recent changes you will check, and then recruit people. Only the patrol leader can recruit people, but it's recommended that they be democratic about it. Anyone can "tune" into a patrol, that is, they can see what the patrollers have marked certain changes, but they can't mark a message under the name of the patrol until they've been recruited. Recent changes, for anon and the totally unrecruited, will stay the way it is, but you will have the option to enable Patrol markings. We can color code them, or a user can assign different trust levels to the patrols and then use the overarching data on certain edits to determine their validity (this is like a huge forward jump in time). The Wikimedia servers will have new Patrol chat rooms, which will be like the LiveRC but for Patrol information. Eventually, programs that can crunch patrol data and LiveRC data will be developed to assist patrolling. The actual process of marking edits patrolled or not will use the existing infrastructure. We will not be making lots of new columns in the database, one column with a certain amount of bits (say two per patrol) will work. * 00 - unpatrolled * 01 - dubious or * 10 - something here. * 11 - patrolled If this isn't scalable, then we can make a new table just for patrols along the lines of COLUMN PRIMARY_KEY rc_patrol_id COLUMN PRIMARY_KEY edit_id COLUMN status What do you think? - -- Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com SN:Ambush Commander Website: http://www.thewritingpot.com/ GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA