Wikipedia talk:STiki/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Bug report: broken link in AIV summary

Hey Andrew. I think Stiki is great and I use it a lot. Here's another bug report for a small bug. There's a small error in the edit summary that Stiki automatically generates when creating a report to AIV. The edit summary looks like this (Reporting 75.151.66.225 for repeated vandalism, found using STiki.), where the IP adress is a link. The problem is that this link is broken, it incorrectly leads to http://wiki.riteme.site/wiki/Special:Contributions/:75.151.66.225. The correct address would be http://wiki.riteme.site/wiki/Special:Contributions/75.151.66.225 (the difference is the colon before the IP adress). For example see this diff [1]. I hope that you can fix it in one of the future versions. Thanks for making Stiki and good luck with your research. Arthena^(talk) 19:02, 13 January 2011 (UTC)

Thanks for the report, Arthena. It was just a simple typo in the code -- glad you spotted it. It's now been fixed on my local machine, and will be rolled out with the next STiki release. Thanks, West.andrew.g (talk) 22:33, 13 January 2011 (UTC)

Fix rolled-out in the 2011/01/31 release. Issue closed. Thanks, West.andrew.g (talk) 08:27, 31 January 2011 (UTC)

Hang

Great job on the new version!

After about 50 reviews with the Cluebot-NG queue, I clicked Innocent, the button highlighted, and the program froze. Couldn't click anything else or exit. Had to force quit. CPU usage was 90% idle while hung. I restarted and it immediately resumed pulling reviews. I was using OS X. —UncleDouggie (talk) 06:14, 26 January 2011 (UTC)

While it did show me the next review after restarting, it immediately hung again. I tried the STiki queue as well with the same result. Then I switched to WikiTrust and it worked, but there was a 15 second delay in getting the second review. The third review was then fast again. Perhaps a STiki server problem? —UncleDouggie (talk) 06:22, 26 January 2011 (UTC)

Turns out on the hangs where I clicked Vandalism, it did perform the revert. I just didn't get the next review. —UncleDouggie (talk) 06:46, 26 January 2011 (UTC)

I've been tinkering around with the server today. Assuming this isn't a problem in the future -- I am going to blame it on this. Thanks, West.andrew.g (talk) 17:47, 26 January 2011 (UTC)

It's been working well today. —UncleDouggie (talk) 04:06, 27 January 2011 (UTC)

Duplicate reviews

I marked a review as innocent in the Cluebot-NG queue, later switched to WikiTrust, and got the same review again! I understand why, but it's annoying. How many others am I re-reviewing that someone else has already judged from a different queue? —UncleDouggie (talk) 06:24, 26 January 2011 (UTC)

The queues are synchronized. Popping an edit from one is equivalent to popping it from all of them -- and the same thing with ignores. I've had some times where I felt like what you described was happening -- but it turns out that it was just the result of edit warring (i.e., same exact changes, different timestamp). Cluebot-NG heavily prioritizes these cases. If what you describe is *actually* happening (not respecting the synchronized "ignore"), then it is a bug and I will look into it. Thanks, West.andrew.g (talk) 17:52, 26 January 2011 (UTC)

One noteworthy exception. When you start STiki, it is not unusual if the first edit that you see is one you have ignored in the past. This is because when STiki starts up, you are yet to log in, so STiki is yet to process "your ignore list". Thanks, West.andrew.g (talk) 18:13, 26 January 2011 (UTC)

I know it happened several times on reviews in which I click Innocent the first time. I thought it must be edit warring as well, but when I looked at the time stamps that wasn't the case. Sorry I didn't save the links, but I will next time. It's more likely to happen during low volume hours because there is a greater chance that someone else hasn't already performed the same review from another queue. —UncleDouggie (talk) 03:59, 27 January 2011 (UTC)

I will investigate the "ignore" system at my earliest convenience. I've had a suspicion there might be a corner case in there which was a little off. West.andrew.g (talk) 14:07, 27 January 2011 (UTC)

Here's part of the problem. I rolled back some other contributions from a user that I reverted. This is one of them. Eight minutes later I was presented with the old edit that I had already manually rolled back. STiki didn't know that it wasn't the most current edit anymore. However, I know that yesterday I saw the problem happen on reverts I made within STiki one one queue and that were then were represented from another queue. I checked the edit summary at the time and my revert had the STiki link in it, so I didn't do it manually. —UncleDouggie (talk) 04:50, 27 January 2011 (UTC)

This one is more puzzling. STiki will (should?) not show an edit which is not most recent on the article. The server-side works hard to make sure the queue maintains this property -- but once popped from the queue, your client similarly checks every RID it gets (no matter the queue). It can't be a server-side error since your machine also does this check. Moreover, this is an API call to Wikipedia made several ten-thousand times daily -- so I doubt their response is incorrect or out of date, unless they are experiencing *severe* replag. Its also a pretty fundamental and straightforward request I make -- so if something was wrong, it should rear its head in more dramatic fashion. Frankly, I'm puzzled on this one right now. West.andrew.g (talk) 14:07, 27 January 2011 (UTC)

The most recent edit check is very busted. STiki just gave me this edit 12 minutes after someone else reverted it. I had reverted 3 other edits during that 12 minutes and had at least that many non-revert reviews as well. This has happened on 3 other articles in the last 20 minutes. —UncleDouggie (talk) 02:55, 30 January 2011 (UTC)

I am looking into this. Out of curiosity, are you moving through revisions at a pretty decent clip, or are you occasionally leaving STiki open while completing other tasks and chasing down non-vandalism issues in the edits? Thanks, West.andrew.g (talk) 03:30, 30 January 2011 (UTC)

