User talk:ClueBot Commons/Archives/2020/August

Latest comment: 4 years ago by Tagishsimon in topic FYI


James Murdoch

Hi, it seems like it is way overdoing it to archive such a scanty talk page. The bot has broken it into a 2013 section and a 2017 section, and there’s nothing left. If they were dearchived, it still would be shorter than a typical talk page. Thanks. Rich (talk) 13:46, 3 August 2020 (UTC)

How to change archive page names

Currently on my talkpage, Cluebot III archives discussions as YEAR/MONTH. I tried to figure out a way where I could change it to MONTH YEAR without breaking the bot but I can't. If I were to move the previous archives, would it break the indexing? If this is possible please tell me. — Yours, Berrely • TalkContribs 11:42, 4 August 2020 (UTC)

Request

(Trolling removed)

Barkawoolcrs, you do know... this is a bot? — Yours, Berrely • TalkContribs 11:39, 4 August 2020 (UTC)

A barnstar for you!

  The Anti-Vandalism Barnstar
Thanks for reverting vandalism Anilgaming2007 (talk) 20:53, 12 August 2020 (UTC)

What happened/What did I do?

Please see User talk:Danre98 and the archive box on the right. I think it's kinda funny but I'd like the listing of random pages gone. --Danre98(talk^contribs) 21:20, 17 August 2020 (UTC)

Nevermind.--Danre98(talk^contribs) 02:24, 18 August 2020 (UTC)

Speedy deletion nomination of User talk:HamlingBline

 

Please refrain from introducing inappropriate pages, such as User talk:HamlingBline, to Wikipedia. Doing so is not in accordance with our policies. If you would like to experiment, please use the sandbox. Under section G3 of the criteria for speedy deletion, the page has been nominated for deletion.

If you think this page should not be deleted for this reason, you may contest the nomination by visiting the page and clicking the button labelled "Contest this speedy deletion". This will give you the opportunity to explain why you believe the page should not be deleted. However, be aware that once a page is tagged for speedy deletion, it may be deleted without delay. Please do not remove the speedy deletion tag from the page yourself, but do not hesitate to add information in line with Wikipedia's policies and guidelines. --Deepfriedokra (talk) 15:37, 18 August 2020 (UTC)

@Deepfriedokra: lol —usernamekiran (talk) 23:30, 18 August 2020 (UTC)

Indexing does not seem to work correctly...

Hi Cobi. Yesterday, I enabled CB3 on a page with <2500 incoming links ([1]), which I do not consider a particularly large number of incoming links by Wikipedia standards. Hopefully, this isn't too high for CB3 to cope with, otherwise, please let me know. Today, it started to archive some threads. While the archive page it created is fine, I don't think the index it created is correct ([2], [3]) - but perhaps I just have a wrong idea about what should be the contents of the index. I think I could manually fix the first index, but I have no idea what to do with the second one... Revert, blank the page? Please advise.

Some remarks:

  • It might be useful for editors if CB3's documentation would specify the maximum number of incoming links more precisely than "large", because this means a lot of different things to different people.
  • Is it possible to apply CB3's archive link fixing to older archive pages as well? It wouldn't need to be fast. I'm sure it would not be possible for links to threads with identical section headers without taking the edit history into account as well, but even if only those links where fixed up which can be reliably fixed up, this would already be an improvement over no fixed up links at all.
  • In many cases, there is a limited number of other pages (related talk pages) which benefit from fast link fixes, while for other (only remotely related) pages, it does not matter much if the links get updated within minutes or days (or at all). So, for pages with a really high number of incoming links, it would be nice, if it would be possible to define a list of pages (including subpages/wildcards) which will be processed first.

Thanks and greetings, --Matthiaspaul (talk) 19:44, 18 August 2020 (UTC)

Don't use underscores in the archiveprefix. That will fix the indexing issue. As far as incoming links, ultimately CB3 has to fetch each one to check if the incoming link was to a section, and if that section was one that it just archived. It's not that it necessarily has a problem with large numbers, but more that it will take a significant amount of time to check larger incoming links, at some threshold delaying the next archival run. The original problem was BLP/N with some 700k+ incoming links. -- Cobi(t|c|b) 20:07, 18 August 2020 (UTC)
Thanks for the fast reply, Cobi. Good to know we're still very far away from the "problem area". Regarding underscores, I thought it would be "smart" to use them instead of spaces to keep people messing with the whitespace from screwing up the archive path name - almost, I would have added an underscore in front of the %%i as well. Well... ;-) I've replaced this by normal spaces now. I also reset the other index, hopefully CB3 will resync.
Any chance regarding applying link fixing to the already existing older archives?
--Matthiaspaul (talk) 20:49, 18 August 2020 (UTC)

CBIII archiving contrary to policy

I don't have more than one example of this and it may have something to do with the user's customized talk page layout, but I noticed today that ClueBot III archived a section of this talk page which contained two declined unblock requests regarding their current block. Archiving of these notices is contrary to the Wikipedia:User pages guideline (see WP:KEEPDECLINEDUNBLOCK). To be fair the guideline prohibits these requests being removed by the user but the intent is clearly for the appeals to remain visible in the event of subsequent appeal, and leaving or forcing them to auto-archive is a back door around this guideline. Is this expected behaviour for the bot or is it a bug? Ivanvector (Talk/Edits) 12:54, 20 August 2020 (UTC)

ClueBot III archives based on the config on a given page. You can use {{subst:DNAU}} to prevent early archival of sections. If this is policy, perhaps update the unblock template to automatically add {{subst:DNAU}}? -- Cobi(t|c|b) 13:18, 20 August 2020 (UTC)

My deleted edits.

I don't like getting my edit reverted "for possible vandalism" without notifying me. Key phrase is without notifying me, since I, basically, know my edits are based on facts, but since I am phoneposting, it's fonna be a problem to type in service symbols.

Sorry for typos. Uchyotka (talk) 22:20, 22 August 2020 (UTC)

Cluebot NG and attempts to include images hosted elsewhere

Hello. While its not strictly a false positive that Cluebot NG reverts attempts to include images hosted elsewhere on the internet, such as a few minutes ago with MySqlID 3761840 (diff), I wouldn't consider it exactly helpfull if you get a (possibly lvl 2 or higher) vandalism warning from cluebot for that. Victor Schmidt (talk) 10:46, 23 August 2020 (UTC)

Battleground Mentality?

Why are these bots anthropomorphized as United States military aircraft? 2600:1003:B85D:B9C8:B010:B755:47D9:6D50 (talk) 13:50, 22 August 2020 (UTC)

Probbably because they need to keep up with the amount of vandalism and unhelpfull edits. AFAIK Cluebot NG is already in a good state and there are AI's outise there that I would consider more broken... Victor Schmidt (talk) 10:49, 23 August 2020 (UTC)
My question has nothing to do with the function or operation of the Cluebots. To put it more plainly: 1) why is a computer program in operation depicted as a military aircraft, 2) why is it US centric and 3) why is the operation name "Enduring Encyclopedia", alluding to "Operation Enduring Freedom" (a US military operation of questionable justification and efficacy), used to refer to anti-vandalism activities to protect the encyclopedia? That all seems inappropriate. 2600:1003:B869:1987:A9E6:33D4:B071:9E36 (talk) 15:37, 23 August 2020 (UTC)

FYI

https://twitter.com/ftrain/status/1298350509221388291 - (warning: contains poop butt) --Tagishsimon (talk) 21:38, 25 August 2020 (UTC)