This page has archives. Sections older than 7 days may be automatically archived by Lowercase sigmabot III when more than 7 sections are present.
Please discuss STiki on this talk page. This software has a single author, West.andrew.g. Unless there is an urgent matter involving the tool, it is preferred to conduct all related conversation here, rather than on his personal talk page.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
I'm wondering what would be in the way technically to getting STiki up on Toolforge so that it's back up and it's less likely to go down hard like this in the future? Jerod Lycett (talk) 01:04, 15 July 2020 (UTC)[reply]
@Ed6767: STiki's source is on GitHub—I believe this is the full source. I know it's been two years since STiki has fizzled out and will likely need a lot of work to get it up to speed, but we might have a way of resurrecting the project. —k6ka🍁 (Talk · Contributions) 23:41, 2 December 2022 (UTC)[reply]
IMO there is a good chance this can be made to run again post-COVID, so I would be in favor of waiting some more months or until we had more definite information. Thanks,L3X1◊distænt write◊15:56, 19 November 2020 (UTC)[reply]
Hopefully that will be the case. West.andrew.g said here that he would try to revive the service the next time he's in Philly, which is probably not going to happen anytime soon given the current state of affairs in the United States. As the tool is open source, though, I would certainly be interested to hear if someone with the technical knowledge might be able to revive it themselves. —k6ka🍁 (Talk · Contributions) 16:41, 14 December 2020 (UTC)[reply]
The developer of the tool is about to lose admin privileges. Is there any way we can revive this tool without his help?
This tool was my personal favorite for reverting vandalism, it made making mistakes nearly impossible. Everything was clear-cut and refined and I'm really upset that we can't use this tool anymore. Is there any way we can revive this tool without the help of the developer, West.andrew.g? He is about to lose his administrative privileges due to inactivity and I think it's clear he is no longer interested in this project. LJF2019talk08:00, 2 April 2021 (UTC)[reply]
