Knowledge talk:STiki/Archive 1

1042:

to check that if a user was blocked before filling (minor incidence) Also i think the formatting is a bit skewy when posting at AIV there. What id also like to see is a warning that you are also editing as an IP when you start up. The time of edit would also be useful (is that available anywhere that i may have missed?)The final comment i have regards to a rollback function. A few edits i did reverted the initial edit of the individual but left other incidences of vandalism (since rollback is not featured). At a slower pace this is fine because youd go thorough your edits and this can often happens in huggle anyway with rollback, when people game the system. It would be beneficial i think to incorporate the tool using the rollback much like huggle does. The program is young though. And constantly changing I applaud this program and encourage others to give it a thorough test to. Sorry if this sounds like a blog but i think for a program thats just starting out its nice to share abit of feedback and experiences from other users. Happy editing, and once again well done.

2075:$ java -jar STiki_2010_07_17.jar Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$ 100(URLClassLoader.java:56) at java.net.URLClassLoader$ 1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$ AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) 596:

for download (2010/04/01). Of course, this only corrects things when the error happens, rather than preventing the error in the first place. Why the error occurs is still a bit perplexing. One thought: Your stack trace indicated it had been 21,000 milliseconds (20 seconds) since the last database communication. Do you always see figures this high, or has a stack trace ever shown a small number (say, less than 5,000 milliseconds?). If it is always high, it could still be a time-out issue somewhere along the line -- and maybe I could prevent it by spawning a thread that just pings the server once every 1--5 seconds. Similarly, do these errors occur during frequent use? or maybe after you've navigated away from STiki to fix something manually on Knowledge, initiate a rollback, etc.? Thanks again for your help and support.

2932:

java.sql.DriverManager.getConnection(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source) at core_objects.stiki_db_con.get_con(stiki_db_con.java:55) at executables.stiki_frontend_driver.reset_connection(stiki_frontend_driver.java:289) at gui_support.gui_ping_server.run(gui_ping_server.java:59) at java.util.concurrent.Executors$ RunnableAdapter.call(Unknown Source) ... west.andrew.g SNIPPED some 100 lines ... Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost. at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2503) at com.mysql.jdbc.MysqlIO.readPacket(MysqlIO.java:600) ... 21 more

1038:

huggle gives you an up to date as it happens queue, this digs a bit deeper in the history and catches older vandalism (I do not not use twinkle so i will not make any comparisons to that software) that’s usually 3 hours old. It often catches vandalsim about 5 minutes old as well. This is very significant. As we have many huggle/twinkle warriors out there but its difficult to catch those that are overlooked in the queue as these tools are used very speedily, so for a vandal fighter who prefers to spend time finding and spotting older embedded vandalism this is an extremely useful tool. That’s what I like.

987:

slower than I had anticipated. When you ask the server for edits, you get a "reservation block" with a time-to-live (10 minutes for 20 edits). If you haven't finished those 20 edits in that time-frame, the database will give them to the next person who asks (and this could very well be "you" again -- but the first copy may still exist in the queue, just unclassified, leading to two copies of the same edit in the queue). Either way, its trivial to fix by just making a list of what's been seen -- I've already uploaded a new version with the fix (but under the same/old filename). Thanks,

1185:

and causing more damage, faster. Obviously, anyone who knew how could make a vandalbot or some sort of device, but the amount of vandalizing IPs who would not know how to do that is far greater than those who do. How many IPs actively fight vandalism and would require this tool? In addition, an IP marking vandalism as "innocent" would mess up the predictions, right? The filter hit is the unregistered user rapidly reverting edits one. Personally, I feel that making this sort of tool available to unregistered users should require community consensus first.

3249: 31: 1527:

they can get straight on with viewing the next diff while the reverting/warning happens. For this specific activity, this is an order of magnitude more efficient than the standard MediaWiki UI (and even tools like Twinkle), where the limitations of the Web interface get in the way. Other features have ended up in MediaWiki having first been implemented in Huggle (for example, showing the diff of a rollback after doing it, something Huggle originated to try to make users spot mistakes).

1860:

previous versions may well indicate that an edit is a vandalism instance. In addition, the paper adopts an active learning model to solve the problem of noisy and incomplete labeling of Knowledge vandalism. The Knowledge domain with its revision histories offers a novel context in which to explore the potential of language models in characterizing author intention. As the experimental results presented in the paper demonstrate, these models hold promise for vandalism detection.

1504:

looks like by far the best implementation of it. (The learning aspect isn't completely new either, in that I can think of at least two attempts to make tools based on it, neither of which really worked). Of course, bots have to compromise, because they have to do the task of reading the diff that a human would do with other patrolling tools, but automated vandalism-detecting bots that take action aren't really something I agree with.

1500:

decision to revert is made by the user, so you're actually just measuring how good the user is at spotting vandalism. Your tool likely has the potential to be very effective at classification, since it has a learning element of sorts. (I would certainly hope that a fancy Java spacio-temportal processing engine is better at that than a few hundred lines of Visual Basic, anyway). But as I'll explain below, that doesn't really matter.

1700:

points above. Regarding point #2: I have tried to preference my machine-learning classifier against displaying edits that have JUST numbers, because I know this is a hard case for non-experts. Nonetheless, they still show up some times. Regarding point #4: This is a difficult case. Nearly all review tools (STiki, Huggle, etc.) -- seem to stick the 'diff' strategy -- and honestly this is something I have no intention of changing.

3012:(In response to the second question) This is conventional behavior for the mouse-less crowd, so I am not inclined to install different behavior -- at least when the classification buttons have focus. However, I can enable it such that when the browser window has focus (i.e., by clicking on it), that a spacebar press fires a scroll-down action. Seems reasonable enough, look for it in the next release (within a few days). Thanks, 158:-- I've only seen the tool on Windows and Linux machines to date. Sorry to hear the edits advanced slowly. This isn't something I've ever experienced (maybe because my laptop resides just across town from my server?) -- but I am going to look into some caching. It is a bit puzzling though -- each button press hits my server once -- and the back-end Knowledge databases twice (both for very small data exchanges). Just 2882:

java.util.concurrent.Executors$ RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$ Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$ Worker.runTask(Unknown Source ) at java.util.concurrent.ThreadPoolExecutor$ Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

3206:

choice among several queues. In addition to previous "metadata" queue, there are two other options: (1) "Cluebot-NG" -- those edits whose score was below the threshold required for automatic bot revert (or couldn't be reverted due to 1RR or other rules). (2) "WikiTrust" -- based on the reputation system of Adler et al.. This is a significant change, and more information is available in the STiki doumentation.

425:

dense with discussion about this error in 2006 and 2007 -- but nothing recently -- so I suspect it might have gotten handled somewhere along the line. I was only using the older version because it has a smaller footprint, and well, "if it ain't broke, don't fix it". Thanks again for your support of STiki, and let me know if issues continue.

514:

network setup? From what I've learned, it seems certain that the connection between my server and your machine is dying or getting killed (rather than an in-code error), but the time-elapsed seems too brief to trigger any sever time-outs. Sorry to bug you again, but I am really grasping at straws on this one. Thanks,

2216:

worried over the fact that users might simply tag a talk page without considering it being a dynamic IP (using the approporate warning for this), which if its the wrong template can be bitey to a passer by. So a prompt ask to warn would give the user a few seconds more to consider customizing a warning or not.

1569:

hurriedly-implemented, fundamentally flawed, misused piece of junk that has driven away useful potential contributors without actually benefiting the project in any way; the revisions it is catching are either harmless or would have been reverted within seconds anyway by Huggle or similar tools (or even a bot).

2555:

However, after a period of time these reservations expire (on the assumption the client died unexpectedly, without releasing the reservation). I'm assuming this expiration screwed things up -- but I cannot wrap my head around the minutae of the problem at this moment. I'll think about this for a while.

3205:

QUEUES. Prior to this version, the STiki GUI had only one queue -- an internal one based on edit metadata. (Note: A queue determines which edits are displayed to a user, based on vandalism probabilities. Techniques vary on how one can arrive at a probability). Now, the "Queue" menu offers an explicit

2857:

Greeting STiki users. Something funky happened on the STiki server a couple of days ago, and as a result, new edits were not being processed in the back-end. Thus, these edits were not being added to the queue, and STiki users were only seeing old edits that had little probability of being vandalism.

2747:

Hello everyone. Thanks for reporting this bug. I realize I've been a little latent recently, but I my schedule seems to be clearing for mid-November. At that point, I'll have some time to implement these feature requests and fix these bugs I've been promising due for so long. Thanks for your feedback

2716:

If an article name contains an ampersand ("&"), then the 'Current-Page' and 'Page-Hist' buttons do not function correctly. For instance, for the article "Maram & Aabroo", the mentioned buttons will send you to "Maram" instead. This is a very insignificant bug, but I thought I would mention it

2660:

Fortunately, in non vandalism cases where the edits are worth undoing for other reasons, it's not a 'terrible' thing if STiki catches them. The salient traits of those edits are likely not altogether different from most vandalism. I also use Arthena's method of toggling the user warning. A simple

2404:

I was getting some weirdness last night, also. No good explanation at this point. However, I was working on a updated version of STiki -- and an error of some kind might have trashed the server state. I'm not going to fret about it unless it appears again. However, do look for the improved version in

2215:

Probably be nice if you can simply customize (or have the option to customize) the warning template (Havent used stiki in a while, i think you can...). I agree though that the user on stiki should have an option to over rule if neceesary though, sometimes you know its a static IP/ same person. But Im

1369:

No, there is no way to disable the functionality in prior versions. However, I am able to monitor who is using the tool. Thus, if an IP address was to start using an older version of the tool, I would certainly give these reverts some examination. 99% of the use I have seen is not by IP users and the

595:

Hi again Svick. I've made some changes and I'm confident I've made progress. I've wrapped every DB-call in a try-catch block looking for this specific error. If the error occurs, it seamlessly resets the connection and re-attempts the operation under the new connection. The fixed version is available

552:

Yes, I have programming experience, although not in Java. I can try to debug the problem (I know it's hard to do if you can't reproduce the problem yourself), if you tell me what to look for. There's nothing unusual when it happens. I'm using Windows Vista and Java 1.6.0_18. I have fast (measured now

286:

On your second point (warnings) -- I spent a considerable amount of time today overhauling the warning structure. I now parse the UserTalk page of the offending editor, looking for previous user-warnings (by month, year), and then append to the appropriate section, incrementing the warn-level by one.

282:

On your first point (jamming) -- this isn't a behavior I've seen before. Edits always advance on my machine (Linux and Windows) -- and this isn't the same machine that hosts the back-end processing and database. I'm not sure of your technical expertise (so just ignore if I confuse you) -- but if your

3061:

Ok, super minor and completely after-holiday worthy--the spacebar advance is only advancing a single line at a time, as opposed to a single paragraph or pane or page. I don't know if 'page down' is actually too much, but at least 5 lines, maybe 10 or 15 would be needed to make it efficient. Thanks

3002:

For those who don't use a mouse -- the ALT+mnemonics+arrows are used to navigate to buttons in a GUI -- and the spacebar is used to "fire" a button. So if you are using a mouse, clicking on a button will give that button "focus" (indicated by a light gray rectangle) -- and pressing the spacebar will

1937:

A side-effect of the blazing speed is that the chance of accidentally reverting to another bad edit has gone up. Rollback would obviously be ideal, but an inbetween fix would just be including the i.p./username of the prior edit. It's usually a dead give-away when a vandal-edit was preceded by the

1503:

I mainly wanted to point out that most existing patrolling tools work the same way -- not so much because it better, but because so many edits are made that loading the text of every diff in real time isn't really feasible. So what the introduction presents as something new, isn't so much, though it

1499:

I'm not saying that Huggle is more effective than STiki (or anything else). If effectiveness is defined in terms of successful classification as vandalism/not-vandalism, Huggle fails miserably because it doesn't actually do that. :) Speaking of a hit-rate is also meaningless with Huggle, because the

1041:

Now what I’ve noticed that i think needs improvement (at the time of writing i am referring to the march 25th 2010 version); I think there is a small glitch in the formation of reporting users to AIV. I found that my report was sent after the individual was block, it would be nice if there was a way

854:

Hello again Svick. Another try (version is 2010/4/2). I noticed your last two stack traces had "last communicated" durations of just over 20 seconds. I implemented the "ping" strategy I discussed above. The client now pings the MySQL server once every 5 seconds with a trivial query. In my research I

2984:

2) Spacebar on most browsers is a way to advance a page downward (page down). This feature would be useful in checking diffs, which don't always show up in a single pane (especially using larger font sizes). The desired functionality could be a global spacebar shortcut to advance the page down or

2931:

at java.lang.reflect.Constructor.newInstance(Unknown Source) at com.mysql.jdbc.Util.handleNewInstance(Util.java:409) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:357) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:285) at

