Requests for comment/Allow thanking bots

The following request for comments is closed. The request for comment period is over.

I propose that bots should be able to be thanked on Wikimedia wikis.

This is beneficial as it:

allows analytics of how many thanks each bot receives, facilitating evidence-based decisions on the relative importance of each bot and allowing prioritization of development
lets the bot operator view which task receives the most thanks, again allowing for prioritization
gives some motivation and recognition to bot operators that their work is appreciated
makes the ability to thank users more consistent and across-the-board
promotes a sense of camaderie and community, and adds a bit of fun to the movement.

Thank you for your consideration. Phabricator task: T341388. Frostly (talk) 21:18, 7 July 2023 (UTC)[reply]

Comments

Support. It is very frustrating when you see a bot doing some useful task in your watchlist, and you cannot thank them for it. As a botmaster myself I know that it will take a while for the bot operator to know about the thank, it is very rare that I log in into my bot account via the GUI. But I do, and when that happends I do check my notifications. Sometimes it is a new task some operator has picked up, sometimes it is an old but very helpful one. Of course it is always possible to write a big thank message on the master's talk page, perhaps by using WikiLove on wikis where it is installed, but that is a little bit different gesture than the routine appreciation the thank tool does, which, let us be straight, is basically the MediaWiki equivalent of the like button. From the perpective of a bot operator I would indeed want to know which actions of mine people find helpful. I would surely learn about the unhelpful ones, people's nature is always to be more prone to complain, but it would be good to be doing useful actions and see that people actually see and appreciate them. On unrelated note I would also enable thanks to non-registered users, but that might be more complicated venture for the obvious reason of IPs rarely being static. --Base (talk) 06:05, 9 July 2023 (UTC)[reply]
Hi @Base, ad your unrelated note, I'd like to note it is possible this will happen with IP Masking (temporary users coming from IP Masking are supposed to have access to full notifications, and adding thanks to that mix is just few more steps). This is not a promise in any way though :). --Martin Urbanec (talk) 20:57, 9 July 2023 (UTC)[reply]
Weak support. I understand the ways how thanking bots could be useful: assuming the Thanks get properly attributed to tasks, it could indeed provide some useful data. This should be doable via API queries at the least. That said, there are many variables that can potentially impact this: first of all, I don't believe there is necessarily a strong colleration between number of thanks and usefulness of a task. I imagine an article-focused bot will always get more thanks than, let's say, the archiving bot, because more newcomers are likely to see the article edits. There are also notifications that can be bothering for some botowners (I login as my bot only once in 3 years, relying on email notifications), but this is something that can be customized on per-bot basis. To summarize: As long as there is anyone who would want to make use of the data made available this way (and there is at least Frostly and Base), I don't see a reason to block this project, even though I'm bit skeptical to its actual benefits. But, we never know until we try. --Martin Urbanec (talk) 20:36, 9 July 2023 (UTC)[reply]
Support nom makes a use case clear, and I cannot see a single possible downside. Additionally, not all bots are fully automated. HouseBlaster (talk) 21:37, 12 July 2023 (UTC)[reply]
Weak support I'm honestly conflicted on this, on one hand this could be useful and could theoretically be used to train a learning bot in the future,there could also be issues with thanks flooding the notification tab of the bot. I'm on the side of worth a try but doesn't have their hopes up.FusionSub (talk) 09:43, 19 July 2023 (UTC)[reply]
Thank notifications can be disabled :) Frostly (talk) 13:13, 19 July 2023 (UTC)[reply]
Support --Princess Rosalina Q 26149 05:05, 4 August 2023 (UTC)[reply]
Support As long as notifications can be stopped, there is nothing wrong with it. --Tmv (talk) 11:30, 7 August 2023 (UTC)[reply]
Support Seems like a net positive. What issues could this possibly cause? QuicoleJR (talk) 16:29, 11 August 2023 (UTC)[reply]
Support per nom. There a a lot of advantages, and no issues this can cause. «RF_22»/ ^talk 17:46, 15 August 2023 (UTC)[reply]
Support per nom: a net positive, and satisfying as well (I've always been appalled that I can't thank citation bot) Edward-Woodrow (talk) 19:58, 19 August 2023 (UTC)[reply]
Support per Base and Tmv. (Admittedly as a tangent, when I first read the title, I assumed "thanking bots" would be used to mass-thank users – thankfully it isn't!) --SHB2000 (talk | contribs) 10:44, 25 August 2023 (UTC)[reply]
Support (thanks Edward-Woodrow for linking me here from en:WP:VPT!). The only potential issue I can think of is when editors may be awarded barnstars/etc. for being the most thanked in a year, etc. However, this seems like it could be solved by modifying the underlying database quer(y/ies) to exclude bot-tagged accounts from the results. (On a more light hearted note, it would also allow for a new ‘most thanked bot’ award to be given out, should editors on local wikis deem it appropriate ). A smart kitten (talk) 18:01, 4 September 2023 (UTC)[reply]
I'm not fully sure. There may be some possible use cases and thank notifications can be disabled, but I could imagine some particular things breaking. If a bot reads its own notifications and isn't expecting a new notification type or a flood of notifications that it should ignore it could crash or malfunction. For example, a bot may read its 10 most recent notifications every minute. This is sloppy code, but sloppy code makes the world go round. Under normal circumstances it's never a problem, but when someone decides to thank the bot for 10 edits in quick succession it may miss a notification it was supposed to process. Perhaps it could be considered to disable thank notifications for bots by default so they won't be caught off guard. — Alexis Jazz (talk or ping me) 06:14, 9 September 2023 (UTC)[reply]
I completely understand the concern. I'd also suggest widely publicizing this change on relevant venues such as Tech News, technical village pumps, mailing lists, etc, so that the risk is avoided. Frostly (talk) 19:14, 9 September 2023 (UTC)[reply]
@Frostly I've added this gRfC to the next Tech News issue. As the proposer, please do feel free to take on the mailing lists (I'd recommend at least wikitech-l). I'm not sure whether technical village pumps make sense given Tech News are generally distributed onto technical village pumps (among other places) -- I feel those two are largely redundant.

