User talk:Yapperbot/Archive 2

This is an archive of past discussions with User:Yapperbot. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Moved from kill switch

Moved from User:Yapperbot/kill/Uncurrenter

– Mdaniels5757 (talk) 00:42, 18 June 2020 (UTC)

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)

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)

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)

I'm replying to this over at the RFBA talk page. Naypta ☺ | ✉ talk page | 08:20, 18 June 2020 (UTC)

nobots

Hi, please check whether Yapperbot properly supports {{nobots}}. See Special:Diff/962878432 and Special:Diff/962949224 for an error. Thanks ~ ToBeFree (talk) 23:24, 25 June 2020 (UTC)

@ToBeFree: Hi, thanks for the message. As was indicated at the BRFA for the FRS task, {{nobots}} is not supported by the FRS task, on the basis that it is an opt-in service that anyone can choose to opt out of at any time anyway. It is supported by Uncurrenter, the other task currently approved. In the case of blocked users, at the moment, I am manually pruning them every so often from the list; however, there is a separate bot task currently under application which will automatically remove blocked and inactive users according to a schedule. Cheers! Naypta ☺ | ✉ talk page | 08:56, 26 June 2020 (UTC)

Ah, thanks!

~ ToBeFree (talk) 09:27, 26 June 2020 (UTC)

Discussion of this page

FYI. This page is discussed here: User_talk:Mathglot#Hi (permalink) --David Tornheim (talk) 22:46, 4 July 2020 (UTC)

@David Tornheim: I think you should consider several parts of that message, David. You quite rightly observed above I believe you made an offer somewhere above to document it. I would very much appreciate that - and yet suddenly in this message you've said I'm not having much luck getting the documentation for the code. You've then said I will have to reverse engineer the code; this isn't what reverse engineering is. Reverse engineering is looking at behaviour and trying to work out how something works from it. You already have the code - reverse engineering is totally unnecessary.

You may wish to be aware that I have made a significant change to the random selection algorithm just now; it now uses a cumulative distribution function of inverted weights based on users' progress through their sending limits to bias the random selection towards those who have received few messages. In the same commit, I have added documentation comments to all of the five or so remaining methods that did not have a documentation comment, with exception given solely to the entry point method and the init() methods, which have specified roles by Golang itself and wouldn't ever be manually called. Go will automatically generate documentation from this, which I am happy to move onto wiki somewhere if you like, although you could read the code and get the same understanding. Naypta ☺ | ✉ talk page | 09:29, 5 July 2020 (UTC)

@Naypta: Having a bachelors and masters in engineering, and extensive experience in industry doing it, I'm amused you think I don't know what reverse engineering is. LOL.

The concept is not limited to engineers who have nothing but the executable or the silicon. One may have access to the schematics and the code and the "documentation" and possibly even the author, and the only way to figure it out is to "reverse engineer". This is a very common problem when the creator has left the organization, died, transferred to another division or simply is too busy on other projects to be of any help. In some cases the person who wrote it 3+ years ago doesn't understand their own code and the documentation either! You might be surprised how often that happens. They may have to reverse engineer their own code.

The wikipage you linked to reverse engineering uses the IEEE definition of "the process of analyzing a subject system to identify the system's components and their interrelationships and to create representations of the system in another form or at a higher level of abstraction".

That sounds about right, that includes deciphering source code that has limited documentation and explaining it at a higher level of abstraction.

One source says^[1]

6.1 Application of Reverse Engineering in ICT

The most common form of reverse engineering in computer programming and engineering is deeply rooted in the everyday tasks of the engineer. The making of a program or a piece of

electronic equipment largely consists of interactions with libraries and components that one has not made oneself. Everybody who has worked as an engineer in ICT will know that

the interfaces of such libraries and components are hard to understand and often lack the necessary documentation. Reverse engineering the interfaces of the components you need

is therefore something that every ICT engineer will have spent time on [6].

[6] Eilam, E.: Reversing: Secrets of Reverse Engineering. Wiley, New York (2011) [Google Scholar]

[Emphasis added.]

References