Alright, some log inspection confirmed my suspicions. You tend to move quite slowly (comparatively speaking) through STiki edits (this is not a criticism). In the particular instance you highlighted, you made 12 classifications in 16 minutes time. This deviates slightly from some of my assumptions. However, your use of the tool is certainly valid, and I need to make some adjustments to handle the matter. Shouldn't be too complicated, and your issue should be fixed (and a new release pushed) in the next day or two. Thanks for your support and continued feedback. West.andrew.g (talk) 05:05, 30 January 2011 (UTC)

Thanks. I can spend anywhere from 2 seconds to 10 minutes on a review depending on what it is. I don't like letting the non-vandalism grammatical disasters go by untouched. Some BLP edits require research to figure out if the edit is vandalism or is correcting vandalism. I also like to take the opportunity to review other contributions by serious vandals. I always find several live edits in other articles and often they're not the most recent edits in those articles. —UncleDouggie (talk) 10:39, 30 January 2011 (UTC)

All the issues described above have been addressed in the 2011/01/31 release. Indeed, I found issues that would explain both your, (1) seeing edits you had ignored, and (2) displaying edits that were not most recent on their article. Confident this resolved, I am marking this matter closed. Thanks, West.andrew.g (talk) 08:30, 31 January 2011 (UTC)

Self review

STiki just gave me my own revert from the Cluebot-NG queue, which is where I also did the revert from. Not a big issue if that's the way it needs to work. —UncleDouggie (talk) 04:05, 27 January 2011 (UTC)

This is a function of how CBNG scores edits. I pull the scores from them, with no modification. The metadata queue, however, has some functionality to make sure no one will ever see these cases. Thanks, West.andrew.g (talk) 13:47, 27 January 2011 (UTC)

STiki server down

... for unexpected maintenance. Hope to have it back up later today. Thanks West.andrew.g (talk) 06:49, 28 January 2011 (UTC)

Should be in relatively good condition now. Thanks, West.andrew.g (talk) 21:35, 29 January 2011 (UTC)

Strange pop-up

I take it that the server is down. I just got a small, blank pop-up window with the title of "Error: Internet connectivity is required". However, I had good Internet service both before and after the window appeared. I couldn't close the pop-up or STiki itself; I had to force quit the app. Upon restarting, I got an immediate error that there was no connectivity to the back-end and the app then gracefully exited. It would be nice to handle this more gracefully when it happens mid-session. —UncleDouggie (talk) 06:52, 28 January 2011 (UTC)

Now it starts up and just sits there without ever opening any windows. At least it lets me quit gracefully. —UncleDouggie (talk) 07:06, 28 January 2011 (UTC)

Your query may well be explained by the message above this thread. It will hopefully be back up running later today. Orphan Wiki 13:23, 28 January 2011 (UTC)

I started writing my first message before the outage message was posted. However, the resulting hang under this condition is still an issue. —UncleDouggie (talk) 20:51, 28 January 2011 (UTC)

ACK -- an easy fix -- and a clearer error message is needed. Thanks West.andrew.g (talk) 03:31, 30 January 2011 (UTC)

Indeed, improved messages were included in the 2011/01/31 release. Matter closed. Thanks, West.andrew.g (talk) 08:32, 31 January 2011 (UTC)

Review of CBNG revert

I just got on and was using the CBNG queue. STiki gave me a rather obviously correct revert by CBNG itself to review! Is this because others have drained the CBNG queue to the point that it didn't have anything better to show me, or did CBNG somehow rate its own action as high risk? It would be really nice to see the queue scores in the STiki client to help fine-tune CBNG and other queues. —UncleDouggie (talk) 04:50, 31 January 2011 (UTC)

Haha. I ensure you the CBNG queue is nowhere close to empty! Looking up the score in my DB, CBNG scored it 95/100 (100 being complete vandalism). These things just happen sometimes. It is possible to show end users the scores, but: (1) They don't mean a thing to the average user, and could introduce bias on how they act. (2) The scores are not strictly comparable across systems, even though they are all normalized onto [0,1]. Thanks, West.andrew.g (talk) 06:54, 31 January 2011 (UTC)

STiki Release -- Jan. 31, 2011

The following is the CHANGELOG from the 2011/01/31 release:

