Forum:Preventing charm log vandalism

From the RuneScape Wiki, the wiki for all things RuneScape
Jump to: navigation, search
Forums: Yew Grove > Preventing charm log vandalism
Archive
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 25 April 2010 by Stelercus.

As you may know, I created and ran a bot called TLULbot a few months back. The purpose of this bot was to simplify the charm logs and make it easier to update them.

However, along with easier editing comes easier vandalism. There seems to be somewhat of a problem with charm log vandalism, or simply errors from users who do not understand how to update the logs.

I am proposing giving TLULbot a new task: every few days, check the values in the charm logs, and log significant changes in the proportions of charms. For blatant vandalism, it would automatically revert. To ensure that it could separate out vandalous edits from regular edits, it could use the history to check individual edits.

Allow me to provide a simple example. I'm a regular user and I approve this message.  TLUL Talk - Contribs 06:38, January 19, 2010 (UTC) 

Simple example

Let's say that TLULbot comes across the Black Demon charm log. It sees these values in the history:

First edit

No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
81–85%9–12%1–3%4–6%0.2–1%
Represents a 90% confidence range based on a sample of 1,000 kills.
1 charm is dropped at a time.
No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
81–85%9–12%1–3%4–6%0.2–1%
Represents a 90% confidence range based on a sample of 1,000 kills.
1 charm is dropped at a time.

Second edit

No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
83–86%8–11%1–3%3–5%0.3–1%
Represents a 90% confidence range based on a sample of 1,300 kills.
1 charm is dropped at a time.
No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
83–86%8–11%1–3%3–5%0.3–1%
Represents a 90% confidence range based on a sample of 1,300 kills.
1 charm is dropped at a time.

Third edit

No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
59–63%25–29%2–3%6–8%3–4%
Represents a 90% confidence range based on a sample of 1,500 kills.
1 charm is dropped at a time.
No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
59–63%25–29%2–3%6–8%3–4%
Represents a 90% confidence range based on a sample of 1,500 kills.
1 charm is dropped at a time.

Fourth edit

No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
62–66%22–26%2–3%5–7%2–4%
Represents a 90% confidence range based on a sample of 1,750 kills.
1 charm is dropped at a time.
No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
62–66%22–26%2–3%5–7%2–4%
Represents a 90% confidence range based on a sample of 1,750 kills.
1 charm is dropped at a time.

It notices something obviously wrong with the third edit: the number of "no charm" drops decreased! So it proceeds to calculate the values if the third edit was removed, but with the values added in the fourth edit.

It then creates this:

TLULbot edit

No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
83–86%8–10%1–3%3–5%0.4–1.1%
Represents a 90% confidence range based on a sample of 1,550 kills.
1 charm is dropped at a time.
No charmGold charm.pngGreen charm.pngCrimson charm.pngBlue charm.png
83–86%8–10%1–3%3–5%0.4–1.1%
Represents a 90% confidence range based on a sample of 1,550 kills.
1 charm is dropped at a time.

This seems reasonable enough, and the percentages seem to be fairly close to what they were before, so it saves this copy. It also notes in the log exactly what it did.

For pages where the percentage changes significantly (exact value to be determined), it places a warning on a designated page (most likely User:TLULbot/Task2/Warnings, or something similar).

It might also be possible to generate graphs of the charm data and percentages, and upload these graphs to Photobucket ImageShack. This would allow easier checking over of the data by humans to watch for anything that may slip through.

What do you think of the rough idea? I'm a regular user and I approve this message.  TLUL Talk - Contribs 06:38, January 19, 2010 (UTC) 

Specification

Here is the detailed specification.

Task

The task of this bot would be to access the charm logs for every monster, and to check to make sure that previous edits were all valid, according to parameters designed to detect vandalism. Blatant vandalism would be immediately reverted, while potential vandalism would be noted in its log and alerted to the operator (me).

There are two possible ways to do this. The first method was chosen per the discussion below.

Method 1 - separate submissions page