[1]
Lysne, Olav (2018), Lysne, Olav (ed.), "Reverse Engineering of Code", The Huawei and Snowden Questions: Can Electronic Equipment from Untrusted Vendors be Verified? Can an Untrusted Vendor Build Trust into Electronic Equipment?, Simula SpringerBriefs on Computing, Cham: Springer International Publishing, pp. 47–55, doi:10.1007/978-3-319-74950-1_6, ISBN 978-3-319-74950-1, retrieved 2020-07-05{{citation}}: CS1 maint: work parameter with ISBN (link)

Other examples of people asking what to do with source code that has insufficient documentation. .

So, yes, if there is not enough documentation, the person reading your code has little choice but to reverse engineer it to figure out how it works. In fact, I was going about the process described here, when I was asking questions about the entry point, the interfaces, variables, what each module does, etc.

Go will automatically generate documentation from this,

I have never heard of a program that is capable of documenting source code.

If you can make one, you will be rich. It would be like asking Deep Blue why it let Kasparov win in Deep_Blue_versus_Garry_Kasparov#Game_6 by letting him improve his position. It's answer would something like, "I did no such thing! In each position, I looked at millions of positions, and I did mix-max tree pruning, and I used the best result. My calculations definitively show that every move he made did not improve his position, and the game was going to be a draw. I was happy to play it out, but the programmers shut me down. Inconceivable! I was not the least bit tired. I can give you a complete list of every single position I tried, the score I calculated if you like, and show you why my calculations were correct, and why you don't know what you are talking about. I can calculate faster than any human. Do you have a room full of paper where I can prove this to you?"

You may wish to be aware that I have made a significant change to the random selection algorithm just now; it now uses a cumulative distribution function of inverted weights based on users' progress through their sending limits to bias the random selection towards those who have received few messages.

I'm glad to hear that! Thank you. Which file is that in?

I have added documentation comments to all of the five or so remaining methods that did not have a documentation comment

I look forward to reading those. --David Tornheim (talk) 11:59, 5 July 2020 (UTC)

@David Tornheim: Having a bachelors and masters in engineering, and extensive experience in industry doing it, I'm amused you think I don't know what reverse engineering is. LOL

I apologise for the way that that came across; I was unclear, and I certainly didn't mean to insult your intelligence in any way. What I was trying to say is that the source code is there, the documentation comments are there, and I'm also here; there's no need to do what the article refers to as type 2 reverse engineering: In practice, two main types of reverse engineering emerge. In the first case, source code is already available for the software, but higher-level aspects of the program, perhaps poorly documented or documented but no longer valid, are discovered. In the second case, there is no source code available for the software, and any efforts towards discovering one possible source code for the software are regarded as reverse engineering. This second usage of the term is the one most people are familiar with. I'll freely admit that second usage of the term is the one I was thinking of here, and the only one I'd ever really heard used. Perhaps the first is more common in EE, I don't know; either way, I've learned something today!

I have never heard of a program that is capable of documenting source code.

May I introduce you to Godoc? For the record, a very similar system is used for the code documentation for MediaWiki. The program does not document the code itself, it generates documentation from markup around the code, including documentation comments. Whether this would be useful to you or not, I am unclear, but I am happy to generate it for you if you would like it.

I'm glad to hear that! Thank you. Which file is that in?

The relevant method is GetUsersFromHeaders in src/frslist/frslist.go.

Naypta ☺ | ✉ talk page | 12:10, 5 July 2020 (UTC)

Naypta Glad you learned something today. :) I thought you might have a good laugh at my Deep Blue response--I had fun writing it. I might send it to my engineering friend who I used to play chess with and spoke in depth about chess programs. Retrograde analysis is very interesting, and is a lot like reverse engineering the best chess move. I wondered if neural nets would ever get anywhere on chess over brute force, and they sure have.

I apologise for the way that that came across No worries. Thanks for the apology. I figured you only knew the one definition, which is why I took the time to explain it, and I am glad you were open to hearing it. Time well spent on my part! :)

Perhaps the first is more common in EE, I don't know; either way, I've learned something today!

I think it might be even more common in software development, especially huge operating systems. I remember hearing about the difficulty in maintaining the code for the IBM 360s (mainframes). It was my understanding that whenever they fixed bug in the code of the O/S History_of_IBM_mainframe_operating_systems#System/360_operating_systems, they often introduced a new bug! That some users claimed the older versions of the O/S were more stable than the ones with the bug fixes.... [I'll get back to the rest of this later...] --David Tornheim (talk) 13:24, 5 July 2020 (UTC)

