User talk:ClueBot Commons

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by NaomiAmethyst (talk | contribs) at 13:19, 20 August 2020 (→‎CBIII archiving contrary to policy: Reply.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

The current status of ClueBot NG is: Running
The current status of ClueBot III is: Running
Praise should go on the praise page. Barnstars and other awards should go on the awards page.
Use the "new section" button at the top of this page to add a new section. Use the [edit] link above each section to edit that section.
This page is automatically archived by ClueBot III.
The ClueBots' owner or someone else who knows the answer to your question will reply on this page.

ClueBots
ClueBot NG/Anti-vandalism · ClueBot II/ClueBot Script
ClueBot III/Archive · Talk page for all ClueBots
Beware! This user's talk page is monitored by talk page watchers. Some of them even talk back.

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]