Wikipedia talk:STiki/Archive 5

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

Archive 1

←

Archive 3

→

SD5bot edit (changing template) seen in STiki queue

I'm seeing a SD5bot edit (485184267 for Thomas Veazey) showing up in the STiki queue. I've taken a look at the STiki source, and while I know Perl, not Java, I can't offhand see any problem with edit_process_thread's should_queue function. About all I can think of is that this is an old insertion into the queue, from before whenever should_queue was put in. I've also been seeing a number of instances of such from the CBNG queue (I hadn't realized that these shouldn't be showing up until I looked at the source), perhaps also from old insertions. Allens (talk | contribs) 06:23, 29 April 2012 (UTC)

Hmmm... This edit...

That's from 2012-04-02.

If you were on the CBNG queue, that would fit with your theory that it was enqueued and then not removed from the queue because bots weren't removed from that until 2012-04-12.

However, I think bots were stopped from entering the STiki queue in August 2011. See User talk:West.andrew.g/TalkArchive04#STiki queues edits from approved bots?

Yaris678 (talk) 12:18, 29 April 2012 (UTC)

The CHANGELOG.txt file agrees with you; good point - I'll keep an eye out for when the CBNG ones are from. (BTW, it isn't going off of the "bot" "permission" directly, but instead from having "bot" in their names, which should be limited to only approved bots and similar. The same is true of not entering bot edits into the CBNG queue. I don't see anything filtering out bot edits from the WikiTrust queue currently.) Allens (talk | contribs) 13:00, 29 April 2012 (UTC)

please look into this, even i am fed up of marking bots as innocent, regards-- ÐℬigXЯaɣ 14:29, 29 April 2012 (UTC)

Gosh. That's not the greatest way to detect a bot. It's obviously open to abuse by vandals (although how far such an account would actually get is another matter).

For the benefit of Andrew, does anyone know a good way to extract a user's permissions from the Wikipedia API? A clunky way would be to regex a page like this CBNG example.

In terms of the current issue. Could it be something as simple as case sensitivity on the word "bot"? I'm afraid I don't know which bit of the code you are looking at and I've never looked at it before.

Yaris678 (talk) 21:19, 29 April 2012 (UTC)

Regarding the user permissions, http://en.wikipedia.org/w/api.php?action=query&list=allusers&augroup=bot&aulimit=500 will give you the first 500, and adding &austart=R will give you the rest. Putting such a list into the STiki backend database then loading it into the program should not be too terribly difficult - I'd produce a patch myself if I knew Java. I am not, however, sure if this is actually necessary - the account creation software may well prevent anyone without a "bot" flag from creating an account with "bot" as part of the username.

Regarding the case sensitivity, it converts the username to uppercase before the comparison. Allens (talk | contribs) 00:02, 30 April 2012 (UTC)

Greetings. First, it seems that the "bot" edit in question got in the queue before the rule was written, so I won't consider this a bug. Moreover, the queue tables in the DB are done with numerical identifiers, so its not as if I can just run a "DELETE... WHERE EDITOR LIKE '%BOT%' query to kick them all out. Second, I am well aware that just regex-ing for "*bot*" in a username is not the most robust way to determine permissions. I was following from the logic of Allens last post. I am pretty sure there is a "new account patrol" or "username patrol" or something of the sort that has some edit-filter-like rules to detect obvious violations of username policy (including having "bot" in a username without the bot-flag). I just thought I'd let the burden fall on that group. This little shortcut saves STiki millions and millions of API queries a month (or the pain of setting up some type of local cache). Thanks, West.andrew.g (talk) 16:26, 1 May 2012 (UTC)

Erm. It appears that my logic above was incorrect. See Wikipedia:Administrators' noticeboard/IncidentArchive747#Niabot_block_review. Sorry... Allens (talk | contribs) 05:47, 8 May 2012 (UTC)

This situation can be solved in a couple of ways:

The most important bots - the anti-vandal bots, ImageRemovalBot, SD5bot, and any others that people can suggest - can be hardwired in as OK.
For the remainder, the possibility of an edit being by an authorized bot may be checked for in a couple of ways - note that neither is necessary if the username doesn't match "BOT"!

If rvprop=flags will give whether or not the "bot" flag was in use, then it can be used for most bots. Anti-vandalism bots tend to operate without this flag but (as with users reverting vandalism) with the minor edit flag, however; this makes it particularly important to whitelist the anti-vandal bots.
If it doesn't, then an API query (or a local cache) will be necessary.

Allens (talk | contribs) 01:47, 9 May 2012 (UTC)

Niabot... good find by Allens.

Yes. I think having a local list of bots on the STiki server is the best way. This can be updated using the API call once per day (or a different frequency). This means that you don't need the millions and millions of API queries a month that Andrew is worried about.

Yaris678 (talk) 11:37, 9 May 2012 (UTC)

Bug in gui_support/gui_fb_handler.java:submit_agf