@Naypta: [cont'd]...The point of the example of IBM's struggles, is that I believe code that was either not fully documented, or whose limitations were not fully understood by others could mean that changes to code that was "working" to "improve" it, may have fixed one problem, while creating a new one. I read over some of History_of_IBM_mainframe_operating_systems#System/360_operating_systems, and it indeed talks about the serious troubles IBM ran into, where they even learned,

"Throwing additional resources (especially staff) at a struggling project quickly becomes unproductive or even counter-productive because of communication difficulties."

There have certainly been some wonderful developments in programming languages, like modularity, object-oriented programing, etc., but to the best of my knowledge, the challenges of reading another person's code have never gone away. In fact, I think it is arguable that the only one who truly understands the code is the computer, which executes it with flawless precision doing exactly as it is told--bugs and all.

May I introduce you to Godoc?

Sure. Thank you.

I am happy to generate it for you if you would like it.

If it is easy to run, sure. Thx.

And thanks for the ref. for the new file. It looks better documented than some of the other files. I'll see if I can figure it out.

Do you think it is operating as intended? Once I had reached my 30 notices for June, I upped my max. to 60/mo. so I would continue to receive notices ~1x/day for the rest of the month. I expected to start getting 2x/day when July hit. But instead my notices in July have slowed down to a trickle. That suggests to me there is a bug. We'll see who finds it first. ;) --David Tornheim (talk) 08:40, 6 July 2020 (UTC)

@David Tornheim: I think it is arguable that the only one who truly understands the code is the computer - I don't know, I think there's some code we've all written at some point where it might even be difficult to convince anyone that the computer knows what it means...

To be clear, my comment about it being more common in EE was about the use of the word, not the practice. Of course, I spend quite a lot of my day reading undocumented code, but I've never heard a software dev call that reverse engineering - just "reading the code" is how I'd call it

I can only imagine how IBM might have had that problem...

I've uploaded the godoc texts to User:Yapperbot/FRS/Documentation/godoc, which you may find useful. I don't think you're familiar with golang (correct me if I'm wrong!) so the important thing to explain in understanding this which is different from how other languages work is that Golang uses capitalisation to determine package exports. That is to say, something (a constant, function, variable etc) in the frslist package in src/frslist that is entitled Something will be accessible in any package that imports frslist - for instance, the main package, which contains the entry point. Something which is called something will only be accessible from within frslist itself, and is not visible to the main package. To try and make sure everything is understandable, I've included those unexported items in the go doc output, but it's important to remember that they aren't globals in a traditional sense; they aren't accessible from other packages.

Do you think it is operating as intended? - Yes, I think so. I've just checked what the bot thinks about you, and it's picked up you've had a count of zero sends this month, so you have probability 1 (on a scale of zero to one). That probability is then augmented by the fact you're in the All RfCs category only, so your probability of receiving any given message is then halved (to preference people who have a specific header - who are more likely to be interested in a specific RfC), so your overall probability ends up at 0.5. There's a lot of people in categories and All RfCs alike that have received no messages so far this month, so your overall likelihood is low, even though your absolute probability is close to as high as it possibly can be, if that makes sense. Naypta ☺ | ✉ talk page | 09:30, 6 July 2020 (UTC)

@Naypta: Yeah Go is new; however, I have learned so many languages--including language(s) and O/S co-written same author(s)--I doubt this one will be much more challenging than the others. Looks much like C and C++ or one of the more recent languages I have learned.

Thanks for explanation of capitalization in globals vs. locals--I wish the old languages did that! Scope of folder structure is nice too. In the future, feel free to send me link to documentation for anything from Go Lang, if you don't want to explain it. Something consice written by the authors or Wiley is preferable to For Dummies stuff, which I loathe. I started to review golang.org/doc/faq and "ideas from languages inspired by Tony Hoare's CSP, such as Newsqueak and Limbo (concurrency)", which I do not believe are incorporated into languages I have learned. Have you taken advantage of concurrency? The notation for that is not familiar to me, so I wouldn't know where to spot it.

