Jump to content

User talk:Yapperbot

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

This is an old revision of this page, as edited by Norvy (talk | contribs) at 21:47, 18 June 2020 (→Random selection: question re: data storage). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

May 2020

Hello, and welcome to Wikipedia. This is a message letting you know that one or more of your recent edits to Sandbox has been undone by an automated computer program called ClueBot NG.

  • ClueBot NG makes very few mistakes, but it does happen. If you believe the change you made was constructive, please read about it, report it here, remove this message from your talk page, and then make the edit again.
  • For help, take a look at the introduction.
  • The following is the log entry regarding this message: Sandbox was changed by Yapperbot (u) (t) ANN scored at 0.952021 on 2020-05-15T13:44:44+00:00

Thank you. ClueBot NG (talk) 13:44, 15 May 2020 (UTC)[reply]

Just a note - this wasn't a malfunctioning bot, this was me making a mistake myself when manually trying something. Sorry, won't happen again! Naypta ☺ | ✉ talk page | 13:46, 15 May 2020 (UTC)[reply]

Current discussions

Moved to User talk:Naypta § Frequency functionality continued

and then to

Moved to User talk:Yapperbot § Frequency functionality continued
^please add new comments here.

--David Tornheim (talk) 09:15, 16 June 2020 (UTC) [revised 23:57, 16 June 2020 (UTC)][reply]

@Usernamekiran: I would ping bot coder to get his/her attention to your question. I believe questions/conerns about the bot should be here, not the coder's talk page. --David Tornheim (talk) 11:06, 16 June 2020 (UTC)[reply]

Frequency functionality continued

Moved from WP:ANI § Please stop Yapperbot NOW
(permalink)

Discussion continued from WP:ANI (and other locations as noted above). Mathglot (talk) 10:22, 16 June 2020 (UTC) [restored with permlink --David Tornheim (talk) 23:39, 16 June 2020 (UTC)][reply]

Copied from Naypta's talk page (permalink) on 00:17, 17 June 2020 (UTC):[reply]

