User talk:Yapperbot/Archive 2

Moved from kill switch
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 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  very much does not apply - indeed if the article hasn't been edited in 1-2 hours it isn't unstable.  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, 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 ☺ &#124; ✉ talk page &#124; 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)
 * 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 ☺ &#124; ✉ talk page &#124; 08:56, 26 June 2020 (UTC)
 * Ah, thanks! Face-smile.svg ~ ToBeFree (talk) 09:27, 26 June 2020 (UTC)

Discussion of this page
FYI. This page is discussed here: User_talk:Mathglot (permalink) --David Tornheim (talk) 22:46, 4 July 2020 (UTC)
 * 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  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 ☺ &#124; ✉ talk page &#124; 09:29, 5 July 2020 (UTC)
 * 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
 * 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.]


 * 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 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)
 * 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 ☺ &#124; ✉ talk page &#124; 12:10, 5 July 2020 (UTC)
 * 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, 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)
 * [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, 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)
 * 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  package in src/frslist that is entitled   will be accessible in any package that imports frslist - for instance, the main package, which contains the entry point. Something which is called   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 ☺ &#124; ✉ talk page &#124; 09:30, 6 July 2020 (UTC)
 * 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)
 * 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 ☺ &#124; ✉ talk page &#124; 09:30, 6 July 2020 (UTC)
 * 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
The probability of receiving notifications continues to be dependent on the day of the month an RfC is processed. (At least that is how I understand it from its behavior and your descriptions of its behavior). I contend that continues to be a problem. I am happy to help you find a way to correct that without a huge change to your code. Until I understand your code more fully it's easier to describe it at the highest level, but I believe the routine GetUsersFromHeaders is where all the action is, and once I have that down, I can propose a fix that would not need to change the outer loop variables. --David Tornheim (talk) 10:25, 6 July 2020 (UTC)
 * I'm very happy to consider any suggestions to make the code better, like I've said! I'm currently working on making sure that multiple sends are batched together if they happen in the same run (this is extremely unlikely for RfCs because of their nature, but is more likely for GAs, where articles are sometimes nominated in batch). If you can come up with a way of keeping users selected at random whilst also distributing their sends out through the month relative to when an RfC or GA nom is processed, and at the same time ensuring that there isn't a substantial risk of leaving users miles off their limits at the end of the month because of statistical changes in send counts, I'm all ears. Naypta ☺ &#124; ✉ talk page &#124; 22:57, 6 July 2020 (UTC)

Discussion about notifications by Yapperbot
See:  User_talk:Naypta  (permalink)  --David Tornheim (talk) 21:04, 12 September 2020 (UTC)

Not recieving talk messages?
I'm subscribed to multiple categories of the FRS, but I haven't recieved any talk messages. Any idea why? — Yours, Berrely  (🎅 Ho ho ho! 🎄) • Talk∕Contribs 14:44, 22 December 2020 (UTC)

Regarding...
...this, why are you soliciting input from a user who's been prohibited from editing Wikipedia? ←Baseball Bugs What's up, Doc? carrots→ 18:48, 19 March 2021 (UTC)
 * Because they're still listed at WP:FRS. The bot has a separate task to remove users who have been indefinitely blocked for 2 or more months from the list, however Bus stop was only indeffed for one month so that hasn't triggered yet. * Pppery * it has begun... 02:59, 20 March 2021 (UTC)
 * Understood. Thanks. ←Baseball Bugs What's up, Doc? carrots→ 07:07, 20 March 2021 (UTC)

Adding peer review to feedback request service
I'd like to request that peer reviews are added to your feedback request service. The details are: Having a single bot manage this in addition to other FRS will help future maintenance by putting FRS-type listings all the same spot using the same tools and bots.
 * There are be 12 possible categories. 11 are based on categories 1 to 11 on WP:PR and then a 12th category called "All peer reviews".
 * I will populate the FRS listing at WP:FRS based on the editors at WP:PRV who nominated to be autocontacted (The lists need to be kept separate as one is basically a plain text list intended for people to read and find volunteers, and the other FRS list is designed for a bot to use)
 * This would usurp the functionality provided by the now inactive User:KadaneBot
 * It will also have the benefit of letting User:Yapperbot keep the FRS list and volunteer lists up to date.

I realise Naypta is not active at the moment but post this hopeful that another editor will take the bot's reins and take this task on :). Tom (LT) (talk) 03:51, 4 April 2021 (UTC)