User talk:ClueBot Commons/Archives/2014/April

False positive, but I still agree with the undo

ID #1770115 or this link

Although it is a false positive, using the regular "Report false positive" interface would undo the bot's change, but I do agree with its undo anyway because what the editor wrote is too long for nothing. The "Report false positive" interface should have an "Undo" checkbox so we can report it without undoing ClueBot's revert. -- Lyverbe (talk) 12:07, 30 March 2014 (UTC)

Arsepisstypografica being reverted by ClueBot NG

hello. i'm sorry if i did something wrong. i can't read this opage properly. please change the font size on your website so i can see what i'm supposed to do here. — Preceding unsigned comment added by Arsepisstypografica (talk • contribs) 00:04, 4 April 2014 (UTC)

Flood of non-archive links in archive box

Thanks for running this great bot. Any ideas on what happened to my archive index? Cube00 (talk) 13:16, 5 April 2014 (UTC)

(talk page stalker) This happens from time to time. However, it is significantly more likely when the configuration template is improperly formatted, as is the case with yours. You do not include the required parameter |archiveprefix. I have added such to your config.

However, down the road you may end up with issues with using the archive page names which have been, and will be, generated with the current config. The "normal" is to have the pages for numbered archives be in the format "Archive 1". Because you did not specify an |archiveprefix, your archive names are, and will be, "Archives/1". To change to using the "normal" page names would require changing to |archiveprefix=User talk:Cube00/Archive and |format= %%i (note space between "= %%"). You would also need to move User talk:Cube00/Archives/1 to User talk:Cube00/Archive 1.

The potential future issues are, in particular, with using other types of archive boxes if you ever to do so in the future.

You can, of course, edit your archive index to make it display reasonably should you desire. I have restored the first version created, which was correct. — Makyen (talk) 23:51, 5 April 2014 (UTC)

Deleted content still showing on article

I was reading Earnings before interest and taxes and read this line of text (brackets included) "[Really? Not according to the table below which shows this as Operating Income. You either have to add Non-Operating Income, or the table below is incorrect. Fix whoever knows this!]. The text was added by an IP editor on March 27, 2014 and according to the article's history page, it was deleted immediately by ClueBot NG. However, the text is still visible on the current version of the article. I tried editing the article to remove it, but the text in question doesn't actually appear within the edit box and so I can't remove it. Here are three screenshots to show what I'm talking about. The first shows the current page as it appears, I've highlighted the "problem" text and included my task bar to show today's date. The second shows the edit history of the text, and the third shows the edit box and the fact the problem text doesn't even show up. Coinmanj (talk) 17:55, 5 April 2014 (UTC)

(talk page stalker) - I purged the page. It resolved the issue for me, see if it's better for you now. BethNaught (talk) 18:11, 5 April 2014 (UTC)

A barnstar for you!

	The Admin's Barnstar
	You are really fast!!! Ck-33023 (talk) 17:23, 5 April 2014 (UTC)

Um... CBNG isn't an admin-bot. --k6ka (talk | contribs) 01:54, 10 April 2014 (UTC)

Wikipedia:Non-free content review

Resolved

Cluebot III: Any reason this review page is not being archived? Or rather hasn't been in a month? There are loads of closed discussions, and it worked fine on March 29, 2014. Maybe there is something wrong with how we have it set up, or something wrong with Cluebot III? Cheers, TLSuda (talk) 21:40, 6 April 2014 (UTC)

(talk page stalker) Off hand, I don't have a good answer for you. This post is to save others some time looking for on-page configuration changes. There were no changes to the on-page CB3 configuration in that time. — Makyen (talk) 00:04, 7 April 2014 (UTC)

When I looked I didn't think there were changes, but that doesn't mean that the settings are good or correct. I really don't understand how these things work, just that there hasn't been any archiving in a week and the page is rather full. Cheers, TLSuda (talk) 00:53, 7 April 2014 (UTC)