Discussion continued from WP:ANI (and other locations as noted at User_talk:Yapperbot#Current_discussions). Mathglot (talk) 10:27, 16 June 2020 (UTC)[reply]

Start of continued discussion

@Mathglot: Thanks for opening up this continued discussion.
Can you commit to looking into an adjustment to the code so that a cold start after some time offline won't repeat this? I wrote my answer to whether or not bot should be turned off during an edit-conflict. I'm willing to commit to looking at the code, but I expect it will take a few days before I have any sense of how it works, given my experience with programming/coding does not include wiki-bot coding. I can't promise I will have the time and patience to sufficiently understand it to verify that this wouldn't happen again, but I will give it a shot. I promise that within the week I will at least get started and will put in at least an hour to looking at it and possibly asking the coder or other bot-coders key questions about how it or certain bot-commands work.
If there is no documentation, I might start (or add to) it.
That's it for this subject for tonight for me... --David Tornheim (talk) 10:48, 16 June 2020 (UTC)[reply]
@David Tornheim and Mathglot: I won't comment on where this discussion should be - as mentioned previously, I'm more than happy to go wherever it takes me!
This is as far as I can tell the first time that the bot being "turned off" during an edit conflict has been mentioned. What do you envisage that would do? Also, doesn't that have the potential to create quite serious issues with frequently-used talk pages? (It may also not be possible in the current implementation, as Yapperbot is coded deliberately to use MediaWiki's "New section" functionality to avoid ever having edit conflicts.)
The idea of rate limiting is clearly one that's possible, though. In theory, this issue shouldn't ever reoccur anyway, but in the event that it did, it might be good to have rate limits involved. I already have edit limiting code from the bot trial, which is hooked into the FRS bot, so changing that to have a limit on the number of messages sent to a single user per run (the bot currently runs on Toolforge every hour) would definitely be possible if people think that's a good idea. One alternative would be simply to add another parameter to {{Frs user}} that allows users to customise a daily limit - perhaps with a default of 3, then allowing users to set any number there, or 0 for no limit.
Whatever changes are made, I want to make sure that everyone is happy with them - so please let me know your thoughts! Naypta ☺ | ✉ talk page | 11:09, 16 June 2020 (UTC)[reply]
On further reflection, I think there are two good options going forward (although there may well be other ones that I've not considered - I welcome additional suggestions!):
  1. Add a per-week limit to {{Frs user}}. I previously said per day limit, but in the vast majority of cases (i.e. pretty much any apart from this edge case of edge cases) that wouldn't be helpful. A week limit would accomplish much the same thing, just with far more utility in normal times, too.
  2. Build the code of the bot to ship multiple notifications to a user in one template. This has advantages and disadvantages: whilst it'd mean less talk page spam in this edge case, it would also mean that the notification might potentially be less clear, as the heading would have to be just "feedback requested" rather than a category (as they might contain multiple categories). It'd also mean the bot would be less easy to debug if there were issues to come up: at the moment, because each message is a product of a single RfC, it's easy to track back issues if they occur and fix them, which would be more problematic without that clear connection.
Let me know your thoughts Naypta ☺ | ✉ talk page | 11:36, 16 June 2020 (UTC)[reply]
Hiya - Allie from IRC here. I would advise putting a hard limit on how many times Yapperbot can write to a specific user's talkpage in a one-hour period, and I would suggest that limit is once - all the FRS notifications for a day should really be delivered in a single edit anyway. I would also suggest implementing a proper rate-limit which takes the per-month limit and uses that to calculate a "cooling-off" period between notifications to a user. For instance, I think I'm set at 30 notifications per month, so a 24 hour cooling-off period would be appropriate, but someone who is set at one notification per month should recieve a notification (on average) every 30 days, instead of just on the first of each calendar month. I'm a bit concerned you're referring to this as an 'edge case' - in my opinion, scheduling is core bot functionality. -- a they/them | argue | contribs 12:01, 16 June 2020 (UTC)[reply]
@Alfie: Hi Allie. This is an edge case, because it is by no means normal for there to be this many "new" RfCs to process. If you take a look at the history of the pages Legobot transcludes RfCs onto - for instance, take the Biographies category - you can see that, on a daily basis, there's normally one, maybe two, RfCs per category. Ninety-nine to process at once is, in every sense of the word, a rarity.
That being said, of course, it being a rarity and an edge case does not mean that it's not something that would be useful to address. A cooling-off period, as you refer to it, is of course possible to implement, but I'm not sure it's really all that necessary - if you look at the history of the way that Legobot previously did this, this was never an issue, and I suspect had I just not sent any notifications of the ongoing RfCs and only started sending messages regarding new ones, it wouldn't have ever come up as an issue either. Bundling FRS notifications in a run is definitely possible, although there's nothing to guarantee that a further run that same day wouldn't pick up a new RfC or GA nom, which would then send another message. Once again, the thing to bear in mind here is that the vast majority of the time, each run will consist of one RfC, maybe two at a push - nowhere near the number experienced this morning. Naypta ☺ | ✉ talk page | 12:07, 16 June 2020 (UTC)[reply]
PS: As to documentation, the specific bot code doesn't have explicit documentation, because it's not a library, but all the relevant bits of code are commented. Code for ybtools, which is the shared library used across all of the bot's tasks, is commented in standard Godoc style as it is a library, so its full documentation is available here. Naypta ☺ | ✉ talk page | 11:11, 16 June 2020 (UTC)[reply]
P.S. shouldn't this discussion be at Wikipedia_talk:Feedback_request_service or User_talk:Yapperbot? --David Tornheim (talk) 10:52, 16 June 2020 (UTC)[reply]
  • If you just bundled all the invites into a single section (possibly by detecting whether the last section on a user's talkpage is an existing recent notification, and adding a new notification to it) I think people would be 90% less annoyed. But people are making much too big a deal of this, if indeed it's just a startup phenomenon. EEng 13:51, 16 June 2020 (UTC)[reply]
    @EEng: That's one of the options I've mentioned above, yeah. I disagree that people are making too big a deal of it, though; it's important. Being a botop means being in a position of trust, by the very nature of running a bot, and I want people to feel that they can put that trust in me. If people feel I've broken that trust, that's a huge issue, so it is important to have these discussions - at least from my perspective. As I said at the ANI thread, bots are here to serve the community, not the other way around, and I want to make sure that mine works the way it's supposed to. Naypta ☺ | ✉ talk page | 13:56, 16 June 2020 (UTC)[reply]
    I can send you a whip with which to flagellate yourself. EEng 13:57, 16 June 2020 (UTC)[reply]
    @EEng: No flagellation intended, self or otherwise - it's not about going "oh no, aren't I awful", it's about going "okay, how can we make sure this doesn't happen again?" Naypta ☺ | ✉ talk page | 08:29, 17 June 2020 (UTC)[reply]
    Well some people derive, ya know, pleasure from that kind of thing. EEng 12:11, 17 June 2020 (UTC)[reply]
    I very much appreciate your saying that in that tone. --David Tornheim (talk) 23:25, 16 June 2020 (UTC)[reply]
  • @David Tornheim and Mathglot: Thanks David for moving the discussion over here. To give an update on some steps I've already taken to try and ensure a better distribution even if such a large list were ever to come up again for simultaneous sending:
    • The random number generator that selects which users are going to be invited to give feedback is now re-seeded every selection, rather than on every bot run, which should significantly increase the variety in users selected when a bot run has a lot of messages to process.
    • The bot now waits for five seconds between each invitation, to try and prevent people being spammed and unable to edit their own talk page from edit conflicts.
    • The number of messages being sent for each RfC/GA nom has been lowered - it was previously a random number between 15 and 25, now it's a random number between 5 and 15.
    • Some issues with storing the state of processing GA nominations have been fixed, which had previously caused problems with GA nominations sometimes going out twice.
    Hopefully these will all be helpful to ensure the bot works better! Naypta ☺ | ✉ talk page | 08:35, 17 June 2020 (UTC)[reply]
Thanks for the update. I haven't delved into the code, except a brief look at this code you referred to. (What language is it written in?) Responding to some of the points:
The random number generator is re-seeded every selection, rather than on every bot run.
That seems odd to me that that would make any significant difference. The only possible concern I would have is if the same process started with the exact same seed. (I would only keep the seed the same if I were trying to debug it.) Are you using the clock for the seed? That's how I used to do it, but I was told that even with the clock, patterns can still emerge. Maybe there are new techniques for dealing with seed that were not available many years ago.
The number of messages being sent for each RfC/GA nom has been lowered - it was previously a random number between 15 and 25, now it's a random number between 5 and 15.
That sounds way too low to me. I've seen RfC's with as many as 200 responses. Do you mean 15-25/day has been reduced to 5-15/day?
Did you get those numbers from LegoBot?
Have you looked at the LegoBot code to see how it works? Do you know if it is available for pubic review too?
...[problems with] GA nominations have been fixed...sometimes going out twice.
Glad to hear it!
Is there a location where other users reviewed your code before it was released? If I find it, I'll delete this, or tell others where that is.
--David Tornheim (talk) 10:32, 17 June 2020 (UTC)[reply]
@David Tornheim: I'm using the clock for the seed, yes - the reason I changed it to every selection is to improve randomisation on runs that have huge numbers of messages, like the one we had yesterday morning. As the RNG was only seeded once, at the start of the process, with the timestamp at the start, the random permutation algorithm was returning the same permutations throughout - because it had the same seed - meaning that a small number of people received a very large number of messages, because their usernames were sorted to the front of the queue by the permutation generator. Now that it's reseeding the generator every selection, it will perform a new random selection every time.
The Legobot code is available for public review over here, but it's not exactly well-documented, to say the least - I'll freely admit that my eyes gloss over a bit when I see things like $temp01, $temp02 and foreach ($temp02 as $temp2) {. I had difficulty gleaning much at all from it, so no, I didn't get the numbers from Legobot - but I can adjust them as necessary, if the feeling is that they ought to be different. I might end up putting them on-wiki, so it doesn't take a code change to adjust them as needed.
As to code review, the code was available for review during the BRFA, but I don't know if it was actually reviewed by anyone - I don't imagine that it was, as it would make BAG members' lives even more difficult having to review entire codebases in languages they might not be familiar with to approve bots. The trial run over there went smoothly, because it was dealing with a smaller volume of messages to send, so there wasn't really an opportunity for this sort of an issue to arise. Naypta ☺ | ✉ talk page | 10:36, 17 June 2020 (UTC)[reply]
That's really too bad if no one reviewed it. It's troubling to me the possibility that code of this importance was not reviewed by at least one long-term experienced bot coder--ideally someone who had been here close to the start of the project. If truly no one reviewed it, I applaud your bravery at putting yourself out there like this, and give you way more slack than I might have from the beginning. No individual should have that level of responsibility.
I had assumed that all bot code had to be reviewed by a number of coders--maybe that was the case in the past.
How much time did you spend analyzing this kind of data:
1. the average number of new RfC's launched per month
2. " " per category
3. the typical number of responses to an RfC?
Do you have some data that you compiled and analyzed?
It sounds like the tests you did were insufficient.
Maybe we can work on some better tests and data analysis to be sure it is doing what editors expect and the input/output ratio makes sense. If we can figure out what LegoBot did, that might be the best, since the challenges we are seeing now may have been worked out already over the years the bot was working.
I'm going to try to do some more research on how Legbot handled the RfCs. Did anyone assist you at all in working on the code?
I see programming language is Golang.
I'm a little unclear on exactly where Yapperbot is located. I think you said: ytbtools
If that's the case, where is the entry point(s)? I hope you can be patient with me. This may be obvious to others... --David Tornheim (talk) 11:10, 17 June 2020 (UTC)[reply]
P.S. After writing the above, I see that three editors commented at Wikipedia:Bots/Requests for approval/Yapperbot. I'm surprised they are not here commenting and making suggestions on how to move forward. I think we should invite them at some point, but hopefully they will find there way here on their own. I think those who reviewed and approved this may share some responsibility for the problems and glitches that could have been caught. --David Tornheim (talk) 11:10, 17 June 2020 (UTC)[reply]
@David Tornheim: At the end of the day, this is a volunteer project, and whilst MediaWiki has paid developers, neither I nor the BAG, nor any other user, has any financial incentive for building bots - we do it to make the encyclopedia better. Imposing a requirement for code review makes total sense when committing stuff to the core repositories for MediaWiki, and indeed is used for MediaWiki extensions, but for a bot - something that runs off a single user account, can be easily blocked if need be, and is still subject to many (albeit not all) of the same limits that other users would have - it's just not a requirement. To the best of my knowledge, it's never been one.
I don't have a formal analysis of the number of RfC responses, no; I of course have anecdotal experience, but I don't have a specific report to show you. If this was a new bot task, I might have considered doing such a report, but as it's just taking over from what a bot was doing previously, replicating the functionality without adding anything new, my feeling (and evidently the feeling of the BAG) was that such a requirement would have been unnecessary. This is, again, the difference between an enwiki bot and commercial code: this is a passion project, not something where there's a list of deliverables, a timeframe and some set objectives.
I'm the sole author of all of the code - there have been no other contributors, pull requests or specific code suggestions made, with exception to some help I had with some of the regexes from some very helpful people on #regex on Freenode. ybtools is the library that powers all of Yapperbot's tasks, including the FRS one; the specific FRS code is here. The entry point in that code is main() in main.go, as is standard for Golang code. Naypta ☺ | ✉ talk page | 11:19, 17 June 2020 (UTC)[reply]
I wrote the below response while you were post the above. I haven't had a chance to read it yet. Need to call it a night... --David Tornheim (talk) 11:55, 17 June 2020 (UTC)[reply]
@Naypta: I'm back. Thanks for the two responses of 11:19 [above] and 12:05, 17 June 2020 [below]. I will start responding to those shortly. Are there any updates other than #Moved_from_kill_switch below? After I reply to you, I have some ideas of work I can do that hopefully we all can find helpful in making sure this bot's handling of RfC's is the best it can be in the short term and long term.
Having not been involved in the code, I think I can help others (especially those who don't have strong programming skills) understand how it works, how it might be improved, the parameters both internal limits and parameters that can be input by users (or admins) to adjust function. I propose tests that can be performed to assure desirable function. I do intend to help collect data on RfC's. I think that is important to seeing if the parameters you established are reasonable/desirable. --David Tornheim (talk) 01:54, 18 June 2020 (UTC)[reply]

Importance of Bot

@Naypta: In response to this comment immediately about how this is a volunteer project and we are not writing code for money here. Yes, obviously true. You seem to imply that because of this, we should lower our standards and shouldn't expect vigorous code review and/or testing. On that point, I disgree.

Despite being a volunteer project, this is one of the most important places people go for their information. The primary reason I edit is that I want to contribute and do my part so that the information we deliver is what is reflected in reliable sources and does meet our rigorous standards like WP:NPOV.

As for the importance of accuracy in bot coding/functionality/testing, especially RfC notifictions, I think it is very important: RfC's are a good way to invite non-involved users to help address difficult content disputes and to help with WP:NPOV and WP:OWNERSHIP issues. If it wasn't so important, I wouldn't be devoting so much time to helping with getting this bot working satisfactorily. I have been on this project for 12 years, and have not taken any serious interest in the functionality of these bots and how they are coded, until I eventually discovered that the reason I stopped getting WP:FRS notices is because the bot has been broken. That is certainly a problem for the project and I am very pleased you are working on it. Again thank you! --David Tornheim (talk) 05:11, 18 June 2020 (UTC)[reply]

@David Tornheim: I don't wish to suggest that the quality of our code should be lower as a consequence of it being a volunteer project; I merely mean to say that people have less time to commit to it, and requiring a formal process of code review would make innovation incredibly difficult, as a result of nobody having the time to deal with it. I'm writing code in Golang here, I've used a library for the core MediaWiki communication, but for the majority of the other parts of the bot, the code is all mine in raw Golang. It would be unreasonable to expect BAG members to learn Golang specifically so they could critique my bot, and it would also be unreasonable in my view to say "if you want to develop a bot, you have to do it in PHP". Code review on MediaWiki itself works because MediaWiki is (close enough to) a single codebase, and projects in Gerrit are generally those that have official Foundation support or have significant enough perpetual community support to be able to go through those code review processes easily. This model doesn't work for bots - not least because, as we've talked about below, there is no requirement for code to be open. Naypta ☺ | ✉ talk page | 08:19, 18 June 2020 (UTC)[reply]

Legobot

Legobot's code

@Naypta: I just looked at the LegoBot code you referred me to: Legobot code. It actually looks pretty straight forward to me--far easier to read than I expected. I see it does a per day calculation:

70: $time = 30/$frsl_limit;

That's how it avoided the problem you ran into. I don't see any limits to how many notices go out per RfC. I do see that it uses an SQL database to make it efficient. It looks like it cycles through every single RfC and every single user who wants notification and there is nothing random about it. I believe it focuses on how much time is left before user can be notified again. I believe it is something like this: (for the "all" RfC case)

initialize MinTime = maximum time to wait before bot runs again (e.g. 1 day)
For each user ($u) {
For each rfc ($r) { /* starting with oldest first */
if ($u has not been notified of $r -and- $u has not reached notification limit yet) {
notify $u of $r
tell database that $u has been notified of $r
}
Calculate delta time $t required before $u can receive next notice.
If $t < MinTime then MinTime = $t
}
}

The bot would wait the larger of $t -and- some min. increment (e.g. 10 seconds) before bot cycles through these again.

That was for the general case of getting all RfCs. Another third loop for each category $c would handle that issue.

To be efficient it could keep track of how much time is left before each $u can receive another notification in each category $c.

Whichever user can next receive a notification is when bot would do the query again.

Are you familiar with SQL? I recently took a Database course, so I know it.

Because it is database, a properly designed query should take care of both loops, returning all relevant records.

Anyway, I believe I can figure out how it works and document it. I will be very curious to see how things are similar or different than your code. --David Tornheim (talk) 11:55, 17 June 2020 (UTC)[reply]

@David Tornheim: Yes, I'm familiar with SQL. It was a deliberate design decision not to use a database for any part of Yapperbot. I didn't want to create a scenario similar to that we have with Legobot, where I might be unavailable to fix it, and things start going wrong, with nobody else able to sort it out, or understand why it's wrong. To that end, all of the data is stored on-wiki, with sole exception to a single file that just stores the timestamp and ID of the last GA nomination (this file is automatically created, so you could replicate it on your own PC anyway).
I came to the same conclusion when evaluating Legobot's code that you did - that there was nothing at all random to do with it - but that completely contrasts with not only the statements made on-wiki about what Legobot did, but also with the code itself - you see references to random user selection in the variable names. I can only suppose that the code that is available on GitHub is not the actual code that was running on Legobot, which is part of the reason I didn't waste too much time looking over the code and documenting every part of it. The other part of that decision was that I wanted to ensure that the design of Yapperbot was independent of that of Legobot, as there had previously been many issues with Legobot even when it was operational, with some even calling for it to be blocked for the way that it handled the FRS. (Incidentally, I'm currently writing code to prevent this exact issue - allowing individual Yapperbot tasks to be blocked individually by administrators.)
Keeping a particular timeframe between informing users is one way of dealing with the issue, I can appreciate that - but on the other hand, that does potentially negatively impact on users who are more active and genuinely want to receive more notifications. It would also result in a much larger JSON file stored on-wiki, so it's something to bear in mind. Naypta ☺ | ✉ talk page | 12:03, 17 June 2020 (UTC)[reply]
I'm back [1]. Will respond to these soon. --David Tornheim (talk) 01:58, 18 June 2020 (UTC)[reply]

Is Legobot code private?

@Naypta: Above you had said: I can only suppose that the code that is available on GitHub is not the actual code that was running on Legobot, which is part of the reason I didn't waste too much time looking over the code and documenting every part of it.

This statement is deeply concerning to me. From what you are saying, it sounds to me that you are saying we don't have access to the actual code that is running Legobot and therefore we are not able to change it, and that only the author of the code can. If true, that to me is a big problem.

I don't think bots that can have huge impacts on the project and could make 1000s of edits in seconds should be private.

Also, what if the coder suddenly disappears? What if the code has biases built in that we are not aware of because we can't see and analyze the code?

I didn't reliaze the bots are basically like regular accounts that can be blocked, but are controlled by software.

The potential that the code or data the bot uses might be private and could be changed without our knowledge is very concerning. It reminds me of all the problems with Black box voting and proprietary software. Richard_Stallman gives his two cents on that.

If the code for some bots really is proprietary I believe that would need to be discussed else, and probably already has. If anyone wants to point me to those discussion(s), I'm all ears.

But I do want to confirm: Is it true that we really don't know for sure what code Legobot is running on?

--David Tornheim (talk) 05:20, 18 June 2020 (UTC) Wow.[reply]

Authors of bot processes are encouraged, but not required, to publish the source code of their bot. WP:BOTCONFIG Wow. --David Tornheim (talk) 07:53, 18 June 2020 (UTC)[reply]

@David Tornheim: Well, technically speaking, nobody but myself and the admins of Wikimedia Toolforge knows for sure what code I'm running Yapperbot on I can tell you, and tell you truthfully, that the exact code you find on GitHub is what is running on Toolforge, but there's no independent guarantee of that of course, apart from going and asking a Toolforge admin. I've chosen to host Yapperbot on Toolforge, not only because it provides a free environment for hosting tools beneficial to the Movement, but also specifically because it means that if I'm not around for a long time and things break, someone else can go and request maintainer status on the tool to take over from me. Using Toolforge for a bot, however, is very much not required.
Bots on Wikipedia aren't running elections - they're sending messages, reverting vandalism and handling minor cleanup tasks. I like free software as much as the next person, and I strongly believe that bot operators should make their bot code public, but I don't think it should be that they must do so. Naypta ☺ | ✉ talk page | 08:15, 18 June 2020 (UTC)[reply]
LOL. Well I appreciate your sentiment of thinking this should be public. In the distant past I worked at big and also small corporations that maintained code for hardware and software. It would be absolutely unacceptable at those businesses for a regular employee to provide an executable that the company heavily relied on for which no source code was available. If they gave two week notice, the first thing they would need to do is document all their software.
Bringing the company's valuable software home with you--even if you created it--is technically stealing company work-product and could land one in court or even jail. (I'm assuming you know that.) I remember cases against former Intel & IBM employees, and FBI raids. I was a first hand witness to a section head who was fired by a superior who had previously worked for IBM. The superior said he used IBM's method to deal with the firing: The superior first crashed all the computers, then invited the employee who was to be fired to his office to tell him bye-bye, and then had the locksmith change the lock on the employee's door during the meeting!
This was all to keep the employee from either taking, deleting, or changing any software. It was something else to experience. I will never forget it.
I shared this story so you might understand just how shocked I am that wikipedia makes no serious effort to assure bot software it relies on doesn't disappear with a volunteer...as happened with this fairly important bot...
That you have had to recreate the bot from scratch, because you don't have access to the code, is just as unbelievable. I do believe you. --David Tornheim (talk) 09:05, 18 June 2020 (UTC)[reply]
@David Tornheim: I understand what you're saying, for sure - but this isn't IBM, it's Wikipedia We're very proud of being volunteers, of not being a corporation - we're here because we want to be. If some bot the community uses breaks, someone else can pick it up and either fix it, if its code is available, or build a new one if it's not. Again, I fully support bots being FOSS - hence all parts of Yapperbot are open source and licensed under GPLv3 - but I'm not sure it's reasonable to demand that volunteers give up their IP in that way.
As to recreating the bot from scratch, it wasn't actually lack of access to the code that made me take that decision primarily; I could have taken the exact code on GitHub, tried running it, and just gone from whatever happened when I did that. There were two primary motivating factors for rebuilding it completely: removing the reliance on an external database, to make sure that the bot was as open and transparent as possible, and changing from PHP to... almost anything else Naypta ☺ | ✉ talk page | 09:12, 18 June 2020 (UTC)[reply]
Well, Wikipedia probably is more important and has greater impact and visibility than those private entities, so the stakes are higher.  ;) I'll take the comments about intellectual property under advisement--I think that is better discussed at the policy page. I believe I'm done discussing this for tonight. I hope you don't mind that I sort of volunteered you to take over Legobot. I won't feel at all hurt if you don't want to, and I am happy revise that suggestion if no one has responded... --David Tornheim (talk) 09:34, 18 June 2020 (UTC)[reply]
(edit conflict) I followed this up by posting here: Wikipedia_talk:Bot_policy#Bot_code_--_can_remain_proprietary??? --David Tornheim (talk) 08:15, 18 June 2020 (UTC)[reply]

Functionality

Wow, a lot has happened. I don't even know the right place to respond, so adding this artificial break. Feel free to refactor, retitle this from "break" to something better, or to move it to a more logical place. (I'm waiving TPO, so go for it.)

Your point #2 of shipping multiple Rfcs in one post would be acceptable, because it eliminates locking me out of my page, but it's not optimal, because I'm simply not going to respond to 30 Rfcs; it would be better to space them out, meaning in practice, I won't get all 30 of them, and most will be reassigned to something else, which is exactly what ought to happen, if there's any hope at all that someone will address them.

We shouldn't lose focus of what this is all about: this is not about a coming up with a schedule for a bot dropping cookies or kittens or brownies on user talk pages, and then it's done, and how many kittens are too many. There's a point to the messages that the bot is writing: namely, to encourage a user to go to the linked page, and spend the amount of time required to respond to an Rfc that needs eyeballs. That is the goal here. Working out whether the "bot is doing what you told it to" on the signup page, is cop-out. We all know why people are signing up, and we're volunteers here, so don't insult our intelligence. (This is not directed at you, but at a snarky comment on the original page, that elicited only my disdain for software engineers that have spent too much time in the office, and are disconnected from people, and reality. I'm an ex-sw engineer, and I recognize the disease. Let's chalk it up to covid-cabiin-psychosis, and give them a pass this time.)

I'm not going to respond to all the stuff about different seed and other individual tweaks, because I have no way of knowing how that will alter things next time around. The goal I'm looking for, functionally, is that if I've signed up for 60 notices a month, that works out to one every 12 hours; therefore, after Yapperbot sends the first one to me, it must stay off my page for 12 hours. I don't know the internals of either the tables or the bot (I know the code is open, but I'm trying to stay away) but I know if I were designing it, I'd do a first pass of the signup page to build an in-memory hash with {$user -> [$average_delay, $last_notif_timestamp] } (where $average_delay holds "12 hours" and ts=0 after startup pre-scan in my case, in whatever units are convenient), and each time through the main loop, you check if $time_now > $last + $delay, and if it isn't, you skip to the next user, and if it is, you do your thing and update $last. If you crash or cold start, then you'd send me one notification right away, and no other for around 12 hours, right? (This won't fix the case where your program is crash-restarting every few minutes, but I'm assuming that you don't auto-restart after a crash? Extra credit: read my TP after a crash, find your last notif, set $last from that.) If that doesn't work, then every time you write me an Rfc, you first read my Talk page, to make sure at write time that you don't wipe out someone else via an edit conflict, right? So, use your Rfc notif on my page as a cookie: read back the timestamp of the last Notif you wrote, and calculate the delay that way. Mathglot (talk) 03:25, 18 June 2020 (UTC)[reply]

Oh yeah: and a shout-out to "not an edge case, but core functionality". +10. Mathglot (talk) 03:33, 18 June 2020 (UTC)[reply]

@Mathglot: I basically agree with everything you wrote. Do you agree with me that there should be no limit as to the number of people who receive a notice for a particular RfC? I believe Legobot had no limit. --David Tornheim (talk) 04:16, 18 June 2020 (UTC)[reply]
A big question for me is how it is supposed to work when there are more RfC's per month than the user requests (that also applies equally to # of RfC/month for a particular category). Which notification would they not get, especially after cold start? For the case where the expected # of RfCs per month is less than the user limit, then one would start with the oldest first until it is caught up. But the reverse might be true for for someone who only wanted 1 RfC per month. Any thoughts on that?
I haven't looked closely enough at the new code and data stored to see how we know if the user had or had not been informed of a particular RfC. There are other RfC attributes of importance for helping to answer and address the questions I raised in the above paragraph:
  1. Is it open?
  2. When was it opened?
  3. How long has it been open? [easily calculated from 2.]
  4. How many editors have been notified?
  5. How many editors have responded?
Items 1, 2, and 3 seem essential to bot functionality. Calculating 4 and 5 might be more difficult. Are these being calculated and used? --David Tornheim (talk) 04:18, 18 June 2020 (UTC)[reply]
@David Tornheim and Mathglot: To try and give a brief answer to all of the technical questions that have been raised here:
1: The bot detects whether an RfC is open or not based on the presence or absence of the {{Rfc}} tag, which is removed from RfCs that are no longer open.
2 and 3: When the RfC was opened absolutely is not taken into account, only relatively. The bot scans for RfCs, detects those that have been opened since it was last run (i.e. those that haven't yet had a message sent), and sends the messages for them.
4: This is easily technically possible, but isn't relevant in the current implementation.
5: This is more difficult in the current implementation, and nor is it relevant to it.
In the current implementation, the list of applicable users for an RfC is randomly sorted, then users are selected from the start of the list in order - which is a way of performing random selection of the users. If a user has exceeded their limit, the next user in the (random) list is chosen. If the entire list is exhausted, it just sends to the number of valid contacts it's reached at that point.
To reply to some of Mathglot's concerns in particular - because of golang's defer functionality, a standard panic should cause cleanup calls to be sent, meaning that the relevant JSON updates would be stored for everything the bot has done anyway; a full on segfault might not do that, but it wouldn't auto-restart then until the next time it was scheduled. Logs are stored on Toolforge for it.
I'm not sure it's a good idea for the three of us to set the specifics of what is, at the end of the day, a decision as to what the FRS is rather than how it is implemented - that is, vis-á-vis the number of messages sent per day, and whether users are selected at random or simply all are sent. However, I recognise that two people expressing concern is, in and of itself, significant. For that reason, I intend on creating a survey of FRS subscribers, to see what people specifically want. I will write this up in neutral terms, and once it has been written, I will advertise it both through a mass message to FRS subscribers and at the relevant Village Pump. This will address several of the issues here, along with some other potential changes that have been suggested. I hope that's something we can all get behind
Final thing for this message (and sorry that it's become a slight sermon!) - I want to address the "edge case" thing. My name is double-barrelled. I'm a living edge case! It's not a way of saying "oh, this doesn't matter because it rarely happens", it's just saying "this isn't the normal operational condition". I find it frustrating when organisations can't work with my name because of the hyphen, just like if you're caught up in this edge case it's frustrating - and I don't want to minimise that, so apologies if that's the way it came across. I'm talking specifically from a technical perspective when I use the term "edge case". Naypta ☺ | ✉ talk page | 08:10, 18 June 2020 (UTC)[reply]
Just one point, which David raised, and Naypta kind of answered the way I would wish, namely:
Q: Do you agree with me that there should be no limit as to the number of people who receive a notice for a particular RfC?
Without being coy, I don't want to respond to that here, because it seems to me out of scope, and because it could tend to lead to a more open-ended discussion about all the functionality of the bot, including, polling people what they want the FRS to be or to do. That is far beyond the scope of how I view my involvement, which is basically as a bug-report on (what I see as) the existing functionality, not developing a new conception of what the bot should do across the board, or how it should be designed. From my viewpoint, the current (implied) specification is fine: the bot delivers Rfc notices periodically to my Talk page, obeying the rules implied in the sign-up page. To me, "implied in the sign-up page" (since it's not a formal spec) includes not delivering more than two a day in my case; anything else is a bug; to others, "it's what you signed up for".
Naypta, it sounds like you are agreeing with my basic conception, and I wouldn't poll anybody about what I view as a bug, but if you do go poll the group about anything, I would only beg that you keep it to the most focused and targeted question possible, to avoid opening up a free-ranging discussion that could open up a can of worms. (Nothing wrong with that for later; I just consider that a different scope, deserving of a different discussion.) If you do decide to, the wording of such a question could be a little tricky, but imho it should be restricted to what I believe we are all talking about here: "what is the right frequency (or maximum frequency) of comments that should be posted to your Talk page, if you have signed up for N Rfcs per month?" You can add an example, if that makes it any clearer: "For example, if all your signups could theoretically produce 30 Rfc invites on your Talk page over the course of a month, when the bot starts up fresh from scratch after a long outage, how many should it post the first day?" (My answer: "1".) It's a little tricky how best to phrase this, so it really covers the information you want, without becoming too opaque to the user. Maybe you an come up with better phrasing. Or, you could just treat it as a "bug fix", put in the frequency throttle yourself and don't survey anybody, and see who complains. I fully expect nobody would complain, and practically speaking, that is probably the least time-consuming approach. It's late and I'm a little fuzzy, but I hope this helps. Mathglot (talk) 08:38, 18 June 2020 (UTC)[reply]
P.S. re "edge case": my spouse has a hyphen, I don't, but I do have weird consonant bigrams that flummox most everyone. I'm not so much an edge case, as a vertex, or a point at infinity or something... Mathglot (talk) 08:40, 18 June 2020 (UTC)[reply]
@Mathglot: Heh, I like the description of someone as a "point at infinity" - I think we'll get along nicely with those sorts of descriptions As to the actual substantive issue, I've been thinking about this for a little while. I'm not opposed to limiting the number sent to one a day, in any way - so I did think about just implementing it straight up. The problem with that, I realised - and the reason I'm going to add this to a survey - is that it's not clear what happens when everyone on the list has been asked, then. At the moment, there are some categories - especially for GA nominations - that are very small on the main FRS page, very few editors subscribe to them. If a GA nom comes in which fits into one of those categories, say with three users in: let's say User 1 has already had a message today, user 2 has already had a message today, and user 3 has reached their total limit. What happens? Do we delay sending the message until tomorrow (no function to do that in the current implementation, but could be written in)? Do we ignore that GA nom completely? Do we do something totally different? This then becomes a more "what does the FRS look like" question than a "technical implementation" question, which is why I think it needs to be put out for broader consensus.
As to specificity, I agree - what I'm going to do is create a page under WP:FRS with some (probably around six to ten) specific questions, each with a survey subsection and a discussion subsection. Hopefully people will discuss those questions sensibly! Naypta ☺ | ✉ talk page | 08:52, 18 June 2020 (UTC)[reply]
Please understand that in saying "one a day" I am not suggesting or implying some sort of artificial threshold or rule of thumb that applies to everybody. Rather, I was saying it should be derived per user. I.e., if someone signs up for a possible 30 a month total, then that averages to one a day. If someone else signed up for 120 a month, that would be a max of one every six hours, in their case. If a universal limit were much easier to implement, and I can see that it might be, then that might be another approach. That could be a question worth putting to a larger group. If it isn't harder to implement, I'd still like to see the derived figure; sign up for ten a month: you get a max of one every three days. Sign up for 720 a month, then you get a max of one an hour. Maybe that's too hard. Mathglot (talk) 09:03, 18 June 2020 (UTC)[reply]
@Mathglot: Nope, that'd be absolutely possible to implement - but it might also not be how people want to do it, because the FRS is split into categories. Someone might want a maximum of one message per day for a GA nomination about tech, but nine a day about something else. This is another point I'll include in the user survey, to try and see what people actually want it to do - one outcome might be to have an automatic calculation of a derived figure, with an optional {{Frs user}} param to set a specific figure instead. Very few things are off the table on the basis that they're "too difficult" technically to do - I just want to make sure that the time and energy invested in doing the things are worth it for the demand in the community for the feature Naypta ☺ | ✉ talk page | 09:07, 18 June 2020 (UTC)[reply]
Good point, didn't think of that; that is even better. And yes; definitely don't want to waste time doing something nobody is interested in, or would make it worse for them. Thanks for considering all the wrinkles. Mathglot (talk) 09:31, 18 June 2020 (UTC)[reply]
I will respond to implementation/functionality later today. --David Tornheim (talk) 18:57, 18 June 2020 (UTC)[reply]

Random selection

Moved from Wikipedia:Feedback request service/2020 survey § Random selection

Rather than randomly reordering the list for each RfC, which could result in one person being selected several times in a row, have you considered "load balancing" the list by randomizing it once, and then going through it sequentially until everyone has been assigned a case? Once the list is exhausted, a new list could be generated. -- Norvy (talk) 19:49, 18 June 2020 (UTC)[reply]

@Norvy: Good suggestion! There's a few problems with doing it this way: firstly, it hugely delays the timeframe for new users being incorporated into the list, as it'd mean that they would need to wait for the list to be exhausted before they would even be considered. Secondly, it could cause issues if users unsubscribe, as they might keep receiving messages. Finally, it introduces a new moving part; rather than just taking the list as is from the wikitext, it'd then need to have a separate list of users, that the bot would have to maintain.
That being said, neither of those issues is insurmountable; what might be a good idea would be to have the bot construct a list of applicable users on run 1, sort it randomly, store it in a JSON file, and then have each successive run running off that list. Each run would check at the start whether the list had been updated; if it had, it would re-create the list. If there were no changes, it could then use that method to evenly distribute the messages sent, whilst keeping the random sorting. What do you reckon about that? Also copying in David Tornheim and Mathglot who I suspect will be interested in this. Naypta ☺ | ✉ talk page | 20:16, 18 June 2020 (UTC)[reply]
Why not just have any updates to WP:FRS trigger a bot that updates the JSON file? Or just check the WP:FRS file once per day and put notice that says it will take 24 hours to update. Maybe it isn't a big deal to check if the file has been updated every time the bot is run, so your implementation might be fine too. --David Tornheim (talk) 20:47, 18 June 2020 (UTC)[reply]
@David Tornheim: That could be doable, but what's the advantage of doing it that way over the way that I suggested? It seems like the way I've proposed would involve a lot less legwork, rather than having to arbitrarily monitor every edit to the page as it's made. Unless you mean the same thing I've suggested, just without a full random shuffle when the list is updated - but without that, my concern is that we're shifting slowly further towards a separate user list, rather than keeping the user list canonically stored on the FRS page. In effect, I want to make sure that issues are preventable and fixable by as many people as possible, all the time. Naypta ☺ | ✉ talk page | 20:47, 18 June 2020 (UTC)[reply]
This was posted before I saw you had updated your comment, for what it's worth. Naypta ☺ | ✉ talk page | 20:48, 18 June 2020 (UTC)[reply]
How and where is the number of times a user has received a notice for the current month stored? -- Norvy (talk) 21:47, 18 June 2020 (UTC)[reply]

Loops

My issue is your choice of outer loop:

MaxNotificationsPerRfC = 5 to 15
For each rfc ($r) {
For $i = 1 to MaxNotificationsPerRfC {
user $u = randomly selected user who has not reached notification limit -and-
who has not yet been notified of $r
notify $u of $r
}
}

I really don't like the idea of randomly choosing who will be notified based on some arbitrary number of notifications per RfC chosen by the program/programmer. This approach has too many possibilities of bias. It also has the strong possibility that users who have capacity to receive many notification won't get them.

I believe the outer loop should be the user, not rfc, like this:

For each user ($u) {
For each category ($c) {
If it is too soon for $u to receive notification in $c, then skip to next $c.
For each rfc ($r) in category ($c) { /* starting with oldest first, or chosen randomly from the list of open RfCs */
if ($u has been notified of $r) skip to next $r
else {
notify notify $u of $r
$t = soonest user can receive another notification in $c.
break; (i.e. skip to next $u)
}
}
}
}
run bot again for min. $t found.

When a user is available to receive an RfC and there is more than one RfC available that they haven't been notified of, then I don't mind if the choice of the RfC to be notified is random, although I think it is better to choose the oldest (or newest first). I just don't see much need to use random selection. --David Tornheim (talk) 21:41, 18 June 2020 (UTC)[reply]

@David Tornheim: This isn't a code issue, this is a "what is the FRS" issue, as we've discussed earlier. Your proposed loop is just an implementation of what you think the FRS should be - with everyone receiving all messages all the time that they can, rather than having any random element involved. That's fine, and a valid viewpoint, but it's different to what the FRS is documented to be - hence why it's the first question in the proposed survey Naypta ☺ | ✉ talk page | 21:44, 18 June 2020 (UTC)[reply]

Survey (drafting)

[This is mentioned a bit above. I will copy those relevant parts of conversation soon.--David Tornheim (talk) 18:41, 18 June 2020 (UTC)][reply]

@Mathglot and David Tornheim: I've created Wikipedia:Feedback request service/2020 survey, which I intend on sending to FRS subscribers and publicising at the Village Pump, as mentioned earlier. I want to make sure you're both happy with the way I have worded the proposals before I do, though. Please let me know if you think it looks good, or if there are any changes you would like to be made (or equally, additional questions to ask!) Naypta ☺ | ✉ talk page | 10:48, 18 June 2020 (UTC)[reply]

@Naypta:. Great. I support the idea--I probably would have done it if you hadn't. Thx for giving us chance for input. Please give me 24 hours to reply & provide any proposed changes before launching. I strongly agree with Mathglot that if you do go poll the group about anything, I would only beg that you keep it to the most focused and targeted question possible, to avoid opening up a free-ranging discussion that could open up a can of worms. I have seen numerous poorly formed RfCs that made a disagreement worse and even more confusing, that were closed as no consensus. This is not so helpful at resolving the problems, moving forward with a new clearer direction. Often the worst problem is the question was too vague or made assumptions that respondents did not agree with and then argued about. Sometimes a yes/no is best. The less text users have to read the better. Links can be provided for discussion context. --David Tornheim (talk) 18:52, 18 June 2020 (UTC)[reply]
Yeah, I'm a bit slow, as well. Copla days? (David, thanks for new section header. I unindented, feel free to undo if you prefer.) Mathglot (talk) 19:01, 18 June 2020 (UTC)[reply]

Moved from kill switch

Moved from User:Yapperbot/kill/Uncurrenter
 – Mdaniels5757 (talk) 00:42, 18 June 2020 (UTC)[reply]

Consider me the first to complain - I came here following this edit. I think the set-up of this bot has confused {{current}} with {{inuse}}. As User:Primefac has pointed out, five hours is way too short. "Current" marks the fact that the event described by an article is still ongoing, not necessarily that much editing is taking place, which is what {{inuse}} is for. I don't think we should be enforcing the removal of {{current}} that quickly - if I hadn't seen the BRFA discussion I would recommend a wait period of 1 month; but I understand that others want a shorter period and can compromise on anything longer than 24 hours. Deryck C. 00:22, 18 June 2020 (UTC)[reply]

I can't remember where the discussion was to link (although there was some at the bot reuqest), but there was recent consensus that the purposes of {{current}} was not simply to highlight events currently ongoing but to denote articles that are currently unstable because of a high rate of editing, which is in turn because its a current event and the available information is changing rapidly. If a page has not been edited for 5 hours then {{current}} very much does not apply - indeed if the article hasn't been edited in 1-2 hours it isn't unstable. {{in use}} is for when an article is undergoing major work by typically one editor and is entirely unrelated to current events. If you think there should be a template that highlights articles about current events irrespective of editing rate then you need to get consensus for that separately because it is not {{current}}, where the documentation explicitly says "It is not intended to be used to mark an article that merely has recent news articles about the topic; if it were, hundreds of thousands of articles would have this template, with no informational consequence." Thryduulf (talk) 00:32, 18 June 2020 (UTC)[reply]
Also, to steal what User:Sdkb said from their speedy deletion template (which I removed): "Bot kill pages are for emergency use with malfunctioning bots, not for disabling bots functioning in compliance with their BFRA because you don't like them" --Mdaniels5757 (talk) 00:45, 18 June 2020 (UTC)[reply]
I'm replying to this over at the RFBA talk page. Naypta ☺ | ✉ talk page | 08:20, 18 June 2020 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Yapperbot&oldid=963275466"