Jump to content

Wikipedia talk:STiki/Archive 6

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 4Archive 5Archive 6Archive 7Archive 8→Archive 10


Error with hibernation

With Windows 7, whenever I un-hibernate (if that is a word) by laptop, STiki says it could not connect to the Back-End. Is there any way to fix this? User Talk:W.D. 19:47, 27 May 2012 (UTC)

STiki uses a persistent connection to the backend database. I assume that when your machine hibernates that the network card is turned off, terminating the connection. If the connection is lost, it will make re-attempts, but I don't know in what context this happens (if it will start attempting immediately or when the machine "wakes"). Suffice to say, this would not be a high priority bug for STiki. After all, the "reservation" you take out on a block of edits expires after 10 or 15 minutes time and some of your cache might be out of whack when restarting. At this time, I'd have to suggest that a hard restart of STIki is preferable. Thanks, West.andrew.g (talk) 02:31, 28 May 2012 (UTC)
  • agreed I have also seen this error message, but i dont think this is a bug. it is caused by the loss of internet connection over an extended period. Clicking ok closes STiki and if you want to use it you can restart STiki. Not much of a trouble in my opinion. but the message in the error notice can be modified to instruct editors to restart STiki so that they are not left clueless. --ÐℬigXЯaɣ 07:51, 28 May 2012 (UTC)

STiki issue

Any possible hints: Wikipedia:Counter-Vandalism Unit/Academy/Questions#STiki Question? benzband (talk) 19:14, 29 May 2012 (UTC)

I've posted to that page. Thanks, West.andrew.g (talk) 19:50, 29 May 2012 (UTC)
Thankyou also. benzband (talk) 19:57, 29 May 2012 (UTC)

CHANGELOG FOR 2012_05_22 RELEASE!!