2610:

True, It doesn't need to be an option. I was just thinking that sometimes I come across an edit in STiki that is not vandalism, but I do want to revert it for some other reason, and then it would not be a minor edit. But in those cases I should just tag it as 'innocent' and make the revert manually

2252:

I like the Huggle idea. But yes, as Ottawa pointed out, the real purpose of the parameter was for dynamic IP addresses. As you observed, STiki sometimes displays vandalism that is 10+ days old. It seems inappropriate to warn an IP such a situation, no? Registered users are always warned, regardless

2027:

Thanks for the pointers. The major change in performance was likely due to a shift in ML approach. Previously I was using Support Vector Machines and I've now switched to Alternating Decision Trees (you may have also noticed that the occasional edit from a registered user now appears). ADTrees have

1796:

I have this functionality (though un-intentionally). STiki clients must ask the server for a RID to review. If disaster were ever to strike, I could simply blank this queue (and STiki wouldn't work). More elegantly, I could populate the queue with only a single RID (perhaps in my user-space), which

1766:

You might want to consider adding a "kill" for older versions, by checking a page or within the backend. Generally, this shouldn't be necessary, but if a bug is found that may actually damage the wiki, or if the backend communication changes, it should prevent or strongly warn against continued use

1466:

anti-vandal tool. My comments (i.e., what you quoted above), are a bit out of context on STiki's Knowledge talk page, because they were basically copied verbatim from my academic writings. In that realm (the academic one), the use of metadata is quite rare, and the use of NLP is far more common. My

1184:

It allows IPs to rapidly revert edits--this is potentially disruptive, because simply editing as an IP does not allow me to click a button and revert edits easily. Instead of manually vandalizing, they could just click the "revert" button as fast as they wanted, switching IPs after becoming blocked

1161:

On the second point, I assume it is only anonymous use of the tool that trips the 'editfilter'. Exactly which filters are being hit? -- I assume those involving the edit rate of anonymous editors? This is more concerning to me. I guess a solution is to encourage users to log-in via a warning dialog

157:

notes, improving the hit-rate (false-positives) is one of my major goals moving forward. I wanted to have a working system across the board before I delved seriously into any one part -- though the vandalism detection rate is likely the single most important! I'm glad to hear things worked on a Mac

2500:

as vandalism and STiki failed to revert it saying that I had been beaten to the revert. However, this was still the latest edit on the page! After this, I did a manual rollback. A contributing factor may have been that I sat on the prior edit I was reviewing for about an hour while I reworked that

1151:

It is correct that the tool can be used without logging in. However, this tool provides IP-users no functionality they wouldn't have otherwise. So in that respect, I see no harm done. Further, Knowledge makes it clear that we should not hold bias against users who choose to edit anonymously. It is

986:

on the dropped connection point for the time being. Now about this edit repeating: There are two possibilities: (1) The same person is committing the same kind of edit on many pages (category vandalism/spam are frequent with this), just making it look the same edit, or (2) You are editing a little

863:

this version. It is now multi-threaded with all non-visual processing happening in the background. Most critically, edits are pre-fetched into a small cache so there is no network latency when the edit needs advanced. Hopefully the multi-threading doesn't cause you any problems that it didn't give

424:

Hi again Svick, I just posted a new version of STiki. With respect to the error you were getting, I changed the JDBC (database connector) from mysql-connector-3.1.14 to version 5.1.12. I am not positive this has fixed the problem (it has never happened on my machine). However, the MySQL forums are

375:

Hi Svick. I know this is a bit of a long-shot, but had you had the program open for 8+ hours when this error occurred? Or has it recently happened multiple times in short succession? All the documentation I can find pointing to this error indicates it is the result of connection time-out (which is

2199:

I just reverted several cases of serious vandalism that were 10 hours old – way to go STiki! However, STiki refused to warn the users because the edits were too old, even though the user talk pages were empty. I went ahead and did the warnings with Twinkle. It would be great if STiki did warnings

1564:

That's it. And yet it doesn't matter that this isn't very good because the patroller is keeping pace with recent changes and will see the revision within seconds anyway. Huggle does not look for key words or do pattern matching on edit summaries, user names, page titles, article content, diffs or

1526:

Diffs are pre-loaded before the user views them, so usually the wait time for one to load is close to zero. Web requests are all made in parallel in the background, so Huggle doesn't have to wait until it's done warning one user to revert another, and the user doesn't have to wait for anything --

1507:

Huggle's main focus is on improving the efficiency of the patrolling process, not of detecting vandalism. After all, if the process is efficient enough that one person can keep up with all changes to the wiki (more or less possible with Huggle at present), it hardly matters. So a single keystroke

232:

Quite often, I click on one of the three classification buttons and nothing seems to happen. Once I clicked “Vandalism (revert)” and the edit was actually reverted (and the user notified), but the GUI didn't change to another edit and won't change even if I repeatedly click “Pass”. Restarting the

3222:

Back-end STiki scores, rather than being on , now harness the logistic nature of ADTree scoring to normalize scores onto (making them probability-esque). This transformation maintains relative ordering so frontend users should notice no change. This transform was also applied to all historical

3215:

Significant changes to communication primitives. All client calls to the STiki database are now handled by stored procedures, as a matter of security. Frontend GUI users should notice no change as a result. All stored procedure calls are logged and can be audited. This change will break previous

2619:

When a change is required that STiki can't handle (non-vandalism, rollback, etc.), I make the change manually and then "pass" so as to not mess up the training. The edit won't actually go to anyone else because it's no longer the most recent. It might be better to click "vandalism" in some cases

1859:

This paper builds statistical language models, constructing distributions of words from the revision history of Knowledge articles. As vandalism often involves the use of unexpected words to draw attention, the fitness (or lack thereof) of a new edit when compared with language models built from

1699:

Thanks for your kind words, Triona. Multiple edit classifications (vandalism, spam, good-faith revert), or even taggings, have long been on my radar for STiki. The rigors of graduate school have prevented me from implementing them thus far. I'll note that this would take care of your 1st and 3rd

1037:

about 3 tries so far. Each version seems to improve on the other. I thought it prudent to share my experiences about this tool, as obviously other vandal fighters are considering new tools all the time. The software does exactly what its said to do in that it compliments tools like huggle. Where

642:

So far I haven't seen this problem with the new version. It may be possible that it appeared always after I didn't use STiki for several seconds, but I don't know this for sure. Is the exception logged if it is catched? In other words, should I run STiki from the command line to see if it writes

2554:

I suspect your problem is related to the "I sat on the prior edit for about an hour" bit. When one uses STiki, they "reserve" blocks of ~10 edits at a time that they are given to work on (so the client can go ahead and process the API calls, so network latency doesn't slow the user experience).

1067:

Rollback. This is something I'm thinking about. Since the edit-window only shows a single 'diff' -- it would be hard to know exactly how much content you are rolling back if you hit the button. Right now, if I see multi-edit vandalism I usually just click on the page history link and initiate a

772:

Failed to populate metadata object: RID in question is: 353066363 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link fai lure The last packet successfully received from the server was 21á739 milliseconds ag o. The last packet sent successfully to the server was 21á292

467:

Failed to populate metadata object: RID in question is: 352977278 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link fai lure The last packet successfully received from the server was 21á793 milliseconds ag o. The last packet sent successfully to the server was 21á234

2861:

I was alerted to this issue when I noticed that only 1-5% of STiki-viewed edits were being classified as vandalism (in the past several days). Typically, this percentage hovers in the 33-50% range. Rest assured that everything has been fixed, and that performance levels should once again be as

2445:

It is my intention to include the "rollback" option in STiki much as Huggle does (either using "rollback" naturally for those who have it -- or implementing "in software rollback" for those who do not). I don't know how to best integrate "diff display" so you can be sure you got it all though?

1254:

I agree. Having definitive user login will also enable me to prevent abuse of the prediction system. I will take the steps to disable this functionality (it could take a small amount of time) and perhaps open discussion somewhere regarding if it should be re-enabled. Thank you for interest and

513:

Hi again Svick. I've spent a good 6 hours trying to track down this bug today, to no avail. You seem like you have some programming experience. Can you characterize any environmental characteristics when it happens? Do you have a fast and reliable Internet connection? Anything weird about your

2955:

Per our IRC discussion (and just to formally close this for the rest of the world)... Looks like your network connection had a hiccup. STiki tried to reset and failed. Not much to be done in terms of *fixing* the issue -- but the Exception should (and will) be more gracefully caught. Likely a

2806:

is now an option when reverting edits (as opposed to simple "undo"). For users who have the "rollback" permission, this was straightforward to implement. For those who do not, a more expensive "software rollback", that mimics the native permission, was encoded. To this end, a more informative

2045:

Another interesting fact is how the shared edit-queue effects perceived performance -- it's a Cache-22 of sorts. If no one knows about STiki and it has only a few users, they all think it is great, because they sign on and there is a large amount of vandalism at the top of queue waiting to be

2427:

I just reviewed an edit that was obviously vandalism. In the diff, I saw that the old rev also had different vandalism. The history showed that the previous vandalism was added by the same IP on the previous edit. So, I did a rollback from the history page and then clicked "Vandalism" in the

1855:

ABSTRACT: This paper proposes an active learning approach using language model statistics to detect Knowledge vandalism. Knowledge is a popular and influential collaborative information system. The collaborative nature of authoring, as well as the high visibility of its content, have exposed

1476:

On a related note, I am sure your tool is the most effective at anti-vandalism on Knowledge (both in terms of raw revisions, and hit-rate). A white-paper describing your technique and your statistics would be well received (and probably generate plenty of citations). I am sure your vandalism

1060:

I've now corrected the AIV problems (formatting). Further, I make an explicit blockage check before reporting over at AIV (For some reason, late last night I had it in my head "such a check is stupid -- if they were blocked -- they couldn't have edited in the first place!". Of course, the

1568:

It's worth me disclosing at this point my views on the abuse filter, which does do pattern-matching of those things, and patterns implemented by overzealous administrators with a poor understanding of regular expressions at that. The abuse filter is in my opinion a poorly-designed,

355:

com.mysql.jdbc.CommunicationsException: Communications link failure due to under lying exception: ** BEGIN NESTED EXCEPTION ** java.net.SocketException MESSAGE: Software caused connection abort: socket write error STACKTRACE: === SNIPPED ~100 lines (see history) === (West.andrew.g)

2881:

Threaded-POST attempt (reversion) failed: java.lang.NullPointerException at java.net.URLEncoder.encode(Unknown Source) at mediawiki_api.api_post.edit_rollback(api_post.java:149) at gui_support.gui_revert_and_warn.run(gui_revert_and_warn.java:173) at

1856:

Knowledge articles to vandalism. Vandalism is defined as malicious editing intended to compromise the integrity of the content of articles. Extensive manual efforts are being made to combat vandalism and an automated approach to alleviate the laborious process is needed.

2124:

I am working on a new version, due for release in the next couple days, at the latest. I'll compile the *.JAR with Java 1.5 -- and give you a ping when that is available. (Edit: And sorry about the TB template, just saw that message the second time through) Thanks,

283:

running the *.JAR from a terminal, does anything get printed to the terminal (stderr?) when these jam-ups occur? The reports of latency I've heard are puzzling -- each RID-advance pings my server once and the WikiMedia database twice (each with trivial payloads).

2335:

Hi Ryulong. STiki isn't a "script" per se -- it just shows users diffs which *may* contain vandalism. Thus the responsibility of making the vandalism/innocent distinction falls to individual users. Any issues should be taken up with the reverting user. Thanks,

3145:

Happy holidays, STiki users. STiki will be taken off-line for several hours today for maintenance -- I am aware of this down time. When it comes back online, old versions of the client will not work -- but there will be a new version available for download.

2645:

This is a better solution for the vandalism rollback case. I'm torn on the non-vandalism problems. I want to train STiki to catch them, but I'm hesitant to actually click vandalism for fear of messing up its detection of real vandalism. We need more buttons!

2428:

classifier to help out the STiki rating algorithm, even though I knew there was no longer an edit for it to undo. It would be nice to be able to go back to previous diffs right in the diff-browser and execute a rollback, just like when using Twinkle. —

2711: 553:

at 25 MBit/s download and 4 Mbit/s upload and 102 ms average ping to www.cis.upenn.edu) and reliable internet connection. It's a university network, so there are rules forbidding some kinds of traffic, but I think that shouldn't be causing this.

1992:

Looks like things have quieted down on the controversy front, which is good. I think I can speak for those with less itchy outrage-fingers that your continued presence around here can do a lot for some of the persistent problems this project

1620:

As for the Razi High School, Why did you revert my post? Please let me know your reasons for doing that? I had just added the jersey color of the school team! BTW I am a Razi graduate and used to be in Razi High School Varsity team. Good Old

1278:← And thanks for understanding. I do like the feel of this tool, and hope that it's uses will be expanded (different warning types, etc.) I also like that it's built on Java, which I feel makes it a more lighter interface and easier to use. 203:

The STiki version of 2010/4/2 eliminates any speed issues. Every non-visual action is now multi-threaded, and similarly, background threads are used to pre-fetch edits so there is no network latency when a new one needs to be displayed.

2315:

Thanks Ryulong. You can understand why 'Inoue Joe HELLO!.jpg' looks a little spammy. It'd be great if you or someone (me perhaps) would add an edit-note above it so that no one is confused. <-This is the real album name... !:

2165:

Exception in thread "main" java.lang.NoClassDefFoundError: java/awt/Desktop at executables.stiki_frontend_driver.initialize_button_panel(stiki_frontend_driver.java:457) at executables.stiki_frontend_driver.<init:

1152:

ultimately the responsibility of the user operating any tool to act properly (and other tools do permit anonymous use). If someone wanted to be malicious, they could abuse the API in *much* worse ways than my tool could facilitate.

926:

So far no problems with the new version. And I really like the speedup. I only have one small issue – I have gotten few times the same edit twice to review. I guess this could be some issue with the caching. 02:45, 2 April 2010

2824:

As STiki grows more complex, it becomes increasingly difficult for me to test all the corner cases. I'd appreciate if everyone continues to post their bug reports and feature requests here. Thank you, and happy reverting!

1740:

The requested changes have been completed in-code. This code will become public-available at the next release. I can't do much about those that have already downloaded a previous version, though. Thanks for your comments,

2595:

Acknowledged, in the next release I will ensure that both the reversion and the user-talk warnings are marked as minor (though I believe the latter already are). It shouldn't even need to be an option, should it? Thanks,

2046:

handled. These people tell others about the performance -- and the user-base expands. Then, the vandalism is distributed among this larger set -- and they don't perceive the performance as being nearly as great. Thanks,

1726:... It's fine to do it in the edit summary, but putting it in the warning that the user gets will just confuse them, not to mention the fact that it makes this page prone to vandalism, and it could be considered spam. - 3003:

fire the button that has focus. Thus, pressing space bar will repeat the last action taken. If you use the mouse to indicate "Innocent" and then press the spacebar, that second edit will also be labelled as "Innocent".

1638:

Ill take a liberty and respond here breifly, West.andrew did not make that edit (though the program he wrote allowed the other editor to make the change), you can directly query the user who did the reversion ; here at

2084:

Errr... I might have compiled with Java 1.6. That would explain the "UnsupportedClassVersion" exception. Time for an upgrade? You could also recompile from the source version, but that would require a couple of libs.

3149:

There is at least one big change in the new version which should make the trouble worth it -- MULTIPLE "revision queues." Whereas STiki's metadata-driven scoring system was the *only* one used in previous versions,

693:

Nope, no output. As long as the program keeps running -- I'm going to consider it a success. There is always the chance that a different error will be thrown, though I haven't heard anything about this. Thanks, -AW

180:

On my PC i find it takes 2 seconds to load each edit(this is at 9am and 2pm uk time), and about 3 seconds for the edit to take effect on the contributions screen. I find that huggle on my pc acts at about the smae

3034:

Sweet. Makes sense on both counts (although I always thought that Enter fired alt+shortcuts). Anyway, clicking on the diff to enable a spacebar/page down will definitely enhance efficiency. Thanks again...

137:

Just started experimenting with STiki on my mac. Going well, and nice work. Two comments. One that it looks like there are too many false positives, and also it feels a bit slow although I am on broadband.

1467:

apologies for not handling my description with more clarity. Indeed, as I note elsewhere I have no intention to compete with your tool and its massive user-base -- mine is far more proof-of-concept.

1893:

Indeed, I happen to have a copy of that paper on my desk right now! I haven't delved into it in great detail yet, but plan to do so in the coming days. Would you happen to be one of the authors?

302:

Again, thanks for your review -- and hopefully after many iterations with users like you, I will have a tool that both fulfills my academic needs and those of the Knowledge community. Thanks,

1370:

older STiki versions are not available for download. Further, the tool is yet to be advertised, so the user-base is not large. In other words, I am confident there will be no issues. Thanks,

376:

set at 8 hours). As you might have noticed -- it is happening deep within an external library, so I haven't had much luck tracking it down in my own code. Again, thank you for your support.

2723: 2820:

User's whose last warning was a "4im" of *any* kind (not just vandalism), will now be reported to AIV if reverted by STiki. The post to AIV will reflect the unique nature of this request.

115:

This was noticed a couple days ago and since has been fixed. Updating (re-downloading) to the most recent version will clear up the problem. Thank you for your continued use of the tool.

2267:

24 hours sounds about right. An exception is if the talk page has one of those glaring University shared IP templates on it, but I suspect that Huggle already deals with this properly. —

3179:

page here shortly and post the CHANGELOG to the talk page. In the meantime, the documentation internal to STiki has been updated, or really, just look at the "Queues" menu. Thanks,

291:. It's a best-effort though: between Huggle, Twinkle, and all types of home-brewed strategies there are many different formats out there for doing this, but I am pretty satisfied. 1797:

instructs them to upgrade. Then, the next version would point to a different queue, and all would be well. I don't see it being relevant for this minor change, though, correct?

2981:

1) Spacebar seems to be advancing to a new diff but I don't know if it's using Vandalism/Innocent/Pass. I don't intend it to do any of these, but if it does, which one is it?