Task 1 - create the separate pages:

  • Requires sysop tools
  • Runs once, and only once
  1. Access a list of pages that use Template:Charm data.
  2. For every page that ends in "/Charm log":
    1. Protect the page (if this can be done by a bot).
    2. Create another subpage of the base page called "Charm log submissions".
    3. Fill in this page with values of 0.
    4. Add a template to this page that includes it in the category "Charm log submission pages" and provides the name of the charm log page.
  3. For every page that did NOT end in "/Charm log":
    1. Notify the operator, and log the page name. This catches the few pages with alternate names, like charm logs for different levels of monster.

Task 2 - update the charm logs from the submission pages

  • Requires sysop tools
  • Runs repeatedly - perhaps every few days
  1. For every page in the "Charm log submission pages" category:
    1. Parse the values from the submissions page.
    2. Parse the values from the verified log page.
    3. Validate the data in the submissions page, according to several rules:
      • If the edit appears to be a revert of a previous edit (to the submissions page), allow it.
      • If the number of kills is less than fifty, ignore the data.
      • If the number of kills or charms is over ten thousand, ignore the data.
      • If the percentages of any type of charm are more than 50% different, ignore the data.
      • If the percentages are more than 10% different, use the data, but warn the operator and note in the log.
    4. For any pages where the data was ignored, notify the operator and note in the log.

Implementation

The bot will be based on the code for AmauriceBot, although with some more extensive modifications that when it previously ran. The bot will contain eight (or nine, for method one) Java classes: Main, TLULbotGUI, WikiSession, Utils, CharmLogCreator (optional), CharmChecker, SandboxCleaner, GESession, and GEChecker. Only the first five (or six) will be used for the tasks specified (though, in theory, the bot would still be able to run any of the tasks of AmauriceBot). The bot will run every few days.

The Main class will contain code for running the bot from the command line, and will be somewhat similar to the code of AmauriceBot, with some changes made because of the new tasks and the GUI.

The TLULbotGUI class will provide an optional Graphical User Interface for the bot. It contains several subclasses which implement interfaces defined in Main to provide graphical feedback. This is done so that the tasks can still run even if the TLULbotGUI class is not present (which shouldn't be a problem, but I'm obsessed with modularity).

The WikiSession class will be nearly unchanged from AmauriceBot, and will manage connections to this wiki, or any specified testing wiki. The changes since the previous version and from AmauriceBot will be to check the control page every 10 edits and to function with the GUI. Access to the wiki is done through the MediaWiki API.

The Utils class will provide utilities for the other classes, and will remain completely unchanged.

The CharmLogCreator class will only exist if Method 2 is chosen. It will run Task 1, and will reuse much of the code from TLULbot v1's original task. It will use the WikiSession class to access the wiki.

The CharmChecker class will exist with either method. It will access and validate the data as described above. It will use the WikiSession class.

The SandboxCleaner, GESession, and GEChecker classes will be unused, and will remain nearly identical to those in AmauriceBot. The only changes will be to accommodate the GUI, so that, in theory, the tasks of AmauriceBot could still be performed.

The CharmPage class from the old version of TLULbot will be removed, since I did not update it for the modifications made to the GUI and it was only intended to run once.

Controlling the bot

After every 10 edits it makes, it will check the "Control" subpage of its userpage. If the content of this page contains the text "TLULBOT-PAUSE" it will pause and await instructions from the operator (myself). Due to the possibility of abuse of this feature, I will request that this page be semi- or fully-protected prior to operation of the bot. A link to edit this subpage will be provided on the bot's userpage, and will automatically set the text of the edit to "TLULBOT-PAUSE".

Should this modification of the subpage fail to stop operation of the bot, the next step would be to block the bot. This method is available only to sysops. A link to block the bot will also be provided on its userpage.

Please note that the bot will access the userpage of whatever user it is logged in as, not simply User:TLULbot.

Source code

TLULbot's main source code is already available here, however, I have modified some of the functionality (particularly surrounding the GUI) since posting the source. I will update once I have written the code for this task. TLULbot is copyrighted under the GNU General Public License.

If I've missed anything, please let me know. I'm a regular user and I approve this message.  TLUL Talk - Contribs 07:31, February 4, 2010 (UTC) 

