Wikipedia talk:STiki

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search



Welcome to the talk page for the WP:STiki tool. It works just as any other talk page. However, before you report a bug or feature request, please check the table of the first section to see if the issue is already known. Please do not edit that table manually, instead just start a discussion and STiki's developers will update the table as appropriate.

Known Bugs and Feature Requests[edit]

STiki Outstanding Bugs and Feature Requests
ID Contact Type Description Status Urgency
T#059 Adotchar Feature Request Identify a mechanism to notify users when they have a message within STiki, possibly with options regarding how prominent this notification should be. Pending Medium
T#060 Materialscientist Bug Fix After the STiki window has been left inactive for a period (hours), if the first edit classified is "vandalism" the "beaten to revert" message will be erroneously displayed. Interestingly, there is no issue if an AGF classification is applied. This is presumably due to a failed check/renewal of the expiration on the rollback token. Pending Medium
T#039 Ugog Nizdast Feature Request The user should have the capability to display some form of article history, primarily/all in the form of metadata, for the edit under inspection. Pending Medium
T#062 Benzband Feature Request Display the edit count of the user under inspection, perhaps with some notion of "recency", to help users determine if it is worthwhile to scrutinize the user's edit history. Pending Medium
T#061 Redhat101 Feature Request For those who use STiki at night or simply prefer a darker interface, that option should be available alongside the other color-change options. Hopefully we can rely on a Java "look and feel" configuration to do this quickly and globally without having to modify individual components. Pending Medium-Low
T#045 Chess Feature Request Current custom AGF messages hide behind opaque names and are fixed in number. There should be a more dynamic CRUD + naming scheme for AGF messages, which if not an in-STiki interface, could depend on user editing of the configuration files. Pending Medium-Low
T#040 Yaris678 Feature Request Rather than the current "last revert" message having a very "error" tone, shift that to something more positively reflecting the classification was still useful. Better yet, detect when conflicting edits are by STiki user to change message tone accordingly. Pending Medium-Low
T#010 Allens Feature Request There is a desire to somehow represent (possibly with underlining or a color) whether a wikilink has an existing article destination or is a "red-link". Some investigation is needed to determine how to best do this with the Mediawiki API, and the performance penalty it causes. Could also be a STiki option whether or not this should be done. On Hold Medium-Low
T#028 John of Reading Feature Request Expand processing to include some alternative namespaces, namely "portal" and "help". Existing classification models would be re-used and there would be an explicit new queue for these edits. Pending Medium-Low
T#027 Arc de ciel Feature Request More careful recording of "pass" actions. This would also permit a feature allowing a user to view, ex post facto, how the edits they passed on were eventually classified. On Hold Medium-Low
T#056 Materialscientist Bug Fix If the article currently being displayed in the STiki browser is deleted (i.e., by the STiki user in a traditional browser), it will cause the STiki browser to stall when the article is subsequently classified. Pending Medium-Low
T#004 West.andrew.g Feature Request The STiki client currently talks to the backend using only MySQL. MySQL communication could be firewalled by some organizations, making the move to HTTP/PHP communications a good idea. However, this remains low priority given that such little mention has been made of this shortcoming. Pending Low
T#003 Chicocvenancio and Meiskam Feature Request STiki exists only in English, and should perhaps put structure in place for localization. Meiskam wrote some initial structure for this, but I am holding on trunk integration. To move forward, we need someone who has the time, expertise, resources (a server), and willingness to run a STiki backend and do all text translation. On Hold Very Low
T#999
-
Feature Request Note that all requests pertaining to the inclusion of back-end classifier features should be lodged and discussed in the sandbox at Wikipedia talk:STiki/Feature development
-
-


CHANGELOG for 2016-08-04 release (and subsequent minor updates)[edit]