2798:

Greetings STiki users, a new version was uploaded tonight! I encourage everyone to download it and begin trying it out. Per the CHANGELOG, some of the bigger changes include:

3201:

The following is the CHANGELOG from the 12/26/2010 release: (note that a change in communication problems will require that users of previous versions update their software)

1064:

Displaying the time of the edit? Ditto, I'll get right on that. I think it may be most useful to put this in relative terms: "This edit was made X hours and Y minutes ago".

2620:

where I do a rollback, but I've stopped this because STiki sometimes added a second user talk page warning right after the warning I had just added from the rollback. —

1437:

Instead, STiki spatio-temporally processes primarily revision metadata (edit timestamp, article, editing-user, and revision comment) to arrive at vandalism predictions.

1255:

discussion regarding my tool. (For posterities sake, note that the above IP throwing in his/her opinion is a vandal that I and others have reverted on many occasions).

1427:

Unlike the bulk of existing anti-vandalism tools, STiki does not rely heavily on natural language processing (e.g., regular expressions) over the article or diff text.

1092:

This can be used without logging in, right? Isn't that potentially hazardous? We could have IP edit wars or 4chan attacks using it. Can this functionality be removed?

2817:

The "current page" and "page history" links now handle special characters in article titles appropriately. In particular, this fixes a reported issue with ampersands.