1. Better handling of "ignore" functionality: Now, an ignored edit becomes immediately available to others, rather than having a several minute "expiration delay" (silly that this wasn't fixed earlier). Also, an issue was fixed where editors would occassionally be re-issued "ignored" edits early in a STiki session.
2. Additional checks added to ensure that users are only shown edits that are "most recent on their article". Now, edits popped have always been checked for this property within the last 10-seconds, with no impact to GUI speed. This should be a substantial improvement for users who classify at slower rates.
3. Added public IRC feeds, hosted at "armstrong.cis.upenn.edu". Two channels currently exist: (1) "#arm-stiki-scores", which reports vandalism probabilities, and (2) "#arm-stiki-links", which reports link additions (both only to en.wiki, NS0). Formats are self-explanatory, and additional feeds can be added upon request
4. Better error dialogues when a client cannot connect to backend due to (1) no Internet, (2) ports blocked, (3) STiki down, (4) software update required.
5. Fixed minor typo which broke "contributions" wikilink in edit summaries when making reports to AIV.

Thanks, West.andrew.g (talk) 08:23, 31 January 2011 (UTC)

Idea

Nice work on the new version. Cool to see it coming along so well and quickly. My thought is that if a common vandal-fighter comes to this page, and doesn't really care about documentation, or machine learning, or anything really--they just want the link to the download with a date telling them the version--that it could be a little more user-friendly to find it on the page. Vandal-fighting is a salesmanship game on Wikipedia since there are so many competitors, and while I'm glad STiki hasn't been overrun by hordes of itchy fingers, the program is so superior to others that it really deserves the widest userbase possible. That's my thought. Thanks again, Ocaasi (talk) 03:34, 1 February 2011 (UTC)

In general, I like the idea. But I wonder if there exists a template of some kind that might make the STiki download links even more prominent? Thanks, West.andrew.g (talk) 06:16, 1 February 2011 (UTC)

 Done Hope you like it. —UncleDouggie (talk) 07:16, 1 February 2011 (UTC)

Looks good to me. Tweak away, but that will definitely make it easier for new users to find what they're looking for. Ocaasi (talk) 07:47, 1 February 2011 (UTC)

A 1000+ revert day

STiki scored more than 1000 reverts in the last 24 hours. Pretty sure this is a record day. Thanks to all the user-base! West.andrew.g (talk) 05:12, 4 February 2011 (UTC)

Unfortunately it appears that nearly all of those edits were performed by one user, Mìthrandir, and several editors are unhappy about the way he used the tool; many of the reverted edits identified as "test/vandalism" plainly were neither. See Mìthrandir's Talk page for comments.--ShelfSkewed Talk 15:38, 4 February 2011 (UTC)

Unfortunate to see that. If his mis-use of the tool continues, let me know, and I can take action accordingly. Thanks, West.andrew.g (talk) 16:42, 4 February 2011 (UTC)

I think he needs to loose access now. He's doing damage to Wikipedia, causing bad feelings and giving STiki a bad name. I'll assume good faith and say that perhaps he was just going too fast. However, users need to learn to go slow first and only speed up when they really know what they're doing. Ask him to manually revert some vandalism from RC for awhile until he can prove that he's ready for an automated tool. —UncleDouggie (talk) 18:27, 4 February 2011 (UTC)

If he starts back up again -- I'll get him. My block functionality is a bit crude at the moment and I'll work on cleaning it up tonight. For a determined someone though, they can turn this into a "meta-detection" problem. Just as they sock Wikipedia or use dynamic IPs -- they can do the same to us. It seems like the editor in question has been around for a while -- so I'll assume good faith in heeding all the warnings he got. Thanks, West.andrew.g (talk) 19:57, 4 February 2011 (UTC)

Cordial warning to his talk page. Thanks, West.andrew.g (talk) 20:06, 4 February 2011 (UTC)

Repeating edits

Resolved

Yet another old problem is back. After restarting STiki, the first edit was this one, which I had clicked innocent on about 25 minutes earlier in my last session (long before the revert failures above started happening.) Both edits were from the CBNG queue. —UncleDouggie (talk) 22:42, 6 February 2011 (UTC)

Not a bug. The key here is that it is the *first* edit shown. Once you (re)-start STiki, it is possible for you to see an edit you have ignored in the past. This is because STiki doesn't know it is *you* yet. Once you log in, edits are fetched and checked according to your policy. While the first edit can have this problem -- never will an edit after the first have this issue.

On one hand, I could make it such that STiki starts with a blank window. Alternatively, I can be proactive in getting one edit to the user and occasionally have this corner case happen. I've selected the latter, and I see no compelling evidence to change. Thanks, West.andrew.g (talk) 22:20, 7 February 2011 (UTC)

I clicked "Innocent", not "Pass". I assume that by "ignore" you mean "pass". If it's really serving up my innocent classifications to others, how does the queue ever drain? —UncleDouggie (talk) 07:17, 8 February 2011 (UTC)

Sorry for the misunderstanding. You were not re-served the same edit. Records show that the second edit you saw was this one. Painfully close, but the model number of the engine differs slightly. Thanks, West.andrew.g (talk) 15:34, 8 February 2011 (UTC)

Wow. I tried to check if this had been the case before posting. When I enter "Ford 4R" into the Wikipedia search box it shows me only the 4R44E and the 44R70W, so I assumed there wasn't any other similar article. It's only if I know to enter "Ford 4R5" that I get back the 4R55E. However, in other search term suggestions I get back up to 10 entries. I should have just checked the old fashioned way. Sorry for the trouble. —UncleDouggie (talk) 16:30, 8 February 2011 (UTC)

edit summaries?

Is it just my computer, or does STiki not show edit summaries? If this is the case, it should be fixed; otherwise, there is a greater chance of reverting legitimate edits. --Ixfd64 (talk) 23:57, 13 February 2011 (UTC)

STiki does show edit summaries, in the "metadata panel". The particular field is labelled "COMMENT." The screenshot at WP:STiki isn't the best example, because it also has a blank comment. FWIW, the vast majority of vandals do not leave comments. Thanks, West.andrew.g (talk) 01:39, 14 February 2011 (UTC)

Thanks for your reply. I was expecting the summary to be placed above the diff (like in most other edit tools), which is probably why I didn't see it. I'm still fairly new to Stiki, mind you. :-) --Ixfd64 (talk) 02:12, 14 February 2011 (UTC)

Thanks for your use of the tool, don't hesitate to ask if there are any other questions. Thanks, West.andrew.g (talk) 02:16, 14 February 2011 (UTC)

Warning offending users

STiki doesn't seem to want to warn offending users at the moment. I've reloaded it, but the problem is still there... Orphan Wiki 00:14, 16 February 2011 (UTC)

Maybe you accidentaly unchecked the box 'Warn offending editor?' in the bottom-left corner of the Stiki interface? Arthena^(talk) 01:06, 16 February 2011 (UTC)

Assuming it isn't taken care of by Arthena's suggestion, could you give some more details? What does the "last revert panel" display? Does it indicate that the warning was placed, when in fact, it was not? Thanks, West.andrew.g (talk) 02:53, 16 February 2011 (UTC)