Greetings STiki-ers... The first update in a long time that isn't an emergency release! As always, your participation and continued feedback is appreciated. This is likely the STiki version that will take us over 1 MILLION reverts. This update brings us:

  • The "ignore" button (adjacent to the "user" line of the "metadata panel") enables a session-length ignore of edits made by a particular user (e.g., repeated maintenance tasks that are not vandalism). The ignore list resets when STiki is restarted. The link will change from a blue "ignore" to red "ignored" if the action succeeds (T#053).
  • Implemented API "thank" functionality. A revision/editor can be "thanked" by using the button adjacent to the "REVISION_ID" line of the "metadata panel". "Thanking" is tied to specific revision-ids, justifying this placement. It was not made an explicit classification button and tied to the "innocent" outcome as such a promotion seems like mission-creep for an anti-vandalism tool. The link will change from a blue "thank" to red "thanked" if the action is successful. Note that only registered editors can be thanked, and the link will be hidden for edits made by unregistered users (T#055).
  • The fact an article is CSD ("candidate for speedy deletion") can now be noted atop diffs, similar to how the "this will rollback 'n' edits" note already appears. This functionality is enabled by default, but is in "options" menu (T#052).
  • First attempt at solving macOS GUI layout issues. These seemed to stem from the fact macOS enforces a border on JButtons (T#054).
  • A situation was identified where rollback tokens were sometimes failing to be acquired. This was in turn causing those rollbacks to silently fail and block subsequent ones. This probably caused some of the "I did work; but made no edits" sessions.
  • Minor change w.r.t. to height of "watchlist options" drop-down, which seems to have no default minimum height
  • Minor change to make login error messages more descriptive


A minor update on 2018-04-10 brought:

  • Edits made by STiki (reverts/rollbacks/warnings) will now be tagged with the "STiki" label. A backend process is available to label all prior revert/rollback actions in this manner, if this is determined desirable by community consensus.
  • Resolved the "milestone for blocked editor" issue; WP:BEANS (T#057)
  • The edit comment for an AIV posting regarding a registered user will link to that user's contributions, not their talk page
  • Minor changes and test suite for IRC feeds
  • Building in (redundant?) checks to ensure that rollback/edit tokens are acquired; still addressing session drop/fail issues
  • Added minor utility script that allows one to grant explicit access to users with Unicode characters in usernames


A minor update on 2018-12-08 brought:

  • Added "Verify session at login" to the "Options" menu. This is an attempt to solve the "session dropped" errors experienced intermittently by some users. If checked, immediately after login, a test edit and AGF of that edit will be made to a dummy page in WP:STiki space (a workflow that shows promise in surfacing session issues). If successful, we proceed as normal. If not, credentials are available to transparently re-login and try again. Debugging information will be written to STDOUT. This option is disabled by default and should not be enabled by those not having issues. Hopefully this temporarily patches and helps in identifying the root cause of this ongoing bug.


Thanks for your continued participation and support. West.andrew.g (talk) 15:07, 12 April 2018 (UTC)

Stiki[edit]

I downloaded the Stiki but didn't find installing file. Can you help me out ?  TheRedBox (Talk) 19:57, 19 November 2018 (UTC)

@TheRedBox: After downloading the executable version, unzipping the file should produce a *.JAR file. This is what launches the tool. If your OS doesn't understand how to launch it, you probably don't have the Java Runtime Environment (JRE) installed. I will point out, your account does not currently appear to have the permissions necessary to use STiki, and as such would require special permission. West.andrew.g (talk) 15:29, 21 November 2018 (UTC)

Frequent 'WMF has dropped session' error message with doing a good faith revert[edit]

Hi, when using STiki I very frequently get the 'WMF has dropped session' error message, but only ever when I'm doing a good faith revert. This morning for example, I started up STiki, and classified a number of edits as 'Innovent', but the first time I tried to use 'Good Faith Revert', the message appeared after I'd hit submit. The text of the message (in case there is more than one such message) is:

  • A check associated with your last revert/AGF action found your login session has been unexpectedly terminated. This is believed to be a bug on the WMF server side, not within STiki itself. Regardless...

I get this fairly frequently, perhaps 50% of the time I try to use STiki. Sometimes it works absolutely fine, other times I just can't do good faith reverts without crashing STiki. I appreciate that if there is a bug on the WMF server, there might be nothing the STiki team can do about it, but I wonder whether other users have experienced this and have found some kind of workaround or way to avoid triggering it? Any tips would be appreciated. GirthSummit (blether) 07:49, 21 November 2018 (UTC)

Would appreciate hearing from anyone else who has this issue. This "dropped session" bug has been an extremely nasty and ongoing one, largely because it doesn't seem to be reproducible across environments. If multiple folks are seeing it often, I could drop in some more telemetry to try to pinpoint what is happening -- and if we can't fix it -- then maybe we'd be able to reach out to the WMF developers with concrete evidence. West.andrew.g (talk) 15:24, 21 November 2018 (UTC)
@West.andrew.g: In case it's useful, I'm using STiki v2.1, on Windows 10, 64-bit. I got my Java platform here. After I left that message this morning, I restarted STiki and GF reverts worked fine again; they seem to be working fine again this evening. If I ever establish a pattern of what seems to trigger it, I'll let you know. I appreciate how hard it can be to get to the bottom of intermittent bugs... GirthSummit (blether) 17:09, 21 November 2018 (UTC)
I haven't experienced this issue at all. I've just used the tool now and I did not have problems. Orphan Wiki 20:40, 21 November 2018 (UTC)
@West.andrew.g: Hi, I'm still getting this error message perhaps half of the times I use STiki; I haven't established a pattern yet, but I thought of a way that it would be possible to make it less annoying.
  • The error only occurs when I do a Good Faith Revert - so, if I get the error message, it means that I've come across something that needs to be reverted; however, the error message tells you that it hasn't performed the revert.
  • By the time the error message pops up, STiki has already loaded the next diff - so, you can't see what page it's failed to revert.
  • The only option you have is to click 'OK', thereby closing STiki - I can't go back. Therefore, if I can't remember exactly what the page was called, there's no way for me to find whatever it was that needed reverting and fix it.
  • Proposal Presumably STiki knows what page it just didn't revert on. Could a hyperlink be added to the error message, linking to the relevant page, allowing you to go and fix the problem manually in your browser?
Just a thought. Cheers GirthSummit (blether) 18:15, 4 December 2018 (UTC)

───────────────────────── @Girth Summit: I think it is reasonable that the error message link to the (un-)affected article, to the extent that helps. I will add that item to the issue tracker. Beyond that, I'll explain a bit about why this is a yucky bug. I send the edit request along with your session token (which STiki receives when you login) and the Mediawiki API generally says "cool" and ties the edit to your account. Then, what we can't figure out, is that sometimes it says "what? who is that? we don't have a session for them (error: assert user fail)". The only way to get new session tokens is for the user to login again -- and I don't want to be in the business of storing credentials and doing this automatically. A hard fail at this point was considered reasonable, because for most of history, and most users, this tends to be a sporadic issue. Question after looking at my code: When you encounter this issue, would the AGF have undone 1 edit? or 2+ edits? there is a branch in my code at this point where different API calls are used, and maybe only one branch is problematic? West.andrew.g (talk) 15:08, 5 December 2018 (UTC)

Tracked as T#063 above. West.andrew.g (talk) 15:16, 5 December 2018 (UTC)
@West.andrew.g: I'm not sure about whether the number of edits I'm reverting makes a difference, I didn't think to log in. What I can say is that it always happens the first time I used AGF revert since logging in - either the first one will fail, or the first one will be OK, in which case I know I'll be able to use it without issue until closing STiki.
In future, before I do an AGF revert for the first time, I'll check the number of edits I'm about to revert, and note whether or not it barfs; if I can establish a pattern, I'll let you know. Cheers GirthSummit (blether) 17:32, 5 December 2018 (UTC)
 Done -- The 2018-12-08 release of STiki has made significant progress on this issue (see the CHANGELOG above). User testing has confirmed cases where sessions were not viable immediately after login, but through multiple login attempts STiki was eventually able to transparently obtain a viable session so that users could proceed without error. There is more evidence than ever this bug is on the WMF side, and debugging code is in place should it become problematic in a new way in the future. I am marking this issue as fixed + closed for now. West.andrew.g (talk) 21:21, 10 December 2018 (UTC)

Help me installing the software, plz[edit]

I tried to install the latest version on Windows, but I couldn't find an executable file. What's wrong? --Mhhossein talk 06:43, 30 November 2018 (UTC)

The .jar file is the executable. ProgrammingGeek talktome 13:20, 30 November 2018 (UTC)
You will need the Java Runtime Environment to run .JAR files. On Windows, you can simply download and install it from Ninite. —k6ka 🍁 (Talk · Contributions) 13:55, 30 November 2018 (UTC)

Using bot passwords for STiki[edit]

I'm aware that users with 2FA enabled on their accounts need to use bot passwords to access STiki (or else login will simply fail, since STiki doesn't provide an interface to enter the authentication code in). I can see here that bot passwords do work on STiki, but it's not immediately clear how one goes to logging in with a bot password. Do I just enter my bot password into the "Password" field (and enter my username like normal)? What permissions are needed for STiki to work properly? —k6ka 🍁 (Talk · Contributions) 11:34, 3 December 2018 (UTC)

Nevermind. I seem to have answered my own question. In this case I more or less gave it the same permissions Huggle requires. I've been able to revert edits with those permissions. —k6ka 🍁 (Talk · Contributions) 03:33, 4 December 2018 (UTC)

Rollbacks/reverts not saving[edit]

Recently, I've been making reverts/rollbacks on STiki, however, on both AGF rollbacks and vandalism rollbacks, I took a look at both the article history, my contribs page, and the article, and have found that the rollbacks are not saving or applying. This has happened 75% of the times I've logged into STiki and tried to rollback edits. Often times when I'm in STiki, I've pressed the button, it moves to the next diff as normal, however, no action was taken. I've then had to manually run the action via the article history page, which is semi-annoying but most likely a bug. I'm wondering if I did something wrong, and I'd be happy to rectify it if so, however, it could be a software bug. I'm requesting either help or a bugfix as to why the rollbacks are only saving a portion of the time.

Sincerely, Redactyll (talk) 00:08, 5 December 2018 (UTC)

@Redactyll: Things like this make my head hurt; how things could work so predictably for the vast number of users, and then have such an unusual error condition. A couple of questions to get started: Does the "last revert panel" change in the moments after an AGF/revert change to report your attempt? Does it report success? Are you able to run STiki from a terminal/console window? If so, is any text printed to the terminal console when one of these errors occur? West.andrew.g (talk) 14:33, 5 December 2018 (UTC)
@West.andrew.g: I've recently logged onto and used STiki to try out these things, here's what I've found so far. When I recently reverted both an AGF edit and rollbacked a vandalism edit (managed to get onto a non-working session, seems to just be a random thing when it occurs), I did not see a change in any panels, except after when I pres the button the information in the bottom panels all change to the next diff that STiki shows me. Right after I press the button, I see the information for the next diff, even before it comes up, which appears to always react exactly once a button is pressed, despite the fact that the diff does not. I tried running the program via terminal, and no text has occurred when the error happens. The final strange thing is that when the issue happens, it's either all the edits in one session, or none of the edits in one session, and luckily recently it's been working perfectly most of the time. I hope this information helps, but if you need me to get back on STiki and find more information to questions, go ahead and ping me and I'll get right to it. Thanks! Sincerely, Redactyll (talk) 03:12, 6 December 2018 (UTC)
@Redactyll: @Girth Summit: This doesn't sound entirely unique from the "Frequent 'WMF has dropped session'..." thread above. Intermittent problems like this have haunted us for years, yet sometimes disappear for months at a time. GRAND IDEA. For both of you, a session that is "bad" always demonstrates problems on the first AGF attempt, right? For those of you having the issue, there could be a login box option to "Verify session viability" or something like that. The moment you login, before everything gets spun up, and while STiki still has your credentials handy, I could have your accounts edit and then attempt to AGF a meaningless page (i.e., something dedicated in the STiki project space). I could verify if this occurred. If it is succeeds, we know the session is "good", if not, we have everything ready to retry a new session transparently and automatically. We could also write a lot of debugging code around this mechanism. Does my thinking here sound correct? West.andrew.g (talk) 11:19, 6 December 2018 (UTC)
Yes, that sounds like a good option - as you say, if it's going to barf it will do it the first AGF attempt, if it survives the first one it's always fine. If I could, as you say, attempt an AGF on a dummy page when I first log in, it would save a lot of trouble. GirthSummit (blether) 13:11, 6 December 2018 (UTC)
@Redactyll: @Girth Summit: Did some coding work today. I hope to do some testing and push out the new version to you before the weekend is over. This will very much be an experimental version. Since I can't re-create the session dropping on my own machine, it might take a couple iterations before we successfully: (a) patch the problem, so that you don't encounter it, if even the solution is a bit of a hack, and (b) possibly identify the root cause and really fix the problem at the source. If you (both) are comfortable with it, could you email me directly (gmail at the very bottom of: [1] to find my email) so I can quickly exchange JAR files with you without having to publish to WP? Thanks, West.andrew.g (talk) 20:30, 7 December 2018 (UTC)
Hi - I just emailed you from a Hotmail account (I know, but I've had it for >20 years, don't want to change it now...). If you ping any files back to me I'll be happy to test them. Cheers GirthSummit (blether) 21:13, 7 December 2018 (UTC)
Greetings! I just sent you the email, and I am awaiting the file transfer. I’ll download the files once I get them, and see if they work. Thank you a bunch for all of this work you put in, I really appreciate it.

Sincerely, Redactyll (talk) 23:23, 7 December 2018 (UTC)

FYI this happens to me sometimes (it's just happened now in fact) but I usually catch it straight away. Then I log out and back in again, and it usually solves the issue. Orphan Wiki 13:24, 8 December 2018 (UTC)
 Done -- The 2018-12-08 release of STiki has made significant progress on this issue (see the CHANGELOG above). User testing has confirmed cases where sessions were not viable immediately after login, but through multiple login attempts STiki was eventually able to transparently obtain a viable session so that users could proceed without error. There is more evidence than ever this bug is on the WMF side, and debugging code is in place should it become problematic in a new way in the future. I am marking this issue as fixed + closed for now. West.andrew.g (talk) 21:22, 10 December 2018 (UTC)
Just to add, I've been using the new version for several days now, and have not had a single recurrence of this issue. This morning, I got the AGF bug for the first time in a while - but realised that it was because I'd opened on the old version of STiki by accident (I will now delete it!). In other words - the bug on the WMF side is definitely still there, but the new version of STiki is working around it efficiently. Thanks for your work on this West.andrew.g, I agree that this is fixed. GirthSummit (blether) 07:33, 12 December 2018 (UTC)