2906:

Thanks, a result of the recent change to include rollback functionality. I believe I already have a fix locally, and will push it out with the next release. Thanks,

2200:

like Huggle in actually comparing the time of the last warning on the talk page and assigning the next higher warning level if the reverted edit is newer. —

1924:, but the vandalism ratio is down to about 1 in 3 from 1 in 10. Much more enjoyable to use. Also, definitely nicer without all of the number-only diffs. 1330:

Thanks; is there any way to disable anonymous use of the previous versions, or should one just hope that the original doesn't fall into the wrong hands?

1051: 3188: 2783: 2691: 2481: 2148: 996: 3167: 2757: 2673: 2629: 2564: 2455: 2276: 2262: 2253:

of elapsed time. I'll add this to a growing TODO list. Nonetheless, what do you think is a good default duration when IP warning is still appropriate?

95: 1672:

The edit may be questionable but in a way that can't be determined solely from a diff - small changes to dates or numeric values are a common example.

1264: 1081: 213: 190: 171: 2239: 2225: 1652: 1406: 1379: 1352: 1317: 1207: 1171: 1028: 1233: 2965: 2915: 2846: 2605: 2414: 1831: 1806: 1761: 1750: 1675:

The edit may not be vandalism, and may not be something we want to revert, but is still deficient in such a way as to require further (re)working.

1142: 3101: 3044: 3021: 2871: 2738: 2655: 2640: 2362: 2345: 2055: 2010: 1902: 1820: 1776: 1709: 3236: 2405:

the next couple of days. I've been (a) implementing rollback, and (b) handling all the bug reports filed on this page and my talk page. Thanks,

1580: 1486: 873: 805: 703: 652: 605: 562: 523: 488: 434: 407: 385: 342: 311: 124: 2834: 2729:

I was wondering why the buttons sometimes don't work! I'm not sure that this is the only problem, but I'll now know what to look for. Thanks. —

1691: 2523:. In this case, the same edit was made twice, with the first immediately reverted by someone else. Why did STiki not revert the second edit? — 1885: 3140: 2134: 2119: 2537:

The only way out of this was to close and reopen STiki, after which it started doing reverts again. It showed me logged in the whole time. —

2395: 2634:

Aha, interesting. When I don't want to give a warning, I just disable STiki warnings by clicking on the checkbox in the bottomleft corner.

2326: 2209: 1791: 1660: 398:

No, I certainly didn't have the program open for more than 15 minutes. But yes, usually, when it happens once, then it soon happens again.

3071: 1224:

Anonymous users probably shouldn't be allowed to use this tool. It could be applied to destructive purposes with very little consequence.-

3219:

For the backend reputation component (for users and articles), the reversions of the recently approved "Cluebot NG" bot are now included.

1847: 855:

found its not always the client or the server that can terminate idle connections -- but network switches sometimes also get involved. I

1630: 2094: 3212:

If the 'diff browser' window has focus, the spacebar key will now fire the 'scroll down' action, per a feature request @ WP:STiki.

2546: 2532: 2514: 2852: 1865: 3175:

New version available for download and servers are back up. Let the bug reports starting flowing (*sigh*). I'll change the main

1454: 3196: 3128:. Just be careful with the spacebar in this fashion to make sure you don't make accidental classifications. Closed. Thanks, -AW 1678:

The edit may be perfectly fine, but in seeing the part of the article given as diff context, there may be something else wrong.

2437: 1300: 1114: 352:

I've been experiencing the above mentioned problem again. This time, I ran STiki from console and got the following messages:

107: 2994: 2793: 2520: 1977:, which probably accounts for 60% of the recent-changes patrolling. He's pretty much seen it all when it comes to vandalism. 3125: 2293: 1732: 147: 1061:

contradiction here is that STiki may be displaying edits that occurred long ago, and the user may have been blocked since.

2771: 2679: 2665: 2469: 2446:

Currently I just use the link I provide to the page history and use rollback there -- but I recognize this is inelegant.

2189: 2587: 2383: 2194: 1622: 2578: 2309: 1811:

No, clearly not for this, just making sure you have a way to clear out "bad" versions if such an event ever happens.

1225: 367: 263: 3209:

Minor changes to AIV reporting. Both reports and comments now have some additional detail to help the admins at AIV.

2167:(stiki_frontend_driver.java:215) at executables.stiki_frontend_driver.main(stiki_frontend_driver.java:177) 1400: 1346: 1294: 1201: 1136: 1108: 3158:" now contribute their scores. I'll post the full CHANGELOG here when everything is online and operating. Thanks, 2947: 2497: 3297: 3289: 3284: 2898: 1669:

The edit may not be vandalism, but is otherwise deficient and needs to be reverted while preserving good faith.

1420: 79: 71: 66: 2501:

editor's good faith attempt into something presentable. I then clicked innocent and was immediately shown the

2099:

I think the last time I tried to upgrade to 1.6, it told me I needed OSX 10.5, which is not an option for me.

1615: 228:

Hi, I'm trying STiki and it seems like a really interesting idea, but there are two issues I have with it:

90: 2139:

Took a little longer than expected, but the front-end has been recompiled with a Java 1.5 target. Thanks,

2956:

side-effect of your port tunnelling, which should go away if we transition to an HTTP protocol. Thanks,

3256: 2973: 2067: 38: 2491: 3232: 3184: 3163: 3097: 3017: 2961: 2911: 2867: 2830: 2779: 2753: 2687: 2669: 2601: 2560: 2477: 2451: 2410: 2341: 2258: 2144: 2130: 2090: 2051: 1898: 1802: 1746: 1717: 1705: 1602: 1482: 1375: 1313: 1260: 1167: 1087: 1077: 992: 869: 699: 601: 519: 430: 381: 307: 209: 167: 120: 1057:

Thank you for your kinds words (the changes I mention here will be present in the next update):

2734: 2651: 2625: 2542: 2528: 2510: 2433: 2272: 2235: 2205: 1640: 1626: 236:

The tool should use the standard “Month year” headings and warning with appropriate level, not

2807:

revert-feedback panel now notes both the technique used, and the number of edits undone/RB'ed.

1907:

No, intra-article linguistic frequency data... it just looked like it was right up your alley.

1866:

http://www.iowahighereducation.com/2010/09/23/ui-researchers-design-tool-to-improve-wikipedia/

2422: 2221: 1964: 1951:

I was trying to think of people in the community you might want to talk to if you have time.

1648: 1229: 1047: 186: 143: 2985:

one which only worked after clicking on the diff itself. Is something like this possible?