Discussion

Comment - If those graphs are uploaded, they should be put on ImageShack - PhotoBucket has pretty heavy restrictions on the amount of images uploaded, while ImageShack does not. The rest seems good to me. Ancient talisman.png Oil4 Talk 18:00, January 19, 2010 (UTC)

Fair enough. I only said Photobucket because I already have an account there, but creating an ImageShack account should be no trouble. I'm a regular user and I approve this message.  TLUL Talk - Contribs 22:39, January 19, 2010 (UTC) 

Support - I don't know much about how bots work but it sounds like you know what you're doing and I get so sick of the constant charm log vandalism. ~ Fire Surge icon.png Sentry Telos Talk  08:34, January 21, 2010 (UTC)

Comment/Question - Could we create a similar bot to detect very large changes to the Exchange: namespace? It also tends to get a lot of vandalism. ~ Fire Surge icon.png Sentry Telos Talk  08:36, January 21, 2010 (UTC)
AmauriceBot already does that. "Logs any apparent Exchange: price vandalism" (User:AmauriceBot/Source_code#Tasks)   az talk   10:18, January 21, 2010 (UTC)
Oh, OK. ~ Fire Surge icon.png Sentry Telos Talk  21:20, January 21, 2010 (UTC)

Support I am very glad to see we can take an active step in this, being able to trust our charm logs will/should put as even more steps above the other fansites. What do you think about not counting any values where at least 50 monsters are not killed? I think 50 is the minimum number to get a fair sampling of charms, but we can discuss that if people want to.--Degenret01 10:47, January 21, 2010 (UTC)

Why not create combat level bracket requirements?? killing 50 goblins is very different to killing 50 Mithril Dragons. (mcb= monster's combat level) mcb<50=70 kills required. mcb<100=50 kills required. mcb<150=25 kills. mcb<300=10?? Unicorn horn dust.png Evil Yanks talk 11:02, January 21, 2010 (UTC)
But that takes away from the reliability. It's just like a Dragon drop log - people often only bother to add their kills if they got a Visage or something. Ancient talisman.png Oil4 Talk 16:59, January 21, 2010 (UTC)

Support - Preserves the everyone can edit factor and improves the reliability of our logs. Excellent compromise. Quest.png Gaz Lloyd 7:^]Events!99s 17:10, January 21, 2010 (UTC)

Support - Per tLUL and Gaz. Ancient talisman.png Oil4 Talk 18:20, January 21, 2010 (UTC)

Support - Anything that reduces the chance of vandalism is great. =D  Tien  00:15, January 22, 2010 (UTC)

Support - P.A (Per all) Fishing.png NnK Oliver (600613) talk 00:53, January 22, 2010 (UTC)

(edit conflict)Comment/new idea - Since TLULbot would be using the history to check the data, it can also check previous edits (resulting in a much longer run time for the first run). This would mean that previous vandalism could also be caught. I should probably include capability for it to check for reverts.

Using the history unlocks another possibility - recording users who have made successful, valid charm log edits in the past, and being slightly more lenient with those users' edits. For example, imagine that Gaz Lloyd here has previously made 50 valid edits to charm logs. Imagine that MisterNoobyVandalGuy has only made 5 edits, and 2 of them were flagged (of which one was actually reverted). It might not flag Gaz' edits unless there was more than a 15% difference in the percentage values, but it might flag MNVG's edits at 10%.

Personally, I don't know if I like this idea. It would be much harder to code for, and could very well expose a vulnerability that could allow a clever vandal to bypass its warnings altogether. I think that it is probably best to just stick with a fixed range at which the edits will be allowed. I'm a regular user and I approve this message.  TLUL Talk - Contribs 01:14, January 22, 2010 (UTC) 

I'd say stick with the 'easier' way, because of the reason you named - smart vandals. Also, thanks for using me as an example -_-' Ancient talisman.png Oil4 Talk 14:13, January 22, 2010 (UTC)
1) Agreed, and 2) changed. I'm a regular user and I approve this message.  TLUL Talk - Contribs 06:47, January 24, 2010 (UTC) 
2) I was joking. Ancient talisman.png Oil4 Talk 09:20, January 24, 2010 (UTC)

