Jump to content

Wikipedia talk:STiki/Archive 13

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10Archive 11Archive 12Archive 13Archive 14Archive 15→Archive 20

Errors

I just started my daily reverts with STiki today and found that all my reversions bounced back as "conflict or error" errors. What gives? hmssolent\You rang? ship's log 13:33, 19 August 2013 (UTC)

Second that. It started couple of hours ago. Widr (talk) 13:36, 19 August 2013 (UTC)
Not good. Can someone run from terminal and let me know if there is any output? This will be hard to debug given my current location and testing ability. I'll search online and see if there might have been an API update that I wasn't aware of. Thanks, West.andrew.g (talk) 13:46, 19 August 2013 (UTC)
I've clicked the Vandalism or AGF button atleast two dozen times, with it going forward, but My COntribs shows nothing neither does the edit count. Some of them were nasty edits. --Rsrikanth05 (talk) 15:59, 19 August 2013 (UTC)
Note that you can still undo the edits manually, by clicking the "article" link. Widr (talk) 16:50, 19 August 2013 (UTC)
Same problem. It is showing Conflict or error/Check page hist. I'm manually undoing by "article" link, but it is time-consuming and lengthy.--AsceticRosé 17:45, 19 August 2013 (UTC)
I will be right on it when I leave work, shortly. West.andrew.g (talk) 19:06, 19 August 2013 (UTC)
I ran in cmd.exe java -verbose -jar , and when I tried Good-faith revert, it produced: 'An edit (not rollback) failed to commit. The server returned code "badtoken" and details "Invalid token".'
When I tried rollback it produced:

A rollback failed to commit. The server returned code "badtoken" and details "In valid token"
Bad token when trying to RB RID:569260249
Token was: 0fbc1284811d65ff9977284defdcdd77+\
Token obtained at: 20130819193959
Session cookie was: enwikiUserName=Atethnekos; enwikiUserID=6696749; enwikiToken =70fca4b55ebbbdcbe04673637b9b7097; enwiki_session=adc63cc844efcc1e120fc875c07e00 99
Refetching token obtained: 25f760b234a4ee6c20d14d42144b7291+\

--Atethnekos (Discussion, Contributions) 19:42, 19 August 2013 (UTC)

EMERGENCY RELEASE INITIATED: Everything was broken as a result of this WMF change. An updated STiki version has been posted. Please confirm its operation. Everyone will need to upgrade. We should also be thinking of how to update STiki users of this fact. We can get a list of recent users by sorting the leaderboard by "last use" and then place a form-message to their talk pages. Assuming their use is recent, I do not believe these constitutes spam given the circumstances. Can a community member undertake this task while I continue to clean up the technical mess? Thanks, West.andrew.g (talk) 23:09, 19 August 2013 (UTC)

Works for me. I've made a template Template:Upgradestiki which can posted on user talk pages just write {{Template:Upgradestiki}} on a new line at the end of a user's talk page. The list of User talk pages that already have the template will show up at: [1] --Atethnekos (Discussion, Contributions) 23:41, 19 August 2013 (UTC)
Sounds good. Thanks for the initiative in doing this. Thanks, West.andrew.g (talk) 00:01, 20 August 2013 (UTC)
The template is now included on the first 100 users of the Wikipedia:STiki/leaderboard when sorted by most recent "last use". P.S., thanks for your kind words here and on my discussion page. And good job with the fix.--Atethnekos (Discussion, Contributions) 00:43, 20 August 2013 (UTC)
Thanks to both of you for getting this taken care of. The new version seems to be working perfectly for me. Jncraton (talk) 01:09, 20 August 2013 (UTC)
Thanks. Will try once I get home as Java is blocked in my corporate network. hmssolent\You rang? ship's log 06:31, 20 August 2013 (UTC)
BTW, any changes to the interface in the new version? hmssolent\You rang? ship's log 06:33, 20 August 2013 (UTC)

Seems to be working fine. --Rsrikanth05 (talk) 11:04, 20 August 2013 (UTC)

My edits?

I have made several edits, but can not see anything in "my Contribution:. Version 2.1 Tito☸Dutta 11:14, 22 August 2013 (UTC)

Sadly the version number of STiki doesn't tell you everything you need to know. You need the release of 2013-08-19. If you download that from WP:STiki then STiki should work.
See also: #Errors
Yaris678 (talk) 12:08, 22 August 2013 (UTC)
Yes, code has now been written that will make this notification more elegant in the future. The server now stores a "minimum required version" datapoint which the client checks at startup. If the WMF does something odd again, I can disable old copies and pop an information dialogue. Thanks, West.andrew.g (talk) 01:15, 26 August 2013 (UTC)

STiki revert

Reverts of STiki edits] are not being notified by Wikipedia notification. The possible reason seems to be: I don't watchlist my STiki edits (otherwise there will be hundreds of pages in my watchlist in every few days). Any way to get notification of such revert? --Tito☸Dutta 22:33, 24 August 2013 (UTC)

While possible to detect with some heuristics, how would you suggest such notification takes place? These reverts should be getting enqueued with high probability, so they become checked by whomever is active on the STiki tool. West.andrew.g (talk) 01:13, 26 August 2013 (UTC)
You sure you weren't notified about the revert via Notifications? See mw:Echo/Feature_requirements#Edit_reverted... Theopolisme (talk) 01:32, 26 August 2013 (UTC)

Admin edits

Can we remove admins' edits, such as User:Dougweller's edit here from STiki's possible non-constructive edits queue? --Tito☸Dutta 09:53, 25 August 2013 (UTC)

Sounds like a good idea to me. lol. Thanks. Dougweller (talk) 11:31, 25 August 2013 (UTC)
STiki relies on its machine-learning derived model to make predictions -- and I am generally not in favor of writing explicit filters that circumvent this logic. A quick query confirms that admin-performed edits are extremely rare in the queue. Such a filters/check would also incur bandwidth costs -- so at the current stage I do not see a great advantage in implementing such a check. Thanks, West.andrew.g (talk) 01:23, 26 August 2013 (UTC)
See T#029 in the request table and below discussion regarding rollback/review/admin edits. West.andrew.g (talk) 14:24, 27 August 2013 (UTC)

Can't download

When I click the download link for the latest version it automatically redirects to Andrew's home page and doesn't actually download anything...? Thanks. — kikichugirl inquire 17:19, 26 August 2013 (UTC)