1565:

anything else. It's far too subjective for a computer program to do in an error-free manner.

249:

Also I like to watch the talk page I post warnings to, so I would welcome this as an option.

3265: 2572: 2502: 2184: 2114: 1393: 1339: 1287: 1194: 1129: 1101: 47: 17: 8: 2372: 2296:. I don't know how this script works, so I've contacted the user and those here as well.— 223: 132: 2468:

Rollback functionality (both "native" and "software") are now implemented in STiki. See

98:

wasn't formatted properly – it seems that “/r” was inserted there instead of a newline.

3228: 3180: 3159: 3093: 3013: 2957: 2907: 2863: 2826: 2803: 2775: 2749: 2683: 2597: 2556: 2473: 2447: 2406: 2337: 2288: 2254: 2140: 2126: 2086: 2047: 1920:

BTW, I don't know if you tweaked the algorithm, or if STiki's machine-learning is just

1894: 1798: 1742: 1701: 1598: 1478: 1371: 1309: 1256: 1163: 1073: 988: 865: 695: 597: 515: 426: 377: 303: 205: 163: 116: 2939: 2890: 2844: 2730: 2721: 2647: 2638: 2621: 2615: 2585: 2538: 2524: 2506: 2429: 2393: 2381: 2303: 2268: 2231: 2201: 2712:

Bug report: ampersand in article title breaks 'Current-Page' and 'Page-Hist' buttons

3067: 3040: 2990: 2577:

I think it would be good if there was an option to mark STiki's edits as minor. By

2358: 2322: 2217: 1881: 1816: 1772: 1687: 1644: 1043: 182: 139: 3176: 2943: 2894: 2811: 2770:

Special characters in article title's should no longer break outgoing links. See

1723: 1576: 1450: 1386: 1332: 1280: 1187: 1122: 1094: 801: 648: 558: 484: 403: 363: 338: 259: 154: 103: 3264:

If you wish to start a new discussion or revive an old one, please do so on the

1871: 1825:

Yeah, not for this, just if some major change has to be done. Sounds good :). -

46:

If you wish to start a new discussion or revive an old one, please do so on the

2028:

inherent support for missing features and enumerated ones, which is a big help.

1665:

There are some more possibilities to consider in the "classification" buttons.

1597:

Some changes made to the STiki description to address this discussion. Thanks,

1384:

OK, I thought something like that, and it should be fine, as you said. Thanks!

239: 2923: 1782: 288: 153:

Hi Prashanthns -- Thank you for your pro-active interest in the tool. As the

3151: 2935: 2886: 2841: 2718: 2635: 2612: 2611:

in my browser, because reverting it in STiki would mistrain the algorithm.

2582: 2390: 2378: 2297: 2178: 2108: 1826: 1786: 1756: 1727: 287:

If one vandalizes with a relevant uw-4 still active - they get reported at

3063: 3036: 2986: 2876: 2662: 2354: 2318: 2007: 1960: 1877: 1812: 1768: 1683: 773:

milliseconds ago. == SNIPPED ~100 lines (see history) == (West.andrew.g)

468:

milliseconds ago. == SNIPPED ~100 lines (see history) == (West.andrew.g)

1682:

Other than that, looks like a great tool so far, keep up the good work.

1530:

Anyway, as for the processing, which you're probably more interested in:

326:

Strange, I'm unable to reproduce the problem now. Everything works fine.

1970: 1954: 1572: 1446: 797: 644: 554: 480: 399: 359: 334: 255: 99: 3155: 2978:

Two questions related to how the spacebar is functioning in STiki:

2351: 1477:

statistics, when aggregated, would tell a quite interesting story.

1462:

Hi Gurch. I have experimented with Huggle and believe you have an

1308:

This feature change has been made per the version of 2010/03/28.

271:

Hi there Svick. Thanks for your interest and download of the tool!

2581:, removal of blatant vandalism should be marked as a minor edit. 2172: 2102: 1162:-- which also notes the potential problems with the edit filter. 2678:

Closing note here. STiki now marks its reversions as minor. See

1722:

I don't think the warning given to the user should link back to

859:

this attempt works. You'll probably also notice that STiki runs

1974: 233:

application fixes the problem, but it very soon surfaces again.

2928:

Ungracefully crashed; from cmd, salvaged this error message.

3092:

Changed in code; will be included in next release. Thanks,

2072:

I got the following error when running for the first time:

748:

Unfortunately, the error still appears in the latest build:

162:

would you estimate the edit advancement to be? Thanks,

2661:

good-faith revert button would solve all of the issues.

1517:* parse that user's talk page to find previous warnings 1511:* carry out a bunch of checks to try to avoid mistakes 2078:

I'm running Mac OS X 10.4 with JRE version 1.5.0_19.

2885:

Caused program to hang ungracefully and then crash.

2579:

Knowledge:Minor#When_to_mark_an_edit_as_a_minor_edit