Thinking a little harder. I have the likely problem/solution. STiki doesn't warn IP vandals if the vandalism occurred over 24 hours ago (on the assumption they might be dynamic IPs and lead to collateral damage). I assume you are using the "Cluebot-NG" queue (its the default one). Cluebot-NG has been down for over a day, and thus is not updating its queue. Thus, any edit you pop from that queue will be over a day old (and therefore IP vandals will not be warned). Until Cluebot-NG comes back up again, I would suggest you switch to the "metadata" queue, which is actively processing. Thanks, West.andrew.g (talk) 02:59, 16 February 2011 (UTC)

Arthena, I definately had the Warn Offending Editor box checked. I unchecked it and checked it again to make sure. Thank's West.andrew.g, I'll see what happens when I use that queue. Orphan Wiki 11:46, 16 February 2011 (UTC)

I think the issue is thus resolved. It's like you said, ClueBot_NG is down. Warnings are fine when using metadata queue. Regards, Orphan Wiki 12:11, 16 February 2011 (UTC)

By the way, Cluebot NG is up again, but I'm still only getting old revisions. Arthena^(talk) 14:19, 18 February 2011 (UTC)

Fixed. Seems like their server completely died -- so I had to reattach my IRC listener. Thanks, West.andrew.g (talk) 15:10, 18 February 2011 (UTC)

Copying article name from diff window doesn't work right

I sometimes need to copy the name of an article out of the STiki window. The only thing selectable is the bold name at the top of the diff window. However, this leads to a confusing mess. —UncleDouggie (talk) 23:14, 5 February 2011 (UTC)

The same thing is happening sometimes in copying article text out of the diff window, but not in all cases. I just had it happen in this diff when I copied the word Phalangeriformes from the left side of the window. Copying it out of the wiki diff window is fine. It's only in the STiki client that things are messed up. —UncleDouggie (talk) 03:33, 6 February 2011 (UTC)

This is a known issue. Your going to have problems copying text out of the diff-window, if it contains lengthy words. The reason is that I insert zero-white-space characters (ZWS) into long text chunks. This is done so that lengthy URLs, for example, don't create a situation where the diff looks crappy or forces horizontal scrolling. (ZWS characters permit a word to be broken across multiple lines).

To remedy this, I have made it so that the username/title/etc. are now highlight-able (copy + paste-able) from the "metadata panel" at the bottom. A minor fix which will be rolled out with the next release. Thanks, West.andrew.g (talk) 22:47, 7 February 2011 (UTC)

Perhaps the text in the diff window and the title above it should not be selectable to avoid having users fall into this trap? —UncleDouggie (talk) 07:14, 8 February 2011 (UTC)

Yes, this was also done, just didn't mention it. Thanks, West.andrew.g (talk) 15:59, 8 February 2011 (UTC)

Fix rolled-out in the 2/24 release (a very minor one). Thanks, West.andrew.g (talk) 00:32, 24 February 2011 (UTC)

Revert failure

An old problem is back. STiki just gave me this edit. I clicked vandalism (with a custom edit summary and no user warning). However, STiki didn't perform the rollback and instead said that I was beaten to the revert. I then did a Twinkle rollback instead. I then noticed that it had been 6 minutes since my previous revert, but I know that I had several cases of vandalism during that time. I just hadn't paid much attention to the STiki revert status pane because it often lags significantly. Beyond the obvious problem of why STiki thought I was beaten when I wasn't, we should make the revert failure condition much more prominent like putting it in a red font. By the time I noticed the problem, I had no way to go back to the edits I had recently classified. The only way out of this situation based on my past experience is to close and reopen STiki. —UncleDouggie (talk) 22:36, 6 February 2011 (UTC)

Right now, STiki will say "beaten to revert?" if *anything* goes wrong with the rollback process. This is because about 99% of the time -- that is in fact what happened (and the question mark was meant to take care of the other 1%, haha). There are lots of error codes. It would seem I just need to implement messages for some of them explicitly.

The page in question did have a rather accented title -- but I don't think we've ever had problems with that. Strange things happen sometimes, could be a network issue. I'll code up better messages for the next release -- and you should let me know if you see anything that implies a technical error.

Also you note that the status pane, "lags significantly." Out of curiosity, how long are we talking? Normally it takes about 1-2 seconds for an RB'ed edits status to appear on my machine, but I live, (1) near the STiki server, and (2) in a major metropolitan area (and thus, likely near some Wikimedia server, as well). Thanks, West.andrew.g (talk) 14:56, 10 February 2011 (UTC)

It can take from 1 to 5 seconds. It seems to be related to how loaded the Wikipedia servers are. However, after 5 seconds my mind is firmly into the next diff. —UncleDouggie (talk) 18:36, 10 February 2011 (UTC)

More abuse

For the second time one of my edits has been dinged as vandalistic by an inexperienced editor using STiki, and for the second time this editor (Ankit Maity (talk · contribs)) shows a pattern of abusing the tool to mass-revert non-vandalistic edits and label them as vandalism. Either this tool needs some serious improvements (How about a whitelist?) or its use needs to be restricted to more experienced editors.--ShelfSkewed Talk 18:22, 19 February 2011 (UTC)

I don't know about serious improvements. It really isn't too difficult to discern vandalism from an innocent edit. These problems have occured with Huggle in the past, I remember complaints being posted there in times gone by. It's more down to careless users than the tool itself (I think anyway...). In light of this, the user that Shelfskewed has brought to light (Ankit Maity), does not have rollback rights. Maybe this should be put into force, as is the case with Huggle. Orphan Wiki 19:34, 19 February 2011 (UTC)