@Alexis Jazz Personally, I think the example you mentioned would be the bot's fault, rather than MediaWiki's. I feel like it would be similar to saying "we need to only allow up to 10 edits per hour from all users combined, because my bot can only process 10 edits when started, and it runs hourly" (which is obviously nonsense). That being said, we should definitely widely advertise both the discussion and the change, to ensure bot operators aren't surprised by it happening. I took the first step by adding it to the next tech news draft. Martin Urbanec (talk) 20:12, 9 September 2023 (UTC)[reply]
Martin Urbanec, oh sure, as I said it would be sloppy code, but that's just how people work. It may be their fault, but it's this change that would trigger the actual problem which may have literally never occurred otherwise. Be honest: we all make some assumptions when writing code. Code would become very unwieldy if it has to be able to deal with every possible edge case and future change. And many tools and bots are barely maintained.
Also, looking at the API help, I don't think thank notifications can be filtered out from the request. (they'll have to be fetched and then ignored by the bot) Does changing the preference also change the API output? (if you don't know I'll have to test it myself) Because if it doesn't, it could still cause flooding issues. Even if a bot is well-programmed and uses notcontinue and/or marks it notifications as read, if it still finds new unread notifications after a few notcontinue/echomarkread requests it could (and perhaps should!) decide it's broken and quit to avoid potentially getting stuck in a long or infinite loop. But with thank notifications, an abuser could possibly make that happen. (there's no limit to the number of thanks one can receive, is there?) — Alexis Jazz (talk or ping me) 20:54, 9 September 2023 (UTC)[reply]
@Alexis Jazz: In my testing on the English Wikipedia, disabling thank notifications in preferences removes them from API output. Additionally, according to this API request, non-bot users on enwiki can make a maximum of 10 thanks in 1 minute. Hope that helps clarify! Best, Frostly (talk) 21:15, 9 September 2023 (UTC)-[reply]