Nope, Chrome time and time again. Somehow working now. :D — kikichugirl inquire 05:36, 27 August 2013 (UTC)
I was transferring my web server and playing with some of the path forward settings. All should now be functional. I am trying to migrate all my stuff off of UPenn systems, as my account termination is imminent there. However, my "www.cis.upenn.edu/~westand" should transfer for at least one year to a new host behind "www.andrew-g-west.com". However, if anyone knows how to do automated link search and rewriting across WMF properties, I would love to hear how I could make my life a touch easier in this transition. Thanks, West.andrew.g (talk) 14:32, 27 August 2013 (UTC)

Edits by autocon-review-rb users and admins

STiki often brings up legitimate edits by users who are reviewers and/or rollbackers, and admins. Probably no STiki user classifies them as either good-faith or vandalism, and no such senior editor/admin is likely to make any vandalism. Although we classify them as innocent, any accidental click on vandalism button will create embarrassment. As such, should not STiki be programmed in a way so that it doesn't collect edits made by any such user? Or am I missing any other technical issue?--AsceticRosé 12:30, 27 August 2013 (UTC)

Hi AsceticRose,
On the face of it, this request is similar to #Admin edits. Andrew decided admin edits are too rare to expend the bandwidth on checking. However, I suspect that reviewer and rollbacker edits would be more common in the queue. Furthermore, their frequency (and the frequency of admin edits) will increase as we get deeper into the queue. This might mean that its value would increase over time as the number of STiki users increases.
See also: Wikipedia talk:STiki/Archive 12#Stuff that makes it less likely that something is vandalism
Yaris678 (talk) 12:46, 27 August 2013 (UTC)
Added to feature request table as T#029. This will likely be an option(s) in the GUI as to whether one wishes to see the edits made by such users (with a default option *not* to view them). Really these things should be encoded and trained as machine-learning features so we don't have to write these manual rules, but I have nowhere near the free cycles needed to make that happen right now. Thanks, West.andrew.g (talk) 14:27, 27 August 2013 (UTC)
  • To add to this suggestion, can you highlight Username (no permission) or do something to attract attention? Font colors (rd bold), small images etc (star, red ball) etc can be used. Similar indicator can be added for Autoconfigs etc. --Tito☸Dutta 14:42, 27 August 2013 (UTC)
I'm especially concerned about the edits by admins because, frankly speaking, admins' edits have nothing to do with any anti-vandalism tools. User:Titodutta's suggestion is also nice given the fact that colored text of username will be comprehended better and more speedily. in a context where all other texts are gray scale!-AsceticRosé 17:12, 27 August 2013 (UTC)

Edit count per session

Is it possible to add a per session edit count stat like AWB

Time: N seconds, Edits: NN, Skipped: nnn, AGF: mm Vandalism: pp

At least the first two Time and edit count, so that one may see "quickly" see the number of recent edits. This will be helpful editors like me who fix a target (not more than 100 edits in this session, then move to something else). --Tito☸Dutta 14:42, 27 August 2013 (UTC)

Target-fixing often leads to hasty edits. Anyway, waiting to see how others will evaluate this.--AsceticRosé 17:23, 27 August 2013 (UTC)

I'm opposed to this for the usual reasons. Quality not quantity, don't want to make STiki even more of an MMORPG to (some) users than it already is, yadda yadda yadda. Theopolisme (talk) 00:05, 28 August 2013 (UTC)

  • Not applicable here. It is just a request of a feature which is related stat and personal record keeping. Everywhere, in office, schools, colleges they keep record of number of classes, hours of works per day. --Tito☸Dutta 13:01, 29 August 2013 (UTC)
  • WP:MMORPG is very applicable here...regardless of your intended uses, I guarantee that there will be other editors who are motivated purely by the stats in the corner, and in turn focus less on the quality of their reverts, but rather the quantity. WP:Editor retention != "revert with abandon and scare away new users 24/7". Theopolisme (talk) 21:03, 29 August 2013 (UTC)
  • MY STiki edits have been more or less good so far. So, that will not be a problem for me. Have you used AWB? If not use once and see the edit stat I am talking about. --Tito☸Dutta 21:11, 29 August 2013 (UTC)

RfC: Are the Category:Wikipedians and its subcategories appropriate for Wikipedia

There is an ongoing RfC going on at Category talk:Wikipedians#RfC: Is this category and current subcategories appropriate for Wikipedia that readers of this Wikipedian software page may be interested it. Technical 13 (talk) 12:19, 29 August 2013 (UTC)

*yawn*. That didn't seem to get very far. I think its pretty clear these categories serve a helpful purpose for some tool developers (especially for tools without a server-side component). Even if they didn't, I don't know why one would try to limit Wikipedians ability to self-assemble in user/talk space. West.andrew.g (talk) 14:19, 10 September 2013 (UTC)

Greetings and... funny twist/minor tweak?

Greetings All. Possibly related to the request for an explicit filter to prevent the edits of rollbackers, reviewers, and other specially permissioned users from appearing, I just found myself being invited to review an edit I had made 9 minutes and 12 seconds previously (I marked it as innocent). I'd imagine that it should be fairly easy to tweak the tool to prevent this. Cheers! --Technopat (talk) 14:47, 11 September 2013 (UTC)