I have continued to add to the documentation page. Please feel free to add to it, correct it, or revise the language to make it easier to understand.

I would prefer you not delete anything or reorganize if possible without discussing first.

Besides the next section I am about to post. That's all for tonight. --David Tornheim (talk) 10:13, 6 July 2020 (UTC)

Concern about probability of receiving notifications

Discussion about notifications by Yapperbot

Not recieving talk messages?

Regarding...

Adding peer review to feedback request service

Users who have been partially blocked should not be treated as "indeffed" by Pruner

Check for blocks before requesting feedback

Down since mid-December?

Yapperbot's last message was posted on 12/18/23; it looks like it needs to be migrated off of GridEngine and has been shut down by the toolforge maintainers. Either komla needs to migrate it or someone else needs to take up maintenance. See T320195 – SJ + 01:54, 29 January 2024 (UTC)

Sj I just noticed that too. I am willing to help with maintenance and debug. I'm not at this point willing to take full responsibility for the code, but more than happy to assist anyone else.

In addition, I would like to address a problem I pointed out to the author (Naypta) of the program long ago that has never been addressed: User_talk:Yapperbot/Archive_2#Concern_about_probability_of_receiving_notifications. It's been a few years since I discussed it with the author. In the end the author didn't feel it worth fixing. I just mentioned the bug to Novem Linguae, who replied "I agree that that sounds like a bug..." here This seems like a good time to consider fixing the bug.

Right now I am reviewing all those old discussions and will see about looking at the code and possibly try to help with documentation before making any recommendation on how to fix it. --David Tornheim (talk) 22:28, 14 February 2024 (UTC)

Naypta hasn't edited in about two years. First things first, someone who is not Naypta needs to 100% fork and take over the bot's source code and get it set up on Toolforge. Are you thinking about doing that David? –Novem Linguae (talk) 22:36, 14 February 2024 (UTC)

Considering it--especially if there are no other takers. --David Tornheim (talk) 22:48, 14 February 2024 (UTC)

Moving Forward

I see there are still no takers. I have been reviewing the code here and here(I believe this is an old version). I am also aware of Wikipedia:Bots/Requests_for_approval/Yapperbot.

Regarding my background and experience: I have a strong background in programming in countless languages popular before 2000, e.g.: C (I read every bit of Kernighan and Richtie's famous book and did all the exercises), Verilog, Pascal, FORTRAN, LISP, BASIC, HPL, Prolog, and Z-80, 8085, 8086, VAX and MIPS assembly. Since then, I have learned some of PERL and Python. Lately, data problems that I might have solved with a program, I just find it faster and easier to maintain an Excel spreadsheet or Access Database. Within the last 5 years, I took a class in Database Management (and learned SQL) and one in HTML. In the old days, I found using a debugger very helpful. I haven't used a recent debugger in quite a while. Those are the pluses.

I do not have experience with GoLang, bots, or any coding on Wikipedia/WikiMedia--other than Wikitext and HTML. I have not used github other than to look at Yapperbot. So if you want me to help get this bot restarted, I have a few questions:

(1) Where is the code that *calls* the bot?

(2) How can a bot be tested without changing Wikipedia pages? I saw the mention of test verification here, but it's not clear to me how that process worked.

(3) Are there any simple bots or simple test GoLang programs you suggest I play with before diving further into the Code? I am also reviewing and read over Pike's post.

--David Tornheim (talk) 22:17, 18 February 2024 (UTC)

You definitely seem to have more than enough background :) I've never run a Wikipedia bot, but here's my interpretation:

The bot's entry point seems to be main.go. Bot calls aren't from Wikipedia; the bot operator runs the bot's code on their machine to monitor changes on Wikipedia.
See Help:Creating a bot § Testing. Basically do a dry run of your bot.

Aaron Liu (talk) 22:26, 18 February 2024 (UTC)

It was actually run from Toolforge, presumably via a crontab that ran "jsub main.go", although I don't have access to Toolforge so can't be 100% sure. * Pppery * _{it has begun...} 22:53, 18 February 2024 (UTC)

Since the bot inactivity coincided with the grid engine shutdown, that does seem likely. Aaron Liu (talk) 02:16, 19 February 2024 (UTC)