I'm willing to follow through with any editing restrictions that community consensus finds appropriate. But at least in this case, the user in question is claiming to have rollback rights (or is actively deceptive on his talk page). Thanks, West.andrew.g (talk) 13:35, 21 February 2011 (UTC)

The user never has had rollback rights. —UncleDouggie (talk) 14:16, 21 February 2011 (UTC)

The userbox on his userpage is false. He has no rollback rights. Under his username in that link, there should be a section called User groups, which will list things like Rollbacker or Reviewer. No such thing exists. At the time of writing this message, his request for rollback has not been dealt with. Orphan Wiki 17:00, 21 February 2011 (UTC)

Simple fixes: require Stiki-ers to have rollback (or 1000 edits), whitelist all auto-confirmed editors, create a page for reporting false positives and abuse. Ocaasi (talk) 17:23, 21 February 2011 (UTC)

Its easy to throw out arbitrary numbers like "1000 edits". Further, whitelisting all auto-confirmed seems a bit extreme -- as all of the problematic users have had this right, I believe. I'd like to see an RFC opened up somewhere so the community can have its input -- and we can perhaps establish a standard by which all tools can adhere. Thanks, West.andrew.g (talk) 18:26, 21 February 2011 (UTC)

1000 is arbitrary, but rollback is not, and requires at least some pre-screening to get. Whitelisting was in reference to the reviewed edits, not reviewing users. So, Stiki might deprecate or completely not queue any edits from auto-confirmed editors. This way if there are mistakes or erroneous vandalism marks, they'll be less likely to effect the editors most likely to be constructive. I don't think a platform-wide standard is likely, but an RfC is a great idea. Ocaasi (talk) 19:56, 21 February 2011 (UTC)

Agreed on the rollback point, and it is something that Huggle uses. However, I respectfully disagree on white-listing edits from auto-confirmed users. First, policies like this make it easy to game the system (just show some patience, and use an auto-confirmed account). Second, this logic is already implictly encoded into most detection algorithms (using the notion of reputation). Third, the fact that a non-autoconfirmed user might be unconstructive is no reason to push STiki's "mistakes" onto them -- and then hope no one notices (WP:BITE). Thanks, West.andrew.g (talk) 21:27, 21 February 2011 (UTC)

Yes, whitelists are an imperfect tool, and they don't take advantage of the machine learning aspects, as you said. I didn't mean to 'dump' mistakes on new editors, just to lessen the probability of marking regular editors' edits as vandalism. That is better handled by algorithms, though, then blanket categorizations. Also, hopefully the 'abusing' STiki users will be few and easily handled. Ocaasi (talk) 22:54, 21 February 2011 (UTC)

Hi, sorry if my simple edit led to such a problem. I think there should be one vandalism and another edit button on STiKi. And another thing even if I am not on the user groups page I have the button near the diff,contributions,etc. page. For this reason I added the userbox. And today I suddenly saw that my button was no longer there. Any glitch or denied the right? If anybody deny the rights to me that was after I requested 7 then please contact me by email. If glitch then please solve it. Sorry if I made any mistake.Ankit Maity 17:08, 24 February 2011 (UTC)

I'm having a hard time parsing what you just said. Regardless, you have never had the rollback right. Looking at Wikipedia:Requests_for_rollback, SkierDude declined your request there and pointed you to this page. Why do you believe that you have that right? What "button" did you have in the past that has now been removed? Thanks, West.andrew.g (talk) 17:47, 24 February 2011 (UTC)

Believe he was suggesting a non-vandalism button for edits that are not good but are not deliberately unconstructive. Not sure about the button; maybe Ankit thinks STiki has a direct role in giving rollback. Ankit, you have to get the permission from WP:PERM, and please slow down a bit with the vandal-fighting until you get those things figured out a little more. Ocaasi (talk) 22:01, 24 February 2011 (UTC)

Orphan Wiki declined my request. That's all okay but even if my user rights is not being shown anywhere I have the rollback button on my contributions,diff, etc. page for some reason or the other. That's all I want to say. But even just because of this edit it is not fair for Orphan Wiki to decline the request. I am not using STiKi anymore even though STiKi is not responsible for anything.--Ankit Maity 05:15, 25 February 2011 (UTC)

Orphan Wiki is not affiliated with STiki, and rollback is not affiliated with STiki. STiki is an independent, user-made program. Rollback is a community-granted ability. You have to ask Orphan Wiki why you were not granted rollback; my guess is that it has to do with your lack of editing history. Rollback is typically granted for editors who have shown they understand the difference between vandalism and non-vandalism, and are careful about reverting edits. I don't doubt that you can figure that out, but it might make sense to wait a few months (or weeks) until you are more comfortable with the tools before increasing your use of them. Ocaasi (talk) 06:53, 25 February 2011 (UTC)

Just thought I'd clarify the situation. Ankit Maity, it was not I who declined your request for rollback rights, it was declined by Skier Dude. This was because it was thought that you weren't quite ready yet to be granted rollback rights, and also based on the evidence that you weren't quite used to automated tools (I simply provided a link to this discussion to help in the decision process). I didn't do this to prevent you from earning rollback rights, I did it to make sure the right decision was made at that particular time. Nevertheless, that doesn't mean you couldn't be granted rollback rights in time to come. I suggest you maybe keep on patrolling the recent changes old school style? That way you can be certain of what really needs reverting and what doesn't, thus proving to the people over at Requests for Rollback proof that you deserve the tool. If you would like further help with all this, I am more than happy to assist you. Just give me a shout on my talkpage. Regards, Orphan Wiki 11:46, 25 February 2011 (UTC)

STiki Release -- Feb. 24, 2011