Support - But now my brain hurts from all the numbers. --Iiii I I I 01:17, January 22, 2010 (UTC)

Support ShinyUnown T | C | E 01:20, January 22, 2010 (UTC)

Additons not counted until checked Okay, I have no idea how hard this would be to implement and would not be able to help implement it, so if you don't like this idea, so be it. Anyhow, what if the actual visible displayed log on pages is separate from the one acutally updated, the additions are not counted onto the displayed version until the bot verifies them. This way we are still allowing everyone to add the data, but we're cutting out mistakes and vandalism before the data misinforms our users. Sort of like how the main page is protected but the articles can still be edited. Feasible?--Degenret01 07:11, January 24, 2010 (UTC)

I think so. Pull the charm data on the article from Page/Charm log, and have that protected. Then, have users input data on Page/Charm log/Unverified or Page/Charm log (unverified). Have tLULbot check the unverified (which beginning should mirror Page/Charm log) edits then edit Page/Charm log. Hello71 16:56, January 24, 2010 (UTC)
Yeah, I'd say that'd be doable. And as a bonus, if TLULbot responded fast enough, users wouldn't ever have to calculate the total numbers, because the unverified data would be reset to zero. Furthermore, it would make it easier to determine what edits had already been checked AND to obtain the data from a single edit, since TLULbot would be clearing the data each time and thus the history would show when TLULbot had last checked the page. This would also mean TLULbot would not have to keep a local record of when it had checked what page, giving it a bit more portability. Very good idea, Degen. I will include it in the specification when I write it (I'm a little busy with finals now, so that may not be for a few days). I'm a regular user and I approve this message.  TLUL Talk - Contribs 20:53, January 24, 2010 (UTC) 

Support The vandalism can sometimes be very hard to spot, and anything that can be done to lessen it is great. Summoning-icon.png To3cutt3r Talk HS Log Summoning-icon.png 15:05, January 27, 2010 (UTC)

Support/question - Would it be able to tell the difference between vandalism and someone reverting vandalism?? While it isn't important that it makes this destinction, it would nearly halve the amount of work that the bot would have to do. Unicorn horn dust.png Evil Yanks talk 06:06, January 28, 2010 (UTC)

Yeah, it would check each individual edit and notice that there was no net change. Or, if we use Degen's suggestion (which I really like the idea of) then that would no longer be an issue since the net change on the page would be calculated automatically. Again, sorry for not writing the specification sooner guys, I should have it up within a few hours. I'm a regular user and I approve this message.  TLUL Talk - Contribs 02:52, February 4, 2010 (UTC) 

Support - suggestions

  1. don't get lenient with anyone - if someone typos the log it can be just as damaging as deliberate vandalism - but you could allow a "yes I'm really sure" flag, which could be accepted if the entry is only half reasonable and the person is trusted.
  2. create similar logs for Kingdoms, Surprise boxes, Crystal chests - anything where people are prepared to do the logging.
  3. store the statistics (mean, std dev, confidence) on wiki, and use a log template to flag possible typos
Rich Farmbrough, 14:25 5 February 2010 (GMT).
  1. Checking between reasonable, half-reasonable, and unreasonable is part of the bot. Those which are half-reasonable will get allowed through, but still flagged. Those which are unreasonable will not be allowed through. I don't think that I can actually give the user any real-time feedback, but I can possibly notify them on their talk page if their submissions were flagged. Real-time feedback would hypothetically be feasible with a MediaWiki extension, but I'm not familiar with PHP coding.
  2. I'm sure that similar logs (and checking) would be possible for other things, including those you mentioned. I believe that there was some discussion of drop logs for any item, not just charms. If and when these are implemented, I think that a bot checking them might be helpful.
  3. Yeah, compiling the statistics was a possibility. It would be feasible to store the stats on the wiki, perhaps even through the same template as the log. Setting view=logstats could make it provide the information. The only problem is with the images, if I write the bot to create any. We don't want to take up too much space on the wiki, but I'm not entirely sure how to upload graphs to an image hosting site via an API.