Pinging @Enterprisey: who might have advice. 𝗐♥, – SJ + 01:43, 19 February 2024 (UTC)

If I were you, I would apply for a ToolForge account. ToolForge is where Wikipedia bots are often hosted and set up to automatically run.

Once approved, use an FTP client to take a peek at the Yapperbot files. Toolforge files are usually public to other Toolforge users, unless set to Linux chmod 0600 or similar. The Yapperbot files are probably located at the path "/data/project/yapperbot" or similar. These may be more up-to-date than what is in GitHub repos, and may also include some configuration files that tell you how the cronjob worked (time interval, bash code to start the bot, etc.)

To set up your own bot or your fork of Yapperbot to use Toolforge cron jobs, you'll want to SSH in to your Toolforge account and then set up a "job". This is the new way to do Toolforge cron jobs. The help file is at wikitech:Help:Toolforge/Jobs framework. One of the old ways to do Toolforge cron jobs is the "grid engine", and this also happens to be why Yapperbot was shut down. The Toolforge sysadmins want to force upgrading to the jobs framework, so they are shutting down all bots still running on the grid engine, including Yapperbot.

How can a bot be tested without changing Wikipedia pages? Use https://test.wikipedia.org/ as a big sandbox, if needed. Those edits will go live on test.wikipedia.org, but won't hurt anything. Or see if the bot has a "dry run" option of some sort by reading its program code. –Novem Linguae (talk) 02:41, 19 February 2024 (UTC)

Thank you both for the advice. Will keep you posted on progress, or you can always ask if you are concerned. --David Tornheim (talk) 06:35, 20 February 2024 (UTC)

All the src and job-related files at /data/project/yapperbot/frs are protected, so we can't access them. – DreamRimmer (talk) 16:23, 20 February 2024 (UTC)

Hello @Legoktm. I hope you're doing well! Does Toolforge have a procedure for taking over an inactive account? Maybe the Yapperbot files chmod can be set to public, or David Tornheim and myself can be added as maintainers? Thanks a lot. Looking forward to your feedback. –Novem Linguae (talk) 17:01, 20 February 2024 (UTC)

See wikitech:Help:Toolforge/Abandoned tool policy. * Pppery * _{it has begun...} 17:09, 20 February 2024 (UTC)

Could we just have the responsibility for FRS be taken over by User:Legobot? It may be a big ask, but it would help with consolidation. Maybe a general purpose RfC bot might be in order. Awesome Aasim 20:36, 20 February 2024 (UTC)

Could we just have the responsibility for FRS be taken over by User:Legobot?

Based on my experience with Yapperbot, I would prefer it, because I believe Legobot's function was superior and met the specification better than the new implementation. I am also hoping that Legobot is documented. There was no real documentation for Yapperbot that I found, despite repeated asks.

Maybe a general purpose RfC bot might be in order. What do you mean? I don't know how others feel, but I wonder if it might be better to separate the RfC notification function from the GA notification function. I can't remember if Legobot did that or not. I can see how the functioning of GA and RfC notification might be similar, but it feels like these a significantly different tasks and priorities, and I would feel more comfortable if the code is separated for clarity and to avoid having any change to the code affect both or inadvertently affect the function we were not trying to correct. Is that what you mean?

Of course, getting the bot (either Legobot or Yapperbot) up and running--as it was--will be the first task! --David Tornheim (talk) 22:11, 20 February 2024 (UTC)

Legobot's FRS task when it ran had its own bugs, i.e Wikipedia talk:Feedback request service/Archive 1#Still receiving messages. Legoktm has never been interested in doing anything to this Legobot task other than fixing the most urgent bugs and occasionally deploying urgent code, and has wanted a new maintainer for years, which makes sense since it wasn't his code to begin with - he took it over from Chris G, who took it over from Harej.

I think Legobot's implementation doesn't have any better documentation, and it depended on a SQL database written by the Rfc list maintenance task, so it will be even more of a pain to resurrect whereas Yapperbot at least has the advantage of having no external dependencies. * Pppery * _{it has begun...} 01:15, 21 February 2024 (UTC)