A very minor release here. As far as GUI users are concerned, it only addresses one issue raised by UncleDouggie (pertaining to copy-paste of text from STiki). Regardless, I have no major changes on the immediate horizon, so I thought I'd go ahead and push this out.

CHANGELOG:

• Transitioned items in the "metadata panel" from JLabels to JTextFields. This way, titles/usernames can now be highlighted and copy-pasted. Main diff-window cut-copy-paste is problematic due to ZWS insertion, and thus it has been disabled (text *selection* also disabled, just to drive the point home).
• Crude blocking functionality added to stored procedures. Blocked users will only be popped a "special" diff from the server -- which tells them are blocked and to discuss it on this talk page.

Thanks for everyone's continued support, West.andrew.g (talk) 00:39, 24 February 2011 (UTC)

Shortcoming in warning detection?

STiki seems to be mostly detecting the level of warning already given to a vandal and responding appropriately. However, take a look at User talk:Tosspot345 and it didn't seem to have worked properly. I noticed that there were lots of messages and posted on WP:AIV manually. I don't think it was just STtiki that got confused, ClueBot NG seems to have got confused too. Any thoughts? Yaris678 (talk) 19:40, 1 March 2011 (UTC)

The problem here is that when ClueBot-NG gets it wrong, it throws off STiki's methodology. If the Cluebot folks would correct this, STiki would have no issue (it just finds the last warning in the current month, and elevates it by one). Cluebot's issue seems to stem from not detecting the proper monthly section headers. This has been raised before, see User_talk:ClueBot_Commons#Duplicate_headers, User_talk:ClueBot_Commons/Archives/2011/February#Adding_duplicate_headings_on_talk_pages, and User_talk:ClueBot_Commons/Archives/2011/February#Duplicate_Section_Headings. But the issue seems un-addressed to this point. Thanks, West.andrew.g (talk) 20:13, 1 March 2011 (UTC)

Thanks for the quick reply. If only the ClueBot guys were so quick, eh?

It is interesting that you say that it only looks in the current month. Is that a Wikipedia policy... that after a month warnings don't count? I can't find that anywhere on Wikipedia:Vandalism. Yaris678 (talk) 20:37, 1 March 2011 (UTC)

That was an over simplification of how STiki actually does things. More accurately, it increases the most recently provided warning by one-level, provided that the warning happened within some timeframe (else it restarts at level 1). I think some tools do use monthly sections as a hard cutoff, though. Absolutely not a Wikipedia standard, but kind of a de facto one for some tools. Thanks, West.andrew.g (talk) 20:49, 1 March 2011 (UTC)

The fact there is no hard rule for what constitutes a "stale" warning doesn't simplify things any, either. Everyone has differing opinions, sometimes leading to AIV requests being denied and the like. Oh well, I haven't gotten to many complaints about the way STiki does it, and I've always tried to play it middle of-the-road. Thanks, West.andrew.g (talk) 20:51, 1 March 2011 (UTC)

It would be useful to try to get some kind of consensus on this. Not least so the automated tools can work together nicely. (...although I guess for ClueBot the priority is to fix the duplicate headers issue)

My personal opinion is that the rules could be made more tough... but that is just my opinion and I think the most important thing is consensus.

I also think that you have to expect the occasional AIV requests being denied - we will never be able to make the human judgement redundant. That said, we obviously want to keep the number of rejected requests fairly low - no point in giving the admins too much workload.

I guess you could see the process of deciding when to make an AIV request as another quantitative trust management issue... but I don't really know where to take that idea. My main thought is that we need more discussion to try to reach consensus.

Yaris678 (talk) 11:42, 2 March 2011 (UTC)

I am happy to implement whatever consensus the community arrives at. Nice reference to QTM, by the way. Thanks, West.andrew.g (talk) 15:54, 4 March 2011 (UTC)

Thanks. I have taken my thoughts expressed here and expanded on them in the user essay User:Yaris678/Deny automated recognition. Any comments would be welcome. Yaris678 (talk) 13:22, 10 March 2011 (UTC)

Only for rollbackers?

During this conversation, it was suggested that only rollbackers should be allowed to use STiki. The conversation then got distracted by a specific case... so I would like to return to the general point.

I think that only rollbackers should be able to use STiki. This wouldn't just reduce abuse and errors, it would also ensure that the learning aspects of STiki isn't learning from false data.

I think that if someone logs in to STiki with an account that doesn't have rollback rights, it should politely suggest that the user request them. Something like...

"You do not appear to have rollback rights, which are now required to use STiki. If you have a contribution history that demonstrates an ability to distinguish well-intentioned edits with minor issues from unconstructive vandalism, please request rollback rights."

Yaris678 (talk) 09:58, 9 March 2011 (UTC)

Actually, I think a better message would be...

"You do not appear to have rollback rights, which are now required to use STiki. Please see the page about the rollback feature to find out more about it."

Yaris678 (talk) 12:58, 9 March 2011 (UTC)

I like the idea. There's little point in having to earn rollback rights, if there are tools that permit open use without the privilege. We have seen in some cases, inexperienced patrollers finding their feet with a proper tool, rather than getting practice with doing it old-school style, which is less easy to mess up, and provides good insight into what to (and what not to) revert. Orphan Wiki 14:19, 10 March 2011 (UTC)

I acknowledge the idea as a good one. I'm a bit busy with real-life right now, but this is something I'm willing to implement when I can. I'd also like to run some reports about who has actually used the tool in the past (i.e., which percentage of users had the rollback right). Thanks, West.andrew.g (talk) 17:13, 10 March 2011 (UTC)

Change in bytes

STiki is well-built and the project page's wording makes it sound high-tech. It's definitely simpler than Huggle, but that's possibly a good thing, especially for newer vandal fighters. However, it would be nice if the screen displayed the change in bytes (e.g., "-566" or "+44") like Huggle does. Guoguo12--Talk--  20:20, 14 March 2011 (UTC)