I really like the idea of the submissions template warning when the data is significantly different from the logs which have already been confirmed. This would be a simple matter, assuming that a separate submissions page and log page are used as proposed. I'm a regular user and I approve this message.  TLUL Talk - Contribs 22:47, February 5, 2010 (UTC) 

Going ahead with coding - Okay, it seems that everyone who has commented supports, so I will start work on coding now. The task will be added to TLULbot's list of tasks, with the status "Coding". I'm a regular user and I approve this message.  TLUL Talk - Contribs 00:55, February 14, 2010 (UTC) 

One thing though, you can't really say it's copyrighted under the GPL, it's more like copylefted ([1]). Just saying. Hello71 17:37, February 15, 2010 (UTC)

Comment - Actually, the GNU General Public License is still a copyright license. It's referred to as a copyleft because it uses the copyright laws in a way other than that for which they were originally intended, to force the software to be free. Here is how the same site you referenced suggests placing something under the GPL:
    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
http://www.gnu.org/copyleft/gpl.html
So although it is often referred to as a copyleft license, it is still a legally binding copyright agreement. I'm a regular user and I approve this message.  TLUL Talk - Contribs 21:03, February 15, 2010 (UTC) 

Use "unverified" and "verified" logs?

Note: Please vote on the overall proposal too; this is a somewhat separate discussion