@David Tornheim When I say a general purpose RfC bot may be in order, I mean that having one bot, maybe named User:RfC Bot, handle the tasks of RfC and RfC's FRS. For GAN we can have a different bot for that. I think having one bot for a single task will be a lot less likely to fail, depending on implementation, than one bot for 30 different tasks. Awesome Aasim 04:20, 21 February 2024 (UTC)

Do you have any evidence for that belief? Legobot failed at this because it's original operator abandoned it and Legoktm picked it up in order for the task not to die without a clear plan for long-term maintenance, not because the bot runs 30 other tasks. Counterexample AnomieBOT * Pppery * _{it has begun...} 04:47, 21 February 2024 (UTC)

As long as the code for each task is separable, running them through the same account does not provide much benefits. Aaron Liu (talk) 14:48, 21 February 2024 (UTC)

Back again

It appears Yapperbot has sprung back to life :) ‍—‍a smart kitten_[meow] 07:35, 21 February 2024 (UTC)

Indeed! --David Tornheim (talk) 08:23, 21 February 2024 (UTC)

and the world is saved! Aaron Liu (talk) 14:47, 21 February 2024 (UTC)

I assume the toolforge folks mass re-enabled bots that have been shut down during the Grid deprecation, but I don't see this in the timeline. Wikitech:News/Toolforge Grid Engine deprecation#Timeline. Bit of a mystery, eh? –Novem Linguae (talk) 15:48, 21 February 2024 (UTC)

@Novem Linguae: After looking at the phab link above (phab:T320195), I think Legoktm might have manually migrated the bot as an emergency measure. All the best, ‍—‍a smart kitten_[meow] 15:51, 21 February 2024 (UTC)