Its also doing the same thing to my talk page. Although I notice Cluebot III hasn't edited in 2 days. TLSuda (talk) 21:43, 7 April 2014 (UTC)

Edit summary

Cluebot, you marvellous bot, thank you for your tireless bot-work around Wikipedia! Is there any reason that your work, like other bots, is not classified as 'bot' on the watchlist? (I am thinking one reason may be because you want some more editor oversight). --LT910001 (talk) 22:03, 2 April 2014 (UTC)

The question was answered in the FAQ. --k6ka (talk | contribs) 22:09, 10 April 2014 (UTC)

Thanks, I understand --LT910001 (talk) 22:48, 10 April 2014 (UTC)

Logged-out archiving

Cluebot III seems to be archiving while logged out since late yesterday Wikipedia time. Supernerd11 :D Firemind ^_^ Pokedex 20:27, 12 April 2014 (UTC)

It's not limited to CB3. A number of bots are also editing under their IP address. Must be a glitch on WMF's end. --k6ka (talk | contribs) 20:30, 12 April 2014 (UTC)

Multi-reversions for ClueBot NG?

Would it be possible for ClueBot NG to be instructed to do what I suggested here? I assume that this would require a new BRFA, but I don't see why it would be any more likely to result in false positives than what it's doing now. Nyttend backup (talk) 21:43, 11 April 2014 (UTC)

ClueBot NG reverts all edits it believes are vandalism, and does a rollback of all the most recent sequential edits of the same user when it detects the latest one is vandalism. If it didn't revert something earlier, it was because either 1) it didn't detect it as vandalism when that edit was made (and re-evaluation is pointless), 2) it detected it as vandalism but didn't revert it due to edit warring, 3) it detected it as vandalism but didn't revert it due to edit count, 4) it detected it as vandalism but had an error when reverting it, 5) it detected it as vandalism but didn't revert it due to one of the other safe-guards, or 6) it was down at the time and didn't see the edit. -- Cobi^(t|c|b) 02:04, 12 April 2014 (UTC)

As long as #6 isn't the case, I'd say this is perfectly normal. I see a lot of edits that CBNG misses that are clearly obvious vandalism. I'm glad it doesn't catch everything, because I'd have no work to do.

CBNG dumps edits that it thinks are vandalism but doesn't revert due to some of the above reasons in an IRC channel. STiki's default queue is the CBNG IRC feed, so you can easily go through and revert what the bot missed. STiki is also good for cleaning up vandalism after a period of time when there are few or no active RC patrollers, either on Huggle or on foot, as STiki continuously monitors RC and saves edits into its server until a human is able to review it. --k6ka (talk | contribs) 18:03, 12 April 2014 (UTC)

Maybe I have the wrong understanding of how CBNG works. Is it likely that the bot will observe an edit and attempt to revert it as vandalism, only to find that a different user has edited the page in the mean time? In other words, imagine that one editor chops a pile of text from an article, and before the bot notices, or after it notices but before it can do anything, another user comes along and vandalises further. The bot's going to revert the second edit, but it can't help the first. Is this likely to happen? Nyttend (talk) 13:11, 13 April 2014 (UTC)

That happens extremely rarely. From vandalize to revert is usually less than 2 seconds, and most of that time is waiting on Wikipedia to respond to the rollback call. There is not much time for a different user to go and vandalize on top of the vandalism. What happens far more frequently is Vandalism > CBNG revert > Vandalism > no revert because CBNG will not revert back to itself (to avoid edit wars). -- Cobi^(t|c|b) 21:26, 13 April 2014 (UTC)

That's not how I thought it worked. Thanks for explaining; I apologise for taking your time. Nyttend (talk) 03:31, 14 April 2014 (UTC)

Using popups, most reverts happen within one to ten seconds of the vandalism being made, with occasional spikes of up to 30 seconds, depending on server traffic and server lag. This is not limited to CBNG - if you use a program like Huggle, you'll notice a lag as well. This is explained quite well in No You Can't Have Instant Reverts.

