Last modified: 2007-04-02 10:05:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4411, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2411 - A special page to ease discovery of vandalism
A special page to ease discovery of vandalism
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Tomer Chachamu
http://en.wikipedia.org/wiki/Wikipedi...
:
Depends on: 2517
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-14 16:47 UTC by James Wu
Modified: 2007-04-02 10:05 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
The page so far (60.96 KB, image/png)
2005-06-23 17:10 UTC, Tomer Chachamu
Details
Further progress (85.31 KB, image/png)
2005-06-23 19:44 UTC, Tomer Chachamu
Details
Actions column (41.68 KB, image/png)
2005-06-25 21:21 UTC, Tomer Chachamu
Details

Description James Wu 2005-06-14 16:47:58 UTC
To speed the discovery of vandalism, a page that pumps out diffs at a high rate on a specific page 
may be a good idea.

I quote from my post at http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%
29#Wikipedia_Special:Monitor :

It would be similar in structure to Slashdot's Meta Moderation (http://slashdot.org/metamod.pl) 
system: a designated page, perhaps Special:Monitor, would pump out X number of recent diffs made 
within the last Y days, on one single page, for the purpose of fast eyeballing.

This would cut out the "middleman" of Recentchanges for those on janitorial duty; only the refresh 
button needs to be repeatedly abused in order to view massive amounts of diffs and scan for 
vandalism at a very fast rate.

The number of diffs and timerange to pull from can be user customisable, or fixed at say, 10 diffs 
per page, pulled from diffs made within the last 5 days. The choosing of whether a diff displays on 
Monitor can be completely random, or completely random, but "viewed" diffs are never viewed again, 
or use a probability system. For a more frequently edited/viewed article, the diffs of the article 
will appear on Monitor more frequently an already viewed diff would have its probability of being 
chosen for Monitor cut, to say, 1/1000th of the original probability.
Comment 1 Tomer Chachamu 2005-06-15 11:33:17 UTC
Some more ideas:

- Only show the latest edits on articles.
- An edit is originally marked as "don't know" but can also be marked 
as "revert", "vfd", "speedy", "keep" etc.
- If "don't know" is *not* marked, the edit will never appear on the page again.
- A button is pressed to take actions and get a new batch of diffs.
- IP edits with blank summaries are the most suspicious. The character count +/- can also be 
used.
Comment 2 James Wu 2005-06-15 16:15:05 UTC
I wasn't really thinking about janitors marking the viewed articles, mainly
because it would be quite overheadish; but also because it takes much of the
janitor's time, since most edits are minor and legit; it also requires a write
to database for every diff viewed.

If VfD or rv could be integrated into Monitor, in a bullet-proof manner, and is
deemed feasible, I am all for it. However as I see it, besides the problem with
overhead, at the least rv integration would be hard to perfect (How many votes
rvs? IPs and sock puppets viewing Monitor?), and it would probably introduce
vulnerabilities.

I don't think it would be safe to allow the Monitor page to have the power to rv
a page; but, VfD perhaps could possibly be well combined with Monitor. Enough
votes would automatically mark VfD and put article on VfD for manual voting.

Sadly, the same can't go for rv, it would be too slow, the VfRDueToMonitorMarks
page would be way too crowded. Letting Monitor rv directly would be giving too
much power to it.
Comment 3 Tomer Chachamu 2005-06-16 06:09:15 UTC
It could open up a new window.

It all depends on what you want to achieve. I thought of it as a more convenient
way of doing patrol: thus, it would get changes from (say) bteween 2 and 4
minutes ago. If the monitor people can cope with that then extend it *forwards*
so that people can inspect diffs made a second ago; then extend it backwards.

I trust people that it should actually revert themselves when they click it.
Remember that they know the article title; they can just go and revert it
themselves. Similarly with marking for speedy and vfd.

It would start with monitoring IP edits with blank summaries, then we could add
summaries, then users, then minor edits, and (if people can handle monitoring
all that!) that would be perfect: every edit except an admin's patrolled. :)
Comment 4 Tomer Chachamu 2005-06-23 16:58:24 UTC
I'm working on it. I have reached the stage shown in the soon-to-be-uploaded
attachment.

I have recieved assurance from Tim Starling that such an extension (note, not
patch, extension) would be enabled on Wikimedia if {the code was of good
quality, it did not modify existing tables, etc, etc}.

It's called Special:Confirm.

Before I continue with this, I would like to hear from Brion Vibber about this.
I assume that's all the opinions I will need to get such a feature onto
Wikimedia projects.

I created an off-site version, but basically it wasn't very good to use, and
also constantly used my server resources parsing the IRC channel into a database.

A screenshot of it so far follows.
Comment 5 Tomer Chachamu 2005-06-23 16:58:52 UTC
Attempting to assign to me.
Comment 6 Tomer Chachamu 2005-06-23 17:10:02 UTC
Created attachment 638 [details]
The page so far

Since the off-site version is down, you can't see the actions bar of the left.

This is what it looks like so far. It supports checking edits (note: not page
creations) and does the rather basic filtering of not checking bot edits.
Comment 7 Brion Vibber 2005-06-23 18:27:05 UTC
Note that to keep the bug tracking list happy, wikibugs-l *must* be in the CC list if you 
reassign.
Comment 8 Tomer Chachamu 2005-06-23 19:44:38 UTC
Created attachment 639 [details]
Further progress

New pages are now recognised. The user link goes to Special:Contributions for
that user. Images are automatically changed from [[Image:This.jpg]] to
[[:Image:This.jpg]] on display - i.e. they are linked to, not included. This
works for local and canonical namespace names. :)
Comment 9 Tomer Chachamu 2005-06-25 21:21:39 UTC
Created attachment 648 [details]
Actions column

It looks beautiful - it's the actions column!

"Edit stacking" is the next part and it's pretty difficult. :)
Comment 10 Rob Church 2006-11-21 16:43:45 UTC
Note the existence of the Patroller extension (see
http://www.mediawiki.org/wiki/Patroller) which provides functionality very
similar to that described above.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links