The above mentioned filter (T#029) has already been implemented in source. It will be pushed at the next release. West.andrew.g (talk) 15:43, 11 September 2013 (UTC)

Insufficient privileges?

Why am I receiving an insufficient privileges error upon logging in? STiki worked the other day, but not today. hmssolent\You rang? ship's log 00:29, 14 September 2013 (UTC)

This occurs even when I entered an incorrect password. hmssolent\You rang? ship's log 13:18, 14 September 2013 (UTC)
Never mind, figured it out - accidentally added an extra character which invalidated the login. hmssolent\You rang? ship's log 14:18, 14 September 2013 (UTC)

Possible bug: duplicate AIV reports

In an older version of STiki, the tool automatically reported someone to the AIV. But a report was already there, and STiki has created another one: https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_intervention_against_vandalism&diff=prev&oldid=565305427

I don't know if this was fixed in a newer version, but I'm just putting it out there. -- t numbermaniac c 01:29, 14 September 2013 (UTC)

I think we make a check to confirm that the user isn't *already* blocked, but we do not completely parse the current WP:AIV page to make sure a block request hasn't already been lodged. I wouldn't call this a "bug", though. The outcomes are interesting to think about. We can assume the STiki generated report was triggered by a revert after, and distinct from, the prior report. Thus, the STiki report is almost an annotation of additional evidence and might bring more attention to a user who is vandalizing rapidly. Regardless how we think this should be handled, I can't imagine this is a very frequent or unwelcome case at AIV, so it will go into the table with "medium" or "medium-low" priority. Thanks, West.andrew.g (talk) 18:43, 16 September 2013 (UTC)
Perhaps it could "extend the report," kind of like how Huggle does it? Theopolisme (talk) 20:54, 16 September 2013 (UTC)
Interesting. It should be pointed out that this is Huggle extending its *own* report, so its free to search/parse for a certain format. There is, of course, an expected format for how AIV reports should be made. However, some casual history browsing indicates this isn't always respected. We can always make a best effort to parse the report and extend accordingly. If we miss something and make a new report, this certainly wouldn't be the end of the world. Thanks, West.andrew.g (talk) 01:40, 17 September 2013 (UTC)
You could always just do something very simple using an indented bullet like:
* [Original report text]
:* [Add additional Stiki report here]
* [The next report]
This would probably be sufficient in 99+% of the cases should the Huggle "extend report" logic prove too limited in practical use to be worth implementing. Theopolisme (talk) 01:59, 17 September 2013 (UTC)
I can't see it in the table... -- t numbermaniac c 06:58, 22 September 2013 (UTC)

Can you authorise me to use STiki?

Would be happy to help. I think I must be a little bit short of the 1000 edits. asnac (talk) 13:03, 21 September 2013 (UTC)

Mmm. Unique pages edited:578 ... far from 1,000. Come back later, or tell us here why you want to. Sincerely,
— | Gareth Griffith-Jones | The Welsh Buzzard | — 19:53, 21 September 2013 (UTC)
Ah, I didn't realise it had to be unique pages. Given that I started in July 2006, by a rough calculation I won't reach 1000 till late 2018. At which time either I'll have less time on my hands, or STiki will have been replaced by something else. I'm not going to sell myself, other than suggest that you glance over my contributions and decide if you think I can be of use now rather than in 2018. asnac (talk) 06:12, 22 September 2013 (UTC)
I certainly don't have the ability to authorize. My suggestion, Asnac, would be to request rollback permissions at Wikipedia:Requests_for_permissions/Rollback. I'm sure the admins who read there will be ready to judge your contributions, and then you would meet the requirements for Stiki as well. --Atethnekos (Discussion, Contributions) 06:47, 22 September 2013 (UTC)
When did it need to be unique pages? You have 1126 edits now, so try logging in to STiki and see if it will let you. -- t numbermaniac c 06:56, 22 September 2013 (UTC)
I get the message "The user you are attempting to login does not have sufficient privileges to use the STiki tool." I'll try the Rollback route. asnac (talk) 07:14, 22 September 2013 (UTC)
Over here it says "1000 article edits". According to X!'s tool you have 755 edits to articles. -- John of Reading (talk) 10:26, 22 September 2013 (UTC)

It is 1000 article namespace edits in order to have automatic approval. Why not all edits? We can't let someone write a bot to make 1000 edits in a couple seconds to non-monitored namespaces (i.e., their own user user/(talk)) and suddenly have STiki permissions. I see that User:Asnac has applied for rollback. We'll see how that process turns out. However, a check of the archives will show I am not married to this 1000 figure. Thought not many recently, I regularly grant permission to those with a decent amount of anti-damage experience, who exhibit good faith, but have <1000 article edits. Thanks, West.andrew.g (talk) 23:23, 22 September 2013 (UTC)

CBNG queue hang

Starting to get 20+ day-old edits again here on the ClueBot NG queue - been using the STiki queue since 11am here and have had no problems apart from a few old edits in between. hmssolent\You rang? ship's log 08:47, 30 September 2013 (UTC)

Can confirm, getting some 50+ day ago edits with Cluebot, but STiki queue works fine. — Reatlas (talk) 12:43, 30 September 2013 (UTC)
It's non-trivial for me to troubleshoot this from the new office. But, I have restarted the process and can confirm that CBNG is processing edits and our listener is reading them and writing them to the queue/database. Let me know if the problem persists. Thanks, West.andrew.g (talk) 13:29, 30 September 2013 (UTC)

Edit Transfer

Hey, I had my account renamed (Formerly Shaun9876). Is it possible for my edits to be transferred to the new name? Thanks ∞ §haun♣༆ 22:29, 2 October 2013 (UTC)

Yes, I will do that later these evening and confirm back here when complete. Thanks, West.andrew.g (talk) 21:26, 3 October 2013 (UTC)
 Done - ~1700 classifications remapped to the new username. Change will be reflected when the leaderboard auto-updates in a couple hours. West.andrew.g (talk) 01:31, 4 October 2013 (UTC)

Pre-formatted revert notice

See [2]. Not sure what caused that. --Atethnekos (Discussion, Contributions) 01:01, 5 October 2013 (UTC)

There appears to be a rogue space at the start of that particular string of text causing this to happen, removal fixes it. Fraggle81 (talk) 01:53, 5 October 2013 (UTC)

Keypresses register twice

I just started using STiki, and noticed that it seems to register each press twice -- once when pushed, once when released. This means that pressing Alt-I for innocent marks the next two as innocent, and more importantly, each press of Alt-V reverts two edits. This happens so quickly that it is very easy to not notice that extra edits are being reverted. Jfmantis (talk) 00:58, 12 October 2013 (UTC)

Trust that then you have gone "back" to the prev. article to re-assess!
I always use the touchpad.
— | Gareth Griffith-Jones | The Welsh Buzzard | — 09:09, 12 October 2013 (UTC)
Don't blame the tool! Blame the User!
— | Gareth Griffith-Jones | The Welsh Buzzard | — 09:22, 12 October 2013 (UTC)
While I admit that I should have noticed earlier than I did, I believe that this is a actual bug. In this source file, an action listener and a key listener are both added to each control button (these lines). So, when you type Alt-V, which is assigned here as the vandalism button's mnemomic, the button is "clicked" and actionPerformed() is called. But if one the buttons already has focus, then keyPressed() is also called. The result of this is that parent.class_action(FB_TYPE.GUILTY) is called twice. Jfmantis (talk) 05:08, 13 October 2013 (UTC)

Thanks for the report and your subsequent source code pointers. I agree with your analysis here. This has probably remained under the surface because I get the feeling mnemonic usage is quite rare. Instead, I think many users, myself included, prefer the hotkeys (not requiring "ALT"). Regardless, this will get promptly fixed. If you'd like to make the change via Github, I'd happily accepted a pull request (if you GitHub and want that reputation bonus). Otherwise, its not issue for me to make the fix that will appear in the next release. I'll also add this to the bug-tracking table. Thanks, West.andrew.g (talk) 15:49, 14 October 2013 (UTC)

 Done -- Fixed in source (and on Github), will be pushed at next release. West.andrew.g (talk) 06:19, 20 October 2013 (UTC)

Special Permission?

May I use this? I am a new account, but want to mainly do anti-vandalism work. --I AM A BOX! OF APPLES! (talk) 20:14, 12 October 2013 (UTC)

Hi, I don't have the power to give permission, but I can tell you pretty assuredly that unfortunately because you are a fairly new account, you are not going to get the permission. My suggestion would be to use WP:Twinkle and scan Recent changes from IP editors and Contributions by new accounts. You can quickly build up experience doing that, and then when you think you have what it takes, apply for WP:Rollback permissions (which will also give you the permission to use Stiki). --Atethnekos (Discussion, Contributions) 20:29, 12 October 2013 (UTC)
 Not done -- Hi User:BoxOfApples (now User:VictorLucas). I agree with Atethnekos' assessment here. You have extremely few edits and have not yet demonstrated anti-damage proficiency. If you are interested in this work and want fast-tracked to more powerful tools, I would suggest WP:CVUA training. West.andrew.g (talk) 15:58, 14 October 2013 (UTC)
Souds good! Gonna do CVUA, then apply for rollback. The only major issue is that no CVUA mentors in my time zone. --VictorLucas 18:48, 14 October 2013 (UTC)

Hi I do fight vandalism too having access to this too will be great. Thanks. --Enock4seth (talk) 22:10, 18 October 2013 (UTC)

Not sure -- First off, anyone know why the edit counter is down? This user certainly has more than 1k edits, but the quantity in the article namespace is likely just below the threshold. They seem to have done very constructive work in a narrow scope (Ghana-related topics) without a ton of anti-damage work. I'm inclined to approve on good-faith and the fact the user should shortly be automatically qualified, regardless. But I'll give a few moments for others to share their opinion before granting. Thanks, West.andrew.g (talk) 06:40, 20 October 2013 (UTC)

Insufficient permissions???

I have both rollback permission and around 10,000 edits...but can't login to the software. Any thoughts? HGilbert (talk) 17:16, 16 October 2013 (UTC)

That is odd. I have added you to a list of explicitly permissioned users. Let me know if this fixes the issue. West.andrew.g (talk) 17:57, 16 October 2013 (UTC)
Yes, I can login now. Fantastic tool. I feel like the boy throwing clams back into the ocean, though...aware of the millions of clams I'll never reach. HGilbert (talk) 00:14, 17 October 2013 (UTC)

Neither Vandal nor good faith

I have come across a couple of NPOV edits and I don't like the choice of only vandal or good faith for these - what is your thought on it?-- 🍺 Antiqueight confer 20:46, 19 October 2013 (UTC)

STiki hyperlinks can be used to visit and edit a page via the normal browser interface. Obviously this permits freedom in the edit comment and user talk template. When you return to the STiki browser you should classify the edit as "pass" to advance to the next edit, since you were uncomfortable treating it as vandalism or a "good faith revert" in the first place. If these are painfully blatant NPOV issues, I personally would consider using good-faith revert with a custom message addressing NPOV policy. West.andrew.g (talk) 06:50, 20 October 2013 (UTC)

CPU hog

Using OSX 10.8, STiki v2.1, after about 15-20 minutes of regular use the stiki_frontend_driver process will often climb in CPU usage, in excess of 150%. You can hear fans going crazy on my machine. This definitely never happened when I was using older versions of STiki, so it may be related to the update, or perhaps the combination of that with my system configuration... anyone else experienced this? Thanks — MusikAnimal talk 16:06, 9 October 2013 (UTC)

I had similar issues on Win7 64-bit. The solution for me was to clear the "Temporary Internet Files" within the Java Control Panel. So that is Java Control Panel --> General --> Temporary Internet Files --> Settings --> Delete Files. I'm not sure what it would be on OSX. Good luck! --Atethnekos (Discussion, Contributions) 16:45, 9 October 2013 (UTC)
Sounds like a genuine (though not urgent) bug that Andrew might want to have a look at.
Yaris678 (talk) 22:15, 10 October 2013 (UTC)
Yeah... I'm pretty sure I installed the Java Runtime Environment in the terminal, so I'm not aware of a place to go to clear the cache, as I don't see an option for this when running the java binary. A simple restart will fix issue, at least for another 15 minutes. Thanks for the help — MusikAnimal talk 14:52, 11 October 2013 (UTC)
You could try uninstalling and reinstalling Java itself (not Stiki, obviously). --Atethnekos (Discussion, Contributions) 17:41, 11 October 2013 (UTC)

Even if installed from the terminal, some GUI widget usually gets placed somewhere with the installation. See if [3] helps you clear the Java cache on your system. STiki does have a ton of HTTP traffic to-and-fro the Wikipedia API, which Java might cache. However, we would assume Java uses some LRU model to keep that structure efficient and finitely sized. So I get the feeling this is not the full explanation (but if it works for everyone, I'd be interested to hear it).

Spikes in memory or computation are not a natural aspect of continued program usage. Memory grows trivially (one could have a year long session w/o issue). Nothing in the design suggests that computation should spike. The dramatic spike (which I assume never ebbs) is suggestive that a thread might be caught in an infinite loop. However, the fact it takes 20 minutes to get to this point suggests the cause is some kind of corner case, so its especially odd it often happens after the same interval. I'd appreciate hearing others experience with this issue. West.andrew.g (talk) 16:15, 14 October 2013 (UTC)

So I'm having the same issue on my home machine, also OSX 10.8. I did some searching and found this (see the update) which implies that at least one release of Java 1.6 removes the ability to clear the Java cache or launch the Java console. Maybe they're talking about Java 7, I can't tell, but on this machine I'm running 1.6.0_51, and I can't find a GUI. I'll report back with what version I'm running at work, where I shouldn't be editing Wikipedia in the first place =P
A few more things... I could update to Java 7, but there still isn't a 64-bit version of Chrome for OSX, so I'd stubbornly rather wait. Another observation that came to mind was that more or less around the same time this issue came about with STiki, I've noticed some Chrome Renderer processes for some sites also suddenly exert a spike in CPU, and I have to kill them. Perhaps this is due to a hidden Java applet on the page. When I think of a Java web applet, I think of those tacky photo uploader things we used to see way back in the day, I'm guessing today frontend-Java applets don't look quite the same, because I don't remember seeing any.
At any rate, I'm leaning toward it being a Java version-specific issue likely effecting users running a similar environment as mine – and that clearing the cache is apparently not possible with such version. Java updates are pushed out with OSX system updates, so I may have updated Java without taking note of it, which might explain why there were no STiki issues before. For now I'm content with just restarting STiki and refreshing webpages :) Thanks everybody! — MusikAnimal talk 04:16, 15 October 2013 (UTC)
Update – running the same version of Java, 1.6.0_51, here on my work machine. — MusikAnimal talk 16:17, 15 October 2013 (UTC)
On my Windows XP computer STiki has sometimes reached 80% CPU usage. There was this one time where it wouldn't go lower than 70% and it was extremely laggy. Closing and reopening fixed it somehow. -- t numbermaniac c 11:13, 18 October 2013 (UTC)

information Note: This thread resumes in a separate topic below. West.andrew.g (talk) 14:37, 21 October 2013 (UTC)

CPU overload by STiki

I'm having this since recently (on Win XP with updated Java): shortly after starting a STiki session, javaw.exe starts consuming 99% of CPU resources eventually forcing me to quit. Comments or advice? Materialscientist (talk) 11:44, 20 October 2013 (UTC)

Using task manager, Set the base priority of javaw.exe to low so that it only uses your idle cycles. Sorry if trivial/useless advice but you didn't say whether it hangs STiki itself or whether you have other important tasks running at IDLE_PRIORITY_CLASS. Ginsuloft (talk) 12:09, 20 October 2013 (UTC)
No, no other important tasks. Yes, setting priority to low seems to help. Thanks. Materialscientist (talk) 13:00, 20 October 2013 (UTC)
Well, that sounds like the same issue I've been experiencing. I'm using OSX, however; I am not able to set the process to "low priority", and frankly that's likely just a workaround, not a solution... Materialscientist, have you only been experiencing this since the most recent update? — MusikAnimal talk 16:14, 20 October 2013 (UTC)
I can't recall when it started, but it is recent. Setting the process to low priority, clearing java cache, or restarting Stiki doesn't help. Materialscientist (talk) 22:47, 20 October 2013 (UTC)
Why doesn't it help? What actually happens when the CPU spike occurs: does STiki hang? The entirety of STiki or just a part of it? Ginsuloft (talk) 23:16, 20 October 2013 (UTC)
It is not a spike, as it persists even after restarting Stiki. Nothing hangs, but the PC obviously slows down, as javaw starts consuming too much CPU resources. Materialscientist (talk) 23:51, 20 October 2013 (UTC)
If nothing (visible) hangs, and it's just some thread stuck in a loop as suggested in the linked thread above, then setting priority to "low" must help: javaw can't slow anything down if it's the only process running at "low" (idle) due to the way the scheduler works. Are you saying it still slows your PC down even after setting the priority to low? Note that restarting resets the priority. Ginsuloft (talk) 23:59, 20 October 2013 (UTC)
Why "must"? In absence of any priority process, javaw takes 99% of the CPU resources even in the low-priority state, which is a problem for the PC. Materialscientist (talk) 00:04, 21 October 2013 (UTC)
"javaw takes 99% of the CPU resources even in the low-priority state" - correct, "which is a problem for the PC" - incorrect. The only reason it uses 99% is because nothing else is using the CPU. Ginsuloft (talk) 00:08, 21 October 2013 (UTC)
First, it should not use 99% of (1 GHz+) CPU. Second, when it does, it is slow on itself, and it hinders running anything else (like Firefox to assist Stiki). Materialscientist (talk) 00:13, 21 October 2013 (UTC)
I apologize. I was trying to help, but it seems I only managed to piss you off. I don't know how to say this without sounding like I mean the opposite, but if it's any consolation, I feel horrible now. Ginsuloft (talk) 00:33, 21 October 2013 (UTC)

Not my place to comment, but doesn't sound like Materialscientist is pissed off, and being the good admin that he is likely assumed you meant no harm.

Anyways just wanted to point out that I was incorrect in saying it takes 10-15 minutes to spike the CPU, but rather as soon as I start STiki. This leads me to believe Materialscientist is experiencing the same issue, so not just an OSX thing. — MusikAnimal talk 03:47, 21 October 2013 (UTC)

I am very interested in troubleshooting this issue. However, it is not one that lends itself to easy analysis. We know that everyone has to be on the 8/19 version of STiki since earlier versions were broken by the API change. The only thing that the update did was (a) Fix the API issue, which pertains only to login actions, and (b) An extremely minor change in revert comments. No changes were made to the edit processing framework. The previous update of the program stretches back to June (which also looks fairly benign). Thus, it is a little unsettling that we are suddenly getting all these corroborating reports of issues. For this to happen, STiki almost certainly has to have a thread stuck in an infinite loop, and one of those threads has to be part of edit acquisition and parsing (these threads make nicely wrapped "packages" that then sit in cache until it is their turn to be displayed). Still, it must be an isolated issue, as only one or several threads are hanging since STiki remains usable. Memory usage shows no noticeable spikes? I'll play with this tonight and see if I can even reproduce the issue on my own machine (Fedora Linux). Thanks, West.andrew.g (talk) 14:50, 21 October 2013 (UTC)
I'm betting it's a Java-related, isolated issue, otherwise you'd have more people complaining of it. Haven't notice a spike in memory usage, just CPU. Like I said, I'm happy dealing with it the way it is for now. I will eventually update Java and I'll let you know if the problem persists. Thanks for your dedication to help Andrew! — MusikAnimal talk 19:42, 23 October 2013 (UTC)
I've experienced the exact same problem running it on Ubuntu with both Sun's Java 6 and OpenJDK 7, which suggests to me that it's not a problem with the OS or Java itself. Jfmantis (talk) 22:48, 24 October 2013 (UTC)

I am able to reproduce the error on my personal machine. It is being investigated. About an hour's worth of troubleshooting and initial profiling this evening were unable to pinpoint the problem, Investigations will continue. Thanks, West.andrew.g (talk) 04:37, 25 October 2013 (UTC)

The other day I was able to reproduce this bug probably 10 times in the span of an hour. This morning I classified for an hour (restarting STiki several times) and did not see the CPU spike once. This is really confusing stuff. Is everyone else still experiencing it? Any specific details about the time-of-day or classification conditions around which the CPU spike seems to occur? I may have to distribute a debug release with output to the terminal and let some of the user-base profile what is going on (although I didn't have much luck with this locally the other night). West.andrew.g (talk) 15:11, 2 November 2013 (UTC)
The overload indeed varies from day to day. It was frequent around the time I wrote it. Last few days I don't experience it (with no change in my local software). Materialscientist (talk) 00:38, 5 November 2013 (UTC)
Same here, baffling! I will make note of when I see the spikes again. — MusikAnimal talk 02:05, 5 November 2013 (UTC)
I must note that oftentimes the CPU will spike to 70 to 100% while the revert/pass is taking place (1 to 3 seconds), but then immediately go back to less than 10% (normal). This is apart from the problematic case where it stays at 100+%, until the fans on my machine start going crazy. Is this brief spike normal behaviour? For all I know that could have always been the case, I just have never monitored the CPU usage until it became a problem. — MusikAnimal talk 02:15, 5 November 2013 (UTC)

Brief spikes are not at all problematic. A lot is going on when the "revert" button in particular is pressed. It has to go and fetch a user page, parse that page, edit that page, commit the rollback in article space, load the next edit into the GUI, and pre-fetch and cache another edit. We should only be concerned with instances where CPU usage is near 100% and and the program is basically idle (outside of start up and the first classification after login). West.andrew.g (talk) 01:23, 6 November 2013 (UTC)

Request for access

I'd like to request special permission to use STiki. Though I don't have rollback permissions, I have been fighting vandalism using Twinkle and I feel that STiki could prove to be a valuable asset for me in continuing my contributions as I become progressively more active on Wikipedia, as it would help to make patrolling edits much easier and faster. Bailmoney27 talk 21:16, 28 October 2013 (UTC)

 Done -- User has demonstrated anti-damage experience and good-faith interactions with users of all kinda on his/her talk page. I'm relatively confident they could get rollback, so I have no qualms in granting explicit STiki permission. Thanks, West.andrew.g (talk) 14:25, 29 October 2013 (UTC)

Leaderboard

Unnecessary back and forth about an edit made to WP:STiki in good-faith

In view of this, should this user be allowed to continue using STiki?
— | Gareth Griffith-Jones |The Welsh | Buzzard| — 21:02, 30 October 2013 (UTC)

Could you explain a little more? The user wrote that "Wikipedia is not about winning", and linked to Wikipedia:WINNING. Maybe, did you miss the "not"? Or is it something else? --Atethnekos (Discussion, Contributions) 21:10, 30 October 2013 (UTC)
The post, in BOLD, did not belong. Posting it demonstrated immaturity, in the least, and certainly a lack of understanding of what this is all about. I am amazed that I need to explain my reverting.
— | Gareth Griffith-Jones |The Welsh | Buzzard| — 21:15, 30 October 2013 (UTC)
Demonstrates a lack of understanding of what this is all about? You mean that Wikipedia IS about winning? — Reatlas (talk) 04:28, 31 October 2013 (UTC)
Hmmm ... that speaks legions ... interesting reaction, which would seem to be a deliberate attempt by Reatlas to throw confusion. Is there confusion? I do not believe so. — | Gareth Griffith-Jones |The WelshBuzzard| — 10:18, 31 October 2013 (UTC)
From my uninvolved status; I can't see what was wrong with adding that WP isn't a competition. Matty.007 10:26, 31 October 2013 (UTC)
@ Matty I agree and that is what the Lead has always said. It is this revision that I reverted. — | Gareth Griffith-Jones |The WelshBuzzard| — 10:39, 31 October 2013 (UTC)
@Gareth Griffith-Jones: The revision that you link includes the following addition: "and Wikipedia is not about winning." Please explain, clearly, what the problem is with this addition. Theopolisme (talk) 11:10, 31 October 2013 (UTC)
I am nipping this in the bud right now. I see nothing inappropriate about the edit of User:Jinkinson. It was topic appropriate, not "in bold", and certainly did not merit this accusation. Let's be civil. Case closed, carry on. West.andrew.g (talk) 14:17, 31 October 2013 (UTC)

Request for permission

I would like to request for permission to use STiKi. I have been reverting vandalism for some time with Lupin's Antivandal Tool and Twinkle and I feel that STiKi will help me very much in doing this. Thanks! Darylgolden(talk) 06:18, 4 November 2013 (UTC)

 Done -- As described, anti-damage experience and good-faith interactions. West.andrew.g (talk) 16:06, 4 November 2013 (UTC)

STiki may be down

Due to server maintenance at the University of Pennsylvania, STiki is currently non-operational. I expect it to come back online and everything to be functional within a couple of hours, maximum. Thanks, West.andrew.g (talk) 14:18, 6 November 2013 (UTC)

Lots of people confirming what I said; the server is down
STiki currently is not working for me either. Flyer22 (talk) 15:28, 6 November 2013 (UTC)
Yea, it's down for me too. I'll try tomorrow. Cheers! -- — Keithbob • Talk • 21:20, 6 November 2013 (UTC)
It is down for me too, but I thought it was a problem with my Internet connection. Now I know. Epicgenius(give him tirade • check out damage) 00:59, 7 November 2013 (UTC)
Not working for me either --Greenmaven (talk) 04:40, 7 November 2013 (UTC)
Still down here too. Hope it'll be up soon. hmssolent\You rang? ship's log 11:43, 7 November 2013 (UTC)
Yeah it's still down. Hope it'll be fixed soon.--Pratyya (Hello!) 14:31, 7 November 2013 (UTC)
No connection here, Thursday evening in the UK — | Gareth Griffith-Jones |The WelshBuzzard| — 17:11, 7 November 2013 (UTC)
Still down here.-- — Keithbob • Talk • 19:28, 7 November 2013 (UTC)
Been all down since West.andrew.g left the message above. Widr (talk) 22:02, 7 November 2013 (UTC)

Whoever has no access to STiki right now, please sign your name below.

Seems fine now. Darylgolden(talk) 00:08, 8 November 2013 (UTC)
 Done -- Service has been restored as of yesterday afternoon. All statistics and reports have been re-generated as necessary. West.andrew.g (talk) 15:07, 8 November 2013 (UTC)

Reverts not taking effect

I have just been editing with Stiki for a while, and found one of my reverts had not taken effect. I checked my contributions - not one revert, vandal or GF, had taken effect! Please check this out. I appear to be logged on to STIKI. --Greenmaven (talk) 07:05, 8 November 2013 (UTC)

Logged out, logged in. Same problem. --Greenmaven (talk) 07:13, 8 November 2013 (UTC)
This is something that has happened to me at times too. It's usually a temporary problem, might or might not be related to some other bugs in the system. Widr (talk) 13:12, 8 November 2013 (UTC)

Not an issue I am able to reproduce. I have to imagine the STiki user's would be here complaining in droves if this were a widespread problem (and if it were, it would be because the WMF folks have toyed with the API again). Browsing WP:VPT shows some possible geographic and replag problems, but nothing terribly widespread. If the "last revert panel" is reporting the completion of an edit, then it has received definitive evidence from the WMF server that the edit request was received/completed, and the burden lies somewhere in their system. West.andrew.g (talk) 15:26, 8 November 2013 (UTC)

What am I doing wrong?

I downloaded this program and can't make it work. What am I doing wrong? Coretheapple (talk) 21:11, 1 November 2013 (UTC)

Disregard. Stupid mistake. I don't have "rollback" permission. Coretheapple (talk) 21:30, 1 November 2013 (UTC)
Hi there, User:Coretheapple. If you are interested in explicit special access to STiki, I'd be likely to approve (I'm also reasonably confident you could get the rollback permission if you requested it). I haven't completely vetted your history, but a cursory glance suggested you've been around a while, done a good quantity of edits, and know how to conduct yourself on the platform. West.andrew.g (talk) 22:12, 1 November 2013 (UTC)
OK. If you point me in the right direction I'll ask for permission. Thanks. Coretheapple (talk) 03:49, 2 November 2013 (UTC)

 Done You can now use the tool. Make sure you are familiar with WP:STiki and WP:VANDALISM before jumping in head-over-heels. West.andrew.g (talk) 15:03, 2 November 2013 (UTC)

Why thank you! I probably won't get a chance to use it for another week or so. Coretheapple (talk) 15:30, 2 November 2013 (UTC)

Request for Access

I would like to request access to use the tool, I am familiar with WP:VANDALISM and other anti-vandalism tools. --Clarkcj12 (talk) 02:14, 15 November 2013 (UTC)

 Already done you have over 1000 edits, so you get the right to use it automatically. --Mdann52talk to me! 08:18, 15 November 2013 (UTC)

User claims lag causes STiki to perform accidental vandalism reverts

I warned a user on their talk page about using STiki to revert constructive edits and misidentify them as vandalism. (Upon further investigation, I discovered that more than half of the edits which the user most recently reverted as "vandalism" clearly were not vandalism.) The reply on my talk page was that the reverts "were accidents caused by lag on my end. When marking an edit for vandalism, my client would click through the next edit on the list as vandalism also, without me either seeing it or knowing what page it was." Has anybody else experienced this phenomenon? MANdARAX • XAЯAbИAM 23:07, 15 November 2013 (UTC)

I have experienced lag while making a revert from time to time, which I perceive as normal behaviour. I don't think the clicks propagate as you say, where subsequent clicks apply to the next change. I can attest however that preventing such should be very easy by simply waiting till you see the next change before clicking anymore buttons. — MusikAnimal talk 23:22, 15 November 2013 (UTC)
I agree with User:MusikAnimal here. Depending on connection speed and regional issues there could be some lag when revisions advance (despite considerable caching to prevent this), but one-click should always map to just one classification. I am not going to make any accusations or dig into this case specifically, but if one is out running the cache and experiencing this, they are probably classifying *really darn quickly*. West.andrew.g (talk) 21:54, 17 November 2013 (UTC)
Thanks for the replies. The response I had given to the user implied that doing five reverts a minute may not provide sufficient time to properly assess the edits. And they promised to try to be more careful. MANdARAX • XAЯAbИAM 22:35, 17 November 2013 (UTC)

Question re data

Hey as you all know there are conversations going on about paid advocacy. Some people say "we have to act this is a huge problem throughout Wikipedia!" and others say "this is SO not a big deal." Everybody is bullshitting. Do you STiki people keep any kind of data that could help the community have a grounded-in-reality discussion about the extent of paid advocacy and COI editing? It would be really great to be able to say something like: X% of edits to Wikipedia are tendentious; Y% of those are from paid advocates" or the like. That would be the super-juicy data bringing together COI and content policies. But anything casting light in that direction would be great. Does anybody know? Should I pose this question elsewhere? Thanks. Sorry for barging in here. Jytdog (talk) 23:39, 18 November 2013 (UTC)

I don't see any way of discovering which editors are paid. One might suspect it by examining an editor's editing history, but not prove it. The bottom line is that unsourced material can be removed. BTW, this discussion does need to happen somewhere else. --Greenmaven (talk) 23:48, 18 November 2013 (UTC)
Thanks for your quick reply - I will leave post-haste. Is there a different place I could pose this question to folks with access to STiki data, or are you The Man, as it were? Thanks and sorry...Jytdog (talk) 23:52, 18 November 2013 (UTC)
I would be "the man" around here, I suppose. Although STiki is aware of unequivocally bad edits (i.e., vandalism; both via the tool directly and other monitoring heuristics), it lacks any logic to link this with COI/paid intentions. The best STiki data could probably do, is given a known corporate/paid/conflicted account or IP address, provide a relative reputation of that account relative to the larger user base (a WikiTrust-esque metric). I know User:COIBot has some heuristics with respect to account names and IP/server adjacency -- and that is probably the most appropriate place to begin this hunt. West.andrew.g (talk) 15:33, 19 November 2013 (UTC)
Thank you so much! I will head over to COIBot. Sorry again if I bothered anybody here.Jytdog (talk) 16:13, 19 November 2013 (UTC)

CHANGELOG for the 2013-05-23 release

Greetings STiki users. Below is the CHANGELOG for the 2013_5_23 release (available for download on WP:STiki), wrapping some small fixes that arose during my dissertation writing. As always, thanks for your continued support. West.andrew.g (talk) 05:14, 23 May 2013 (UTC)

  • Fixes to the AGF message dialogue (T#025). One can now abandon the revert action after the dialogue has been displayed, and checks ensure that the customized message will not be placed if the revert fails. Both edits (the revert and the message) commit after the message has been submitted.
  • The AGF message dialogue has been updated with the modifications made by users at WP:STiki/Good-faith-revert_messages. Similarly, the number of user customizable messages has increased from 2 to 4.
  • The space bar is now disabled when the "classification panel" has focus (most of the time). Previously, pressing spacebar would repeat the previous classification action taken. However, this seemed to cause far more accidents than intent-driven uses (T#026).
  • The "user talk" links in the interface (in the "metadata" and "last revert" panels) now append the affected page title in a special format that makes welcoming/warning messages easier for Twinkle users. See WT:STiki/Archive_11#Feature_Request:_Article_Reference_on_Talk_Pages
  • Minor changes to backend queuing, stopping the CBNG queue from displaying edits made by STiki users.

Pending changes and STiki

a sysop reverted a couple of edits using STiki and the changes stayed in the Pending Changes queue. I presume that's a bug. Josh Parris 11:44, 13 November 2013 (UTC)

Yes I thought this was a bug with the MediaWiki software so I made a post at WP:TECHPUMP. Didn't see it until now but someone responded also saying this was a STiki bug. — MusikAnimal talk 15:25, 13 November 2013 (UTC)
I am snowed under with work right now, so if someone could do a little digging on STiki's behalf it could hasten a resolution (and I'd go ahead and push a new release). When a permissioned user makes an edit via the browser interface then it is automatically approved, yes? Is there an API parameter that STiki should be passing along with the edit in order to make this happen? Or is this something that needs to happen via an explicitly separate, after the edit has committed, API call? I don't know where FlaggedRevs/PendingChanges/whatever stands at the moment, but I remember STiki getting through the early trials just fine. West.andrew.g (talk) 16:25, 13 November 2013 (UTC)
Here's my interpretation of what's going on here.
The edit to Josh Abraham and the edit to Drake are both good-faith reverts. Therefore, STiki hasn't used the inbuilt rollback functionality of the wiki. (This would mark the edit as minor, which we don't want to do.) STiki has just copied the new wikicode from the old version of the article. This means that the wiki hasn't recognised that we have reverted to a previously accepted version of the article and hence hasn't automatically accepted this new version.
I don't think there is an easy fix. I guess there are three possible solutions:
  1. if the Pending Changes aspect of WikiMedia could detect a revert that didn't use the revert function the problem would disappear.
  2. if the MediaWiki API could allow for a non-minor revert that would enable the problem to be fixed in a simple way.
  3. Andrew could investigate the PC-related aspects of the API and then make it detect and then fix this problem, but that sounds like a ballache.
Looks like 2 is the most sensible option but it does require persuading someone to change the MediaWiki API and persuading someone to install that change on Wikipedia.
TLDR: The problem is with the MediaWiki software that Wikipedia is based on, not STiki. A workaround could be programmed into STiki but it would be a ballache.
Yaris678 (talk) 13:31, 14 November 2013 (UTC)

Thanks for the analysis Yaris, I think I now see the issue. This will affect all good-faith reverts using the tool, and ALL reverts made by a user who does not have the rollback permission (but they would need to be a reviewer for the problem to present itself). It seems rollback edits by reviewers are 'auto-accepted' where as all other edits by reviewers are not? This is true in the browser interface as well? If this is the case, I think #3 is probably the most timely and realistic solution. West.andrew.g (talk) 15:16, 14 November 2013 (UTC)

Errr... I might want to take that back. I played with PC and and API for about a half-an-hour and I have some thoughts:
  • If a user wants to good-faith revert a single un-reviewed edit (or multiple consecutive by the same user) we don't even want to edit via the typical API calls, but we should use the "unaccept" function of pending changes, which handles the PC annotation and effectively makes a revert? Not elegant, but sure.
  • Should a STiki "innocent" classification be interpreted as marking a PC edit as "accepted"?
  • Imagine we have 2+ un-reviewed edits by DIFFERENT users. STiki is going to use its "rollback style" logic and only display the most recent one. The revert action will only be considering the most recent edit, but it seems anything we do via PC will cascade through all the edits under review (i.e., the older of the two edits will never actually be reviewed, but effectively be accepted regardless of our classification).
  • How does the previous case work with pure vandalism/rollback actions? STiki is presumably already doing these.
Implementing this ourselves would come with a non-trivial coding and testing burden. Also, we need someone who is very familiar with PC to counsel us on these corner cases (and perhaps their consultation would be valuable in making sense of the above points). I can see why Yaris likes #2, and getting this done in software could save ourselves and other tool authors some burden. How is Huggle handling this? West.andrew.g (talk) 16:26, 14 November 2013 (UTC)
Good point about 2 making things easier for Huggle etc also. Do you want to do the Buzilla request? (I'm about to log off).
To answer your other points:
  • innocent=accepted? I vote no. STiki has always been clear that it is vandalism focused and anything else is a bonus. WP:Reviewing covers several things including BLP issues and copyvios, which an unwary STiki editor might not pick up on.
  • pending edits by different users: In this situation I would be fine with STiki staying with the current functionality and showing and reverting the edits by only the top user. The other edits can be dealt with by the reviewer. (If the STiki editor is a reviewer, he/she may choose to review using the standard wiki interface.)
  • Pure vandalism / rollback: If my theory is correct then these will be automatically accepted after reverting by STiki. If anyone knows of a contradicting example, let's see it!
Yaris678 (talk) 18:25, 14 November 2013 (UTC)
Tracked in Phabricator
Task T59073
I attempted a Bugzilla entry for this (at right), but I fret I wasn't as articulate as I hoped to be. I feel like there are two separate issues here with: (1) not auto-accepting identity reverts, and (2) the type of chaos a lengthy PC-chain might cause. If anyone wants to impart some clarity over at Bugzilla, please do. West.andrew.g (talk) 20:15, 14 November 2013 (UTC)
I think the guys at Bugzilla are suggesting that you can use rev_sha1 as a way tell MediaWiki that you are reverting. I don't know enough about the API to know if this makes sense. Yaris678 (talk) 19:50, 22 November 2013 (UTC)
That was not my interpretation. For one "baserevid" is not text that appears anywhere in the API documentation (must be internal to the software). Second, "sha1" (which is a hashcode) isn't something you "provide" about an edit, it is a property of an article version. I interpreted their discussion as: "we're currently detecting reverts using some flag [baserevid] that has limitations; we could do this better if we changed to sha1 comparison, which is a data field we have readily available in our current code". I could also be incorrect here, maybe post for a clarification on Bugzilla? West.andrew.g (talk) 19:58, 22 November 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:STiki/Archive_13&oldid=1142514196"