The following changes were part of a new release rolled out this evening:

  • The "wiki-diff" link in the metadata panel wsa repaired so that it now displays the same diff as in the diff-browser. This was an omission in the GUI's switch to exclusively rollback functionality. (T#008)
  • Some (but not all) users reported that the different elements in the "help menu" failed to jump to the appropriate section/anchors in the help-doc. This has been fixed. Also, a related bug was discovered/fixed where external links in the help document were not being handled correctly (T#011)
  • The diff-browser now has copy-paste functionality. Text can be highlighted in the diff-browser and transferred to the clipboard either via CTRL+C or a right-click context menu (T#012).
  • It is now possible to enable HTTPS support via the "Options" menu. If checked, HTTPS will be used for all communication with the MediaWiki API and any links that open in browser and point to "wikipedia.org". A restart is required. (T#013).
  • Following from the above, the "Appearance" menu has been renamed to "Options". This could soon become a larger bin for settings. Documentation changed accordingly.
  • Minor (invisible) changes were also made to the way that persistent settings are stored, so that the XML output remains clean and human-editable as STiki evolves.
  • Code has been put in place such that, if consensus is reached, that STiki can only be used by editors with the rollback permission. This functionality is encoded but currently not in use (T#005).
  • If STiki is going to post a user-warning to a "User Talk" page which is in fact a redirect, it now resolves that redirect (T#002).
  • Most are familiar with warning templates {uw-vandalism#} or {uw-spam#}. Less common are those like {uw-test#}, {uw-joke#}, or {uw-advert#} that also identify problematic users. The identification and escalation from these templates (into spam/vandalism ones) is now part of warning logic. Notably, STiki will not jump from a non-spam or non-vandalism level 4 warning to an AIV post (it will post a level 4 spam/vandalism instead), though it will do this for "4im" cases. (this request was not bug-tracked; it was posted by User:Allens).

Thanks to everyone for their support and suggestions/bug-reports! The next release may be a while off: I am heavily involved in my thesis dissertation and some travel in the coming month is likely to provide questionable Internet connectivity. In the meantime, enjoy this one! Thanks, West.andrew.g (talk)

RfS on rollback requirement?

Prior discussion on the topic (now archived)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I note that Andrew has written, but not activated, code that requires users to rollbackers before they can use STiki. He says he is awaiting consensus on this issue. Since this one has been going round for a while, how about we determine consensus with a Request for comment?

Maybe it would help if we listed some of the issues that have been identified so far. I will start a list below. Feel free to expand or change it.

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

List of issues

Started by Yaris678 (talk) on 08:12, 22 May 2012 (UTC) Feel free to expand or change it in the usual wiki way.

Pro-restriction

  • People using STiki who aren't familiar with vandalism have been known to revert innocent edits. They may also be marking vandalism as innocent. Anyone can make a mistake but these will be more common with people who have not gained enough experience to get rollback.
  • While the responsibility lies with the user who is doing the reverting, when innocent edits are reverted it harms the reputation of STiki.
  • With the exception of Andrew, most editors have no way of checking on the edits that another user marks as innocent.
  • Though I'd happily make it available (possibly in a dump or online query), such files would necessitate ORT inspection. West.andrew.g (talk)
  • It is actually quite easy to get rollback rights. This would not put a massive barrier up.
  • Earlier in the life of STiki, the priority may have been to get more users in. Now the priority should be to ensure quality.
  • Hmmph. Given our market share relative to Huggle's there is still plenty of room for growth. Even when STiki has "big days" with 1500+ classifications, the hit-rate tends not to drop > 10% relative to slow days. Clearly, there is still lots of vandalism out there and STiki could use more users (and/or a more even distribution of their working times). Thus I see this as a WP:AGF issue combined with probability. Assume a user could, (a) pop another edit from the queue, which has a X% chance of being vandalism, (b) inspect another STiki users effort, which has a Y% chance of being incorrect. I would pick max(x,y). We know that X=~50%, even on big days and Y doesn't even approach this. West.andrew.g (talk) 15:23, 22 May 2012 (UTC)

Anti-restriction

  • Many people without rollback rights have done good work with STiki.
  • Many people don't realise how easy it is to get rollback rights. They may just see that they are required and then think "STiki is not for me."
  • While rollback does indicate some experience with vandalism, its focus is on people who won't falsely call something vandalism, not people who won't falsely call something innocent.
  • An informal peer review system is already in place. I (User:West.andrew.g look at the milestones page almost every single night (and so does OrphanWiki). For every new user to STiki, I inspect their talk page (for complaints about STiki use), look at their classification percentages, and spot-check their STiki reverts. Granted this is many as 24 hours behind schedule and doesn't accommodate for over-use of innocent, but its been working fine. West.andrew.g (talk) 14:51, 22 May 2012 (UTC)
  • As User:meiskam earlier observed, anyone who can program worth $0.02 could take the open-source code, modify a single line, recompile -- and easily skirt the requirement (and/or trivially use the the codebase for more malicious purposes). Somehow this erodes the legitimacy of the barrier. We could imagine a more complicated system where rollback rights are checked on the server side before edits are distributed; but this is work and overkill. If someone is smart enough and willing enough to evade the simple client-side check, then they will just ignore the standard channels of edit distribution (or build their own trivial ones) before wreaking havoc. West.andrew.g (talk)
  • Much bad press comes from inappropriately marking the edits of regulars as vandalism, and templating them. Fair or not, the inappropriate revert of a regular is more damaging to the tool than a screwup on an IP address. To limit this, I have proposed a warning dialogue to be popped if one is about to template a regular (T#015, now implemented in my local source). We can discuss how to define "regular." West.andrew.g (talk)

Other options
It has been suggested that a system of peer review would be better. Some issues with this are as follows:

  • That system is not available now. It could be implemented in future, but until then, let's choose from the available options. Going for a rollback requirement now doesn't prevent us from going for something better later.
  • This would involve extra work (presumably for Andrew) to code it.
  • This would involve all STiki users looking at edits that another STiki user has looked at. However, with clever software design this could be kept reasonably low.
  • This would be looking at whether the person was falsely classifying vandalism as innocent, which is somewhat the reverse of what getting rollback rights looks at. Allens (talk | contribs) 12:22, 22 May 2012 (UTC)
  • Piggybacking with Allens here. If someone marks an edit as "innocent", sure we can have another STiki user review it later, no big deal. However, in the "AGF" and "vandalism" cases, there is an explicit edit on-wiki, so the community as a whole is already doing peer review for us during standard recent changes patrol in these cases. Having STiki users inspect STiki reverts would be: (a) detrimental to the overall hit-rate, (b) confusing as hell. Here we advertise a tool to help people find vandalism, and then we start popping them edits which are likely to be "the very opposite of vandalism." Just look at the recent talk-page posts where a user was confused and screwing up edits because the CBNG queue was popping him revert actions. Personally, I'm more concerned about over-agressive reverting (gives us bad press) than people who operate too conservatively. STiki's problematic users are edit-count-itis cases, and they certainly fall into the former bin, not the latter. The lone exception is people who might operate very-very-very conservatively (i.e., holding down the innocent button for an hour in the hope of helping vandals by exhausting our queue -- and I can detect this autonomously). West.andrew.g (talk) 14:36, 22 May 2012 (UTC)
  • Further, if we start having STiki users inspect and possibly revert the reverts of other STiki users, I foresee problems. I don't think it would be good for the STiki user base/community if we started waging wars against each other and especially new users. Even if this happened, reviewing edits probably shouldn't be done in the normal interface. Are we going to start reverting and templating each other over some subjective vandalism interpretations? Explicit review just involves too much scrutiny of individual edits, as I see it, so I prefer broad and informal review (see the header immediately above), as is already occuring. Thanks, West.andrew.g (talk) 14:44, 22 May 2012 (UTC)
    • Hmmm... I didn't want to go into this in too much detail here because it shouldn't affect whether or not we use Rollback, at least in the short term. But I can think of a way of doing this that does not involve feeding reverted STiki edits to other users. The idea is that we are trying to quantify the false-positive and false-negative rate of each STiki user, rather than trying to confirm each STiki classification. Therefore, you can just take (a subset of) edits that have been classified as innocent and give them to different users. If an edit has been classified as innocent by A and vandalism by B then that counts as a potential false negative by A and a potential false positive by B. This would be summarised in percentages for each user (once they have had say 10 such reclassifications). We would have to expect no user to get a zero on these stats because you will get a mark when you get it right but the other user gets it wrong... but if we make sure that we don't have a situtation where one user X's edits are always reassessed by user Y then these numbers should fall away, allowing us to see who has genuine bad stats. Yaris678 (talk) 15:28, 22 May 2012 (UTC)

Summary/voting user positions

  • west.andrew.g: I oppose the requirement of rollback. We have two real cases here:
  • Concern about over-use of reverts: This is already vetted by recent changes patrollers at large. They come to our attention via STiki's talk page, or in nightly talk page inspections for new users. This just doesn't happen often, but if it starts to, I would reconsider. Plus we have T#015 in the works to deflect bad press.
  • Concern about over-use of innocent: Forced peer-review is likely to lead to redundant work with minimal relative benefit. With the user-base at its current size, it seems unlikely these cases (if the exist) are ruining the party for the rest of us, there is just too much vandalism (as evidenced by minor drops in hit-rate% on popular days). Moreover, there is no incentive to casually over-using innocent in a community that rewards editing. Finally, AGF is relatively new, and while it lends even more subjectivity to classification, it could also eliminate some of concerns over "too much innocent."
  • However, I would support monitoring the investigation of frequent STiki users, i.e., > 500, >1000 classifications whose vandalism+revert rate is well below the norm. I could output a DB report of a user's actions which then could be fed into the ORT. West.andrew.g (talk)
  • Comments by Yaris678 (talk)
    • (policy-wonky point) This thread started as a discussion about whether or not to have an RfC, rather than as an RfC. If we are going to treat it like an RfC then it should be advertised more widely, as per WP:RFC.
      • Acknowledged. I don't want to see this happen, either, as it would invite a bunch of people who have no familiarity with our operations. West.andrew.g (talk)
    • I don't think an actual RfC is necessary because we may have got the salient points out in the open anyway.
    • Of these, the most important is the fact that the code currently available for restricting to Rollbacker is client-side, not server-side. Although this will deter casual vandals, they are easy to spot anyway. Using a client-side system introduces a new danger of appealing to people as a way to show off their programming skills by "hacking in". The fact that its not that difficult or impressive won't necessarily stop someone doing it and being jolly annoying when they do.
      • I wouldn't really be concerned if someone coded around rollback. STiki is two things: a queue, and a feedback mechanism. Someone who screws with those things is our concern. Does a barrier to entry invite a user the user to look into the code-base and possibly discover more malicious opportunities? Hard to say. I could probably implement rollbacker checks on the server side. Then an attacker needs to have rollback to wreak havoc. However, this probably isn't a major hurdle for them given they've already invested the time to dig through code and possibly develop programmatic attacks. Indeed, I am quite confident I could program a script whereby I could get a near unlimited number of accounts the rollback right without a single human action. Then, I could launch these against STiki's rollback-protected services. Just the same, I could use them against Wikipedia in general. Perfect security is not realistic in collaboration. Getting back to rollback: rather than talking prevention, I think ex-post-facto detection is more appropriate. If someone circumvents rollback and uses STiki appropriately, who cares!?!? If they mis-use, they can be detected via the channels we discuss below and elsewhere. West.andrew.g (talk) 17:45, 24 May 2012 (UTC)
    • The idea of allowing trusted users to review database info sounds promising. I would be against having a hard number of classifications to warrant attention because that leaves the system open to gaming. However, I agree that an editor with a very small number of classifications probably isn't worth worrying about (for this purpose) because an attack by lots of short term accounts would be obvious for other reasons. Of course if trusted editors want to look at classifications of new STiki users then that would help for other reasons. They may be able to give the editor a few pointers like "You can check for this sort of vandalism by..."
      • Yes, but I envision this happening in a quite offline manner. Someone would email/post me and say "hey, user X has 2000 classifications and his percentages just don't look right". I will respond (privately?) with files (i.e., a list of RIDs marked guilty/innocent/AGF) that can be fed into ORT (see below) for manual review. West.andrew.g (talk)
    • Andrew, what is ORT? I'm guessing this is a technical term that has passed me by.
      Yaris678 (talk) 16:20, 24 May 2012 (UTC)
      • ORT = "Offline Review Tool." A description is in the help documentation. Basically you can provide ORT a file with revision-IDs and then browse them quickly in a STiki-like interface (but there are no classification options, it's just for browsing edits, including those that are no longer most recent on their article). West.andrew.g (talk)
        • Thanks. Would the ORT tell the user the classification? Or would it be more the case that they have a list with RIDs and classifications for a given user, they then scoll through the diffs on the ORT and compare the RIDs to the list and work out if the classifications make sense. Yaris678 (talk) 17:25, 24 May 2012 (UTC)
          • At current, it does not display any "classification". It is not specific to STiki review and was developed with more generic intentions. However, as I implicitly suggested above, I could just produce 4 RID files for any user, one for each classification. West.andrew.g (talk) 17:47, 24 May 2012 (UTC)
            • Ah... must have missed your implication. 4 RID files for each user sounds like a jolly good idea. This has the added benefit that the RID checker will be in the right mode when they look at each diff. Should make the whole process very efficient. Yaris678 (talk) 18:41, 24 May 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Re-opening discussion

I think I might have been a little brash in my quick rejection of the rollback requirement above -- due mainly to a lack of prior incidents and a desire to see STiki's popularity grow. Appropriately, in the past 5 days, the milestones page has revealed 3 non-rollback users who were quite careless and uneducated in their use of the STiki tool. This brought bad press at CVU, ANI, and perhaps in the eyes of a large number of contributors. Myself, DBigXRay, and others should not have to go around doing damage control for the mistakes of others. In other words, my attitudes towards some type of qualification requirements are beginning to change.

Though there may be complicated ways to do this, at the current time I advocate a simple approach. I am about to be forced into a quasi-involuntary wikibreak (two weeks or so) and I'd like to see it in place before then. My draft proposal is as follows:

  • Anyone who has used STiki in the past will continue to have access (grandfathered in)
  • Any user with rollback will have access
  • Any user with X edits in the article namespace has access, where X>1000 (?)
  • Any user can request access on this talk-page, and we can grant explicit access as we see fit.
    • Perhaps I could give the regular users read-write access to a single DB table for the purpose.

I think we should continue to let users (who have access) operate unchecked; with manual review of existing users via ORT as we see fit (discussed above)

Thoughts on this? Thanks, West.andrew.g (talk) 06:05, 31 May 2012 (UTC)

The above proposal sounds very sensible. I would go with a 1000 edit limit for non-rollbackers.
If this could be implemented on the server side that would be preferable.
Arguably grandfathered rights should be removed from anyone that has caused trouble (even if down to inexperience, rather than malice). I'd expect this to be judged on a case-by-case basis.
As discussed before, grandfathered rights should also be removed in full after a time because anyone who has been a serious STiki user should be able to get Rollback after a few months any way.
Yaris678 (talk) 07:25, 31 May 2012 (UTC)
I fail to see the viability of a purely server-side implementation. We want to confirm that a user has permission (per our server), before they are allowed to commit an action on WP servers. This would mean both actions would need to be fired from STiki's servers. Without this, there would be a client-side branch that could trivially be programmed around. However, STiki should not become a man-in-the-middle for the MediaWiki API due to privacy and latency concerns. Such a branch seems necessary. Did you have something else in mind?
Note there are some complex token-passing cryptographical techniques that the CBNG folks and I discussed a long while back that could address a separate *part* of the issue (i.e., the ability to forge identities to the STiki server). Given my upcoming wikibreak and their incompleteness, I am not interested in implementing them at this time.
As I think I've said before, if one has the motivation to open up STiki and code around rollback -- let them. If they screw up they will be caught via our normal channels. Right now we're just concerned about stopping newbies with a bad case of edit-count-itis who don't know how to read a diff or interpret vandalism. These people aren't malicious and often apologize or retire when they get called out on their errors. Truly malicious individuals aren't STiki's problem: they are Wikipedia's problem. Open access models are fundamentally insecure and no matter how much obfusction we layer on top of them, it doesn't change this fact. Thanks, West.andrew.g (talk) 16:33, 31 May 2012 (UTC)
There is obviously some aspect of the architecture of STiki that I didn't get (and perhaps still don't). If it's going to be a lot easier to do it client side then do that. Your reasons make sense. And maybe the other stuff can be addressed later.
Yaris678 (talk) 16:54, 31 May 2012 (UTC)
In the immediate, the client-side strategy will be the one implemented. I'm more in curious in what you interpret "server-side" to mean here? Thanks, West.andrew.g (talk) 17:03, 31 May 2012 (UTC)
What I mean is that if the qualification requirement is implement on the server side, the STiki server won't serve you a RID if you do not have rollback.
I am guessing from you recent comments that the server doesn't actually check who is asking it for RIDs. Is that correct? i.e. if the STiki client asks for one, it gives it. Presumably the client tells the server that a certain user is logged in, but the server doesn't check that info. Crucially, I am guessing that the client doesn't pass the STiki server the password, that is only used by the client to access the Wikipedia server.
I am guessing you have done this to avoid anyone having an issue with your server processing their Wikipedia password.
Is that correct? If so then I can see why someone forging an identity to the STiki server could be an issue and that until that issue is addressed, implementing the qualification requirement server side can not be done robustly.
Yaris678 (talk) 18:18, 31 May 2012 (UTC)
Currently, the only reason the STiki server cares who are is to (a) Not serve you edits you have ignored, and (b) To do statistics over classifications (i.e., the leaderboard). All of your assumptions above are correct. STiki's server does not and will not handle user passwords. Currently users can audit how the password is handled on the client side via source-code. Such assurances would be impossible if it were passed to the server. Thus your understanding of robustness is precisely why I don't want to begin down this path. Can we imagine ways for STiki to verify identity w/o handling a password? Yes, this was some archived discussion, but again, not imminent. Thanks, West.andrew.g (talk) 19:13, 31 May 2012 (UTC)

Long ago, at what precise point I cannot say when, I recall suggesting that STiki should be limited to rollback-granted users, in the same way that Huggle is. There's a level of trust, and quality, attributed to users of the tool, in that way. They've proved they know how to deal with erroneous / vandal edits by manual tackling. Just my thoughts. Orphan Wiki (talk) 23:17, 31 May 2012 (UTC)

Users should expect to see this implemented client-side in the next release -- which won't be all that impressive, but should resolve the issue prior to my international travel stretch beginning on ~6/9. While I work on the code aspects, I wonder if someone couldn't modify WP:STiki (anywhere else in wiki-space?) to reflect this change in policy (even if they immediately revert afterwards so we can restore the minute it does go live). Thanks, West.andrew.g (talk) 02:19, 1 June 2012 (UTC)
It probably doesn't need a massive change to WP:STiki. Just change the first two sentences to "STiki is a tool used to detect and revert vandalism on Wikipedia. STiki uses state-of-the-art detection methods to determine which edits should be shown to end users, who must have the rollback permission." Yaris678 (talk) 09:31, 1 June 2012 (UTC)
Is that actually going to be the case, or is it the more nuanced set of qualifications discussed above? Allens (talk | contribs) 10:17, 1 June 2012 (UTC)
Good point. If its a complicated one, then maybe it needs its own section, rather than being half a sentence in the lead. Yaris678 (talk) 10:48, 1 June 2012 (UTC)
  • In the proposals at the top it also says editors having more than 1000 edits can be allowed. While I personally support Rollback rights for using tools, I guess allowing editors having 1000 "article space" edits (not talk or user space) can be allowed to operate this tool, as they gain an understanding of vandalism. They would be able to get rollback rights easily after some reverts with stiki , because the admins at wp:RFP/R often look for at least 50 vandalism reverts and not newbie to give Rollback rights. --ÐℬigXЯaɣ 11:30, 1 June 2012 (UTC)
  • Unless there is consensus to the contrary, I planned to implement the 4 conditions above with X=1000. I suggest we specifically scrutinize users with X>1000 but w/o rollback when they do participate. Pending how this turns out, we increase X, or eliminate the possibility altogether. I don't think qualifications warrants there own section, but maybe an enumerated sentence: "In order to use STiki, a user must: (1) ..., (2) ..., or (3) ..." -- no need to mention the grandfathering of existing users. Thanks, West.andrew.g (talk) 12:51, 1 June 2012 (UTC)
  • I've put a rough draft at Wikipedia:STiki/Sandbox. (The material about the requirements is at the bottom of the lead section; any place higher didn't format well for one reason or another.) All that has to be done once its formatting is right is to change the Download section links and copy it (except for the {{Sandbox notice}} template at the top) over the current Wikipedia:STiki page (noting where it's being copied from in the edit summary, for CC-BY-SA purposes). Allens (talk | contribs) 13:52, 1 June 2012 (UTC)

Thanks for trusting me. Andrew can you let us know from when do you plan to put STiki usage restrictions ? Just found another user abusing the tool, reverted and warned--ÐℬigXЯaɣ 17:41, 1 June 2012 (UTC)

? regarding first sentence, DBigXray? Allens (talk | contribs) 19:40, 1 June 2012 (UTC)
Need to tie up some loose ends around the code-base before I push a release; but I am aiming to get it done tonight (within 12 hours). Thanks, West.andrew.g (talk) 17:46, 1 June 2012 (UTC)
A little delayed after the server drama of last night. Now implemented! Thanks, West.andrew.g (talk) 06:23, 3 June 2012 (UTC)

Feature Request: Add {{Shared IP advice}} to warnings when appropriate

I recently had a message from a confused user about a warning for something he (?) didn't do; this was because it was a shared IP address. Twinkle, when warning an IP user, adds {{Shared IP advice}} after the warning. I suggest STiki should do the same when warning an IP user. This could be done in gui_revert_and_warn.java's warning_template. Want me to work up a patch? BTW, regarding that subroutine, what's this "|subst=subst:" doing? Allens (talk | contribs) 09:08, 26 May 2012 (UTC)

Acknowledged. This happens after every warning, regardless of level? See also Wikipedia:Substitution. West.andrew.g (talk) 12:22, 26 May 2012 (UTC)
If one has it set on in one's preferences (which is the default), yes - even after a block, actually. Shared IP Advice is also substituted, BTW.
I didn't see anything about "subst=subst:" in WP:Substitution, although I note that Twinkle is also doing it for its warnings. Ah. m:Help:Substitution is more helpful. So that's to make sure that recursive substitution is working, provided the inner templates are set up for it. Allens (talk | contribs) 13:40, 26 May 2012 (UTC)
Implemented in local source, will be pushed at next release (hopefully within the week, along with user qualification changes). Thanks, West.andrew.g (talk) 02:10, 1 June 2012 (UTC)
Thanks! I was about to inquire if you'd like me to create a patch... Allens (talk | contribs) 02:14, 1 June 2012 (UTC)
Included in tonight's release. Matter now closed. Thanks, West.andrew.g (talk) 06
24, 3 June 2012 (UTC)

STiki may be down

I was working on tonight's release and the STiki server became unreachable. Everyone else seeing this? Bad weather rolling through Philadelphia may to be blame. Stay tuned. Thanks, West.andrew.g (talk) 00:12, 2 June 2012 (UTC)

Rumor has it there was some "quasi-planned" building maintenance to occur tonight between the hours of 8PM-12AM (Eastern U.S. time). I say "quasi-planned" because none of the mailing lists which are supposed to broadcast these things did so. Apparently a printout in the elevator was the only notification given (and I wasn't in the office today). I have to assume the machine lost power and not just network -- so it should prove interesting to see if everything comes back up automatically. Hopefully they finish before midnight, so I can travel into the city to get it all back online if I have to. Thanks, West.andrew.g (talk) 00:54, 2 June 2012 (UTC)
I can't connect either. Traceroute stops at external2-border-router.seas.upenn.edu, but that may be a firewall effect. Allens (talk | contribs) 01:05, 2 June 2012 (UTC)
Me neither. I upgraded but still no go. So I guess the server is down Ttguy (talk) 03:33, 2 June 2012 (UTC)
Same here. Sunray (talk) 05:05, 2 June 2012 (UTC)
Same with me--ÐℬigXЯaɣ 05:32, 2 June 2012 (UTC)
both of you please move to WP:ANI or wp:DRN or discuss on your own talk pages, Talk:STiki is not the right place for this--ÐℬigXЯaɣ 13:45, 2 June 2012 (UTC)
The following discussion has been closed. Please do not modify it.

That might not be a bad thing. Some editors are using STiki for blanket removals from articles that they don't know much about. See for example: http://en.wikipedia.org/wiki/Special:Contributions/Gareth_Griffith-Jones Can it be reformed or can its users be overseen by someone please?Red Hurley (talk) 11:58, 2 June 2012 (UTC)

  • For such User related issues
    Wrong venue. Please move to WP:ANI
     – ÐℬigXЯaɣ 13:02, 2 June 2012 (UTC)
I don' t understand such anger over this:
http://en.wikipedia.org/w/index.php?title=Freshford%2C_County_Kilkenny&diff=495203875&oldid=495173898
Could you explain ,please! -- Gareth Griffith-Jones (talk) 13:28, 2 June 2012 (UTC)
The server (or the connection to it) are back up. Allens (talk | contribs) 14:33, 2 June 2012 (UTC)
It didn't come back up the easy way -- made a drive into the office this morning (after firing some angry emails about the situation last night). Backup battery kept systems alive for ~30 minutes after power loss (but network was probably gone immediately). My non-STiki machines came back online at midnight last night (they are set to turn on whenever power restores) -- leaving me a little concerned about what I'd find on "armstrong." Indeed, it did turn back on, but boot failed due to detected disk corruption. "fsck" was successful in recovery and everything came back online. Everything has been restarted (including backend processing). May take a little bit for caches to refill and the queues to populate to their typical vandalism density. Thanks, West.andrew.g (talk) 20:57, 2 June 2012 (UTC)
I trust that you've got a backup (ideally offsite) of the backend database with its records of human-judged vandal/good-faith-revert/innocent? Allens (talk | contribs) 21:25, 2 June 2012 (UTC)
Backed up nightly to a local external via rdiff-backup, which in turned is mirrored at a couple other universities. I also have non-networked physical drives hidden in multiple places along the U.S. East Coast :-). West.andrew.g (talk) 21:44, 2 June 2012 (UTC)

For future reference: "Butt" can be a legitimate last name...

See Talk:London Borough of Brent#Leadership of the Council; I've checked the council website, and unless someone's hacked into it, the name of the leader of the council in question is, in fact, Mohammed Butt. Oops... Allens (talk | contribs) 19:38, 29 May 2012 (UTC)

Good to know. However, for basically every profane term in existence it is probably to find a Wikipedia article (often album names) that use the term "legitimately." Does this mean we shouldn't use the terms for vandalism learning? Nope. However, I am sure these legitimate uses get worn out a bit with false-reverts, especially via AWB. As you point out, citations really help out in determining legitimacy. If I was watching such an article, I might frame uses of the questionable term with an HTML comment to let patrollers know that, in fact, the usage was acceptable. Thanks, West.andrew.g (talk) 19:58, 29 May 2012 (UTC)
Try figuring out which are the "legitimate" swearwords in a South Park episode article... I've seen cases in which the possible-vandal replaced some swearwords with others; in such cases, I hit the "pass" button and hope that someone with more knowledge of the show can sort it out. Good thought on the comment. Allens (talk | contribs) 20:24, 29 May 2012 (UTC)

CHANGELOG for 2012-06-03 release!

A quick report of the changes in the new version:

  • Users must now meet qualification conditions in order to use STiki. Prior users will be grandfathered in and not subject to these criteria. While possibly turning away new users, this is a necessary step to prevent abuse, maintain reputation, and ensure classification accuracy. A user must meet one of the following:
(1) Have the rollback permission.
(2) Have > 1000 article namespace edits.
(3) Receive special permission from STiki administration (by asking on this talk page).
  • Given that "templating the regulars" (WP:DTTR) seems to be a primary source of reputation loss for STiki, it has now been addressed programatically. Per the "options" menu, a dialogue can be popped with an informative message, and an opportunity for re-inspection can occur when one is about to revert a "regular." Currently "regular" is defined as a registered editor with > 50 NS0 edits. (T#015).
  • Previously, the "overuse of the pass button" warning was popped to users whenever they had 10 passes in a session. This is excessive for consistent users. Now, use of the pass button will be persistently tracked with long-term users seeing fewer/no warnings. This is stored in the settings file and therefore will not be persistent across different machines.
  • Thanks to hard work by User:Allens, the external link processing capabilities have been vastly improved. For GUI users, this will manifest itself when the "Options"->"Activate Ext. Links" option is enabled. The quite tricky case where just *part* of a URL changes is now handled correctly (T#009).
  • The {Shared IP advice} template is now appended to all IP user-page warnings; a message about creating an account to avoid DHCP issues.
  • MINOR: The persistent settings file now has refined permissions. Whereas the prior version just applied standard Java file permissions (and was world read-able). The file is now only read-writeable by the OS user that operates the STiki tool. No effect to end-user.

Thanks for your continued use of the tool. This will be the last release for a bit (unless something is seriously broken in this new one), as I am about to take a semi-involuntarily wikibreak (my Internet connectivity will be quite poor for 2-3 weeks due to travel). Try not to overwhelm me with bugs and feature requests to process my return :-). Thanks, West.andrew.g (talk) 06:37, 3 June 2012 (UTC)

Comments

Thanks Andrew for the latest new features, much appreciated. However, I have come here with a bug, somehow the {shared ip} template is given even to the registered users eg [1], [2] and is inappropriate. Please look into it, if possible.--ÐℬigXЯaɣ 09:20, 3 June 2012 (UTC)

I've emailed Andrew a patch that should fix it - I'm having some problems getting STiki to even partially compile locally, so I can't test it out even for compilation here. Allens (talk | contribs) 12:11, 3 June 2012 (UTC)
Fixed. That was a quite clumsy addition. File name has not changed (same date) but the code behind has. Thanks, West.andrew.g (talk) 14:13, 3 June 2012 (UTC)

Diff 496284476 for the "Dunchurch" article contains: <ref> www.coventrytelegraph.net/news/coventry-news/2010/01/04/pranksters-hit-dunchurch-with-homer-simpson-statue-92746-25521340/">http://www.coventrytelegraph.net/news/coventry-news/2010/01/04/pranksters-hit-dunchurch-with-homer-simpson-statue-92746-25521340/">http://www.coventrytelegraph.net/news/coventry-news/2010/01/04/pranksters-hit-dunchurch-with-homer-simpson-statue-92746-25521340/</ref> if done with external-links activation enabled. (Only the last http://... is enabled as an external link.) If external-links activation is not done, then it shows up as: <ref>http://www.coventrytelegraph.net/news/coventry-news/2010/01/04/pranksters-hit-dunchurch-with-homer-simpson-statue-92746-25521340/</ref> which is the same as is actually on the page. I'll see if I can figure out something... Allens (talk | contribs) 12:56, 8 June 2012 (UTC)

Local work on this is waiting until my Mac gets its OS upgraded to have Java 1.6 - I should be getting in the CDs for the first part of the upgrade tomorrow. (The newest version of STiki, primarily due to the much-needed security enhancements on the configuration file, won't compile/run on Java 1.5.) I am also looking at installing a debugging-use "switch" to display bare HTML (as if it were plain-text) instead of the interpreted version (JEditorPane's setContentType looks like the right way to do this). Allens (talk | contribs) 22:35, 11 June 2012 (UTC)
Good to hear about the OS upgrade -- sorry about the Java 6 features creeping in. My Java 5 compiler is a little funky under my current set up, so while I intended to leave it active to check compiles for your purposes, I ended up switching it back at some point. Strangely enough, when I do make the explicit switch it doesn't complain about the config file, but does complain about usage of Pattern.quote(). Any ways, good luck! Thanks, West.andrew.g (talk) 00:11, 12 June 2012 (UTC)

Sorry about the feature change

Hi, fellow STiki developer and users, I am sorry about changing the T#004 item on the feature table to done, I thought it was about the connection using HTTPS (which was made avalible in the previous release) rather than changing the server connection to HTTP rather than MySQL. Apologies again, Thanks,W.D. 13:46, 8 June 2012 (UTC)

Quite okay. Sorry for the terse revert thereof. Thanks, West.andrew.g (talk) 23:32, 11 June 2012 (UTC)

New requirements

I have never used STiki but was checking into the possibility tonight. As I understand it, I would either need rollback or 1000 edits to qualify to use this tool now. I also understand that this is a new requirement. I would like to give my opinion of this new requirement.

By the time a new editor reaches this new bar, I suspect they will have found their niche and will have become set in their ways. As I understand it, STiki is not all that much more powerful than TWINKLE. From what I understand, the advantage with STiki is in the targeting.

Maybe it is my great loss that I do not know the wonders that are included with STiki. If so, it is also a loss to Wikipedia because I could, even now, be fighting vandalism with it.

If the tool is actually useful, you may want to keep the bar at the level where users who are still finding their niche in the community qualify. Just sayin' - UnbelievableError (talk) 06:55, 10 June 2012 (UTC)

It's a difficult issue because it generally takes quite a long time for anyone to become used to the nuances of when edits should be reverted as if they were vandalism. After a while a good editor will know when a plain revert is warranted and when something with less WP:BITE should be applied. Unfortunately there have been a couple of cases where people were using tools like STiki without sufficient experience, and they can cause trouble (by upsetting new editors), and can bring a bad reputation to the tool (particularly when they regard use of the tool as rather like a game). There is no practical way to evaluate whether a particular user is ready for something like STiki, so I can understand why a fairly high bar has been set. Johnuniq (talk) 07:32, 10 June 2012 (UTC)
  • Thank you Johnuniq, for a detailed explanation. As mentioned above, we were forced to raise the bar, however this bar should not be considered as a barrier for contributing to the encyclopedia. AS from your CSD log I agree that you will be a good vandal fighter. Please check wp:VANDAL, WP:RCP and make a few (lets say 10-15) proper anti vandal reverts with twinkle. And We will be glad to allow you special access to use STiki as a trusted user. thanks. (On side note you can also request for WP:ROLLBACK as you are experienced enough, all you need is 50 anti-vandal reverts to get rollback rights )--DℬigXray 13:45, 10 June 2012 (UTC)
Thanks to both of you for your responses. Now I understand the situation. While anyone can create an account and wrongly revert a good faiths edit as 'vandalism', STiki allows one to mislabel edits more quickly and efficiently. I can see where that could be a problem. - UnbelievableError (talk) 01:49, 11 June 2012 (UTC)

Hi UnbelievableError,

I'm glad the replies helped. In terms of why STiki is different to other tools, such as Twinkle, you may like to check out Wikipedia:STiki#Comparison to other tools.

Yaris678 (talk) 17:48, 14 June 2012 (UTC)

 On hold until The User:UnbelievableError is ready. --DBigXray 14:40, 25 June 2012 (UTC)

Good Faith Reverts

Moved from User talk:West.andrew.g
 – DℬigXray 19:03, 11 June 2012 (UTC)

I don't know if this can or should be corrected but it bothers me seeing a "Good faith revert" when in fact what is taking place is a "Revert of a good faith edit".— Vchimpanzee · talk · contributions · 18:13, 11 June 2012 (UTC)

Hi Vchimpanzee, I believe you are talking about some revert done by a stiki user, would you be so kind as to provide the diff or the link of the said incident ? Thanks--DℬigXray 18:39, 11 June 2012 (UTC)
Here is the diff. I assumed the wording was automatic and not something the user did.— Vchimpanzee · talk · contributions · 18:49, 11 June 2012 (UTC)
  • Thanks for the diff, I see that this was a correct revert done by the User:Theopolisme. The edit summary was indeed the default stiki edit summary for WP:AGF reverts which is "Good faith revert of edit(s) by USERNAME using STiki" I agree that such reverts are actually ""Revert of a good faith edit." But I think both of them convey more or less the same meaning. For special cases the users have the option to change the default edit summary if they feel appropriate
  • @Andrew The default edit summary for AGF edits in twinkle is "Reverted good faith edits by USERNAME(talk): EXTRA COMMENT(if any). (TW)" which I believe is more accurate. I agree with User:Vchimpanzee and I think this small grammatical modification is worthy enough to be included in the next Stiki version. regards --DℬigXray 19:15, 11 June 2012 (UTC)
Thanks for the input.— Vchimpanzee · talk · contributions · 19:17, 11 June 2012 (UTC)
Modified in my local source code. Change will be pushed at next release. Thanks, West.andrew.g (talk) 20:23, 11 June 2012 (UTC)
Accepted
I know I'm late to the party but.. hey! It's me! Okay. Random. :) Theopolisme TALK 08:01, 13 June 2012 (UTC)
I would like to encourage users to add the extra comment in most cases. If the edit was made in good faith some kind of explanation as to why it was not kept is only civil. Yaris678 (talk) 17:53, 14 June 2012 (UTC)
For example this revert. Yaris678 (talk) 22:16, 14 June 2012 (UTC)

Current DDTR warning

I see some problems with this:

  • There is no policy against templating a regular; it is an essay, not even a guideline (and see Template the regulars for a counterargument). 'Many on Wikipedia suggest not "templating the regulars"' would be more accurate.
  • It currently happens even when no template will happen - when doing AGF. Even if a warning is desired for AGF, it needs to read differently. (One thought is to enable a different template/auto-warning for "regulars" - a message indicating that "there seems to have been a problem with one of your recent edits [linking to it] and I was forced to revert it; please examine and, if necessary, reply on my talk page", for instance.)
  • Something higher than 50 edits may be advisable - the German Wikipedia apparently requires 150 (non-reviewed) edits before a user is exempted from flagged revisions scrutiny, for instance. (Note that gui_display_pkg.get_user_edit_count will need to be changed also if the minimum edit count is to be above 50, incidentally.) If limiting to the article namespace (NS0), then the minimum should be at or below 500, however, for efficiency.

I've made the first revision in my local STiki source copy, incidentally. Allens (talk | contribs) 15:03, 18 June 2012 (UTC)

Out of curiosity, Allens, how often are you seeing this message? Thanks, West.andrew.g (talk) 14:25, 30 June 2012 (UTC)
Hi Allens,
I have never seen this warning myself. Would it be possible to copy the message onto the wiki so we can all have a look at it and edit it as appropriate? Maybe copy the original to WP:STiki/DTR warning and then copy your version over the top. Then we can see your changes and make our own and discuss it if needs be.
Similarly, could you extract the text of too-many-passes warning to WP:STiki/Passes warning
I know I could do that one, but you know your way around the code and I wouldn't know where to begin.
Yaris678 (talk) 07:27, 19 June 2012 (UTC)
Good idea; certainly. Will be up in a few minutes (I'm still waking up...). Allens (talk | contribs) 12:41, 19 June 2012 (UTC)
The DTTR one is up at Wikipedia talk:STiki/DTTR warning, and the Pass one (including some minor suggested modifications) is up at Wikipedia talk:STiki/Pass warning. (Their text is found in the gui_globals.java file in the gui_support directory, incidentally.) Allens (talk | contribs) 13:55, 19 June 2012 (UTC)
Response to be found in the next section. West.andrew.g (talk) 14:19, 30 June 2012 (UTC)

Permission

Can I Have permission to use STiki. Grizzly1110 (talk) 20:17, 20 June 2012 (UTC)

I suggest that you probably need to get some further familiarity with Wikipedia and its processes first. For instance, on List of animal sounds, it is in fact considered vandalism to blank a page (in all but a few cases); one should instead propose it for deletion (Twinkle has some convenient means of doing so, labelled with acronyms like "PROD")... or, better yet, add reliable sources (moreover, one of the external links on the page may qualify as a source; I've changed the tag from {{unreferenced}} to {{refimprove}}) - perhaps from Wikitionary? Allens (talk | contribs) 20:44, 20 June 2012 (UTC)

So is the answer yes or no. Grizzly1110 (talk) 22:03, 20 June 2012 (UTC)

  • Dear Grizzly1110 we thank you for your interest in STiki, but we need to make sure that STiki is not misused by the user. We will be glad to allow you a special access to the tool if you do the following
  1. spend some time in understanding WP:Vandalism and how to handle it, and correct usage of warning templates .
  2. Install WP:Twinkle and follow the methods of WP:RCP to make anti-vandal reverts. It would be easier for us to judge your understanding if you have more than 50 correct reverts.
When you are ready, you can post a message and we can take a look into your case. Please take your time in understanding the anti-vandalism policies as any reckless use of the tool will get you blocked from Wikipedia instantly. --DBigXray 22:18, 20 June 2012 (UTC)

Hey I have to say I installed Twinkle BUt I Don't know if I HAVE Windows 9 or Late!?!? — Preceding unsigned comment added by Grizzly1110 (talk • contribs) 22:33, 20 June 2012 (UTC)

 On hold until the new user shows an understanding of Vandalism and addresses recent concerns mentioned on talk page. --DBigXray 11:18, 21 June 2012 (UTC)

help please I only have internet explorer 8. Grizzly1110 (talk) 20:16, 22 June 2012 (UTC)

Self reverts

Just logged into STiki. Started using the STiki queue and the first two edits served were both self reverts:

Seems to be working fine now though. Hmmm... Yaris678 (talk) 20:12, 22 June 2012 (UTC)

Hmm... now I'm getting served a 38-day-old STiki edit by an established user. I am guessing this is a sign of queue exhaustion! Yaris678 (talk) 20:53, 22 June 2012 (UTC)
...and a bot edit or two or three or more... stopped counting Yaris678 (talk) 21:11, 22 June 2012 (UTC)
Seems like the list is completely exhausted :P good job everyone! ;) Anir1uph (talk) 21:19, 22 June 2012 (UTC)

D'oh! I was actually using the WikiTrust queue! What a mistake! Now using the STiki queue and it seems to be working fine. Slightly low hit rate.... but that is probably a touch of genuine queue exhaustion! Yaris678 (talk) 21:48, 22 June 2012 (UTC)

Permissions

I have used Twinkle, Huggle, and now AWB. I have extensive editing of vandalism and am a current instruction at the Wikipedia CVU Academy. I am looking to have access to STiki in order to have a better understanding of how it operates. I will use it sparingly as Huggle is my 1st choice (for now at least); however, I will want to make sure that any new user who wants training on it is adequately taught. Thanks in advance. --Morning277 (talk) 16:38, 25 June 2012 (UTC)

Hi Morning277,
You already qualify twice over. You have over 1,000 article-space edits and you are a rollbacker. Either of these should mean that you can use STiki. Requesting is needed as an alternative to these, not in addition.
Download it and give it a go. If you have problems let us know.
Also, if you want to know more about what makes STiki different, check out Wikipedia:STiki#Comparison to other tools.
Yaris678 (talk) 16:45, 25 June 2012 (UTC)
Thanks for the information. I will check it out now. Thanks again. --Morning277 (talk) 17:07, 25 June 2012 (UTC)

 Already done as user is qualified --DBigXray 17:09, 25 June 2012 (UTC)

PRAISE

Whoever wrote this script is a genius. I have only been using it for a couple of days but must say that it beats all other tools for fighting vandalism that I have ever used. --Morning277 (talk) 15:50, 27 June 2012 (UTC)

I quite agree. Check out Wikipedia:STiki#Credits and more information for the names of the people responsible.
Also, I notice that you mostly use the ClueBot NG queue, which is based on data from User:ClueBot NG.
BTW, I probably wouldn't call STiki a script. It is written in Java not a scripting language.
I am glad you like STiki. I am also very impressed with the number of classifications you have made. 1572 in 2 days!
Yaris678 (talk) 08:27, 28 June 2012 (UTC)

Update

I was still running the January version until this morning, when i realized there had been an update :P benzband (talk) 09:04, 28 June 2012 (UTC)

  • That happens if you dont Keep in Touch :) link --DBigXray 15:49, 28 June 2012 (UTC)
    • Hmm, so now there is a good faith button but i wonder would this 1 or this 2 or this 3 seriously count as good faith? (i don't think so, but then that's just mho) benzband (talk) 09:26, 29 June 2012 (UTC)
  • Agree1 was indeed Good faith revert, Kudos to Morning for that wise decision ( on a side note: I have tried that beer )
  • no Disagree 2 and 3 were clear cases of vandalism actually. Editors should try to use vandalism button for clear cases of vandalism, so that the erring IP/user may be auto warned and auto-reported for block (if needed) at WP:AIV by STiki.
  • If one is certain that the edit is unhelpful and needs to be reverted but a choice is to be made between Vandalism and Good faith then in my opinion it is better to Assume good Faith ;-) --DBigXray 12:33, 29 June 2012 (UTC)
I agree that those last two were vandalism. Arguably the first one was too. I'm sure the IP just thought he was having a laugh but that isn't the same as contributing to the encyclopedia. GF revert is for when it is reasonable to assume that the editor was trying to improve the encyclopedia but got the wrong end of the stick somewhere.
Remember that the first level warning is very polite and does not accuse the recipient of vandalism.
Yaris678 (talk) 12:52, 29 June 2012 (UTC)
Understandable... but I don't think the existence of said beer means that it is at all likely that the IP thought he/she was improving the article by mentioning it in that way in an article that was blatantly not about the beer. So I'd have called it vandalism. That said, I tend not to bother with warnings for a first offence by an IP and I don't mention vandalism in my edit summaries, so the effect would be pretty similar. Yaris678 (talk) 15:59, 29 June 2012 (UTC)
Yeah i'd have called it vandalism too… as for your custom summary i'll adopt steal that idea next time i use STiki as it seems most sensible. benzband (talk) 16:10, 29 June 2012 (UTC)
I can't see how someone could pursue and edit war via STiki. Obviously people can lie in their edit summaries... but that applies to any edit summary. Yaris678 (talk) 17:13, 29 June 2012 (UTC)

Agreed, but we must not forget that a vast majority of Wikipedians (even old ones) are not aware what STiki means or is. --DBigXray 17:42, 29 June 2012 (UTC)

Ah yes, 'inconstructive' is even better. benzband (talk) 18:00, 29 June 2012 (UTC)
But isn't a true edit warrior going to think the other edit is unconstructive. I agree that most editors haven't heard of STiki, but there is a wikilink. Hmmm.... Yaris678 (talk) 18:05, 29 June 2012 (UTC)
No when you simply revert a page then the by default edit summary is similar to the one you use. Not much of an issue though, was just sharing my concerns. :) --DBigXray 20:17, 29 June 2012 (UTC)
Rollback

I've also noticed that i can no longer use rollback in the updated version… :-( benzband (talk) 18:40, 29 June 2012 (UTC)

The check-box is gone. Every revert/good-faith action now results in a rollback action being initiated. If multiple edits will be rolled-back, this fact is represented in the visual diff. If you do not have the native rollback permission on Wikipedia, STiki will perform multiple actions/queries behind the scenes in order to recreate that functionality ("software rollback"). Thanks, West.andrew.g (talk) 13:53, 30 June 2012 (UTC)

It would appear that I'm in reverse

Last night, I returned to my editing with STiki, following a two weeks holiday without a PC. This morning, I checked the leader-board statistics to see how my 14 days absence had affected my records. I particularly noticed these three:

  1. Last column – total for this month – was adjusted whilst I was away to reflect that the the May/June total had been subtracted – it had been showing a combined two-monthly total of 5,810 – to 3,007 (June 28)
  2. First column – total STiki use – has increased by 218 from 6,044 to 6,262 (June 29)
  3. Last column – following yesterday's editing – has been reduced by 231 to 2,994 (June 29) rather than increased to 3,225

I had assumed these statistics were automatically produced. Any ideas on what has happened here?

Kind regards,

Gareth Griffith-Jones (talk) 08:13, 30 June 2012 (UTC)

A little jet-lagged here and having a hard time parsing the above. I am thinking this goes back to the fact that "uses this month" does not count the "number of uses in the current calendar month (June)" instead it measures "number of uses in the last ~30 days." I wasn't really interested in totals by calendar month, but rather, some metric of "recent use." Would this explain everything? If yes, maybe update documentation to be more clear. Thanks, West.andrew.g (talk) 13:07, 30 June 2012 (UTC)
Column header is actually written by my script, so I've went ahead and updated both the article and script accordingly. Thanks, West.andrew.g (talk) 13:38, 30 June 2012 (UTC)
Well that explains it all :) --DBigXray 14:01, 30 June 2012 (UTC)
I still cannot understand why the figure would reduce though. Remain the same, yes, if 30 or 29 (whichever way you interpret it) days ago there was no use, but how can it reduce by any figure, let alone 231?
Odd, isn't it, or am I missing something? -- Gareth Griffith-Jones (talk) 15:51, 30 June 2012 (UTC)
If 30 days ago you made 500 classifications and today you make 250 classifications, then when the leader-board updates tonight the last column would reduce by 250. You said you were only absent for 2 weeks, so wouldn't you have been active some 30/31 days ago? I can manually audit your STiki history use, but I am pretty confident everything is sound here. Thanks, West.andrew.g (talk) 16:07, 30 June 2012 (UTC)

Once again I am indebted to you, Andrew. Your numerical analysis is now perfectly clear to me. Thank you again. Best wishes, -- Gareth Griffith-Jones (talk) 16:22, 30 June 2012 (UTC)


Feature Request: Show probabilities and/or recent reversion rate

I have noticed, as west.andrew.g had pointed out was likely, that the longer one goes with a given queue the lower the proportion of true hits gets. In order to tell this (so as to know when to switch queues and/or take a break), it would be nice to do one or both of:

  • Showing what the current probability (or equivalent 0-1 rating) is of the edit being "bad";
  • Showing the recent reversion rate (rate of either vandalism/spam or "good faith revert" classifications), say over the past 100 or so edits.

-- Allens (talk | contribs) 03:27, 21 May 2012 (UTC)

It occurs to me that a built-in chi-square comparing recent reversion rates with one's overall average could be of use, but I suspect it would require too much data to be that useful. Allens (talk | contribs) 10:01, 21 May 2012 (UTC)
Looking at this issue from the perspective of the leader board, it would be helpful to know the predicted percentage of vandalism in the edits that the user classified, for comparison with how much vandalism they actually identified. Yaris678 (talk) 12:40, 21 May 2012 (UTC)
Hmm... good point, although this would be only for vandalism/spam and not for "good faith revert" (unless, for the STiki classifications, West.andrew.g has enough data to start predicting those separately). Allens (talk | contribs) 14:45, 21 May 2012 (UTC)
I seem to remember far back in STiki's history there was a desire to show the vandalism probability (you can have at the archives, if you wish). This was rejected (and will continue to be) on the basis of bias. Let's imagine you are *completely undecided* on whether an edit is vandalism or not (lets pretend the other classifications don't exist). However, you see that the probability is 99.999%. I feel this would make some users more likely to lean towards vandalism on the basis the user feels the algorithm knows something they don't (and especially that poor prior user reputation might be driving this, in which the case there could be a sentiment the user "probably deserves it (another vandalism classification")). I want pure and clean human responses.
Now, basic statistics are another matter. I can implement a dialogue that shows things like "number of STIki users online", "recent vandalism %", etc. This added as a feature request up top. Thanks, West.andrew.g (talk) 16:11, 21 May 2012 (UTC)
In table as T#014. You seem to generate all the "medium-low" priority requests, so I don't know how many of these I'll be able to push out in the next release (I've taken care of all the "medium" ones in a local source) -- and anymore than 1 hour of coding a day between 1:30-2:30AM has me feeling guilty about dissertation writing. West.andrew.g (talk) 16:18, 21 May 2012 (UTC)
Good point on the probabilities (I will confess an ulterior motive of curiosity!). Understood fully about the dissertation writing; it is the priority (that and writing up publications)! (My own Wikipediaing is likely to reduce significantly for about 5 weeks later this summer, when I'm teaching a summer class...) I'll do my best to write up a patch whenever I can for any suggestions, although I have no idea how to do so for the database... Allens (talk | contribs) 18:46, 21 May 2012 (UTC)
Yeah, don't worry about a patch here, your resources are best spent on the link parsing issue. This is basically just going to be a couple queries dumped into a dialoge box. FWIW, I will be basically off-wiki for two weeks beginning around 6/9. West.andrew.g (talk) 19:25, 21 May 2012 (UTC)

I've been thinking about the best way of indicating queue exhaustion without telling the user the predicted probability of an edit. Perhaps you could provide two statistics for a queue:

  • Hit rate - The percentage vandalism from the last 20 edits.
  • The time since the 10th previous edit was classified (i.e. the median period relating to the edits covered by the hit rate, I can't think of a good name for this one.)

If the hit rate is low that indicates that it may be time to try another queue, unless the time is high, in which case some new vandalism may have appeared.

It may be worth having the stats for each queue next to that queue in the revision queue menu. That would mean that a user then knows which queue looks like the best one to go for. Potentially, you may even find that users find these stats interesting. I think I will. That could help to encourage people to do more work with STiki Yaris678 (talk) 18:34, 24 May 2012 (UTC)

With the time wasted getting the server back online and what not; I have to unfortunately report this feature did not make it into this release. I do see why it will be a valuable resource, and I promise everyone will see it the next one. Thanks, West.andrew.g (talk) 06:29, 3 June 2012 (UTC)

White-list

Is there a possibility to add a STiki white-list, such that edits by experience users (say > 40000 edits) are automatically excluded from the STiki list (assuming that they they must be knowing what they are doing while editing articles). Also, such a white-list of experienced editors is used in Huggle. I am new to STiki, so forgive me if such a request has already been discussed. Thanks! Anir1uph (talk) 00:57, 17 June 2012 (UTC)

When you say the STiki list... were you using the ClueBot NG queue? I have said before that there is an argument for having a whitelist for that queue because it only looks at an edits content, not at a user's reputation. How frequently do you see such edits? Such edits come up fairly rarely in my experience. And even if the edits were excluded, the queue would include innocent edits by new users... so the be thing is: Be careful.
But yes, STiki users could be saved a small amount of time looking at blatantly innocent edits if the ClueBot NG queue was filtered by a white list. I would suggest that much fewer than 40,000 would be required to get on the white list. Maybe 2,000 edits in article space?
Yaris678 (talk) 19:59, 17 June 2012 (UTC)
Yes i mostly use the ClueBot NG queue, but what am highlighting is the STiki software which processes that queue and sends it to STiki users. And yes, such edits are rare, but when we get towards queue exhaustion, such edits are requested to be judged with increasing frequency, and sometimes they are quite obviously decent edits done by some experienced editor to maintain/improve the article.
I have also noticed that when an experienced editor makes a mistake, the mistake is reverted most of the time by the editor him/herself, and diversion of STiki's assets to check such cases is not required, as they are not vandalism, just mistakes that are soon corrected without intervention of STiki.
Also, i am not capable of recommending criteria for inclusion of editors into a white list, due to obvious conflict of interest, as i myself have quite recently crossed 2000 edits in article space! :D Anir1uph (talk) 21:34, 17 June 2012 (UTC)
Congratulations on the 2,00 edits.  :-)
That is a good point about queue exhaustion. Queue exhaustion is a more frequent occurrence now because we have more editors. Therefore, a white list now will be more useful. It will mean that STiki users are able to pursue queues even longer and revert even more vandalism!
Yaris678 (talk) 22:05, 17 June 2012 (UTC)
Thanks you! Yes, that is exactly my point. Anir1uph (talk) 22:30, 17 June 2012 (UTC)
I understand the idea. However:
  • Sometimes reverting a "regular" is indeed necessary, particularly when the person didn't spot that something went wrong with another anti-vandalism tool (due to server load or whatever) such as Huggle or Igloo; see my talk page for two (very) recent instances. Both users in question were rollbackers with over 6000 edits (over 12000 in one case).
  • If the number of edits in question is to be in the article namespace (NS0) only, then it will be difficult to check this for more than 500 edits (although this can be increased to 5000 if the STiki server is granted an account with the "bot" flag).
I suspect the intent of this may be best done via a "meta" queue combining the CluebotNG and STiki/metadata queues, with the latter including more user-based features. Allens (talk | contribs) 15:02, 18 June 2012 (UTC)
Hmmm. OK! This was just a suggestion for improving, but I understand the difficulties too. Thanks!
Quite welcome; thanks for the suggestion! Allens (talk | contribs) 12:39, 19 June 2012 (UTC)
I’m thinking about what Allens said about occasionally coming across an edit by an experience editor that needs reverting. Obviously its good if you can revert such edits… but it is getting away from the purpose of STiki. Andrew has always been clear that he wants STiki to vandalism focused. The reverts for such experienced editors will be almost exclusively good-faith reverts.
I think experienced editors crop up in the CBNG queue at a higher rate the further into the queue I get. If we exclude, or at least demote, experienced editors then I can imagine that STiki users will be able to keep going for longer before experiencing symptoms of queue exhaustion.
If STiki could have access to number of article-space edits up to 5,000, then I can imagine it would help if the CBNG probability of vandalism for registered editors was divided by max(1, numNS0edit/50), where numNS0edits is the number of edits to article space, up to a maximum of 5,000).
I have just made this formula up but do you see what I mean?
Yaris678 (talk) 15:30, 25 June 2012 (UTC)

Or one can directly use the white-list used by Huggle. (or modify it in any way desirable and then use it.) Anir1uph (talk) 09:38, 26 June 2012 (UTC)

There is more discussion here than my jet-lagged brain feels like entertaining at this point. My viewpoint is best summarized by Allens with "the intent of this may be best done via a 'meta' queue combining the CluebotNG and STiki/metadata queues, with the latter including more user-based features". The idea should not be to draw lines in the sand with explicit lists, but to implement them as features and let algorithms learn those thresholds. BTW, I am not sure that CBNG has no user-based features; I know that Bayesian language probabilities drive their approach, but I also think some metadata is tossed in at a later stage. I generally would prefer to let the 3rd party queues exist in their purest form and hack away at our "metadata" approach in the future. No action will be taken on this immediately, but it will be handled implicitly when the STiki/metadata classifier is refined in the future (with user edit count as a standalone feature). This logic can then be combined/transferred to the benefit of the CBNG queue. Thanks, West.andrew.g (talk) 15:14, 30 June 2012 (UTC)
Thanks for your response and explanation. I hope you get time to bring it to fruition Anir1uph (talk) 16:19, 30 June 2012 (UTC)

User Name change

Hi!...I recently had a user name change from Srikarkashyap to Strike Eagle..I have ~800 reverts using my old account(Srikarkashyap) while I have done ~280 using the new user name.Hence, I request both the accounts be merged into one to avoid any future confusion.Thanks! ϮheჂtriԞeΣagle Sorties 05:53, 17 June 2012 (UTC)

Warning messages now on the wiki

Thanks to Allens for extracting the warning messages from the code.

I would like to encourage STiki users to have a look at Wikipedia:STiki/DTTR warning and Wikipedia:STiki/Pass warning and see if there are any improvements you can make.

Just edit those pages as you would any other page... or discuss it on the relevant talk pages.

Yaris678 (talk) 08:57, 20 June 2012 (UTC)

I will integrate the changed messages into the next release. However, should these pages require significant modification in the future, it is probably preferable to ping everyone with a message on the main talk page; as expecting casual users to watch at such depth is a bit unreasonable. Also, it should be mentioned that modifications to those pages are not immediately reflected within the tool. Thanks, West.andrew.g (talk) 14:37, 30 June 2012 (UTC)

Cannot seem to connect

I use STiki usually on my laptop while at home. It works fine then. But when I try to use it from my institute's computer lab (which is a different ISP provider, network etc), i get the following message display: Screenshot (I am not sure if i am breaking any copyrights by putting this on my fb wall, if i am, kindly inform me!) The operating system is the same as mine - Win 7. Points 1, 2 and 4 in the error message are not applicable, so it seems there is a problem with 3. Any suggestions/how do i fix this? Thanks! Anir1uph (talk) 11:39, 27 June 2012 (UTC)

Whereas I can't connect to Facebook from work!
So I can't see your screenshot. However, I suspect that it is because your institute has a firewall which doesn't like you accessing a remote database using MySQL. See T#004 above in #STICKY: Known Bugs and Feature Requests.
I know when I had a certain firewall on my home machine I had to tweak its preferences to put it in "game mode". That allowed STiki to work. I am guessing that your institute won't allow you to do that.
Is that consistent with point 3 in the message?
Yaris678 (talk) 12:10, 27 June 2012 (UTC)
Thanks! Yeah that is exactly what the message says, that "Port 3306 is not open (MySQL) due to a firewall or your network's admin settings." Hmm. yeah i just saw T#004. Cool.
What if i try to use STiki using a proxy service? I usually access sites which are blocked by the courts/ISP via Ultrasurf. But once i forgot to restore normal settings and started using Wikipedia using the proxy, i got a warning message about blocked open proxies. Will i be able to use STiki safely using such way-arounds? Anir1uph (talk) 12:49, 27 June 2012 (UTC)
Wikipedia makes a best effort to block open proxies. Since STiki hooks into the Wikipedia API you wouldn't really be able to use STiki through such an IP address (though the STiki server itself does not care). See Wikipedia:WikiProject_on_open_proxies and Wikipedia:Open_proxies. However, this does not prevent you from using (1) an open-proxy which is not on the block list (the coverage is woefully incomplete), or (2) a "closed" proxy which might require registration or is privately operated. I'm not familiar with the software you are using, in particular, but I assume its popularity is one reason its IP addresses are on the block list. There may be some challenge finding a proxy that allows MySQL:3306 communication, though, as most (I am guessing) are limited to HTTP and other standard ports. Thanks, West.andrew.g (talk) 14:08, 30 June 2012 (UTC)

CVU STiki Request

Could User:Geraldshields11 please have STiki permissions, for I am instructing him/her at the CVU? Thanks, W.D. 17:10, 28 June 2012 (UTC)

Accepted WP:CVUA members and their Trainees are trusted users, Kindly grant access (per discussion Wikipedia_talk:Counter-Vandalism_Unit/Academy#New Requirements for using STiki )--DBigXray 08:09, 29 June 2012 (UTC)
STiki would like to apologise for the delay in this service due to leaves on the line. Normal service will be resumed shortly. Yaris678 (talk) 16:52, 29 June 2012 (UTC)

Hello all. Thanks but as of 10:27 PM EST, I do not have permission to log in. Geraldshields11 (talk) 02:28, 30 June 2012 (UTC)

 Done Should now be enabled. Thanks, West.andrew.g (talk) 04:42, 30 June 2012 (UTC)



Archive 1←Archive 4Archive 5Archive 6Archive 7Archive 8→Archive 10
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:STiki/Archive_6&oldid=1138272958"