Out of curiosity, how do you find this statistic useful? Isn't it information already encoded visually in the diff itself?

I will add that diff-magnitude is one of the features that STiki (metadata queue) uses to make vandalism predictions. Of course, I could make all of these features visible to end users, but I've always been quite set on keeping a minimalist and clean interface. Perhaps an eventual solution is to display feature values in an (optional) pop-up window? Thanks, West.andrew.g (talk) 00:12, 16 March 2011 (UTC)

I realize that minimalism is your goal and I agree that less is more. When I asked myself why I find it useful, I actually Huggled for a while to see. I realized that I tend to glance at the number before making a revert, just to check to make sure I didn't miss any content change. I also find that the number's quicker to read than looking at the diff when large amounts of text are removed/added, and it points out what color to look for. Dumb, isn't it? Guoguo12--Talk--  01:13, 16 March 2011 (UTC)

Aside from minimalism issues, I'm always concerned about amplifying signals. STiki's comprehensive metadata is supposed to be doing all of that thinking for the end-user. If humans are using their own heuristics on top of STiki's, it might be more convenient in the interim, but I think it might divert or confuse the data by 'double-counting' for certain signals. Would the most methodologically clean approach be to have absolutely no meta-data at all, just showing the diff? What is the tradeoff between that and showing all of the meta-data? Is the current arrangement the best compromise between those two points? Would it be interesting to give users the option to select which meta-data they can see? Why am I asking so many questions? Ocaasi (talk) 08:33, 16 March 2011 (UTC)

I do believe that certain bits of displayed metadata are critical in practice. For example, the article title: Statements that would be considered vandalism in a non-fiction setting (a history article) are interpreted much differently if the topic is fictional in nature (which makes the impossible possible). Providing the article title helps to contextualize these scenarios. Imagine someone adding "... and then they flew to Mars."

Similar, I feel is the revision summary. If someone makes a massive deletion of quality content, but is a registered user (another metadata field), and uses the comment to explain it was due to copyright issues -- I'm inclined to believe them. Without seeing the comment, one may label this vandalism.

The two examples I provided are not part of STiki's heuristics, and it would be very difficult to encode them as such. So at least in these cases, I would say they are ultimately of benefit to the software. Thanks, West.andrew.g (talk) 14:20, 16 March 2011 (UTC)

Yes, at the least, anything useful and not part of the metadata should be included, since at that point it just helps the reader. Not that I understand the trade-offs here fully, I just had a hunch about some of the considerations. It sounds like the current set-up is just about exactly what it should be. Ocaasi (talk) 14:47, 16 March 2011 (UTC)

Suggestion

Resolved

 – New version uploaded, and the relevant fix to the API code was brought live by developers. Thanks, West.andrew.g (talk) 21:05, 1 March 2011 (UTC)

It would be nice if you could decide if STiki adds articles you edit through it to your watchlist. I assume most editors wouldn't want most articles edited this way to their watchlists. I know I don't. No More Mr Nice Guy (talk) 16:21, 1 March 2011 (UTC)

Amen. I would love to have the option to not watchlist articles I edit with STiki, even while having the "watchlist pages I edit" box ticked in my preferences. A fluffernutter is a sandwich! (talk) 16:52, 1 March 2011 (UTC)