And yes, the bot has a strict 1RR rule which prevents the bot from reverting to its own edits, just in case the edit was a false positive. It will also not revert the same user/page combination within a period of 24 hours - if User A vandalized an article, and CBNG reverts it, no matter how many times User A attacks the page, CBNG won't revert - even if it isn't reverting to its own edit - for a period of 24 hours. However, the bot ignores this one rule if the page is listed at User:ClueBot NG/AngryOptin, but it still won't revert to itself, at least in my experience. --k6ka (talk | contribs) 23:36, 15 April 2014 (UTC)

How should we report the rare False Postives for Cluebot III?

@K6ka:, as I mentioned on my talk page, I have reported and reverted a revision by Cluebot III to Talk Graphene. Normally, I would never report this here because I know you guys don't like false positive request showing up in this talk page. However, I did this because when I have reported using the link click here (given above) and Reference ID 602521213, it pointed to another page instead of Talk Graphene. The reason its a false positive is two fold. First, it archive a post that was literally less than 2 weeks old but ignored posts that were more than 1 month old. Second, I feel like the wiki-editors of Graphene make gradual changes and need more time to discuss things than Cluebot III is really allowing us to do. I don't want to have to constantly resurrect old talk pages just to reply to people. In the future, how can I more efficiently report 'false positives' from CluebotIII and not CluebotNG without having to post on this talk page about them? Physics16 (talk) 21:45, 15 April 2014 (UTC)

@Physics16: CBIII has a few odd quirks in its programming. According to WP:ARCHIVE:

"ClueBot III can take several days between the time the configuration template is first placed on a page and when archiving begins (example of 4 day delay). Lowercase sigmabot III typically begins archiving new pages the first time the bot runs after the configuration template is placed on the page. Lowercase sigmabot III typically begins runs at 0 UTC daily."

Still not sure how CBIII works exactly, as I don't use it (I use lowercase sigmabot III) and I have never set it up before. You'll have to ask Cobi for that. In that case, you'll need to archive that discussion manually. Isn't that hard. Before I set up sigmabot III on my talk page I used to archive it manually.

If you want to tell archive bots not to archive a particular discussion until a certain date, you can use the {{Do not archive until}} template. --k6ka (talk | contribs) 23:44, 15 April 2014 (UTC)

(talk page stalker)@Physics16: There are several things in your initial post in this thread which indicate misunderstandings and I understand your frustration.

First: ClueBot NG (CBNG) and ClueBot III (CB3) are different bots. They perform different functions. This is the combined talk page for both of them.

• CBNG is the bot that fights against vandalism by rapidly reverting edits it believes are vandalism. It is the bot that has the report False Positives link. It is enabled throughout this Wikipedia and is configured globally.
• CB3 is a bot that performs automatic archiving of talk pages. It has no false positive reporting link and errors in its actions should not be reported through that link. They should be reported here on this page. CB3 runs on an opt-in basis for each page and is configured separately within each talk page on which it has been specifically enabled.

Explicitly regarding your issue that threads are not kept on the Talk Graphene page long enough: The length of time prior to threads being elegible for automatic archiving is specified in the |age= parameter in the {{User:ClueBot III/ArchiveThis}} template near the top of the page and is specified in hours. On Talk Graphene this was specified as 730 hours which is 30.4 days. This can be changed to whatever length of time you feel is appropriate for that page. It certainly should be changed to a length of time that makes it such that you do not need to routinely resurrect a thread from the archive. I have changed it to 90 days (2160 hours). It is configurable on each page because this length of time is different for different pages depending on the level of traffic on the page.

