artslave wrote:

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.

[edit]
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
wiped.

"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
articles.

"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).

artslave wrote:

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!

avarab wrote:

*** Bug 2112 has been marked as a duplicate of this bug. ***

k.xue wrote:

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?

Lotsofissues

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.

[1] http://bugzilla.wikipedia.org/show_bug.cgi?id=1116
[2] http://meta.wikipedia.org/wiki/Enotif
[3] http://bugzilla.wikipedia.org/show_bug.cgi?id=454
[4] http://meta.wikimedia.org/wiki/Email_notification_to-do_list
[5] http://en.wikipedia.org/wiki/Bayesian_filtering (optional)

(moved and adapted from duplicate bugzilla 2112 to here)

the.r3m0t wrote:

Bayesian filtering sounds too computationally expensive.

(In reply to comment #6)

Bayesian filtering sounds too computationally expensive.

Yes, this is why my proposal was already mentioning: "optional".

No activity in over 3 years, closing as WONTFIX. Please REOPEN if you have a valid reason.