-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFC39UAqTO+fYacSNoRArbEAJ9hPqoQZfUjZEqpK97R4ZyHnkjwWACfVws+
04HyxUWF6yrDTZEtEeh4Eq0=
=0CFu
-----END PGP SIGNATURE-----