The length of time to wait for archiving is a choice which should balance how long a thread should remain on the page to be sure that it is no longer active and keeping the entire page short enough such that the length does not detract from the use of the page for active discussions. A year, or more, delay in archiving is not unreasonable if the level of traffic on the page is low. I have set up several pages with 1, or 2 year delays prior to archiving. However, I have only used those lengths of time on pages which are currently very low traffic. I have also seen pages which are configured to archive threads in 3 days, or less. For most pages I would start with 30, 60, 90 or 180 days depending on an estimate of what appears appropriate for the specific page. It is, of course, possible to change the length of time as the nature of the traffic on a page changes.

For more information about configuring automatic archiving you can read Help:Archiving a talk page#Automated archival. The page User:ClueBot III#How to archive your page is available describing the configuration options specifically for ClueBot III.

In the last few edits by CB3 on Talk Graphene I did not see any cases of it archiving a page which was less that the configured 30 days. If you could provide the date on which this occurred, I will take a look to see if I can figure out what was going on.— Makyen (talk) 06:17, 16 April 2014 (UTC)

Archive bust

I think I broke the archiving function at User talk:TheVirginiaHistorian. After some years editing, I thought to set up an archive function of some sort, but when the bot came to play, some entries have been hidden without displaying an archived toggle box, the remaining text has been twice duplicated, leaving more text than hidden. I am not even sure what template I asked for, maybe archive in 90 day increments. It was a shot in the dark, but I don't want to just revert the bot. Please assist. Thanks.TheVirginiaHistorian (talk) 08:28, 20 April 2014 (UTC)

(talk page stalker)  Done (I believe) The primary issue was that in 2 of your edits 5 days ago some error occurred and the page size was doubled twice from 224kB to 899kB. I have not linked the diffs here because they are 225kB and 449kB long.

I restored a version of the page prior to the problems being introduced and recovered the changes which had been made to the page since then: 1x DLP bot; and adding the ClueBot III (CB3) config. However, I did not check the diffs of the 2 large additions to the page. If you added content aside from the erroneous doubling that will still need to be recovered. I'm will to help do so, I just did not want to spend time looking for something which might not be there in such large diffs.

I blanked the two archive pages which CB3 created (all content is back on your main talk page). CB3 should be using them both archive pages in its first couple/few edits. Thus, there is no need to have the pages deleted.

I restored the CB3 config you had which, discounting issues due to the above mentioned page size doubling edits, appeared fine. I also added an archive box to the page and linked the archive index which CB3 creates. The archive index is , of course, wrong at the moment, but CB3 will regenerate the index the next time it runs on the page.

It should be good to go at this point. — Makyen (talk) 10:34, 20 April 2014 (UTC)

Thanks. I'll provide an update when it runs. TheVirginiaHistorian (talk) 11:48, 20 April 2014 (UTC)

Mongoloid idiot

Hello, I'm Mongolian man. Word Mongoloid stopped meaning as Down syndrom or Idiot from 1996 years. My country Mongolia is great country with great history. Please stop using mongoloid as Down syndrom or idiot. 09:37, 22 April 2014 (UTC)Batka83 (talk)

To request deletion of a redirect please create a discussion at WP:RFD. BethNaught (talk) 09:48, 22 April 2014 (UTC)

Wrong place. This is the wrong talk page you're asking at and you are barking up the wrong tree. Please follow the link that BethNaught provided above. --k6ka (talk | contribs) 22:21, 22 April 2014 (UTC)

Help with numerical vandalism

Hello all! I hope this is the right place to make a feature request. If not, please yell appropriately and I will take my messy briefcase elsewhere. Is there any way ClueBot could help out a little more with respect to numerical vandalism? I'm speaking of when IPs and account users randomly change the numerical values in articles, ostensibly with nefarious purposes. (Ex: [1][2][3][4]). I usually revert these edits with my stock edit summary "Unsourced, unexplained numerical changes", which seems like something a bot could do. From my personal experience IPs seem to make these edits most often although accounts (socks and SPAs) do as well. Based on how rampant it is, and how often certain pages get hit, I wonder if it's not a coordinated attack by various vandalbots. If the bot/user were to add a summary they might be able to game the system, so if there's a way to pre-emptively plan for that (perhaps by looking at how many warnings were on the user's talk page or something and holding them to a higher standard), that'd be great. Sometimes only one number is changed, sometimes the edits are vast like in the Invader Zim example above. They almost NEVER come with references. I dunno how the ClueBot works or if it looks at user behavior to make decisions, so I can't be terribly helpful for suggestions to facilitate the process. From my human experience: if I notice a familiar user changing dates, I won't typically question them. But if it's a new user, or an IP, and/or they have multiple talk page warnings, or they're not explaining their changes properly, then my hackles go up. Anyhow, thanks for listening! Cyphoidbomb (talk) 17:32, 23 April 2014 (UTC)