Degenret has come up with an interesting suggestion - why not keep the "Monster/Charm log" pages, but also have "Monster/Charm log submissions"? The former would be protected, and users could only edit the latter. TLULbot would check the data in the charm log submissions page, and add it to the main charm log. However, it would not do so if blatant vandalism/invalid submissions had occurred (eg. 100 000 kills, a 50% change in drop percentage, less than 50 kills) and would simply erase the info, noting the change in its log and notifying the operator (me). It would also warn the operator if potential vandalism had occurred (10% or more change in drop percentages. This would have the benefit of reducing the amount of math that both users and the bot would have to perform.

The alternate option is to simply check the edit history and check all edits every time, or keep a log of which edits had been checked. This option is harder to code for, would mean more strain on the servers, and more error-prone. It also means that all edits (including vandalous ones) would be instantly reflected on the article. However, if the bot stops working, the charm logs will not get updated unless a sysop updates them by hand. I plan to provide the source code of the bot so that another user may run it in case this occurs.

Please vote below on whether or not you think that we should use these "unverified" and "verified" logs. I think that saying Yes (use the unverified page) or No (just check the history) is more appropriate than Support or Oppose, since they are alternate options.


Yes - I think that using the "submissions" page for users to add their drops would be better, due to the decreased strain on the servers (not to mention my bandwidth) and the reduced chance of errors on both the part of the bot and anyone updating the logs. I also like the fact that vandals cannot immediately have their edits shown on the article. I strongly recommend this method. I'm a regular user and I approve this message.  TLUL Talk - Contribs 07:31, February 4, 2010 (UTC) 

Epic support Woot I thought of some thing that everybody doesn't hate >.> (jk). Thanks for incorporating that in,this will solve a lot of problems. Vandals aside, many people just updated it wrongly, and trying to figure out if an edit is vandalism, a mistake, or correct info was sometimes a bit of work. And how many of us would view the same edit trying to decide it was legitimate? Great job Dark Angel Lol.--Degenret01 07:40, February 4, 2010 (UTC)

Strong support - I can't think of any way this would not help. It's just awesome Smile Ancient talisman.png Oil4 Talk 18:53, February 4, 2010 (UTC)

Support - Submissions sounds good. Should work well. Unicorn horn dust.png Evil Yanks talk 06:17, February 7, 2010 (UTC)

Ridiculous support and also you don't actually have to provide the source code (i.e. the .java files), just the compiled version (the .class files). (I think) Hello71 18:53, February 7, 2010 (UTC)

Comment - It's recommended, but not required, to make the source code (*.java) available under an open license per RS:BOTS. --Quarenon  Talk 01:15, February 8, 2010 (UTC)
Just saying... Hello71 02:15, February 9, 2010 (UTC)
Actually, I don't have to provide any of the code, compiled or otherwise. However, I've already got the code up for the first version of TLULbot, so why not provide the updated one? I fully intend to put it up on TLULbot's userpage. I'm a regular user and I approve this message.  TLUL Talk - Contribs 05:19, February 9, 2010 (UTC) 

Using Submissions Page - Okay, it looks like everyone seems to support the idea of a submissions page. I'm a regular user and I approve this message.  TLUL Talk - Contribs 00:53, February 14, 2010 (UTC) 

Massive support - Charm logs receive waaaaay too much vandalism and this will help to take the pressure off of our shoulders. ~ Fire Surge icon.png Sentry Telos Talk  08:19, March 1, 2010 (UTC)

The largest support I ever gave (well, maybe not that big) - A surprisingly high proportion of the vandalism I revert is done to charm logs. This will definitely aid in allowing human editors to more things than just act as police. Having said that, I must note one thing: Since we have many users who stalk recent changes, the two that I named are only examples, it's rare for obvious vandalism to last long enough for the bot to catch, unless the vandalism takes place in a time that there are no active users (unlikely given the global community of the wiki). I know that whenever I see a change to a charm log, I first see if the numbers are reasonable. Anything outrageous is automatically reverted. Then, if the numbers seem reasonable, I look at the actual percentages of the two edits to see if there is any large change. I'm a bit more lax on this step with registered users who don't have red userpage/talk page links (this is kind of like the idea that you stated earlier), and for users that I know I generally don't bother to compare at all. Finally, if everything seems fine, I go do something else. However, there are a few subtle things that may slip the human editors, and, from my perspective at least, that is what this bot is about. --LiquidTalk 00:30, March 2, 2010 (UTC)

Oh, and Idea: Would it be possible to design an interface so that the users updating logs only have to enter in the number of kills that they have, as well as their charm drops? The site can then automatically update those numbers in. All the addition I have to do is the primary reason that I don't bother too much with charm logs. (The other is that I don't count the kills/charms anyways, and the last, and probably the most important one is that I'm lazy). --LiquidTalk 00:30, March 2, 2010 (UTC)
Yup, that's how it will work. At least, that's how it will work if TLULbot manages to get around to the pages fast enough (it's only 150 pages, give or take, so that shouldn't be a problem). I'm sorry for taking so long on this, I hope to be in the final testing phase by the end of the week. I'm a regular user and I approve this message.  TLUL Talk - Contribs 00:55, March 2, 2010 (UTC) 
I've considered this interface idea before. Here's a mock-up.
http://img194.imageshack.us/img194/8250/dropsl.th.png
Since a bot is able to filter the results, this might be worth it. However, I've withheld presenting this idea for the Grand Exchange since it makes pages much more susceptible to vandalism, in my opinion. --Quarenon  Talk 05:33, March 2, 2010 (UTC)
Another thing that could go with this is the idea of using a single page to represent a submissions queue for all charm log updates. That translates into a single hit that the bot has to make as opposed to one hit for every log; of course, if the coding is already in place then it probably isn't worth changing. --Quarenon  Talk 17:06, March 2, 2010 (UTC)
Hmm, for the screenshot, it gives an error because "Charms exceed number of kills." What if the monster drops multiple charms, like the Corporeal Beast or Rock lobster? Are we going to have a slot for the number of charms dropped at once also? (Or is it constant for each monster and only has to be initialized once?) --LiquidTalk 22:22, March 2, 2010 (UTC)
Well, TLULbot will be doing the comparison based on the percentage values returned by the template, and the template automatically accomodates for multiple charms. The current working plan is that the data will be entered in exactly the same way as it is now, except that users will not have to be doing any adding because there will be no data already in the slot. This means they are still going to an edit page. This page includes a value for the number of charms dropped. TLULbot will flag pages with the number of charms different, but still reasonable, so a knowledgeable user can take a look at it. I'm a regular user and I approve this message.  TLUL Talk - Contribs 23:13, March 3, 2010 (UTC) 
I too am not too familiar with how the charm drop count works, although that could be made an editable field or fixed on a per-monster basis; it doesn't necessarily have to require one drop per kill. It's just an example of how client-side validation might be used to reduce the number of incorrect, but still good-faith, submissions. --Quarenon  Talk 01:33, March 4, 2010 (UTC)
A submissions queue on a single page would mean reducing the amount of data transferred, but not significantly (since TLULbot is grabbing the text over the API, there are no images or formatting to be downloaded). It would also greatly increase the risk of a user messing up and disrupting the entire page, requiring TLULbot to go delving into the history — another tricky part of the API to code for, and one that the currently existing base functions in TLULbot does not support. I think that perhaps transclusion into a single page might be better, if the purpose is for monitoring/etc. I'm a regular user and I approve this message.  TLUL Talk - Contribs 23:13, March 3, 2010 (UTC) 
The ease of monitoring is a nice effect of this as well. The idea of a unified queue has less to do with bandwidth and more with consolidating more information over fewer server/database connections, although I just realized that this argument is moot if you use an API query like this:
https://runescape.wiki/api.php?action=query&generator=categorymembers&gcmtitle=Category:Charm_logs&prop=revisions&rvprop=comment%7Ccontent%7Cuser%7Ctimestamp
Anyway, the general idea was to have the interface script perform the edits on the queue, although it would be cumbersome if a user had to make these submissions manually for some reason. With that in mind, it's probably not the greatest idea. --Quarenon  Talk 01:46, March 4, 2010 (UTC)
Well, the submission that you've created looks more like one of your Javascript calculators. At this time, edits cannot be made through these calculators, and I was under the impression that that was intentional design to avoid a calculator that causes vandalism when submitted. All that a bot can do is verify the data.
If what you're suggesting is a new script for the submissions, one that can do verification of its own, then that's a separate discussion for the Yew Grove. It would be incredibly useful, but it's not really related to TLULbot's function. Users attempting to vandalise the wiki could still edit the data on the submissions page the old way, and you'd need a bot to transfer over the uploaded data onto the validated page anyways. I'm a regular user and I approve this message.  TLUL Talk - Contribs 23:13, March 3, 2010 (UTC) 
It's a mock-up of a new script for updating the logs in response to Liquidhelium's comment above about ways to make charm submissions more convenient. It would have to work in conjunction with another method like TLULbot to make further validations to the submitted data, since vandalism is still likely possible. In fact, it's conceivable that more bad-faith vandalism might happen as a direct result of how easy it becomes to submit data. I'm somewhat neutral myself on whether the benefits outweigh the possible abuses. --Quarenon  Talk 01:57, March 4, 2010 (UTC)

Question - After a certain log accumulates enough data, where the confidence interval is extremely small, is it even worth it to continue accepting updates to the log? If new submissions start changing the drop percentages by a significant amount, then that would suggest that either the old or new data was biased, or that the actual drop rates were changed. --Quarenon  Talk 02:01, March 4, 2010 (UTC)

I still think that adding the data to the log when it has a small confidence interval is a good thing, because then it will continue to support those numbers. If something is significantly changed, or if the data is biased, it will be brought to our attention by the warnings. I'm a regular user and I approve this message.  TLUL Talk - Contribs 03:31, March 4, 2010 (UTC) 

STRONG SUPPORT - I've actually been waiting for a bot to patrol all the charm logs for a loonngg time. I also strongly support the submissions page idea. Hope this can be implemented ASAP. Lil cloud 9 08:07, March 7, 2010 (UTC)

Strong Support - per this edit [2] i made to revert a charm log vandalism after witch degen edited afterwards since the charm log was incorrectly edited before the vandalism [3] Dragon helm.png Team6and7 Talk Dragon boots.png 16:15, March 7, 2010 (UTC)

Support - No reason not to support. Hunter cape (t).png Sentra246Blue hallowe'en mask.png 09:06, March 8, 2010 (UTC)

Closed - User:TLULbot is to begin performing the proposed functions. Magic-icon.pngStelercusIlluminated Book of Balance.png 16:33, April 25, 2010 (UTC)