1533:* automatic page-blanking summaries are listed first 1523:* report the user if they were already warned enough 1514:* revert all consecutive revisions by the same user 2230:I would rather just integrate the Huggle code. — 1938:same author; very unlikely they're not both bad. 1120:It also trips the editfilter about every edit. 2814:, all STiki reverts are now marked as `minor' 1872:http://portal.acm.org/citation.cfm?id=1772942 1551:* users with more than 500 edits are ignored 1957:WMF developer, into all of the big projects 1520:* leave an appropriate higher-level warning 2317:that kind of thing. regular STiki user, 1029:Personal Experinces and some bugs noticed 1785:does, is annoying, but can be useful. - 1781:I agree. Forcing users to upgrade, like 1536:* reported/blocked users are listed next 14: 3262:Do not edit the contents of this page. 2772:the notes about the 2010/11/28 release 2680:the notes about the 2010/11/28 release 2470:the notes about the 2010/11/28 release 44:Do not edit the contents of this page. 3141:Dec. 26 -- STiki down for maintenance 2748:and continue use of my tool. Thanks, 3243: 1661:Suggestion regarding classifications 25: 1848:U IOWA Vandalism detection research 1545:* edits to articles are listed next 23: 24: 3311: 1967:specific work, among other things 1542:* anonymous edits are listed next 864:me. Thanks again for everything, 3247: 1548:* then everything else is listed 254:Thanks for an interesting tool. 29: 2853:Recent performance hiccup fixed 2377:I'm not getting any revisions. 2294:I don't think this is vandalism 3197:STiki Release -- Dec. 26, 2010 2056:16:44, 25 September 2010 (UTC) 2011:00:15, 25 September 2010 (UTC) 1903:18:18, 24 September 2010 (UTC) 1886:11:46, 24 September 2010 (UTC) 1539:* warned users are listed next 13: 1: 3237:03:42, 29 December 2010 (UTC) 3189:19:46, 26 December 2010 (UTC) 3168:15:54, 26 December 2010 (UTC) 3102:03:49, 29 December 2010 (UTC) 3072:08:50, 27 December 2010 (UTC) 3045:23:43, 12 December 2010 (UTC) 3022:21:28, 12 December 2010 (UTC) 2995:18:01, 10 December 2010 (UTC) 2966:15:49, 24 December 2010 (UTC) 2948:23:36, 19 December 2010 (UTC) 2916:15:04, 17 December 2010 (UTC) 2899:13:14, 17 December 2010 (UTC) 2847:10:38, 28 November 2010 (UTC) 2835:03:14, 28 November 2010 (UTC) 2794:STiki Release -- Nov. 28 2010 2784:03:32, 28 November 2010 (UTC) 2692:03:31, 28 November 2010 (UTC) 2482:03:28, 28 November 2010 (UTC) 2415:14:44, 26 November 2010 (UTC) 2396:12:05, 26 November 2010 (UTC) 2384:08:57, 26 November 2010 (UTC) 2190:15:54, 5 September 2010 (UTC) 1852:Didn't know if you saw this: 329:Thanks a lot for this change. 2872:21:19, 6 December 2010 (UTC) 2758:22:42, 1 November 2010 (UTC) 2674:00:21, 10 October 2010 (UTC) 2363:23:15, 8 November 2010 (UTC) 2346:23:05, 8 November 2010 (UTC) 2327:21:41, 8 November 2010 (UTC) 2310:21:11, 8 November 2010 (UTC) 251:(STiki actually does this.) 7: 2739:23:31, 8 October 2010 (UTC) 2724:19:07, 8 October 2010 (UTC) 2656:09:42, 8 October 2010 (UTC) 2641:08:27, 8 October 2010 (UTC) 2630:17:16, 7 October 2010 (UTC) 2606:14:46, 7 October 2010 (UTC) 2588:19:55, 6 October 2010 (UTC) 2565:06:39, 4 October 2010 (UTC) 2547:12:31, 3 October 2010 (UTC) 2533:11:00, 3 October 2010 (UTC) 2515:10:37, 3 October 2010 (UTC) 2456:06:28, 4 October 2010 (UTC) 2438:08:45, 3 October 2010 (UTC) 2277:09:17, 4 October 2010 (UTC) 2263:06:28, 4 October 2010 (UTC) 2240:04:12, 4 October 2010 (UTC) 2226:10:31, 3 October 2010 (UTC) 2210:09:06, 3 October 2010 (UTC) 2149:18:26, 26 August 2010 (UTC) 2135:15:57, 17 August 2010 (UTC) 2120:15:54, 17 August 2010 (UTC) 2095:14:11, 17 August 2010 (UTC) 1832:22:08, 11 August 2010 (UTC) 1821:18:04, 11 August 2010 (UTC) 1807:18:00, 11 August 2010 (UTC) 1792:17:54, 11 August 2010 (UTC) 1777:17:47, 11 August 2010 (UTC) 1762:16:29, 11 August 2010 (UTC) 1751:14:31, 11 August 2010 (UTC) 1710:14:27, 11 August 2010 (UTC) 10: 3316: 3223:scorings (API accessible). 2195:User warning for old edits 1733:12:06, 7 August 2010 (UTC) 1692:06:45, 7 August 2010 (UTC) 1407:23:20, 30 March 2010 (UTC) 1380:22:51, 30 March 2010 (UTC) 1353:22:32, 30 March 2010 (UTC) 1318:22:20, 28 March 2010 (UTC) 1301:16:02, 26 March 2010 (UTC) 1265:15:50, 26 March 2010 (UTC) 1234:15:37, 26 March 2010 (UTC) 1208:15:03, 26 March 2010 (UTC) 1172:05:08, 26 March 2010 (UTC) 1143:03:22, 26 March 2010 (UTC) 1115:02:57, 26 March 2010 (UTC) 1082:20:56, 25 March 2010 (UTC) 1052:15:11, 25 March 2010 (UTC) 806:22:34, 31 March 2010 (UTC) 704:22:30, 31 March 2010 (UTC) 653:22:06, 31 March 2010 (UTC) 606:21:38, 31 March 2010 (UTC) 563:09:35, 31 March 2010 (UTC) 524:05:11, 31 March 2010 (UTC) 489:23:51, 30 March 2010 (UTC) 455:It doesn't seem it helped: 435:23:01, 30 March 2010 (UTC) 408:16:45, 30 March 2010 (UTC) 386:07:03, 30 March 2010 (UTC) 368:22:29, 29 March 2010 (UTC) 343:23:22, 25 March 2010 (UTC) 312:04:26, 25 March 2010 (UTC) 264:21:53, 22 March 2010 (UTC) 191:15:11, 25 March 2010 (UTC) 172:04:01, 25 March 2010 (UTC) 148:11:41, 24 March 2010 (UTC) 125:15:44, 26 March 2010 (UTC) 108:15:19, 26 March 2010 (UTC) 1653:08:54, 19 July 2010 (UTC) 1631:00:43, 19 July 2010 (UTC) 997:03:38, 2 April 2010 (UTC) 874:21:03, 1 April 2010 (UTC) 214:21:06, 1 April 2010 (UTC) 2717:for completeness' sake. 2162:Still getting an error: 1581:09:31, 19 May 2010 (UTC) 1487:18:30, 18 May 2010 (UTC) 1455:09:22, 17 May 2010 (UTC) 3216:versions of the client. 2352:blame it on the alcohol 2802:Rollback implemented. 1641:User:Dripping Flame/ir 1421:Relationship to Huggle 3260:of past discussions. 1616:Razi High School edit 42:of past discussions. 2503:Fahd of Saudi Arabia 2389:Now it works again. 1973:The main guy behind 1767:of the old version. 91:Broken report to AIV 18:Knowledge talk:STiki 3126:2011/01/31 release 2974:Spacebar keystroke 2862:expected. Thanks, 2496:I just classified 2068:Error when running 1963:I think he's done 96:This report to AIV 3303: 3302: 3272: 3271: 3266:current talk page 2521:same thing happen 2492:Failure to revert 2188: 2118: 861:much much quicker 85: 84: 54: 53: 48:current talk page 3307: 3281: 3274: 3273: 3251: 3250: 3244: 3124:Included in the 2306: 2300: 2181: 2175: 2170: 2111: 2105: 2100: 1829: 1789: 1759: 1730: 1432:nor does Huggle 1405: 1403: 1397: 1390: 1351: 1349: 1343: 1336: 1299: 1297: 1291: 1284: 1206: 1204: 1198: 1191: 1141: 1139: 1133: 1126: 1113: 1111: 1105: 1098: 1068:rollback myself. 243: 63: 56: 55: 33: 32: 26: 3315: 3314: 3310: 3309: 3308: 3306: 3305: 3304: 3277: 3248: 3199: 3143: 2976: 2933: 2926: 2883: 2879: 2855: 2796: 2714: 2575: 2519:I just had the 2494: 2425: 2375: 2304: 2298: 2291: 2197: 2179: 2173: 2168: 2109: 2103: 2076: 2070: 1850: 1827: 1787: 1757: 1728: 1720: 1718:Warning Notices 1663: 1618: 1445:Just saying... 1442:so does Huggle 1423: 1401: 1395: 1388: 1385: 1347: 1341: 1334: 1331: 1295: 1289: 1282: 1279: 1202: 1196: 1189: 1186: 1137: 1131: 1124: 1121: 1109: 1103: 1096: 1093: 1090: 1088:Anonymous users 1031: 774: 469: 357: 237: 226: 135: 93: 59: 30: 22: 21: 20: 12: 11: 5: 3313: 3301: 3300: 3295: 3292: 3287: 3282: 3270: 3269: 3252: 3241: 3225: 3224: 3220: 3217: 3213: 3210: 3207: 3198: 3195: 3194: 3193: 3192: 3191: 3142: 3139: 3138: 3137: 3136: 3135: 3134: 3133: 3132: 3131: 3130: 3129: 3113: 3112: 3111: 3110: 3109: 3108: 3107: 3106: 3105: 3104: 3081: 3080: 3079: 3078: 3077: 3076: 3075: 3074: 3052: 3051: 3050: 3049: 3048: 3047: 3027: 3026: 3025: 3024: 3007: 3006: 3005: 3004: 2975: 2972: 2971: 2970: 2969: 2968: 2930: 2925: 2922: 2921: 2920: 2919: 2918: 2880: 2878: 2875: 2854: 2851: 2850: 2849: 2822: 2821: 2818: 2815: 2808: 2795: 2792: 2791: 2790: 2789: 2788: 2787: 2786: 2763: 2762: 2761: 2760: 2742: 2741: 2713: 2710: 2709: 2708: 2707: 2706: 2705: 2704: 2703: 2702: 2701: 2700: 2699: 2698: 2697: 2696: 2695: 2694: 2574: 2571: 2570: 2569: 2568: 2567: 2493: 2490: 2489: 2488: 2487: 2486: 2485: 2484: 2461: 2460: 2459: 2458: 2424: 2421: 2420: 2419: 2418: 2417: 2399: 2398: 2374: 2371: 2370: 2369: 2368: 2367: 2366: 2365: 2330: 2329: 2290: 2287: 2286: 2285: 2284: 2283: 2282: 2281: 2280: 2279: 2245: 2244: 2243: 2242: 2196: 2193: 2164: 2160: 2159: 2158: 2157: 2156: 2155: 2154: 2153: 2152: 2151: 2074: 2069: 2066: 2065: 2064: 2063: 2062: 2061: 2060: 2059: 2058: 2036: 2035: 2034: 2033: 2032: 2031: 2030: 2029: 2018: 2017: 2016: 2015: 2014: 2013: 1999: 1998: 1997: 1996: 1995: 1994: 1985: 1984: 1983: 1982: 1981: 1980: 1979: 1978: 1968: 1965:WP:edit filter 1958: 1944: 1943: 1942: 1941: 1940: 1939: 1930: 1929: 1928: 1927: 1926: 1925: 1913: 1912: 1911: 1910: 1909: 1908: 1875: 1874: 1868: 1849: 1846: 1845: 1844: 1843: 1842: 1841: 1840: 1839: 1838: 1837: 1836: 1835: 1834: 1823: 1764: 1719: 1716: 1715: 1714: 1713: 1712: 1680: 1679: 1676: 1673: 1670: 1662: 1659: 1658: 1657: 1656: 1655: 1617: 1614: 1613: 1612: 1611: 1610: 1609: 1608: 1607: 1606: 1588: 1587: 1586: 1585: 1584: 1583: 1570: 1566: 1557: 1556: 1555: 1554: 1553: 1552: 1549: 1546: 1543: 1540: 1537: 1534: 1531: 1528: 1524: 1521: 1518: 1515: 1512: 1509: 1505: 1501: 1492: 1491: 1490: 1489: 1471: 1470: 1469: 1468: 1440: 1439: 1430: 1429: 1422: 1419: 1418: 1417: 1416: 1415: 1414: 1413: 1412: 1411: 1410: 1409: 1360: 1359: 1358: 1357: 1356: 1355: 1323: 1322: 1321: 1320: 1276: 1275: 1274: 1273: 1272: 1271: 1270: 1269: 1268: 1267: 1243: 1242: 1241: 1240: 1239: 1238: 1237: 1236: 1215: 1214: 1213: 1212: 1211: 1210: 1177: 1176: 1175: 1174: 1156: 1155: 1154: 1153: 1146: 1145: 1089: 1086: 1085: 1084: 1071: 1070: 1069: 1065: 1062: 1030: 1027: 1026: 1025: 1024: 1023: 1022: 1021: 1020: 1019: 1018: 1017: 1016: 1015: 1014: 1013: 1012: 1011: 1010: 1009: 1008: 1007: 1006: 1005: 1004: 1003: 1002: 1001: 1000: 999: 953: 952: 951: 950: 949: 948: 947: 946: 945: 944: 943: 942: 941: 940: 939: 938: 937: 936: 935: 934: 933: 932: 931: 930: 929: 928: 899: 898: 897: 896: 895: 894: 893: 892: 891: 890: 889: 888: 887: 886: 885: 884: 883: 882: 881: 880: 879: 878: 877: 876: 829: 828: 827: 826: 825: 824: 823: 822: 821: 820: 819: 818: 817: 816: 815: 814: 813: 812: 811: 810: 809: 808: 771: 770: 769: 768: 767: 766: 765: 764: 763: 762: 761: 760: 759: 758: 757: 756: 755: 754: 753: 752: 751: 750: 749: 725: 724: 723: 722: 721: 720: 719: 718: 717: 716: 715: 714: 713: 712: 711: 710: 709: 708: 707: 706: 672: 671: 670: 669: 668: 667: 666: 665: 664: 663: 662: 661: 660: 659: 658: 657: 656: 655: 623: 622: 621: 620: 619: 618: 617: 616: 615: 614: 613: 612: 611: 610: 609: 608: 578: 577: 576: 575: 574: 573: 572: 571: 570: 569: 568: 567: 566: 565: 537: 536: 535: 534: 533: 532: 531: 530: 529: 528: 527: 526: 500: 499: 498: 497: 496: 495: 494: 493: 492: 491: 466: 465: 464: 463: 462: 461: 460: 459: 458: 457: 456: 444: 443: 442: 441: 440: 439: 438: 437: 415: 414: 413: 412: 411: 410: 391: 390: 389: 388: 354: 350: 349: 348: 347: 346: 345: 332: 331: 330: 327: 317: 316: 315: 314: 297: 296: 295: 294: 293: 292: 284: 275: 274: 273: 272: 246: 245: 234: 225: 222: 221: 220: 219: 218: 217: 216: 196: 195: 194: 193: 175: 174: 134: 131: 130: 129: 128: 127: 92: 89: 87: 83: 82: 77: 74: 69: 64: 52: 51: 34: 15: 9: 6: 4: 3: 2: 3312: 3299: 3296: 3293: 3291: 3288: 3286: 3283: 3280: 3276: 3275: 3267: 3263: 3259: 3258: 3253: 3246: 3245: 3242: 3239: 3238: 3234: 3230: 3229:West.andrew.g 3221: 3218: 3214: 3211: 3208: 3204: 3203: 3202: 3190: 3186: 3182: 3181:West.andrew.g 3178: 3174: 3173: 3172: 3171: 3170: 3169: 3165: 3161: 3160:West.andrew.g 3157: 3153: 3147: 3127: 3123: 3122: 3121: 3120: 3119: 3118: 3117: 3116: 3115: 3114: 3103: 3099: 3095: 3094:West.andrew.g 3091: 3090: 3089: 3088: 3087: 3086: 3085: 3084: 3083: 3082: 3073: 3069: 3065: 3060: 3059: 3058: 3057: 3056: 3055: 3054: 3053: 3046: 3042: 3038: 3033: 3032: 3031: 3030: 3029: 3028: 3023: 3019: 3015: 3014:West.andrew.g 3011: 3010: 3009: 3008: 3001: 3000: 2999: 2998: 2997: 2996: 2992: 2988: 2982: 2979: 2967: 2963: 2959: 2958:West.andrew.g 2954: 2953: 2952: 2951: 2950: 2949: 2945: 2941: 2937: 2929: 2917: 2913: 2909: 2908:West.andrew.g 2905: 2904: 2903: 2902: 2901: 2900: 2896: 2892: 2888: 2874: 2873: 2869: 2865: 2864:West.andrew.g 2859: 2848: 2845: 2843: 2839: 2838: 2837: 2836: 2832: 2828: 2827:West.andrew.g 2819: 2816: 2813: 2809: 2805: 2801: 2800: 2799: 2785: 2781: 2777: 2776:West.andrew.g 2773: 2769: 2768: 2767: 2766: 2765: 2764: 2759: 2755: 2751: 2750:West.andrew.g 2746: 2745: 2744: 2743: 2740: 2736: 2732: 2728: 2727: 2726: 2725: 2722: 2720: 2693: 2689: 2685: 2684:West.andrew.g 2681: 2677: 2676: 2675: 2671: 2667: 2666:69.142.154.10 2664: 2659: 2658: 2657: 2653: 2649: 2644: 2643: 2642: 2639: 2637: 2633: 2632: 2631: 2627: 2623: 2618: 2617: 2616: 2614: 2609: 2608: 2607: 2603: 2599: 2598:West.andrew.g 2594: 2593: 2592: 2591: 2590: 2589: 2586: 2584: 2580: 2566: 2562: 2558: 2557:West.andrew.g 2553: 2552: 2551: 2550: 2549: 2548: 2544: 2540: 2535: 2534: 2530: 2526: 2522: 2517: 2516: 2512: 2508: 2504: 2499: 2483: 2479: 2475: 2474:West.andrew.g 2471: 2467: 2466: 2465: 2464: 2463: 2462: 2457: 2453: 2449: 2448:West.andrew.g 2444: 2443: 2442: 2441: 2440: 2439: 2435: 2431: 2423:Need rollback 2416: 2412: 2408: 2407:West.andrew.g 2403: 2402: 2401: 2400: 2397: 2394: 2392: 2388: 2387: 2386: 2385: 2382: 2380: 2364: 2360: 2356: 2353: 2349: 2348: 2347: 2343: 2339: 2338:West.andrew.g 2334: 2333: 2332: 2331: 2328: 2324: 2320: 2314: 2313: 2312: 2311: 2307: 2301: 2295: 2278: 2274: 2270: 2266: 2265: 2264: 2260: 2256: 2255:West.andrew.g 2251: 2250: 2249: 2248: 2247: 2246: 2241: 2237: 2233: 2229: 2228: 2227: 2223: 2219: 2214: 2213: 2212: 2211: 2207: 2203: 2192: 2191: 2186: 2182: 2176: 2163: 2150: 2146: 2142: 2141:West.andrew.g 2138: 2137: 2136: 2132: 2128: 2127:West.andrew.g 2123: 2122: 2121: 2116: 2112: 2106: 2098: 2097: 2096: 2092: 2088: 2087:West.andrew.g 2083: 2082: 2081: 2080: 2079: 2073: 2057: 2053: 2049: 2048:West.andrew.g 2044: 2043: 2042: 2041: 2040: 2039: 2038: 2037: 2026: 2025: 2024: 2023: 2022: 2021: 2020: 2019: 2012: 2009: 2005: 2004: 2003: 2002: 2001: 2000: 1991: 1990: 1989: 1988: 1987: 1986: 1976: 1972: 1969: 1966: 1962: 1959: 1956: 1953: 1952: 1950: 1949: 1948: 1947: 1946: 1945: 1936: 1935: 1934: 1933: 1932: 1931: 1923: 1919: 1918: 1917: 1916: 1915: 1914: 1906: 1905: 1904: 1900: 1896: 1895:West.andrew.g 1892: 1891: 1890: 1889: 1888: 1887: 1883: 1879: 1873: 1869: 1867: 1863: 1862: 1861: 1857: 1853: 1833: 1830: 1824: 1822: 1818: 1814: 1810: 1809: 1808: 1804: 1800: 1799:West.andrew.g 1795: 1794: 1793: 1790: 1784: 1780: 1779: 1778: 1774: 1770: 1765: 1763: 1760: 1754: 1753: 1752: 1748: 1744: 1743:West.andrew.g 1739: 1738: 1737: 1736: 1735: 1734: 1731: 1725: 1711: 1707: 1703: 1702:West.andrew.g 1698: 1697: 1696: 1695: 1694: 1693: 1689: 1685: 1677: 1674: 1671: 1668: 1667: 1666: 1654: 1650: 1646: 1642: 1637: 1636: 1635: 1634: 1633: 1632: 1628: 1624: 1604: 1600: 1599:West.andrew.g 1596: 1595: 1594: 1593: 1592: 1591: 1590: 1589: 1582: 1578: 1574: 1571: 1567: 1563: 1562: 1561: 1560: 1559: 1558: 1550: 1547: 1544: 1541: 1538: 1535: 1532: 1529: 1525: 1522: 1519: 1516: 1513: 1510: 1506: 1502: 1498: 1497: 1496: 1495: 1494: 1493: 1488: 1484: 1480: 1479:West.andrew.g 1475: 1474: 1473: 1472: 1465: 1461: 1460: 1459: 1458: 1457: 1456: 1452: 1448: 1443: 1438: 1435: 1434: 1433: 1428: 1425: 1424: 1408: 1404: 1399: 1398: 1392: 1391: 1383: 1382: 1381: 1377: 1373: 1372:West.andrew.g 1368: 1367: 1366: 1365: 1364: 1363: 1362: 1361: 1354: 1350: 1345: 1344: 1338: 1337: 1329: 1328: 1327: 1326: 1325: 1324: 1319: 1315: 1311: 1310:West.andrew.g 1307: 1306: 1305: 1304: 1303: 1302: 1298: 1293: 1292: 1286: 1285: 1266: 1262: 1258: 1257:West.andrew.g 1253: 1252: 1251: 1250: 1249: 1248: 1247: 1246: 1245: 1244: 1235: 1231: 1227: 1223: 1222: 1221: 1220: 1219: 1218: 1217: 1216: 1209: 1205: 1200: 1199: 1193: 1192: 1183: 1182: 1181: 1180: 1179: 1178: 1173: 1169: 1165: 1164:West.andrew.g 1160: 1159: 1158: 1157: 1150: 1149: 1148: 1147: 1144: 1140: 1135: 1134: 1128: 1127: 1119: 1118: 1117: 1116: 1112: 1107: 1106: 1100: 1099: 1083: 1079: 1075: 1074:West.andrew.g 1072: 1066: 1063: 1059: 1058: 1056: 1055: 1054: 1053: 1049: 1045: 1039: 1036: 998: 994: 990: 989:West.andrew.g 985: 981: 980: 979: 978: 977: 976: 975: 974: 973: 972: 971: 970: 969: 968: 967: 966: 965: 964: 963: 962: 961: 960: 959: 958: 957: 956: 955: 954: 925: 924: 923: 922: 921: 920: 919: 918: 917: 916: 915: 914: 913: 912: 911: 910: 909: 908: 907: 906: 905: 904: 903: 902: 901: 900: 875: 871: 867: 866:West.andrew.g 862: 858: 853: 852: 851: 850: 849: 848: 847: 846: 845: 844: 843: 842: 841: 840: 839: 838: 837: 836: 835: 834: 833: 832: 831: 830: 807: 803: 799: 796: 795: 794: 793: 792: 791: 790: 789: 788: 787: 786: 785: 784: 783: 782: 781: 780: 779: 778: 777: 776: 775: 747: 746: 745: 744: 743: 742: 741: 740: 739: 738: 737: 736: 735: 734: 733: 732: 731: 730: 729: 728: 727: 726: 705: 701: 697: 696:West.andrew.g 692: 691: 690: 689: 688: 687: 686: 685: 684: 683: 682: 681: 680: 679: 678: 677: 676: 675: 674: 673: 654: 650: 646: 641: 640: 639: 638: 637: 636: 635: 634: 633: 632: 631: 630: 629: 628: 627: 626: 625: 624: 607: 603: 599: 598:West.andrew.g 594: 593: 592: 591: 590: 589: 588: 587: 586: 585: 584: 583: 582: 581: 580: 579: 564: 560: 556: 551: 550: 549: 548: 547: 546: 545: 544: 543: 542: 541: 540: 539: 538: 525: 521: 517: 516:West.andrew.g 512: 511: 510: 509: 508: 507: 506: 505: 504: 503: 502: 501: 490: 486: 482: 479: 478: 477: 476: 475: 474: 473: 472: 471: 470: 454: 453: 452: 451: 450: 449: 448: 447: 446: 445: 436: 432: 428: 427:West.andrew.g 423: 422: 421: 420: 419: 418: 417: 416: 409: 405: 401: 397: 396: 395: 394: 393: 392: 387: 383: 379: 378:West.andrew.g 374: 373: 372: 371: 370: 369: 365: 361: 353: 344: 340: 336: 333: 328: 325: 324: 323: 322: 321: 320: 319: 318: 313: 309: 305: 304:West.andrew.g 301: 300: 299: 298: 290: 285: 281: 280: 279: 278: 277: 276: 270: 269: 268: 267: 266: 265: 261: 257: 252: 250: 244:all the time. 241: 235: 231: 230: 229: 215: 211: 207: 206:West.andrew.g 202: 201: 200: 199: 198: 197: 192: 188: 184: 179: 178: 177: 176: 173: 169: 165: 164:West.andrew.g 161: 156: 152: 151: 150: 149: 145: 141: 126: 122: 118: 117:West.andrew.g 114: 113: 112: 111: 110: 109: 105: 101: 97: 88: 81: 78: 75: 73: 70: 68: 65: 62: 58: 57: 49: 45: 41: 40: 35: 28: 27: 19: 3278: 3261: 3255: 3240: 3226: 3200: 3148: 3144: 2983: 2980: 2977: 2940:Congratulate 2934: 2927: 2891:Congratulate 2884: 2860: 2856: 2823: 2797: 2731:UncleDouggie 2715: 2648:UncleDouggie 2622:UncleDouggie 2576: 2573:Minor edits? 2539:UncleDouggie 2536: 2525:UncleDouggie 2518: 2507:UncleDouggie 2495: 2430:UncleDouggie 2426: 2376: 2292: 2269:UncleDouggie 2232:UncleDouggie 2202:UncleDouggie 2198: 2169: 2161: 2077: 2071: 1921: 1876: 1858: 1854: 1851: 1721: 1681: 1664: 1623:71.62.41.187 1619: 1463: 1444: 1441: 1436: 1431: 1426: 1394: 1387: 1340: 1333: 1288: 1281: 1277: 1195: 1188: 1130: 1123: 1102: 1095: 1091: 1040: 1034: 1032: 983: 860: 856: 358: 351: 253: 248: 247: 227: 159: 136: 94: 86: 60: 43: 37: 3254:This is an 2373:Stiki down? 2218:Ottawa4ever 1870:Full Cite: 1755:Okay :). - 1645:Ottawa4ever 1226:168.9.25.23 1044:Ottawa4ever 224:My feedback 183:Ottawa4ever 140:prashanthns 133:A bit slow? 36:This is an 2944:Complaints 2895:Complaints 2774:. Thanks, 2682:. Thanks, 2472:. Thanks, 2289:Bug report 1033:Ive given 643:anything? 160:how latent 155:STiki page 3298:Archive 5 3290:Archive 3 3285:Archive 2 3279:Archive 1 3156:WikiTrust 2498:this edit 1464:excellent 80:Archive 5 72:Archive 3 67:Archive 2 61:Archive 1 3227:Thanks, 2812:WP:MINOR 2804:Rollback 2006:Cheers, 3257:archive 3154:" and " 3152:Cluebot 3062:again, 2842:Arthena 2719:Arthena 2636:Arthena 2613:Arthena 2583:Arthena 2505:edit. — 2391:Arthena 2379:Arthena 2299:Ryūlóng 1922:working 1828:EdoDodo 1788:EdoDodo 1758:EdoDodo 1729:EdoDodo 1621:Days!-- 39:archive 3064:Ocaasi 3037:Ocaasi 2987:Ocaasi 2936:930913 2887:930913 2840:Nice! 2663:Ocaasi 2355:Ocaasi 2350:Sure, 2319:Ocaasi 2008:Ocaasi 1993:faces. 1975:Huggle 1961:Werdna 1878:Ocaasi 1864:News: 1813:Triona 1769:Triona 1684:Triona 982:A big 181:speed. 3177:STiki 2924:Bug 2 2183:) · 2113:) · 1971:Gurch 1955:RobLa 1724:STiki 1573:Gurch 1508:will: 1447:Gurch 1396:comms 1389:fetch 1342:comms 1335:fetch 1290:comms 1283:fetch 1197:comms 1190:fetch 1132:comms 1125:fetch 1104:comms 1097:fetch 1035:STiki 927:(UTC) 798:Svick 645:Svick 555:Svick 481:Svick 400:Svick 360:Svick 335:Svick 256:Svick 240:uw-v2 100:Svick 16:< 3233:talk 3185:talk 3164:talk 3098:talk 3068:talk 3041:talk 3018:talk 2991:talk 2962:talk 2912:talk 2868:talk 2831:talk 2810:Per 2780:talk 2754:talk 2735:talk 2688:talk 2670:talk 2652:talk 2626:talk 2602:talk 2561:talk 2543:talk 2529:talk 2511:talk 2478:talk 2452:talk 2434:talk 2411:talk 2359:talk 2342:talk 2323:talk 2273:talk 2259:talk 2236:talk 2222:talk 2206:talk 2185:@705 2180:talk 2145:talk 2131:talk 2115:@704 2110:talk 2091:talk 2052:talk 1899:talk 1882:talk 1817:talk 1803:talk 1773:talk 1747:talk 1706:talk 1688:talk 1649:talk 1627:talk 1603:talk 1577:talk 1483:talk 1451:talk 1376:talk 1314:talk 1261:talk 1230:talk 1168:talk 1078:talk 1048:talk 993:talk 984:whew 870:talk 857:hope 802:talk 700:talk 649:talk 602:talk 559:talk 520:talk 485:talk 431:talk 404:talk 382:talk 364:talk 339:talk 308:talk 260:talk 210:talk 187:talk 168:talk 144:talk 121:talk 104:talk 2877:Bug 2316:--> 2166:--> 1783:AWB 289:AIV 3294:→ 3235:) 3187:) 3166:) 3100:) 3070:) 3043:) 3020:) 2993:) 2964:) 2946:) 2914:) 2897:) 2870:) 2833:) 2782:) 2756:) 2737:) 2690:) 2672:) 2654:) 2628:) 2604:) 2563:) 2545:) 2531:) 2513:) 2480:) 2454:) 2436:) 2413:) 2361:) 2344:) 2325:) 2308:) 2305:竜龙 2275:) 2261:) 2238:) 2224:) 2208:) 2187:· 2177:· 2174:X! 2147:) 2133:) 2117:· 2107:· 2104:X! 2093:) 2054:) 1901:) 1884:) 1819:) 1805:) 1775:) 1749:) 1708:) 1690:) 1651:) 1643:. 1629:) 1579:) 1485:) 1453:) 1378:) 1316:) 1263:) 1232:) 1170:) 1080:) 1050:) 995:) 872:) 804:) 702:) 651:) 604:) 561:) 522:) 487:) 433:) 406:) 384:) 366:) 341:) 310:) 262:) 242:}} 238:{{ 212:) 189:) 170:) 146:) 123:) 106:) 76:→ 3268:. 3231:( 3183:( 3162:( 3150:" 3096:( 3066:( 3039:( 3016:( 2989:( 2960:( 2942:/ 2938:( 2910:( 2893:/ 2889:( 2866:( 2829:( 2778:( 2752:( 2733:( 2686:( 2668:( 2650:( 2646:— 2624:( 2600:( 2559:( 2541:( 2527:( 2509:( 2476:( 2450:( 2432:( 2409:( 2357:( 2340:( 2321:( 2302:( 2271:( 2257:( 2234:( 2220:( 2204:( 2171:( 2143:( 2129:( 2101:( 2089:( 2050:( 1897:( 1880:( 1815:( 1801:( 1771:( 1745:( 1704:( 1686:( 1647:( 1625:( 1605:) 1601:( 1575:( 1481:( 1449:( 1402:☛ 1374:( 1348:☛ 1312:( 1296:☛ 1259:( 1228:( 1203:☛ 1166:( 1138:☛ 1110:☛ 1076:( 1046:( 991:( 868:( 800:( 698:( 647:( 600:( 557:( 518:( 483:( 429:( 402:( 380:( 362:( 337:( 306:( 258:( 208:( 185:( 166:( 142:( 119:( 102:( 50:.

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Knowledge

talk:STiki/Archive 1 - Knowledge

Index