That seems fairly difficult to code into the bot, and if implemented would probably result in a lot of false positives. Some things, such as (maybe) a date template, the bot might be able to revert an edit that changed the "Release date for Mozilla Firefox" to "99 June 5939". Otherwise though, only a human can really check the source to see if the information changed was correct, as websites are not created equal. --k6ka (talk | contribs) 15:59, 24 April 2014 (UTC)

Aww, shucks. Well, thanks for listening! And thanks for working on the bot--it's a pretty awesome tool. Cyphoidbomb (talk) 16:46, 24 April 2014 (UTC)

Great Mosque of Cordova

Your bot makes chaos:

• Cathedral of Córdoba is a redirect to Cathedral of Córdoba (disambiguation).
• The correct lemma (after long discussions) is Mosque–Cathedral of Córdoba.

--Ulamm (talk) 17:29, 24 April 2014 (UTC)

I'm not seeing any troublesome ClueBot edits at any of those articles. Please could you be more specific, and cite diffs? – Wdchk (talk) 00:42, 25 April 2014 (UTC)

@Ulamm: Both ClueBot NG (abbreviated as CBNG) and ClueBot III (abb. as CBIII) are well-designed bots that create more usefulness than they do chaos. ClueBot NG (the anti-vandalism bot) is known to make the occasional mistake (false positive), but all anti-vandal bots have made a false positive at least once in their lifetime. The way CBNG works means that there will always be false positives, but its important that false positives are reported to the developers so it can be used to improve the bot. See the FAQ on how the bot works, and report any false positives here. --k6ka (talk | contribs) 18:46, 25 April 2014 (UTC)

Undetected vandalism

Hi there. This user did some vandalism that got undetected by more than a month: [5]. Could you improve your algorithm to also detect that? Srezz (talk) 17:19, 27 April 2014 (UTC)

Not all vandalism is caught by CBNG, and in a way that is intentional. The bot scores each edit, calculating the chance that it is vandalism. Then a cut-off point, above which edits are classified as vandalism, is selected. This depends on the false-positive tolerance, which is set by a human. The current maximum false positive rate is 0.1% which allows the bot to catch 40% of vandalism. Catching more vandalism means more false positives and more annoyed legitimate editors, so it's a fine line the operators have to tread. BethNaught (talk) 17:54, 27 April 2014 (UTC)

Vandalism catch rate is current around 60%, I believe, with a false positive rate of 0.1%. Increasing the vandalism catch rate also increases the false positive rate, and vice versa. Community consensus is that the bot remains at the 0.1% false positive rate, so it won't catch all vandalism. The bot was never designed to replace human vandal fighters, but was designed to assist them and reduce editor burnout rates.

If you're looking for a tool that really does catch nearly 100% of vandalism, check out STiki. It patrols recent changes and uses a variety of tactics to draw conclusions. Suspect edits are kept in a server, where they are checked by human users and then reverted if needed. The tool is useful for catching vandalism that's been undetected for months. --k6ka (talk | contribs) 16:10, 28 April 2014 (UTC)

ClueBot NG and pending revisions

Please check out the history at Jasper Johns; ClueBot NG rightfully reverted a vandal IP edit, but for some reason that reverted edit is still identified as "pending review". postdlf (talk) 17:21, 29 April 2014 (UTC)