No More Mr. Nice Guy -- I assume you also have this option checked in your preferences? (just making sure there is no unexpected behavior going on here). Yes, this sounds like a reasonable feature (I'll just add a checkbox to the GUI), I'll add it straight away and it will be included in the next release. Thanks, West.andrew.g (talk) 17:35, 1 March 2011 (UTC)

I do have this option checked. Thanks for the quick reply and implementation. I could get used to this level of service. No More Mr Nice Guy (talk) 19:46, 1 March 2011 (UTC)

Thank You. I love STiki and this will make it even better.--Nyswimmer (talk) 17:39, 1 March 2011 (UTC)

See also, Wikipedia:Village_pump_(technical)#Watchlist_API_fix_needs_synched.2Fmerged.2Fdeployed.... Still waiting on the devs to fix a related technical issue arising in the 1.17 release. Thanks, West.andrew.g (talk) 18:26, 1 March 2011 (UTC)

I just uploaded the change, so you'll need to re-download the software to see it. However, I don't think the changes will actually work until the devs address the issue immediately above. Thanks, West.andrew.g (talk) 18:37, 1 March 2011 (UTC)

The changes work for me--Nyswimmer (talk) 19:01, 1 March 2011 (UTC)

Works for me too (after clearing the cache). No More Mr Nice Guy (talk) 15:48, 2 March 2011 (UTC)

STiki Public Service Announcement

Hello STiki users, and thanks for your continued use of my tool.

As you may have noticed, the "ClueBot NG" queue has not been updated in some time. Initially, this was the result of the ClueBot NG being completely offline. Bot service has since been restored. However, the IRC feeds on which STiki depends to enqueue scores have not yet been restarted. I have raised this as an issue with the developers (see User_talk:ClueBot_Commons#IRC_Feeds) -- but I am yet to receive a response. Perhaps some others can pile on over at that talk page to see if we can't make some traction.

In the meanwhile, I encourage STiki users to switch to the "metadata" queue, which is actively processing/en-queuing fresh edits. You are much more likely to find vandalism in this stack. I also realize, that due to to the CBNG-queue being down, that STiki may take a rather lengthy period of time to load/initialize. I apologize. Fixes in the near future will allow me to adjust the "default" queue on the server to circumvent such issues. Look for these changes in a couple weeks time -- I am quite bogged down at current trying to prepare some academic work for WikiSym. Thanks, West.andrew.g (talk) 22:16, 22 March 2011 (UTC)

Thanks for the update, I was wondering about those things. It might be helpful if you added a status bar that said what the STiki was up to, so when it seems like it's hanging we could know it's trying to connect to something, for example.

By the way, a few days ago I got an edit I made through STiki back as suspected vandalism 2 minutes later... I think this was on the metadada queue. No More Mr Nice Guy (talk) 09:12, 23 March 2011 (UTC)

Yep. I noticed this issue the other day when I was on STiki. The metadata queue works fine. If anything it seemed more accurate than usual. I don't know if it has been learning... or maybe it was just catching stuff that ordinarily I would have seen through the other queue. Yaris678 (talk) 10:24, 23 March 2011 (UTC)

Hmm, I just updated, but the 'meta (combination)' queue is grayed out for me (i.e. I can not click to enable it). Arthena^(talk) 16:36, 23 March 2011 (UTC)

"STiki (metadata)" (the second drop-down option), is the one I was discussing above. The "meta (combination)" queue is a future-work effort to aggregate the scores from all the other queues into a "super-queue". Thanks, West.andrew.g (talk) 17:41, 23 March 2011 (UTC)

I did wonder if that would confuse someone. Would you consider renaming the "meta (combination)" queue to be merely "combination"? Yaris678 (talk) 19:02, 23 March 2011 (UTC)

Seems reasonable, and a simple change. Added to my TODO. Thanks, West.andrew.g (talk) 01:26, 24 March 2011 (UTC)

Cool. Thanks. Yaris678 (talk) 09:00, 25 March 2011 (UTC)

My copy of STiki seems to be picking up the ClueBot NG feed now. I guess the problem has been fixed. Yaris678 (talk) 17:24, 25 March 2011 (UTC)

What makes you say that? It doesn't look to be fixed, to me. Thanks, West.andrew.g (talk) 20:51, 25 March 2011 (UTC)

Ahhh... well... its "working" but giving very old diffs. I take it that they are ones added to the queue before the feed went down. I guess I mis-described that one.

I quickly moved on to the STiki feed, which found me lots of fresh vandalism.

Yaris678 (talk) 21:27, 25 March 2011 (UTC)

CBNG's feed came back up today, yay! Let's just hope it sticks around. Thanks, West.andrew.g (talk) 21:28, 26 March 2011 (UTC)

Err, not so fast. ClueBot is down again. I just suggest users play things by ear. If the ClueBot queue is showing poor performance, the feeds are probably down, and you should transition over to the STiki metadata queue in the meantime. Thanks, West.andrew.g (talk) 20:45, 28 March 2011 (UTC)

Edits don't go through

Sometimes using STiki, when I click "Vandalism (Undo)", the revert doesn't go through. Sometimes the reverts do work, but the warning doesn't go through, even when the "Warn offending editor" check box is checked. What causes this? -Porchcrop ^{(talk|contributions)} 01:38, 22 April 2011 (UTC)

I assume when you say that the "revert doesn't go through", that the "last revert panel" in STiki reports that nothing was reverted? 99% of the time because you were beaten to the revert: That is, sometime in the prior 10-20 seconds, someone else made an edit (likely a revert) to the page you were trying to revert. Thus, your edit would be conflicting, and the software does not try to force the edit through.

If a warning doesn't go through (but the revert does), it is likely because you are trying to warn an IP editor, and the edit occurred some time in the past (more than 24 hours ago, I think). This is due to dynamic IP address concerns. Policy suggests we shouldn't warn IP editors if some time has expired, because someone else could have the IP address now -- and we wouldn't want to have un-welcoming behavior towards them.

Does this seem to explain matters? I suspect this should explain it, but if not, we can begin tracking down any bugs (in which case, record the RIDs that have proven problematic for you). Thanks, West.andrew.g (talk) 04:19, 22 April 2011 (UTC)

Possibly it could be a revert conflict for the revert. But the warning doesn't go through even if the IP did not edit previously before 24 hours. Sometimes the warning doesn't go through even for registered users' edits. -Porchcrop ^{(talk|contributions)} 07:09, 22 April 2011 (UTC)

If you can pass along the RIDs where unexpected behavior takes place, I'll take a look at them and report back with: (1) and explanation, or (2) a bug report and fix. Thanks, West.andrew.g (talk) 23:21, 22 April 2011 (UTC)

bug report: classification using hotkeys is applied to multiple diffs

If I make a classification using one of the built-in hotkeys (alt-v, alt-p, alt-i), it seems like this classification is not only applied to the current diff, but also immediately to the next diff. It's not a big problem, I just have to use the mouse instead. Arthena^(talk) 07:11, 24 April 2011 (UTC)

Hmm, I'll look into this. I'll also note that after the first "mouse" classification, you can use just the "v-p-i" keys (without ALT) in order to classify. Thanks, West.andrew.g (talk) 20:11, 24 April 2011 (UTC)

STiki maintenance

Greeting, STiki users. Over the next several hours (possibly stretching into the next day), the STiki database will be undergoing some maintenance tasks. This could result in intermittent dysfunctional behavior and downtime. Please do not report these as bugs until everything stabilizes.

These updates: (1) should result in some minor speed improvements in the client-side, (2) lay the foundation for the inclusion of the "anti-link-spam" queue, and (3) help prevent "forced updates", and keep legacy versions of STiki in good working order, even as improved versions get rolled out. Thanks, -AW

Err, that didn't end up going so well, so I think I have rolled everything back to its previous state. Let me know if anything is broken. Thanks, West.andrew.g (talk) 14:05, 10 May 2011 (UTC)

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5