In gui_support/gui_fb_handler.java's submit_agf function, the following is in error:

		} catch(CommunicationsException e){
			parent.reset_connection(false);
			submit_vandalism(); // If con failure - reconnect - reattempt

It should be "submit_agf", not "submit_vandalism". Hopefully, this won't have caused any problems aside from some errors in the database, since the old gui_revert_and_warn should have already taken care of reverting the edit. Allens (talk | contribs) 19:06, 29 April 2012 (UTC)

Thanks, fixed the error in my local copy and will roll out with the next release. Yes, this isn't code that I imagined gets called much (if ever). Despite lots of error-catching code in place for CommunicationsExceptions, I am not sure how often the client is actually successful in recovering from one (I think there is a dialogue message popped if it successfully happens). Thanks, West.andrew.g (talk) 16:32, 1 May 2012 (UTC)

ACK, fixed in the 2012_05_22 release. Matter now closed. West.andrew.g (talk) 00:50, 22 May 2012 (UTC)

Recommendation to STiki users: WikiEdDiff and/or Schnark's variant thereof

I'd like to recommend that all STiki users use wikEdDiff. The easiest way is by ticking the box in "Gadgets" tab of "my preferences".

An excellent example of why it is useful is this edit, which STiki served me. The edit confused the standard MediaWiki diff (and the diff browser in STiki, which I assume is also based on solving the Longest common subsequence problem). This makes it hard to decide if there has been vandalism or not.

wikEdDiff displays this diff in a much more helpful way so I was able to see that there was no vandalism.

Users may also be interested in a variant developed by Schnark, which is described at De:Benutzer:Schnark/js/diff/core.

Yaris678 (talk) 22:22, 29 April 2012 (UTC)

I have had WikEd checked since April 12. That is the same isn't it? The result is well worth having. -- Gareth Griffith-Jones (talk) 22:38, 29 April 2012 (UTC)

wikEd includes wikEdDiff. Have you seen the diff aspects of it though? When looking at a diff, click on the Δ icon underneath it. It took me a while to realise the button was there! Yaris678 (talk) 22:50, 29 April 2012 (UTC)

Yes, I have been using that symbol since April 12 ... it's excellent. -- Gareth Griffith-Jones (talk) 06:33, 30 April 2012 (UTC)

Two things:

STiki actually simply takes the HTML of the standard MediaWiki diff and edits it to make it usable in the Java window (including adding external links if desired); it doesn't do a separate diff.
How does one substitute Schnark's variant for that used by wikEdDiff?

Allens (talk | contribs) 01:57, 30 April 2012 (UTC)

Interesting:

If the displaying of diffs is based on reading it from MediaWiki html, it should be quite straight forward to display a wikEdDiff or Schnark's diff in the STiki GUI. That would be awesome.
To use Schnark's diff (in the normal wiki interface), put
```
mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:Schnark/js/diff.js&action=raw&ctype=text/javascript');
```
into your common.js. Schnark's diff is then accessed using tabs that appear above and below the diff. This means you can look at wikEdDiff and Schnark's varient and the same time (if you really want to). The last tab in Schnark's diff gives you some parameters you can tweak. These are described further at De:Benutzer:Schnark/js/diff/core.

Yaris678 (talk) 07:53, 30 April 2012 (UTC)

I haven't done enough investigation with these other diff algorithms to really speak about them. However, I can confirm that STiki does use the diff provided by the Mediawiki API, which is HTML and CSS markup. The Java object which handles the diff browser (an "HTMLPane" or something of the sort) cannot handle things like CSS, so some modifications are made to "simplify" the API diff into very basic HTML. On top of this, some logic is added for line-breaks. Is there a way to query for these modified diffs? Thanks, West.andrew.g (talk) 16:40, 1 May 2012 (UTC)

Since both Cacycle's and my diff are implemented in JavaScript there is no direct way to access them via an external application. So the only way to use an alternative diff in STiki is to re-implement one of the diffs in Java. The code for the diff algorithm is at User:Cacycle/diff.js or de:Benutzer:Schnark/js/diff.js/core.js. --Schnark (talk) 07:20, 8 May 2012 (UTC)

OK. Looks like its not quite as simple as I thought... But if Andrew could get Schnark's code working from inside STiki that would be cool. In the mean time, I recommend everyone accesses it the normal way and clicks on the "wiki-diff" link to see the diff in their web browser. Yaris678 (talk) 12:06, 9 May 2012 (UTC)

Should I use mass rollback on this user?

Joey836 [ http://en.wikipedia.org/wiki/Special:Contributions/Joey836] Seemed to go rather edit manic, should I use mass rollback because by chance, some of these edits were vandalism? Willdude123|Ƹ21ɘbublliW (talk) 18:03, 1 May 2012 (UTC)

Umm... why? Sure, it looks like this user was moving pretty quick through classifications, but not terribly so. I picked out 5 or so reverts at random, and all of them were pretty legitimate cases of vandalism. What evidence of wrongdoing do you have? Checking his user-talk, the user only got one warning for templating a regular (which isn't terrible considering his quantity of reverts). Also, mass rollback is going to be pretty worthless, given that the user hasn't edited in over a month's time and there will be plentiful intermediate edits on articles. Thanks, West.andrew.g (talk) 19:12, 1 May 2012 (UTC)

Good point! Willdude123|Ƹ21ɘbublliW (talk) 19:19, 1 May 2012 (UTC)

STiki-athon!

To promote usage of the tool, we could have an annual STiki-athon where the person who fights the most vandalism in one day wins! If you think it is a rubbish idea then say.Willdude123|Ƹ21ɘbublliW (talk) 12:47, 7 May 2012 (UTC)

I'm open to discussion on this, but I have my doubts. Foremost, the idea of a "race" could have ill consequences. If someone classifies so quickly that they make mistakes, this is not a good reflection on the tool. Such a mindset could also cause one to pass on edits that require "extra work" and just target the easily vandalism, leaving behind damage. Secondly, I'd rather see this amount of workload distributed over multiple days. If a competition classifies many-thousand edits over the course of several hours, those users will be deep in the queue and getting a low vandalism hit-rate. Spread that same effort over several days and the net-gain (in terms of vandalism percentage) would be much higher. I think the milestone barnstars are a good step towards rewarding loyal users. Your suggestion of "usage drives" is solid, but needs some refining, and maybe some rules if it is to become reality. Thanks, West.andrew.g (talk) 14:04, 7 May 2012 (UTC)

I feel it's very important to distinguish been a "good faith" revert and a vandalism revert. If I'm correct, warnings are not distributed for GF reverts? If so, then the tool good be ill-used in order to garner extra edits in a competitive environment. Orphan Wiki (talk) 14:41, 7 May 2012 (UTC)

Maybe a monthly STiki drive.Willdude123|Ƹ21ɘbublliW (talk) 16:00, 7 May 2012 (UTC)

strong oppose because STiki is not a competition and Andrew's comment above. Such a thing will do more harm to the wikiproject than good. We already have Milestones for such felicitation -- ÐℬigXЯaɣ 16:16, 7 May 2012 (UTC)
Support to promote the use of Stiki. We should also have awards for the top 3.--Deathlaser : Chat 15:56, 11 May 2012 (UTC)
Oppose - per my comment above. Orphan Wiki (talk) 21:20, 11 May 2012 (UTC)
Oppose 1. It will cause a lot of rubbish reverts and 2. It will turn into a full on scramble if several thousand people were unleashed onto the limited number of vandalism available. God knows what will happen if hundreds of people clicked on revert at exactly the same time... P0150neD r1Ce asian 02:46, 13 May 2012 (UTC)
Comment - Having a leaderboard is already a little bit competitive... but in a much more manageable way. If we were to go any more competitive, then we'd definitely need some kind of peer checking system. I'm sure we could design such a system... perhaps based on my idea... whether Andrew would want to / have time to program such a system is another question. Yaris678 (talk) 15:30, 15 May 2012 (UTC)

Blank non-rollback diff

Diff 492685257 (for the article Jim Saleam) shows up as completely blank, and it is not marked as a rollback situation (as in, it isn't a self-revert, as far as I can tell). Wiki-DIFF does show up changes, although it also indicates that it was already reverted. I suspect the reversion happened between the time the STiki server picked up the diff and it sent the diff to my client, with the client code fetching the old page and a current version of the page instead of the actual next revision. Allens (talk | contribs) 13:08, 15 May 2012 (UTC)

Hmm. I don't compute the diff, I fetch it directly from the API by providing the RID I want the "current page" diff'ed against. This is done after a confirmation that the "current page" is still the one the vandalism score was computed for. If a revert slips in between these two API calls it might cause the issue you describe. This also indicates you were classifying pretty fast. Display information is built/cached ~10 edits ahead of where you are working. However, once every 30 secs. or a minute, I scan through the local cache and ensure that no page has been edited while in cache. Seemingly you also evaded that check. Inevitably, someone will ask "why not do the check immediately before the edit is displayed to a user?" Because that is the last place you want the latency of an API call to slow edit advancement.

Unless this becomes something frequent, I am not going to worry about it. Now that I think about it, replication lag between WMF servers could be another possible explanation (which I think people at Village Pump have been reporting values > 1000 seconds recently). Thanks, West.andrew.g (talk) 14:56, 15 May 2012 (UTC)

Oh, right (regarding not computing diffs locally), now I remember. Whoops! (In terms of classifying quickly, I read at something over 1000 words a minute.) Just a bit ago, I was seeing a high replication lag for watchlist updates, so that may well be it. Allens (talk | contribs) 15:18, 15 May 2012 (UTC)

Text selection/copying

It would be really useful to be able to select text from the diff and copy it to the clipboard. Unless I'm being extremely thick, this doesn't seem possible at present. Is it possible to add this functionality? Jakew (talk) 11:25, 16 May 2012 (UTC)

Hi Jakew,

This one has come up before. Andrew decided to make the text non-selectable because he had to add invisible characters to it to make it work with the Java HTML pane that he is using.

Andrew,

Would it be doable to render the HTML using different out-of-the box code? A Google search throws up a few things that look interesting... but I don't know enough details to know what would work for you. [The DJ Project looks promising.

Yaris678 (talk) 12:30, 16 May 2012 (UTC)

Hi guys. I don't think the problem here is with Java's HTMLPane implementation, as this is an issue most browsers face. That pane can have copy-paste functionality, I have just explicitly turned it off due my inclusion of Zero White Space (ZWS) characters. Essentially, wiki markup can have some very long tokens, i.e., external URLs, wikilinks pointing to particular sections, some templates, etc. If naively dumped into the diff browser, these would result in a horizontal scrollbars being displayed in the worst case, and hideous justification in most cases. Thus, my code inserts ZWS white space characters in long tokens. These say, "hey, you can break the token/line here if you have to, but if you don't use that break, then don't display anything." While not visible to a human user, those characters are still "there", and show up when copy-paste actions are performed, i.e., copy-pasting a long token like "electroencephalograph" might turn into "elect#roenceph#alograph." This was my motivation in turning off copy-paste (and enabling metadata fields to be copy-pastable).

However, I must admit this even bugs me at times. I think the solution might be to leave the ZWS characters in place and then manipulate how clipboard actions work (filter out any ZWS characters whenever a copy action is performed). I've assigned this ticket T#012 in the table up top and will investigate shortly and hopefully have a solution at the next release. Thanks, West.andrew.g (talk) 15:34, 16 May 2012 (UTC)

Thank you both for your helpful explanations. I'll look forward to the next rev. Jakew (talk) 17:16, 16 May 2012 (UTC)

This feature request was included in the 2012_05_22 release. Now closed. Thanks, West.andrew.g (talk) 00:51, 22 May 2012 (UTC)

Advertisment

I have created an advertisment for STiki here: User Talk:W.D. 15:54, 17 May 2012 (UTC)

Hmmm... I'm generally against adverts... especially ones that change... although your one does have the redeeming feature of humour.

Can you reduce the frame rate? I don't get time to read one thing before it goes on to the next.

Yaris678 (talk) 17:11, 17 May 2012 (UTC)

I'll have more time to comment on this later, but @Yaris, see: Template:Wikipedia_ads#Current_ads. A lot of them are quite busy. There is some way to add your own ad (i.e., a STiki advert) to this category and it becomes part of a rotation that is randomly displayed for those who choose to add the advert template to their user (talk) page. Thanks, West.andrew.g (talk) 19:34, 17 May 2012 (UTC)

Also W.D., I should say thanks and that I appreciate the effort. My most immediate comment is that the "stop asking rhetorical questions" frame doesn't really transmit any information to the reader. The biggest battle the tool probably faces is "well... why not use Huggle?". I wonder if a frame or two might be more effective if they addressed "comparison of STiki with other tools" aspects, i.e., reservation system, intelligent routing, score memory, etc. Thanks, West.andrew.g (talk) 19:38, 17 May 2012 (UTC)

I presume it cannot be defamatory to Huggle.User Talk:W.D. 20:20, 17 May 2012 (UTC)

I think there are probably more polite ways to go about it than calling Huggle out directly. Large portions of the "comparison to other tools" section on the main STiki page are implicit digs at Huggle and the other tools (all in good competition, of course). A statement like "Tired of getting beaten to reverts?" is not inappropriate, IMO. Thanks, West.andrew.g (talk) 00:57, 18 May 2012 (UTC)

I agree, lets simply replace the line "stop asking rhetorical questions" with "Tired of getting beaten to reverts? " as this makes perfect sense, It is not defamatory to any other tool, in fact, this line "beaten to revert" ironically is used in Stiki, but it happens very rarely with Stiki and hapens very frequently with other tools. In fact this is one of the main reasons why I love STiki so much. -- ÐℬigXЯaɣ 06:20, 18 May 2012 (UTC)

I note the reduced frame rate. Thanks.

I like the point about being beaten to the revert. How about this as a user box?

User Box

Code

Because of STiki, this user is seldom beaten to the revert.

|| {{User:Yaris678/STiki UserBox 2}}

Yaris678 (talk) 06:59, 18 May 2012 (UTC)

I am a big fan of this one! It will get the standard treatment and be up on the main page within the day (ugh, its going to be a long one). Thanks, West.andrew.g (talk) 14:24, 18 May 2012 (UTC)

Thanks.

Would you prefer "beat" to "beaten". I know Americans say "beat"... but I don't know if that is seen as colloquialism or standard English. I could always parameterise the choice!

Yaris678 (talk) 14:31, 18 May 2012 (UTC)

I'm American, and I think "beaten" sounds more appropriate. Anyone picky enough to care about such things can easily copy the template to their userspace and make the trivial change. Thanks, West.andrew.g (talk) 14:39, 18 May 2012 (UTC)

Cool. "Beaten" it is. Yaris678 (talk) 16:11, 18 May 2012 (UTC)

Replaced Rhetorical questions slide.81.178.188.181 (talk) 19:11, 18 May 2012 (UTC)

Oops! I wasn't logged in then.User Talk:W.D. 19:30, 18 May 2012 (UTC)

Neat. A couple of questions. 1. How do we get this into the Wikipedia adverts rotation? 2. At minimum, we need to turn the image into a link to the WP:STiki page, rather than the image file. 3. Perhaps a template is best for this purpose? 4. Other than possible inclusion in the rotation, how can we use it? Thanks, West.andrew.g (talk) 19:38, 18 May 2012 (UTC)

looks cool, I like the inherent relationship between STiki, stick (both the wooden stick and sticking on the wall), and Beat/beaten

-- ÐℬigXЯaɣ 19:41, 18 May 2012 (UTC)

I think it is already in the rotation. If it is displayed on the Wikipedia Ads template then it links to STiki User Talk:W.D. 07:43, 19 May 2012 (UTC)

Nice! I've also added the hard-coded template (that pointing only to the STiki advert) to the main STiki page so others can show support if they wan. Thanks for your contribution. West.andrew.g (talk) 14:11, 19 May 2012 (UTC)

Keyboard Shortcuts

I may be simply missing something, but are there keyboard shortcuts available for STiki? I've found them very useful when using Huggle, etc. C_(u)w_(t)C_(c) 01:17, 18 May 2012 (UTC)

After a single edit has been classified with the mouse (thereby giving the button panel "focus"), the keys "V", "G", "P", and "I" will mark edits as "vandalism", "good-faith", "pass" and "innocent" respectively. While in the same mode, the PG_UP, PG_DOWN, UP_ARROW, and DOWN_ARROW keys will also scroll the diff browser. Thanks, West.andrew.g (talk) 02:15, 18 May 2012 (UTC)

yes, I guess a lot of new users don't know this (including me, until Andrew informed me in my early days with stiki), So this makes a strong case to include the shortcuts in the Wikipedia:STiki#Using_STiki section.-- ÐℬigXЯaɣ 06:13, 18 May 2012 (UTC)

Good point, I feel I've written it out a couple of times in talk-page history, as well. Would one of my friendly talk page watchers like to take on this task? I know I move about 10x quicker when using shortcuts vs. the mouse. Thanks, West.andrew.g (talk) 14:19, 18 May 2012 (UTC)

I've put it in; not sure if it's in the best place. Allens (talk | contribs) 14:52, 18 May 2012 (UTC)

Yeah, I liked the content, but felt it was a bit buried by going in the image caption. I reorganized things a bit into an explicit "interface" section. When I implement your "redlinks" feature request, I plan to make it an option, so it can also be described in that same section. I still feel that section is about at its limit, though. Thanks, West.andrew.g (talk) 15:15, 18 May 2012 (UTC)

Feature Request

Would it be possible to include HTTPS support when connecting to the Wikipedia API? I would revert vandalism while at work, but I would prefer not to have my password floating around in corporate network logs. Thanks, and keep up the great work! C_(u)w_(t)C_(c) 11:46, 18 May 2012 (UTC)

Yes, this seems like a very good idea. I've filed it as T#013 in the tracking table up top. Barring any unexpected difficulty, this change should be expected in the next distribution. Thanks, West.andrew.g (talk) 14:32, 18 May 2012 (UTC)

Am I correct in my assumption that HTTPS is needed only for login actions? Thanks, West.andrew.g (talk) 05:00, 19 May 2012 (UTC)

If I'm correct, making only making the login actions use HTTPS would allow for Session Hijacking, but it'd still hide the password and other credentials. If possible, I'd consider letting the user decide which connection type they'd like to use, balancing speed and security. Thanks! C_(u)w_(t)C_(c) 11:46, 19 May 2012 (UTC)

Good point. Bug and feature table up top updated to reflect this. Thanks, West.andrew.g (talk) 13:56, 19 May 2012 (UTC)

Included in this evening's release. Matter now closed. Thanks, West.andrew.g (talk) 00:53, 22 May 2012 (UTC)

Other templates in gui_revert_and_warn.java's highest_warn_level

As well as checking for previous levels of uw-vandalism for the vandalism queues in highest_warn_level, it may be best to check for uw-test# and uw-delete# (and I can see uw-error#, uw-joke#, uw-notcensored#, uw-defamatory#, and uw-unsourcedBLP# as possibilities, although perhaps not for causing AIV postings - instead, do a uw-vandalism4 or 4im warning). Similarly, checking for uw-advert# for the link-spam queue may be preferable. Corresponding modifications to im_warn_present would be advisable, of course. Allens (talk | contribs) 15:23, 18 May 2012 (UTC)

Acknowledged! Though I'd imagine many of these rarely get used in practice, it may be nice to detect them and push a level higher using vandalism warnings. I need to stop with the talk page chatter for now, it's a busy office day and I have thesis writing to do! West.andrew.g (talk) 15:33, 18 May 2012 (UTC)

Understand on dissertation writing; luck! In regard to frequency of usage, I was looking specifically for ones used by Twinkle, which I figure are likely to be used more frequently. Uw-test# is also used by 28bot (as is uw-articlesig, for that matter).

STiki pitting vandal fighters against each other

I tried out STiki for the first time yesterday and after a few edits I was shown the diff of someone else's revert of obvious vandalism. I guess that seeing the vandalism (something about POO being the best food) distracted me from noticing that the vandalism had been reverted, so I reverted and ended up templating a good vandal fighter. After I realized my mistake I tried to repair it, but not before I got reverted and templated myself (by someone using STiki ironically). This was about 12 hours ago, and since then I've seen the same problem happen twice more, with a total of 5 vandal fighters being templated for vandalism. ([1], [2], [3], [4], [5].)

My first question is: does such a thing happen often (STiki flagging reverts of vandalism as vandalism)? My second question is: is there a way to opt out of receiving edits performed by established users who have, say, more than X edits? ~Adjwilley (talk) 16:58, 18 May 2012 (UTC)

Slightly related comment: A wonderful feature to have (IMO) would be if STiki showed the edit summary of the offending edit, along with the diff. ~Adjwilley (talk) 17:02, 18 May 2012 (UTC)

Hi Adjwilley,

I have been presented with a revert of vandalism, but only rarely.

The edit summary is shown on STiki at the bottom of the window, where it says "comment".

BTW, which queue were you using? I am guessing it was CluBot NG (the default). This does seem to occasionally pick up edits by experienced editors because it looks at the content of the edit rather than the history of the editor. Maybe there is an argument for filtering CBNGs results, e.g. with the Huggle white list. However, even if this were done, there would still be the chance of a good edit by a new editor showing up so the biggest thing to say is: be careful.

Also, you may like to try the STiki queue. Click on "Rev Queue" at the top and select "STiki (metadata)"

Yaris678 (talk) 18:29, 18 May 2012 (UTC)

AS yaris has already stated, the best and the most important thing is Revert Carefully so read the edit summary compare the diff, and try not to restore vandalism. being human, one can make mistake sometimes but if you are careful, this wont happen often. regards-- ÐℬigXЯaɣ 18:41, 18 May 2012 (UTC)

Hi Adjwilley and thanks for your use of the tool. Suffice to say, if the vandalism/damage resides on the left hand side of the diff presentation, then you should certainly give it a good look to see if it is a "revert" situation. Yaris was correct in pointing you to the revision comment. Be careful with your actions and don't get in too big of a hurry classifying edits.

We also need to distinguish between STiki (the GUI) and the backend algorithm/queue that determines what edits you are displayed. It is likely you were using a third-party queue called CBNG, (based on the logic of User:ClueBot_NG). Because of its third party nature, I do not modify the logic, and yes, this queue does have an unusual habit of displaying reverts (I would agree with Yaris that it is "rare"). If you go to the menu->"queue", you can change the prioritization logic. I administrate the "STiki (metadata)" queue, and have hard-coded rules against this sort of thing (but perhaps lower accuracy across the board).

Second, the tool does not have an explicit mechanism to filter by things like "edit count". However, features like this are *implicit* in the scoring algorithms. A prolific editor who uses the word "poo" will produce a lower vandalism probability than a brand new editor that does the same.

Thanks, West.andrew.g (talk) 18:49, 18 May 2012 (UTC)

Thank you. I was in fact using the default cluebot setting, and yes, by being more careful with my lefts and rights I would have avoided the situation. I appreciate the responses here. ~Adjwilley (talk) 19:06, 18 May 2012 (UTC)

sure Adjwilley and make sure you dont end up templating yourself, I have seen that with Stiki some have already managed to do that

which as, it appears, will truely be an unfortunate situation. -- ÐℬigXЯaɣ 19:46, 18 May 2012 (UTC)

Feature Request

I've noticed that when STiki adds a warning to a user's talk page, it doesn't sign it at all (with four "~"s). Am I missing something? I'm a bit tired of SineBot spamming my talk page with warnings about not signing my posts. Could you fix this? R^oc^ks²⁵ 22:11, 19 May 2012 (UTC) — Preceding unsigned comment added by Rocks25 (talk • contribs)

Your post above (which was signed) and SineBot's subsequent and redundant appearance here should give us some indication what is happening. This is not an issue with STiki (it has placed 75,000+ talk page warnings; there would have been many many complaints by this point if STiki did not sign correctly). Instead, something about your custom signature formatting seems not appease SineBot. However, I am not sure what the problem is. See Wikipedia:Signature#Customizing_your_signature and User:SineBot. In particular, the latter has a sandbox that you can test the bot in. Browsing your contribution history it seems like most your edits outside the main namespace are with STiki, thus why it seems like STiki is the problem. Hope you get this sorted out, and thanks for your use of my tool. West.andrew.g (talk) 23:35, 19 May 2012 (UTC)

Treatment of "good faith revert" in machine learning?

I am curious how "good faith revert"s will be treated for machine learning. If this was learning to create an anti-vandalism bot, then they would probably be considered innocent or simply not counted. For STiki purposes, they could be considered anything from neutral (between innocent and vandalism) to equal to vandalism. Allens (talk | contribs) 15:03, 21 May 2012 (UTC)

I have not retrained since AGF inclusion. I suspect the AGF cases will be discarded given the issues you mention. STiki is foremost an anti-vandalism tool and it is much easier to treat the problem as a two-class one. AGF edits certainly tend to share some characteristics of vandalism, and therefore this should lead to a queue ordering that looks like VANDALISM->AGF->INNOCENT, which in my opinion is a desirable result. Thanks, West.andrew.g (talk) 15:53, 21 May 2012 (UTC)

P.S. Congratulations on second-place on the leaderboard! I actually look forward to the day you pass me! Thanks, West.andrew.g (talk) 16:36, 21 May 2012 (UTC)

Blush... thanks! Allens (talk | contribs) 19:11, 21 May 2012 (UTC)

Constant lag? (Update: improved?!)

I have used Stiki for a while now, and I have noticed a slight lagging issue in stiki 2.0. Although annoying, it was still endurable. However, with the new Stiki 2.1, I am experiencing Stiki taking up to half a minute to load a page, as well as it hanging for minutes when I make any sort of revert. This renders the software completely unusable. Any programmers out there want to take a look into this issue? For more detailed descriptions of the issue, please comment on my talk page. Oh, and btw, good job on that good faith revert option. It has been long missed by me!!!P0150neD r1Ce asian 11:13, 26 April 2012 (UTC)

That is a completely unacceptable amount of lag. For users besides Tony, how long does it take for you to advance between revisions? There is really only one culprit for delay throughout the program: network latency. Your computer needs to talk to (1) the Wikmedia servers (in Florida, Virginia, or Amsterdam, I believe), and (2) the STiki server (Philadelphia). The farther you are geographically from these locations, then STiki should be marginally slower (but not 30 seconds/edit!). This is surprising because most of the network work happens in the background, *before* an edit becomes the one displayed in the browser (everything is threaded). Where are you geographically, if you don't mind? Have you used a tool like Huggle before? How slow is it? What is your ping time to server "armstrong.cis.upenn.edu"? Answer these question and we can begin troubleshooting the issues. Thanks, West.andrew.g (talk) 13:55, 26 April 2012 (UTC)

Another thing that might help (Though i cannot explain why it worked before) - are you using any form of firewall or antivirus that does real-time web scanning? Personally i use Avast! on my main PC, but its webshield in combination with Huggle causes a 5 second slowdown while Huggle loads a diff. Once it is disabled revisions are loaded almost instantly. Excirial^{(Contact me,Contribs)} 14:16, 26 April 2012 (UTC)

I am in Melbourne, Australia, so it is quite far from the servers. That may explain the issue to an extent. Huggle was fine for me, however. My broadband is usually quite fast, with speedtest giving download speeds of over 10 mbits. As for the ping, I can't do it right now because I'm at work, and cmd is of course disabled. I will give you an update as soon as I get home. For my firewall, I use the default Windows Firewall, and my antivirus is Microsoft Security Essentials (usually quite non-intrusive, so I don't believe that is the issue). Thanks for the prompt reply guys, hope you fix it soon :) P0150neD r1Ce asian 00:12, 1 May 2012 (UTC)

Update. Pinging armstrong.cis.upenn.edu gets me a reply in about 380 ms, so I don't think that's the problem. Also, I tried using the program despite the lag, and found that after about 5 minutes, the lag disappears! However, if I quit and restart the .jar, the lag returns for another few minutes. Hope that helps.P0150neD r1Ce asian 07:17, 6 May 2012 (UTC)

Yes, STiki does lots of caching to try to speed the user experience. Of course, when you start STiki these caches are empty so a lot of network resources are used trying to fill them. Orthogonally, I just discovered something this morning that might improve performance. STiki shares a machine/DB with some other research tasks; and one in particular was writing to a table that contained hundreds of billions of entries (and the index updates were a big *ouch* on DB utilization and memory management). I've dumped most of that table to an archival one so writes now happen to a much smaller table. This has the potential to make STiki's DB queries a little snappier (though it may not even be human noticeable). Thanks, West.andrew.g (talk) 16:25, 21 May 2012 (UTC)

Errr... Actually a pretty big improvement in latency on my end. I'll write an alert script so this never happens again. Thanks, West.andrew.g (talk) 17:54, 21 May 2012 (UTC)

Bug report (addition?): Link parsing and display

I am seeing a repeated problem in which, IF STiki is in "Activate Ext-Links" mode, the display contains repeated instances of the link followed by '">', with only the last link being active (or not, if it ends with a "}}"). This gets bad enough in some cases (490032557, 489906611) that one side of the diff is expanded widthwise while the other side is compacted into a narrow column.

Regarding the already-reported problem with "}}", perhaps adding link_desc = link_desc.replaceAll("\\}\\}.*" , ""); in add_hyperlinks would work? I admittedly don't know Java regexes. (BTW, if they work anything like Perl's, it will be more efficient for XLINK_REGEX to be "(https?|ftp)://([^\\]\\s\\|]+|" + gui_globals.BRACKETED_REGEX + ")*" - non-greedy regexps like BRACKETED_REGEX cause a lot of backtracking.) If you'd like, I can try modifying a local copy to make sure it'll compile, at least (I haven't yet due to the need to download a couple additional libraries). Allens (talk | contribs) 00:36, 1 May 2012 (UTC)

Hi Allens, at this point I think the link-parsing is in need of some serious inspection and re-thinking. When my time affords it, I'll dig in and address all of these link-related issues you've pointed out. If I recall, it turns out to be more non-trivial than it should be; but I have to imagine there is a relatively straightforward solution to address a bunch of corner cases regarding "space usage" and "special characters". Thanks, West.andrew.g (talk) 16:50, 1 May 2012 (UTC)

It occurs to me that the code in feature_hyperlinks.java might be reusable for this (or at least could be unified with whatever more-reliable solution is created). I do note that that code has the assumption that citation urls are always prefixed with "url\s*=\s*" (such as in parse_url_and_desc), when "(?:archive)?url\s*=\s*" is preferable ("archiveurl" refers to a page replaced via web.archive.org or WebCite). Allens (talk | contribs) 15:03, 18 May 2012 (UTC)

I'll note that link parsing is proven to be a darn hard problem for me. In particular, its one I've spent a whole lot of time on (I mean, I have 2 publications regarding Wikipedia link spam), so its not like it was a minor issue. In particular, I use all the logic I currently have to "guess/parse" what links are on a page. However, then I ask the API, "hey, is this link actually one on the page?". Only if the answer is yes do I report it on IRC and feed it to the anti-spam system (note that I don't make clients take this API hit when processing diffs, thus the inaccuracies you report). I can tell you I am right about 95% of the time.

Due to the sheer displeasure this causes me, this is something low on my priority list. Is it something you'd like to take a shot at fixing? After all, aren't you Perl folks ninjas with the regexps? It is easy to test any functionality autonomously on the server-side, complete with error reports (given that the API has ground-truth). Let me know and we can set something up. Thanks, West.andrew.g (talk) 16:49, 21 May 2012 (UTC)

I can take a look at it, although you will need to look over any Java-specific syntax... One question is whether we actually need to be just looking for what the system will turn into an external link (I just realized that {{official website}}, {{plain link}}, and {{URL}} need to be accounted for; these don't require http://, and none would be noted by feature_hyperlinks.java as far as I can tell), or whether ones that a person would perceive should be checked also. Admittedly, we won't have ground-truth from the API for the latter, which would be a headache. Allens (talk | contribs) 18:39, 21 May 2012 (UTC)

Glancing over my code, links are handled in two places. [feature_hyperlinks.java] seems to be the more viable effort and is the "backend" method used for link analysis. [diff_markup.java] contains method [add_hyperlinks()] which does it for the GUI. When I cite 95% accuracy I was speaking of the former. That is the one we can automatically evaluate and should try modifying first. Once satisfied with that, we can trivially transfer its logic to the GUI side.

In terms of Java regex, you'll want to see this documentation -- and yes, I can help you through the Java syntax. As you note with the templates above, there is a tricky number of corner cases. Before we start worrying about "perceptions", let's see if we can equal whatever the Wikipedia parser is doing. Note that if we need to exchange lengthy source code or worry about details too trivial for public consumption it is fine for us to coordinate privately via email. Thanks, West.andrew.g (talk) 19:21, 21 May 2012 (UTC)

It should also be fairly straightforward to setup [feature_hyperlinks.java] as an offline testbed for your work (it already has a main method to this effect), as it is has no real serious dependencies on other classes. Thanks, West.andrew.g (talk) 19:36, 21 May 2012 (UTC)

I agree that feature_hyperlinks.java is the code to start with. In terms of 95% accuracy, are you meaning that it spots 95% of the URLs, that the URLs it spots are external links by the API 95% of the time, or what? If you happen to know a couple example pages where it isn't correct, that would be helpful. I've started to construct a set of test cases in my sandbox, to expand on the existing test cases imbedded in feature_hyperlinks.java:main; I'm planning on writing some perl code to extract URLs from the resulting HTML output for comparison with feature_hyperlinks.java's output (I doubt I'll get it entirely congruent short-term, but I can get it closer than it is now). I've located the MediaWiki code for parsing external links (e.g., http://svn.wikimedia.org/doc/Parser_8php_source.html#l01168, http://svn.wikimedia.org/doc/Parser_8php_source.html#l00090, and http://svn.wikimedia.org/doc/GlobalFunctions_8php_source.html#l00771) and am analyzing it. Converting feature_hyperlinks.java into an offline testbed would indeed be very helpful (at some point in the future, getting it to read in an outside file for testing instead of a built-in one would be nice, but I can get along without that). Allens (talk | contribs) 10:31, 22 May 2012 (UTC)

By 95% "accuracy", I mean that after hours/days of running, calls to the [parse_success()] method in feature_hyperlinks.java will return 95% (I have this automatically emailed to me 4x daily as part of a larger report). That is, of the links which feature_hyperlinks.java identifies, 95% check out when we ask the API about the URLs on the page. Note that we can't ask the API about links in hindsight, it will only tell us what links are on a page "now." Note also that this approach doesn't speak to the accuracy of the inverse: i.e., the number of links that our approach misses altogether.

If you see the [confirm_url() method], I am going to uncomment the [System.out.println()] that reports the errors. I will let it run like that, and send you some of that output for analysis. Thanks, West.andrew.g (talk) 14:16, 22 May 2012 (UTC)

I thought so on the accuracy from the code & comments in it, unless you had a further set of testcases you were running it over. BTW, I note that some cases of apparent false positives may actually be due to that the "contains" in confirm_urls doesn't compare hostnames case-insensitively (and the MediaWiki software lowercases hostname characters). Allens (talk | contribs) 15:50, 22 May 2012 (UTC)

Good observation on the case-insensitivity -- I'll convert to lowercase for the purpose of checking against ground-truth and error reporting. Second, I discovered a bug in the "ground truth". My API query only returns the first 500 external links on the page (as I correctly documented, haha...). I'll need to fix this, as some articles have > 500 links so any additions beyond those would be reported as errors ("Barack Obama" for example). Third, with both of us iterating on these things, how should we manage the code versions we are each working on? FWIW, I'll fix these two bugs I indicate above, let everything run for a while, and try to get you an error report this evening. Thanks, West.andrew.g (talk) 16:31, 22 May 2012 (UTC)

Well, once you can send me how to convert feature_hyperlinks.java into an offline testbed, I can start directly working on the code instead of doing setup for it. Then you can worry about dissertation writing instead of coding for a bit, unless I need to ask for help on something... Allens (talk | contribs) 19:00, 22 May 2012 (UTC)

Errr. I am not so sure about the lowercase bit. See [6]. Upper-case is certainly allowed on the directory path and that example has one link with "NOAA" (capitalized) in the host name. Thanks, West.andrew.g (talk) 17:50, 22 May 2012 (UTC)

Fascinating. It's converting it to lowercase for displaying the URLs, and my browser converts the hostnames to lower-case for interpreting them (as browsers are supposed to - alterations in the case of the hostname won't make any difference), but it isn't actually doing so for the href="http://HOSTNAME" part. Uppercase is allowed (and can have an effect) for the directory path, but I am not terribly worried about the extraction process altering the case. Allens (talk | contribs) 19:00, 22 May 2012 (UTC)

More problems! Ground-truth doesn't hold!!!! I started noticing that URLS were appearing verbatim in my error log as they were in my subsequent manual API xlinks queries. I then made edit [7] and then immediately pinged the API to ask which xlinks where there. The link at the end of the edit did NOT appear. Waited about 10 seconds, whala! it appeared. Clearly we are hitting the API before the xlinks can be parsed out of the diff; or replication lag is killing us. In practice, we don't want to hold up vandalism processing in a thread while links are parsed. I'll need to rethink this strategy. Thanks, West.andrew.g (talk) 18:32, 22 May 2012 (UTC)

Slowed things down to see if that helps. We already waited a little bit after an edit made was made before processing it (for orthogonal and justified reasons). With a little more delay (still in the justifiable range) maybe the parser will get its work done in time. Let's see what an error report gives us tonight (if nothing else, there will be fewer errors on the basis of this change). West.andrew.g (talk) 18:56, 22 May 2012 (UTC)

That may be because the server lag is high today - it was up to close to 10 minutes earlier, IIRC. Allens (talk | contribs) 19:00, 22 May 2012 (UTC)

STiki Leaderboard

I have changed my username, and I now login with the W.D. username. Everything has been transferred. Would it be possible to merge the two?Willdude123|Ƹ21ɘbublliW (talk) 07:12, 15 May 2012 (UTC)

I have mapped your previous classifications in the database to the new username. The change will be reflected on tonight's leadboard update. Do realize that any surviving ignore actions by "WillDude123" could be displayed to "W.D." -- I wouldn't worry about this though, ignores tend not to survive long, especially given the influx of new users we've seen lately. Thanks, West.andrew.g (talk) 14:39, 15 May 2012 (UTC)

WD, can you please explain to me how you realized this username change? What do you actually login with? I note that even after my manual update above, that I began seeing "WillDude123" appear again on the leaderboard. Is this all just a bunch of redirects? Thanks, West.andrew.g (talk) 16:29, 21 May 2012 (UTC)

Before I realized my username changed, I made a few edits. It seems I can login with both but only W.D. has all my contribs. So I can use both, which is a bit strange.User Talk:W.D. 17:40, 26 May 2012 (UTC)

db_geolocation.java: get_gmt_offset returning 0.0 as error value?

This essentially assumes that any IP address with an undecidable timezone is in the UK (GMT+0 timezone). I suggest it would be better to have it return whatever's the most common IP-address editor timezone - probably the east or west coast of the US. Allens (talk | contribs) 10:06, 21 May 2012 (UTC)

Or can you make these IPs be treated as a separate set by the alternating decision tree? I guess partly it depends on how many IPs fall into this category. Could we collect enough data on them? I guess even if we can't collect enough data on the time dependence we could still come up with a decent time-independent classifier. Yaris678 (talk) 12:33, 21 May 2012 (UTC)

That's a reasonable solution when it comes to those IPs not classifiable by country; the country is returned as "", which isn't treated as a separate country for reputations, but probably should be if there's a significant number of them. (Actually, even if an IP couldn't be classified by country, it could at least be classified by which Regional Internet Registry it fell under, although that should perhaps be a separate characteristic from country to allow for a larger-scale grouping.) The timezone itself is not actually used in the classification; it is used to figure out what the day-of-week and time-of-day it is in the IP's location. If there are enough of these unknown timezone ones, then perhaps that characteristic could be treated as a separate datum for the decision tree. Allens (talk | contribs) 14:41, 21 May 2012 (UTC)

Foremost, it absolutely terrifies me that Allens is reading my code; I can only imagine how many more of these posts I might wake up to :-)! Yes, this is some inelegant code, but no, I don't think it is a serious problem. First, my IP->GMT+/- database has complete Internet coverage, that is, there is an entry for every IP address. However, it is true that not all IPs have a populated GMT+/- field, but this figure is less than 0.01%. The *vast* majority of these are "RESERVED" IP addresses, which are generally not publicly routed, and therefore STiki would never see them. The tiny remainder map to "United States Armed Forces" and "Satellite Providers." Bottom line, even if we mapped all these users to their own "special group" I don't think it would be statistically significant (I'd have to write a very time consuming script to determine if we've ever seen one before, meh). Regardless, *we can't (simply) fix bugs regarding feature calculation*. Because the AD-Tree was trained over a particular implementation, it needs to classify over that same implementation. Changing the implementation would require re-calculation for all corpus instances and the installation of a new tree. Simply not worth it for this. I'll place a TODO in my code, but I am opting not to elevate this to "bug" status. Thanks, West.andrew.g (talk) 15:43, 21 May 2012 (UTC)

I'll also note that time-of-day and day-of-week are not killer features, i.e., they are not among those with the greatest quantity of information gain. They are certainly interesting features (that further establish that school children are a major source of vandalism), but they aren't really driving the classifier. As an academic, sometimes I implement these things because they fulfill more theoretical objectives than practical ones (or more accurately, I implement them because they fill theoretical needs in my publications, which I then implement faithfully). West.andrew.g (talk) 15:58, 21 May 2012 (UTC)

I'm certain that you'd find far more things problematic if you ever read over my academic code than I do with yours - mostly "huh? what's this for?"; intra-code documenting, aside from naming variables and subroutines well, is not a particular strong point of mine unless I'm particularly keeping this in mind (as I will for any patches). (Your code is quite clear, BTW; good job!) I understand fully about the retraining problem; anytime I suggest a new or modified tree-feature, assume that I'm suggesting it as something to do in the future whenever enough of them accumulate to make it worth recalculating.

That's interesting regarding those not being killer features, and on the schoolchildren (I think you mentioned that in a paper and I forgot it...). Three thoughts that I had earlier that this brings back to mind:

Category:Shared IP addresses from educational institutions may well be of interest, especially if expanded from the current single IPs to the surrounding /24 or so. Admittedly, it also includes some college and university addresses - but only ones from which there has been vandalism previously, as far as I can tell. There may be some other listings of educational IP addresses - will take a look around.
Combining the day-of-week data with the country and information in the Weekend article, to indicate whether a day is a local weekend, might make DOW significant enough to actually (indirectly) be in the tree.
Checking to see whether the page title and/or any categories matched "[Ss]chool" might well be informative, particularly in combination with the educational IP classification.

I may try working some of the above up into a patch (the educational IPs one would be difficult for me). Allens (talk | contribs) 19:09, 21 May 2012 (UTC)

All very good points. I'll note I am aware of (and have an implementation + ADTree model for) many other features. See my CICLING and PAN-CLEF papers. I simply haven't gotten around to bringing them all live (and there may also be scalability issues with certain features, or a large quantity in combination). The vast majority of features require a new API query, and at several edits a second at peak times, this puts some stress on the system. I really need to do an info-gain ranking and start the consideration from there (which I might have already done, somewhere). Thanks, West.andrew.g (talk) 19:31, 21 May 2012 (UTC)

In terms of info-gain rankings, also keeping in mind in any decisions made whether the feature in question requires a new API query would be good. The first two of the above, incidentally, wouldn't require an API query (except for an occasional update from the educational shared IP category); the third one should be able to "piggyback" on another API query for the categories (adding "categoryinfo" to "prop="). I'll keep in mind whether an API query is required for what suggestions to make about new features (I've got a list...). Allens (talk | contribs) 17:54, 24 May 2012 (UTC)

Hi Allens. First off, thanks for the code contribution sent via email. Those statistics look great! I will integrate this into the code base when an opportunity presents itself (just got your second email, I'll wait for an update!). One minor question, though. We've been addressing thet ask of finding diffs in an article. However, part of the motivation for this was to be able to accurately detect links in diff presentation. This doesn't present major differences. However I can imagine a case where http://www.url.com is changed to http://www.otherurl.com and the right-hand side of diff would be formatted as something like

http://www.<font color="red">other</font>url.com

Can this happen? Or are diffs always split at token granularity? I feel like I saw this case once in my studies about two years ago. I'll need to strip out such font tags before processing, but can you think of any other considerations?

Second, regarding new features. I must admit I haven't been too eager to improve the "STiki (metadata)" approach lately and have been focusing on the interface instead. I too have lots of feature ideas (plus the ones from PAN-CLEF/CICLING papers that need to be brought live). Doing this in a small and incremental way (i.e., whenever a new idea for a feature rolls in) isn't exciting (why be a less distanct second-place behind CBNG?) and a PITA (retraining, install the new ADTree, ensure scalability, etc.). I was also a bit frustrated to hear the CBNG folks claim they had equaled or slightly improved upon our performance in CICLing over the Potthast corpus.

I need to bite the bullet, do it in bulk, and include some novel features to retake "first place". My current situation doesn't afford the time for this. However, I will make a promise that I *will* make this happen once my proposal is defended in a month or two (I should note that my proposal/dissertation will be essentially will be one and the same. I am writing my dissertation now and just plan to leave one chapter blank = proposal. Write one conference paper about work I've already started and use that to fill in the blank chapter = dissertation. Not exactly the way its supposed to happen, but oh well).

As an aside, you may notice I tend to be quite anal/responsive about keeping up to date with my talk page and all these suggestions. This does tend to get a little fatiguing. That being said, I appreciate your ideas and think they will prove fruitful in the future. For things like long-term feature development it might be helpful to create a sub-page and develop our ideas there. This would be a little less public-facing and could act as more of a sandbox for our ideas. Then when bulk implementation time rolls around, we have a consolidated resource to consult. We could even section out the page by data/query source (i.e., content-features, user-features, article features, etc.). In fact, let's use (Wikipedia_talk:STiki/Feature development). You could get a start there by (a) listing what STiki already has, (b) transferring ideas from the CICLING paper, and (c) dumping your own ideas. Thanks, West.andrew.g (talk) 21:24, 24 May 2012 (UTC)

Quite welcome on the code; I've sent the revised version. I'm afraid that the diff in use is indeed capable of breaking things down within URLs - see this diff as an example. It looks like the tokens/segments it uses are split by something like \b.

In terms of your proposal/dissertation, you might find interesting how most (all?) of Europe does dissertations - they're basically a compendium of the person's papers stuck together with some introductory material and linkages explaining how it fits together.

Good thought on the subpage - will start work on that. Allens (talk | contribs) 23:24, 24 May 2012 (UTC)

Sidenote, we shouldn't concern ourselves too much with the multiple WikiTrust features (esp. of the CICLING paper). WikiTrust just hasn't been getting the job done quick enough lately, and I suspect might have scalability issues with the pace at which en.wp currently operates. Part of the reason that queue (WikiTrust) might be so "bad" is that something like 80% of the RID requests I pass to their API (RIDs just made on the wiki) timeout without yielding the WikiTrust score. We can approximate that score via STiki's user reputation (a more binary version), possibly with normalization by edit count. Point being, I don't think these are viable features for a live implementation. Thanks, West.andrew.g (talk) 00:20, 25 May 2012 (UTC)

Warnings about templating regulars: Who's a regular?

Number of edits total should certainly be part of it. How about increasing that threshold based on user reputation, as in (time-decayed) number of "offensive" edits? (Better yet would be number of warnings on the user's talk page, but that would be harder - I know the STiki server is already figuring out user reputation so could send that info to the client.)

(BTW, is there some reason that user reputation as used inside STiki is purely focused on number of offending edits and doesn't take into account the user's total number of edits and/or total number of recent edits? I'm particularly surprised on this given the PAN-CLEF results.) Allens (talk | contribs) 19:13, 22 May 2012 (UTC)

Hmm. My inclination was to lean towards simplicity. This also helps end-users know what is going on. Complex solutions also imply more and more queries to Wikipedia or my server (and with the lag complaints, I am starting to be a little hyper-aware of this). After all, how many registered users with > 50 edits actually vandalize? As long as their is a low false-positive rate it won't annoy the end-user. Moreover, its not like we will stop the revert/template altogether, just say "hey, you might want to take a second look at the edit and the user"

As the EUROSEC'09 paper explains, the lack of normalization was an acknowledged shortcoming but done for robustness reasons. If you create a feature like that, you give someone a means by which to alter their own reputation by making edits to smooth out the bad ones (e.g., possibly using a bot in user space). This another one of those things that you should probably implement in practice, but might attract considerable criticism when getting a paper reviewed. Thanks, West.andrew.g (talk) 19:29, 22 May 2012 (UTC)

I agree that simple is good. You could base it on a simple edit count or possibly edit count + confirmed/autoconfirmed.

I think a bigger issue is what the message says. We don't want to imply that the STiki user should either:

Ignore the edit
Revert the edit without warning the user.

We may want the user to double check. And then have a think about what the most appropriate action is. Three things which may be a good idea are:

Conclude edit is actually innocent and press that button.
Revert edit and template user (as usual).
Revert edit and discuss it on the article talk page (but no templating the user talk page)
Mark the edit as innocent for STiki purposes but discuss it on the article talk page.

Yaris678 (talk) 12:32, 23 May 2012 (UTC)

Edit count in article-space, gotten via list=usercontribs w/ucnamespace=0, may be preferable for the threshold. Having among the buttons ones that automatically open the article's talk page (good thought) after the revert/innocent-marking would be nice. Allens (talk | contribs) 12:43, 26 May 2012 (UTC)

No no no. That is not how you want to compute edit count. See meta=userinfo (ui), which has the downfall of counting across all namespaces. However, using "usercontribs" has bigger issues. "usercontribs" lists at most 500 edits and then you have to start making recursive calls. That user who just reached 1 million edits and then used STiki for the first time? Yeah, I tried to "usercontrib" his edit count for milestone page reporting.... The operation ran for 5+ minutes and then overflowed something like 128MB of memory. No thank you! 15:59, 26 May 2012 (UTC)

? Why would you need to know if the person had a higher edit count than the threshold? Just specify that, which should be less than 500, as the number of entries to return. If you don't get back that number of entries, the person hasn't edited enough yet. Allens (talk | contribs) 16:29, 26 May 2012 (UTC)

Valid point. Will do. West.andrew.g (talk) 00:57, 27 May 2012 (UTC)

Could STiki remember...

Since STiki remembers the WP username, I assume it's saving some state somewhere. I wonder if it would also be possible for STiki to remember:

The user's WP password (this would need to be optional, of course, for those on shared computers)
- Yes. Would probably be stored in plain-text, though. West.andrew.g (talk)
- On second thought, I have decided to decline this request for security reasons. STiki's code is open source. The format and location of the properties file is obvious to anyone who opens up the source. Thus, any program on your system will know where to find this file (and the potentially plaintext password inside it). All it would take is an attacker who claims to have compiled an "improved version" of STiki and convince someone to download it and try it out, and they a password. Simply not worth it for the minor inconvenience of entering it each time. Thanks for the suggestion, though, and I am currently considering the "pass message" you describe below. Thanks, West.andrew.g (talk) 04:07, 26 May 2012 (UTC)
  - Sorry, I don't follow. If an attacker wished to use a supposedly "improved" STiki to harvest passwords, couldn't they just modify STiki to transmit the password once it has been entered? Jakew (talk) 08:03, 26 May 2012 (UTC)
    - Hmm. the application wouldn't have to look like STiki or have anything to do with Wikipedia in order to steal the password. In fact, this is something some malware does: it has profiles of where plaintext passwords might reside and just checks these paths in bulk. Granted, it is not STiki's fault that you got malware on your machine (or the hacked version of STiki, or whatever the point of entry is...). However, shouldn't STiki have some responsibility not to exacerbate the problem? West.andrew.g (talk) 12:31, 26 May 2012 (UTC)
      - Personally, I prefer software to automate as much as possible, and I'm willing to take responsibility for keeping my computer free of malware and other nasties. But I won't press the issue any further; it's your program and I respect your decision. Jakew (talk) 17:16, 26 May 2012 (UTC)
        I also respect your approach to the problem and believe you are vigilant in keeping your machine clean. However, I have to program for a general purpose audience who may not meet the same standard. The last thing I need is irate talk page traffic over such a minor thing. Plain-text passwords in general are not a great idea. West.andrew.g (talk) 01:01, 27 May 2012 (UTC)

The fact that the "you've used the pass button several times" warning has been given.
- Hmmm. Maybe. Even experienced users need a jostle sometimes. West.andrew.g (talk)
- This has been encoded on my local machine and will be included in the next release. Use of "pass" will now be tracked persistently (although because it is based on a "setting" and not a DB query, this count will not be persistent across different machines). Experienced users will see the warning far-far-far less often, and eventually, never. I do agree that seeing it every session after 10 passes was a bit excessive. Thanks, West.andrew.g (talk) 05:32, 26 May 2012 (UTC)

The last selected queue?
- No. The queue which is selected at start-up is not *always* CBNG as one might think. This is set via a query to my DB. When CBNG has been down for long periods, I have set the default queue to "STiki (metadata)" and I intend to retain control over this. West.andrew.g (talk)

Thanks! Jakew (talk) 15:08, 23 May 2012 (UTC)

Feature development sub page

Hey guys,

I think having a subpage for features is a good thing. Ideas get suggested now and then and if keeping the info in one place probably means that Andrew doesn't have to explain multiple times why the same thing would be practical.

However, is Wikipedia talk:STiki/Feature development the right structure to go for? I think splitting the page by feature type makes sense.... but I think you want a page in the WP: name space, maybe Wikipedia:STiki/Feature development. That way the page is not about threads of talk but is a collection of information. This means it is easier to suggest ideas in the associated talk page and then summarise what it all means on Wikipedia:STiki/Feature development.

On a point of terminology, do we want to use the word "feature"? I gather this is what is used in academic circles. It is the feature of edit that informs the probability of vandalism... but there is the chance that this could get misunderstood as a "feature request" for the software. Perhaps we should add a qualifying term. e.g. say "informing feature" or something like that. At the very least there should be an explanation at the top of the page about what you mean.

Yaris678 (talk) 08:12, 25 May 2012 (UTC)

I placed it in the "talk" space because I didn't want to have to construct the page with any formality in presentation (i.e., an article), but to be a sandbox for idea development and discussion. I guess talk pages also imply certain norms I wouldn't want to require, either. In my eyes the difference is a minor one; if someone feels strongly, move it and maybe redirect the talk page back to it (and correct any pointers).

Feel free to add such a description for "features" to the page. However, the very impetus for creating that page was so that there didn't have to be an excess of "hand-holding" descriptions. Add a warning to this effect you like. I tend to be rather generous in describing technical bits with intuitive descriptions on this talk page. This takes a long time. I don't mean to sound rude, but in the spirit of getting things done, sometimes I/we cannot cater to everyone -- and the talk page split was designed so this would happen more naturally. West.andrew.g (talk) 12:21, 25 May 2012 (UTC)

So long as the page isn't in article space, the rules are pretty flexible. For example, Wikipedia:Pending changes/Request for Comment 2012 contains backgound info, structured discussion and more free-form discussion; Wikipedia talk:Pending changes/Request for Comment 2012 contains discussion about what is on Wikipedia:Pending changes/Request for Comment 2012, including what to do next.

I have added an explanation of "features" to the top of that page.

Yaris678 (talk) 11:34, 28 May 2012 (UTC)

Satisficing approach

Given that one of the issues with new informing features is whether or not it is worth getting the data from an API call, would it be possible to take a satisficing approach? This seems to fit naturally with the ADTree framework. i.e. You could use an ADTree before making some of the API calls, you would then only make the API call if requested to do so by ADTree. The ADTree would be designed (pruned) so that it doesn't bother getting info if it doesn't make much impact on the probability of vandalism. This pruning would include (but not be limited to) cases where the probability of vandalism is so low either way that the edit is unlikely to reach the top of the queue. Yaris678 (talk) 08:12, 25 May 2012 (UTC)

First, this is an interesting idea: rather than pre-computing a feature set and providing it to the ADTree model, we could just compute features on-demand if they are encountered along the tree path. This is an implementation detail that deserves serious consideration when I "bit the bullet in bulk." This does, however, have the side effect that we cannot review these features in hindsight, or possibly use that edit for retraining (at least without computing the full feature set offline). Similar with stopping mid-way through the tree when we have an intuition about relative score (or just know it won't be a poor one). Given ongoing academic intentions, I prefer to follow these things to the end. West.andrew.g (talk) 12:28, 25 May 2012 (UTC)

Ha ha. Yes. Maybe that is a good definition of satisficing "Something that works well in practice but doesn't help with academic intentions."

I guess if you did implement something like this you could also have a script that extracted the missed-off information when called. However, you'd have to:

Allow it to just get the data for a given period, rather than all missing data. That could take a long time and clog up the servers.
Think carefully about what information could actually be extracted after the event. Some information will change... but some you will always be able to get. For example, you could always get the en.wp server to give you the diff between two versions and it will always be the same... unless the article gets deleted.

Yaris678 (talk) 11:44, 28 May 2012 (UTC)

How about a compromise? Put any data retrieval that isn't immediately necessary into a separate thread with low priority, using API calls with the "maxlag" parameter set (and pausing as appropriate if it comes back as needing a pause due to high lag). Allens (talk | contribs) 11:58, 28 May 2012 (UTC)

To what extent are there quiet periods (and busy periods) for STiki and the en.wp server? If they exist then doing things this way seems like the best of both worlds. Yaris678 (talk) 12:31, 28 May 2012 (UTC)

I'm certain that the en.wp server load varies - I've seen the maxlag warning popping up on my watchlist a number of times. The STiki server would be under variable load from two sources: Keeping up with en.wp changes and keeping up with STiki clients. Allens (talk | contribs) 14:08, 28 May 2012 (UTC)

There are graphs out there that will show you the load on en.wp servers. They seem to be having issues with replag lately. However, this seems to rarely happen with normal operations -- high replag generally follow cache clears from version updates, DDOS attacks, etc. Regardless, I can't fix their issues. In its current version, STiki has never really fallen behind, it keeps pace with the edits just fine. Same with the frontend client work. Computationally, STiki and its associated DB work consistently eat about 50% of one processor. There are elegant ways to get non-critical data at a later time if en.wp servers are suffering, but this ends up being more a PITA than it is probably worth, as some features would require two implementations: "historical" and "immediate" (i.e., the editcount example). The historical versions can be extremely inefficient, and cause more server work than the original (plus if there is some delay, the queries are likely to miss caches). West.andrew.g (talk) 15:05, 28 May 2012 (UTC)

I certainly wouldn't encourage doing anything later that would require a separate implementation and/or be inefficient when done later. I was more thinking of ones that are basically an API request (not altering depending on at the time or later) followed by a database insertion. I note that it would be valuable for the STiki server requests to be able to use the "bot" flag, to request more data per API call, and a request for this (or continuing to have this) would be more likely successful if using maxlag whenever possible. Allens (talk | contribs) 17:04, 28 May 2012 (UTC)

What does AGF% mean?

I think the title here is pretty self explanatory. Also what do the other headings on the leaderboard mean? — Preceding unsigned comment added by Zibart (talk • contribs) 10:35, 25 May 2012 (UTC)

The editor's revision is regarded as not being vandalism, but being unconstructive and should be "undone". -- Gareth Griffith-Jones (talk) 10:42, 25 May 2012 (UTC)
AGF = WP:Assume good faith. In STiki we call the action an "AGF revert". What other terms confuse you? West.andrew.g (talk) 12:30, 25 May 2012 (UTC)

The 'BACK' button

For the first time this afternoon, I have the 'BACK' button "live" ... is this new, or has it not been functioning since I began using STiki? -- Gareth Griffith-Jones (talk) 17:24, 25 May 2012 (UTC)

Ummm.. that button has been in place for over a year. Try watching it more closely. If you pressed "AGF" or "vandalism" on the previous edit, then you cannot go "back" from that and it will be disabled (you need to handle your screw ups manually, and probably with an apology to the editor involved). Otherwise (if you last pressed "pass" or "vandalism") you can go back at most one edit. Let me know if it does not exhibit this behavior (or if anyone else has issues). Thanks, West.andrew.g (talk) 18:19, 25 May 2012 (UTC)

Yes, I can understand that you should not be allowed to return to the last edit after a Vandalism and an AGF revert automatically, and that the BACK button should at these times be disabled. Thank you. -- Gareth Griffith-Jones (talk) 07:14, 26 May 2012 (UTC)

Actually its not by choice that the back button gets disabled, once you press vandalism or AGF then you actually revert the article (and template the user as well) this cannot be simple undone by a press of back button and needs to be manually done. while apologizing Please Do not Blame "STiki" or "BOT" as you did in past. This discourages new users and scares them from editing and contributing. regards-- ÐℬigXЯaɣ 08:15, 26 May 2012 (UTC)

Thanks for that, ' ÐℬigXЯaɣ

... and that is exactly what I had already understood.

My reason for starting this section was merely that up until May 25, I had believed that the 'BACK' button was permanently disabled and had just been made 'alive'. Andrew has now made this point clear to me above.

Please be assured that I fully understand that any "undoing" has to be done manually. I take full responsibility for any action that I may perform here on Wikipedia. May I also state that I value the support that I have received from fellow "STikians" ... with kind regards, -- Gareth Griffith-Jones (talk) 09:12, 26 May 2012 (UTC)

Would this be possible?

Could I create a text file (through a script or something) to get the revision IDs of a user's edits, to then put in to the ort? User Talk:W.D. 08:44, 26 May 2012 (UTC)

Why yes, you could! Is there a non-hypothetical question here? West.andrew.g (talk) 12:34, 26 May 2012 (UTC)

Yes, there is, I would possibly interested in even getting the users in a category, for instance, educational institutions and patrolling the edits of such category. On a side note, does STiki add anything to the score if it is a shared IP? User Talk:W.D. 17:40, 26 May 2012 (UTC)

I should probably emphasize the "Offline" in "Offline Review Tool." You can't undo edits via ORT. Moreover, there is no guarantee the content still exists in the most recent article version. It's useful for ex post facto review (i.e., corpus building). West.andrew.g (talk) 01:05, 27 May 2012 (UTC)

Re Sidenote: It does not at this time. Such a feature is in development, though it is difficult to detect exhaustively (more realistically, we would just be looking for the existing category members).