Last modified: 2011-03-13 18:06:31 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 T2958, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 958 - Proposal to extend recent changes flags
Proposal to extend recent changes flags
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Lowest enhancement with 8 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 2112 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2004-11-29 15:47 UTC by CXI
Modified: 2011-03-13 18:06 UTC (History)
3 users (show)

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


Description CXI 2004-11-29 15:47:50 UTC
The nature of this request is a suggested enhancement to the flags displayed in
Special:Recent Changes. These are entirely programmatic in nature, being derived
from data obtained from the article or edit text in question. 

A full report of proposed additions, issues, implementation details and
commentary from the proposal's tenure on the Village Pump may be found at the
included URL. Apologies if I should have included it in the bug description, but
it's somewhat lengthy and I'm not sure of the customs surrounding MediaZilla
Comment 1 Catherine Munro 2004-11-30 23:05:04 UTC
The essentials (from the given link):

Okay, at the moment RC displays the m and N flags for "minor edit" and "new page", 
respectively. Currently, the only other method of edit assessment on the RC page 
is the username and edit summary, both of which are of limited use, especially in 
the case of vandalism. This is a proposal for additional RC flags that would 
decrease vandalism response time and make things easier for RC junkies and admin.

Proposed flags and issues
Note that these flags use a (totally unofficial and made-up) standard, wherein 
lowercase is used for flags related to the edit, whereas uppercase is used for 
flags related to the article itself.

"+" - Significant addition. Edits that add over a certain amount of characters 
would trip this flag. Typically this would total a couple of sentences of editing. 

"-" - Significant removal. Opposite of above. Not triggered if "blanked" (below) 
is triggered. 
Possibly "--" and "++" for large addition/removal (for lack of a more original 
name) These would be triggered by the addition or removal of a couple paragraphs 
of text. This may just be bloat, however. 

"B" - Blanked. Triggered if all text has been removed from a article. 
Is this letter already used for bots? An alternative is "W" for whited out or 

"R" - Revert. Triggered if edit matches a previous version of the article. 
This would require the calculation and storage of the md5sum for every version of 
a page. 

"u" - Unwikied text. Triggered if a significant amount of unwikied text is added. 
The value of "significant amount" could result in improper flagging of minor edits 
if too low, and miss unwikied stubs if too high. Perhaps should be calculated as a 
percentage of article size. 

"C" - Contentious. Triggered by an edit to an article that is {{disputed}} or has 
received over a certain number of edits in a given amount of time. 
The former system for detecting contentious articles might flag non-contentious 
articles with factual problems, whereas the latter might flag rapidly-growing 

"D" - Recently deleted article. This would trigger upon recreation of a previously 
(recently) deleted article. 

"p" - Profanity (or "t" for Trigger). This flag would be triggered if an edit 
contained any profane or trollish words, as specified in a protected list of 
trigger words. 
This would yield a high level of false positives, especially on innocuous articles 
about reproduction or similar. For this reason, it may be of limited use. 

"E" - Highly exposed article. Used for articles directly linked to by the front 
page, or having received a certain amount of hits in a period of time (this should 
make waves of vandalism immediately following linking in news articles, blogs or 
on the front page more difficult). 
Comment 2 Catherine Munro 2005-02-20 06:15:15 UTC
Copied from en:Village Pump (proposals):
"I like this idea a lot — in fact, let's take it a step further. Some version control systems 
include in the information about a submission how many lines were added and how many were removed 
("+5 -2"). How about we include something just like this beside each edit in RC, the watchlist, 
diffs, and so on? Lines might not work for us, but maybe characters or words. It would allow you to 
quickly identify how big an edit is without relying on the "minor edit" box (indeed, that box might 
be able to disposed of). Deco 19:14, 18 Feb 2005 (UTC)"

I thought it was a great idea!
Comment 3 Ævar Arnfjörð Bjarmason 2005-05-08 18:35:27 UTC
*** Bug 2112 has been marked as a duplicate of this bug. ***
Comment 4 Kai 2005-05-08 19:09:22 UTC
A far more elaborate and better proposal than mine.  However can I recommend distinguishing the high 
risk vandal watch alerts from general upkeep either by isolating vandal alerts to an exclusive 
summary page or a highlight marking?  

Comment 5 T. Gries 2005-05-08 20:39:32 UTC
This proposal can be _combined_ with [1]:

"E-mail notification for page changes or new pages, 
 where title or body or category matches a regular expression"

on which I am working. 

The current Enotif [2, 3], which already allows for notifications on page
changes or creation (for
Sysops etc.) could be extended with Regular Expression matching [1] and the RC
flag conditions as proposed in this bugzilla 958.

[5] (optional)

(moved and adapted from duplicate bugzilla 2112 to here)
Comment 6 Tomer Chachamu 2005-05-08 20:53:28 UTC
Bayesian filtering sounds too computationally expensive.
Comment 7 T. Gries 2005-05-08 20:59:39 UTC
(In reply to comment #6)
> Bayesian filtering sounds too computationally expensive.
Yes, this is why my proposal was already mentioning: "optional".
Comment 8 Roan Kattouw 2008-09-06 22:03:32 UTC
No activity in over 3 years, closing as WONTFIX. Please REOPEN if you have a valid reason.

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