Hi! Yes, I got it working last night (well, it started working after I thought it wasn't and went to sleep). This was just a one-time emergency measure, it really needs a permanent maintainer. I'm happy to assist with getting people set up with Toolforge, etc. @David Tornheim do you have a Toolforge account? Would be best to set up a new tool and bot account for this and then we can work on transitioning.

We should set a 1 to 2 month deadline for a new maintainer to get set up (otherwise just turn it off again). Legoktm (talk) 19:05, 21 February 2024 (UTC)

@Legoktm: Thanks for doing that and thanks for offering to help with the transition. Yes, I just set up an account under the name "davidtornheim".

Have you looked at the code for both? Yapperbot has little to no documentation. And according to what I read above, apparently Legobot did not either. I have expressed concerns that Yapperbot does not really meet the desired specification the way I believe Legobot did. One of my goals will be to correct the code to meet the specification. It sounds like one of the reasons for the end of Legobot--besides not having a maintainer--was that it relied on a database not maintained within Wikipedia. That sounds like a more serious problem. Is that your understanding of the main reason Legobot was not revived for RfC (and possibly also GA) notices? Or was it simply because the new maintainer preferred writing their own code? If there is a location that I could read more about the history of the demise of Legobot's RfC notification, I would like to jump into that. --David Tornheim (talk) 20:38, 21 February 2024 (UTC)

I don't think there's any real story to read here. In short, Legobot's FRS task died for unknown (to this day) reasons in December 2019 at a time when Legoktm was almost entirely inactive, people started complaining at Wikipedia talk:Feedback request service/Archive 1#Not getting any invitations?, and Naypta noticed the complaints and was inspired to write their own code. Naypta couldn't have reused Legobot's FRS code because it is tightly coupled with Legobot's RfC list code. They wrote at Wikipedia:Bots/Requests for approval/Yapperbot, in what now seems like wishful thinking, This has the main advantage that there is no database - all the needed information is stored on-wiki - so it would be a whole lot easier for someone else to pick up the bot in the event that I'm unable to continue to manage it and it breaks. I also suspect that, due to the compiled nature of Golang, it'd be a hell of a lot faster - although that's a suspicion, rather than any kind of actual metric. * Pppery * _{it has begun...} 23:47, 21 February 2024 (UTC)

@Pppery: Thanks for the explanation. I do remember that problem now. When you say wishful thinking, do you question the claim that it runs faster and/or that it would be harder to pick up? It may, in fact, be easier to figure out than the old Legobot's code that does the same thing. The fact that no one knows why Legobot stopped working in 2019 is interesting. I don't know if that is worth looking into or not. For now I intend to put my focus on Yapperbot, since it is now working. If there is anything that Yapperbot requires of Legobot, I would want to know that up front. At some point, I will probably try to compare both programs to see if some of the code in Legobot seemed superior. The way Yapperbot chooses who to inform does not seem right to me. I believe in needlessly does too few notifications. --David Tornheim (talk) 00:02, 22 February 2024 (UTC)

The fact that the bot would be easy to pick up again when it breaks was wishful thinking - this discussion is showing that it isn't easy. * Pppery * _{it has begun...} 00:04, 22 February 2024 (UTC)

To be fair, it seems like the difficulty was due to bot code on toolforge not being readable for whatever reason and an external factor of the grid engine shutdown. Aaron Liu (talk) 00:06, 22 February 2024 (UTC)

I agree with Aaron, I suspect that if someone compiled the Yapperbot code on their laptop and just started running it, it would've worked fine. There's actually very little in the Toolforge tool itself, just a few config files and the golang binaries. Legoktm (talk) 00:10, 22 February 2024 (UTC)

@David Tornheim: great, I just approved your Toolforge request, you should have access to the general platform now. Here's what I suggest to move forward:

File a request to adopt the yapperbot tool as it's abandoned.
Create a new bot account and file a BRFA to take over the Yapperbot tasks
Once the adoption request goes through and the BRFA is approved, switch it over to use your new bot account
This should take no more than a month and it'll meet my deadline to find a new maintainer.
At this point you're in full control and you're welcome to switch to other code, whether it's Legobot's old stuff (I wouldn't recommend it) or something entirely new.

I would also strongly suggest finding a second person to act as a backup maintainer who also has access to the Toolforge tool. Let me know what you think of this plan. Legoktm (talk) 00:21, 22 February 2024 (UTC)

Thanks. Novem Linguae offered to act as a backup. That makes me more comfortable too. And thanks for further explanations from everyone. And yes, the plan sounds fine. --David Tornheim (talk) 00:27, 22 February 2024 (UTC)

P.S. It looks like Legobot might not be entirely dead yet. And there is discussion here: User_talk:Legobot. I will start reading up on that. Does Legobot still work *with* Yapperbot? I got that feeling from reading User_talk:Legobot#Mysterious_non-RfCs --David Tornheim (talk) 23:36, 21 February 2024 (UTC)

The current status is that Legobot is responsible for maintaining pages like Wikipedia:Requests for comment/Wikipedia policies and guidelines, whereas Yapperbot is responsible for sending messages to people's talk pages. These tasks are completely unrelated technically and share no code with each other. The two bots work together, in a way. * Pppery * _{it has begun...} 23:47, 21 February 2024 (UTC)

Got it. --David Tornheim (talk) 00:02, 22 February 2024 (UTC)

FYI. Update coming soon. I am almost done writing up a post on my progress in reviewing code, creating accounts and bots, etc. and in general preparing for handling Yapperbot functions. I'll post in another section. Would it be better, if I instead post on the talk page for User:Feedback_Request_Service_bot and ping editors there? If one of you wants to create a talk page there with the best opening parameters including archiving, please be my guest. --David Tornheim (talk) 04:58, 13 March 2024 (UTC)

Maybe throw a link to the BRFA on the page User:Feedback_Request_Service_bot, then ping Primefac asking to add a bot flag. –Novem Linguae (talk) 05:38, 13 March 2024 (UTC)

@Novem Linguae:

Done. When I post my update about my work studying Yapperbot, Legobot, creating accounts, etc., and ask for some questions, would it be better to post here--where we have been discussing the possible adoption--or on the new bot page, or on my personal talk page? I can see advantages & disadvantages to all three.

FYI. While working on this, I did try you suggestion of posting a question to Village Pump.. Although, they did mostly answer my question, I found discussion here easier.) --David Tornheim (talk) 01:18, 14 March 2024 (UTC)

This section is getting a bit long. Maybe starting anew at User talk:Feedback Request Service bot and pinging key editors to the new discussion would be a good choice. –Novem Linguae (talk) 01:30, 14 March 2024 (UTC)

I posted the update here: User_talk:Feedback_Request_Service_bot#Update --David Tornheim (talk) 05:40, 15 March 2024 (UTC)