Wikipedia talk:STiki/Archive 18

Archive 15

Archive 16

Archive 17

Archive 18

Archive 19

Archive 20

→

Archive 25

Whitespace in Diff Representation

Greetings. Not sure if this classifies as a bug, but I just came across an edit on the STiki diff browser in which no actual changes could be seen. So I popped over to the revision history page, where I could see that 66 bytes (blank spaces) had been added, and from there to the article's Difference between revisions page, where all was revealed. Regards, --Technopat (talk) 16:52, 4 October 2014 (UTC)

And again (4 bytes). Regards, --Technopat (talk) 17:02, 4 October 2014 (UTC)

Hmmm... I wouldn't have expected STiki to highlight the change in red, because, in the diff style STiki uses only the "black" pixels become red. The "blank" pixels stay "blank"... if you see what I'm saying.

What is STiki actually showing? A blank diff browser? The exact same text each side? The same text, but with the new spaces inserted (but not highlighted, as explained above)?

Yaris678 (talk) 15:10, 5 October 2014 (UTC)

Greetings, Yaris678. On the two occasions referred to above, "The exact same text each side". No highlights. No inserts. Regards, --Technopat (talk) 15:25, 5 October 2014 (UTC)

First, I hope you don't mind I changed the section title to something a bit more descriptive for archival purposes. Second, without digging into the source code, I acknowledge this is likely a deficiency of STiki's diff display. The color scheme and use of bold red text to indicate changes mirrors the Wikimedia default back in 2009/2010 when STiki was initially authored.

There is a larger shortcoming here, though, and that is that the diff display is essentially a bare-bones HTML browser. HTML renders multiple space characters as a single one. This is true also of actual Wikipedia pages. Notice that although wikitext may contain multiple spaces, they are rendered as one (look at the rendering of the version you reverted, [1]).

In the code behind, STiki has all this whitespace and is coloring it red -- it just gets squished and you can't color whitespace. Can/how do we fix this? One can force whitespace to display, but this could cause some font and line-breaking weirdness. Even if we get it to render visually, how do we add emphasis (a la red text)? I'm not sure Java's bare bones browser can handle the "spans" and other techniques used in the current Mediawiki style. As a bit of a hypothetical is there even a need to try to show this white-space? If it doesn't effect rendering, who cares? If rendering is not affected, could it just be treated as a null diff? Maybe a note could be added when excess whitespace is present (acknowledging the fact it might not be rendered)? Point being, I can't imagine a completely elegant/straightforward solution at the moment. Does the community have any thoughts? West.andrew.g (talk) 02:59, 6 October 2014 (UTC)

Thanks for that explanation. It may seem obvious to you techie folk, but for mere users, like yours truly, maybe a little note in the Using STiki section overleaf to the effect that in the unlikely event that an edit shows up on the diff display as having no apparent change, it's worth checking the revision history to see if the number of bytes has been modified. It's true that the byte count doesn't show vandalism of the type that substitutes all the letter As in the text for Es, for example, but such changes would show up anyway on the diff display. On second thought, maybe the above suggestion is overkill... On the other hand, I don't remember a byte count showing up on the STiki diff display, and while for larger edits there's really no need, 'cos red text adequately covers 99.9% of edits, could a byte count be incorporated as a default setting in the edit properties box (the Wiki-diff link doesn't show this –as I pointed out above, it's necessary to go to the page history to check that)? Or would you also consider this overkill? Regards, --Technopat (talk) 14:35, 6 October 2014 (UTC)

Be bold in making that change if you think it appropriate. I will investigate the possibility of displaying byte change counts somewhere in the metadata panel, although things are already quite tight. As you mentioned, a raw plus/minus doesn't always tell the whole story. The back-end classifier uses a more helpful metric "bytes of churn in edit", but trying to explain/communicate the meaning of this to editors familiar with the current plus/minus one is probably more confusing than beneficial. West.andrew.g (talk) 15:09, 6 October 2014 (UTC)

Much as I get a kick out o' being bold, with all due respect, I'll wait for some more feedback on that one, especially as to how to phrase it succinctly if the consensus is to include it. Regards, --Technopat (talk) 17:08, 6 October 2014 (UTC)

Edits by senior editors

Greetings. Edits by senior editors (admins, reviewers, more than a fixed number of contributions, etc.) are not likely to be unconstructive. So why are they showing up on Stiki? If we remove these edits from the feed, it will be easier to focus on actual vandalism. Jayakumar RG (talk) 12:32, 13 October 2014 (UTC)

Most of the time, they won't show up. However, as the queues empty, more and more will be the higher scoring ones, so will go to the top of the queue. Ignoring all admin/experienced edits can be a bad thing; If the account is hijacked and starts vandalising, if no one reviews the edits, how will we ever catch them? --Mdann52talk to me! 12:52, 13 October 2014 (UTC)

You can stop these edits appearing by going to Displayed Edits and unchecking Edits by Privileged Users. Melonkelon (talk) 13:14, 13 October 2014 (UTC)

I think I will uncheck the Edits by Privileged Users. Btw, keeping their account secure is part of the requirements for extra privileges right? Jayakumar RG (talk) 13:30, 13 October 2014 (UTC)

@Jayakumar RG:. Keeping an account secure is a basic requirement of ALL accounts, not just sysops/crats et al. As Mdann52 stated, in the event the account gets hijacked, like say thru the OpenSSL HeartBleed vulnerability or if their network is intercepted, can't help it right? --Rsrikanth05 (talk) 08:39, 21 October 2014 (UTC)

Web interface?

Implementation of a web interface for STiki might be a good idea, for those that can't install software, or for those on devices that don't support java app downloading (e.g. Chromebooks). Grognard Chess (talk) Ping when replying 14:02, 24 October 2014 (UTC)

It is perhaps worthwhile to look into how easy it would be to turn STiki into a Java applet that could run inside a browser (though I imagine some aspects of the GUI might not transfer simply). Anyone have any perspective on this? Otherwise, a thorough re-coding is probably not on my agenda (heck, a mobile application would be much cooler). West.andrew.g (talk) 16:07, 24 October 2014 (UTC)

Edit "reservation"

The server doesn't seem to have reserved one of the edits that I was reviewing. When I was being shown this edit, another edit using STiki by Onel5969 was performed at the same time as I was going to revert it, also using STiki. Is it supposed to show edits to multiple editors at the same time? – Epicgenius (talk) 15:45, 24 October 2014 (UTC)

Epicgenius - Hi. This happens to me as well from time to time. Especially when I'm doing two or more things at once, and the Stiki engine sits for a few minutes. Onel5969 (talk) 16:12, 24 October 2014 (UTC)

Oh. So it is not a problem that I have only on my end. Apparently, the STiki software works so that "when a user is shown an edit, they have a "reservation" so that no other STiki users are viewing the edit simultaneously ... [and] redundant work (edit conflicts, multiple reviews of good edits) is being avoided." Maybe it's not doing that anymore. – Epicgenius (talk) 16:15, 24 October 2014 (UTC)

At any given time, a STiki user has ~15 edits on their machine that are queued up for display and have a "reservation" against them in the back-end database. Generally, this means that no other users can have these edits in their queues, nor will others receive these edits when they ask for a fresh block from atop the queue. These reservations all have a "time-to-live" (TTL) of ~10 minutes. If the edits aren't classified in 10 minutes after receipt, the reservation is released on the server side (despite the fact they still may be cached and enqueued locally for subsequent display). This is a practical necessity: We can't let an attacker own the entire database by taking out infinite reservations on everything, and if someone does not close STiki correctly (or it hits a bug) then the reservation will not be elegantly released (and we want someone else to classify these edits). There are *also* checks ran every couple seconds to de-queue locally cached edits that have since incurred an edit conflict. In all probability, a pause/delay/slowdown/break by one user caused the edit to be re-issued, and the timing was narrow enough to avoid the aforementioned checks. I don't see this is a significant problem (the edit conflict was noted); this is lots of checking and my timing evidence shows 99.9%+ of edits are classified within their 10 minute reservation window (or elegantly released). West.andrew.g (talk) 16:22, 24 October 2014 (UTC)

@West.andrew.g: Thank you for the explanation. The problem is that I was shown the screen just a few seconds before the other edit was being made. When Onel5969 made the revision, it may have been handed to me by accident. It may be a one-time error, though. – Epicgenius (talk) 16:42, 24 October 2014 (UTC)

Request to join

Hi all, 'd like to be permitted to use STiki. I'm nowhere near 1,000 article edits, but have been using and somewhat editing Wikipedia for almost a decade. Lately I encountered vandalism in an article I've been editing, and so started doing some manual vandalism tracking and reverting. I've read a lot of material about it, and wish to help. Thanks. Ehudzel (talk) 10:29, 24 October 2014 (UTC)

C -- @Ehudzel: First off, thank you for your long-term participation on the project. This certainly demonstrates good-faith in your request. However, just 60 edits across this time interval doesn't speak much about your knowledge of the warning system and some of the other practicalities by which the vandalism machinery operates. Would you be willing to participate in a round of WP:CVUA? We typically use that process to onboard requesting users who might already have several *hundred* edits. Thanks, West.andrew.g (talk) 13:51, 24 October 2014 (UTC)

Thanks a lot. I will try WP:CVUA. Ehudzel (talk) 14:16, 25 October 2014 (UTC)

Request for Access

I would like to use STiki. For awhile now I have been patrolling Real Time Recent Changes (Beta) and using Twinkle to revert vandalism. I think STiki could help increase my speed and ease of anti-vandalism. Note: I have made over 500 edits and created a new page (Achievement Hunter) EoRdE6 (talk) 18:56, 29 October 2014 (UTC)

Due to above referenced travel, can an experienced STiki community member perform the usual due diligence and make a recommendation here? Thanks, West.andrew.g (talk) 02:03, 30 October 2014 (UTC)

Not sure: to me, it seems like EoRdE6 would benefit from WP:CVUA. although they have done some with vandalism, and warn users pretty consistently, it seems like there are some issues with false positives, ie, reverting constructive contributions. a related concern is that the user has not always fully replied to reponses made by users whose edits they reverted. i think CVUA would help EoRdE6 get a better sense of how to deal with ambiguous cases, discussion with other editors, using the talk page, etc. aside from some sparse contributions on an old account from over a year ago, EoRdE6 has only been editing for about a month. i think it's a good idea to take more time to become familiar with counter-vandalism efforts. ~ Boomur [☎] 04:54, 30 October 2014 (UTC)

I'll agree with this recommendation. However, I'd also like to have a broader discussion on STiki recruitment and participation. We recommend a lot of people over to WP:CVUA. However, how many of those ever return to classify as part of the STiki team? To some extent this might speak to the fact the user wasn't *that* interested, but conversely, we could be losing participants due to borderline circumstances (trying to imagine through some cost-benefit-risk ratios here). WP:CVUA doesn't seem like a terrible burden to me. How long does it ordinarily take to complete (absent communications delays)? Others may have noticed our "milestones" page has been a little sluggish lately, and we haven't been on-boarding new users at the typical rate. Daily classification counts have also been down, despite revert rates holding steady to previous numbers. How can we do better? West.andrew.g (talk) 16:32, 30 October 2014 (UTC)

Some admins issue a template when they award rollback rights. If I recall correctly, this mentions Huggle and some of the other new capabilities available to rollback users. I don't think STiki is on that list; can and should we be? West.andrew.g (talk) 16:35, 30 October 2014 (UTC)

i think the most common rollback message is {{rollbackgiven3}}, which does not actually mention Huggle etc. not sure if there is some other message that does? i don't think it would hurt for this message to direct users to the additional tools that are made available by receiving rollback. might also be worth mentioning on WP:RBK! ~ Boomur [☎] 17:05, 30 October 2014 (UTC)

The template seems to be substituted, but this is an example of what I was thinking of: User_talk:Tony_Tan_98#Rollback. Thanks, West.andrew.g (talk) 20:40, 30 October 2014 (UTC)

IP editing?

Yesterday, it seems as though an IP user, 108.21.111.234 (talk · contribs · WHOIS), was using STiki, at least in their summaries.

Is this a bug, or are IP users now allowed to edit using STiki? Epicgenius (talk) 14:39, 29 October 2014 (UTC)

It's a registered editor who has WP:STiKi, but, somehow, sometimes the editor's IP address is recorded as using WP:STiki; I noticed the matter earlier this year regarding my own IP address, and Johnuniq explained the matter to me. He explained it better than I just did to you, which is why I've pinged him via WP:Echo to this discussion. Flyer22 (talk) 14:45, 29 October 2014 (UTC)

Okay, so it's a bug. Got it (kind of; still need that explanation, though). – Epicgenius (talk) 17:27, 29 October 2014 (UTC)

I'm on a plane (and therefore a sub-par connection). Can someone search/link the archive on this? I recall this coming up before, but I am not sure I had a great explanation. STiki continues to record the username in its databases, so it seems the WMF is dropping the session? STiki never modifies the session key and I don't think we even have "log out" code that could be mis-firing -- so something has to be happening on the WMF side to preliminary terminate things. I'm not privy to what that is, and it might be hard to file a bug report with the WMF given this strange junction of my third-party tool and their server-side behavior. West.andrew.g (talk) 01:36, 30 October 2014 (UTC)

I don't have any insight into what might cause a STiki session to be become logged-out but WP:VPT has had claims from people that they get logged out while doing normal editing. When manually editing, if something logs you out you might notice any of several clues such as your skin changing (if you have a non-default skin), or your signature not appearing in a preview (if posting a comment), or your name not appearing at the top of the window, or the "You are not logged in. Your IP address will be publicly visible if you make any edits." warning that appears above an edit window. However, when making automated edits with a tool like STiki, none of that happens. STiki thinks it is logged in, and it would be difficult for it to detect that it no longer is. Bots are supposed to use something called "assert=user" to check they are logged in, but I don't know if there is a good way of doing that for a tool like STiki. Johnuniq (talk) 09:34, 30 October 2014 (UTC)

Thank you for the pointer on the "assert" extension. I wasn't aware of this and it seems straightforward to implement. I've tracked the issue as T#048 in the above table. Thanks, West.andrew.g (talk) 16:19, 30 October 2014 (UTC)

Oh, you are using the API for the work? I guess you have to ... should think before talking. So, yes, assert=user should be a simple fix for whatever is the underlying problem. For some related humor, check Special:Contributions/10.68.16.32 (for onlookers, that shows current editing from a private network which "cannot" happen; it is a bot which has not noticed that it is logged out). Similar incidents have been reported in the past, although I've never seen a direct explanation. Apparently some bots (wmflabs?) access Wikipedia directly without going through the Internet, so private IP addresses are used. Johnuniq (talk) 01:27, 31 October 2014 (UTC)

By the way, for testing I think you can log on using a browser and STiki. Then use STiki, then go to the browser and log off. I think that will also log off the STiki session without STiki's knowledge. Johnuniq (talk) 10:46, 31 October 2014 (UTC)

This was confirmed as a bug last month I believe. I think the session issue is a WMF thing. I have found myself logged out multiple times in the past within a few minutes while making an edit. --Rsrikanth05 (talk) 18:47, 31 October 2014 (UTC)

How to close STiki if it stops responding?

STiki can be a little temperamental when my Internet speed is slow, which means it sometimes stops responding and refuses to close. I can't find the process in task manager, so how can I close it? I can always open a new process, but prefer to close previous. Melonkelon (talk) 22:29, 30 October 2014 (UTC)

Nevermind, it's the javaw.exe process. I suspected it could've been but wasn't sure, so I just opened multiple processes and sure enough it was. Melonkelon (talk) 22:35, 30 October 2014 (UTC)

It also happens when I click on pass at times even though my internet is not slow. --Rsrikanth05 (talk) 18:50, 31 October 2014 (UTC)

STiki not working?

I can't connect to the STiki server for some reason today. Is it down for maintenance or just down? --I am k6ka ^{Talk to me!} _{See what I have done} 11:20, 31 October 2014 (UTC)

Yep, it's down. Widr (talk) 14:28, 31 October 2014 (UTC)

I think a status indicator should be put up on WP:Stiki. --Rsrikanth05 (talk) 18:49, 31 October 2014 (UTC)

Still down. Melonkelon (talk) 20:00, 31 October 2014 (UTC)

C Scheduled maintenance at UPenn took us offline. Still awaiting a response from my local colleague. West.andrew.g (talk) 20:25, 31 October 2014 (UTC)

Is there an ETA for having the server back online? - Cwobeel (talk) 21:02, 31 October 2014 (UTC)

As soon as one the aforementioned colleague walks down to the server room and presses a button. As pre-condition to this, he'd need to actually be in the office. We're getting dangerously close to the weekend, so I just sent an email to an additional contact who can help. There is nothing technical about the solution -- and we've long been troubleshooting code so that the server will re-attach itself to the network, but clearly that isn't working yet. West.andrew.g (talk) 21:59, 31 October 2014 (UTC)

Is it possible to set up an alternative 'temporary' server for Stiki to run when the main server is down? Or to act as a switch to switch it back on or something? I suck at programming, my opinion does sound stupid. --Rsrikanth05 (talk) 09:48, 1 November 2014 (UTC)

That sounds a bit more like an "alternate" server, in which both servers run simultaneously, syncing data between each other, and one can take over when one goes down. Because the STiki server stores edits, having a temporary server that only runs when the main server is down would probably mean no edits in the server for STiki users to check, unless the edits on the main server are synced with the alternate server. --I am k6ka ^{Talk to me!} _{See what I have done} 14:00, 1 November 2014 (UTC)

I was right then. It was a stupid idea. :p --Rsrikanth05 (talk) 15:20, 1 November 2014 (UTC)

I'm assuming that Stiki won't be up till after 8am on Monday morning which [in local time zone for UPenn] would be more than 16hours from now? --Rsrikanth05 (talk) 13:32, 2 November 2014 (UTC)

It doesn't seem like anyone wants to work weekends, especially considering how over there DST just ended, so everyone gets an extra hour of sleep (may as well sleep in rather than work!). Monday it is, then. --I am k6ka ^{Talk to me!} _{See what I have done} 19:25, 2 November 2014 (UTC)

 Done -- Back online. More details as my time permits. West.andrew.g (talk) 20:06, 3 November 2014 (UTC)

Thank you! --Rsrikanth05 (talk) 20:11, 3 November 2014 (UTC)

Nothing grand to report here. The connection went down because of planned maintenance, and while my scripts used to *detect* the downtime were accurate, the reconnection code once again failed. I have already authored an alternative strategy for next time (these are all based on ways to check and restart interfaces in Linux, things like "service network restart", "ifup eth0", sending commands to the specific network manager, etc.). I emailed my on-site colleague within one hour, but unfortunately it was caught in a spam filter, and the correction was not completed until he returned to the office on Monday AM. These maintenance windows have slowed dramatically now that classes are back in session at the hosting site, so I am hopeful we will have a good long run -- and if not -- I am hopeful I have finally found something that works on the auto-reconnect front. Thanks, West.andrew.g (talk) 16:54, 7 November 2014 (UTC)

Feature Request:3RR caution

I have gotten into trouble with the WP:3RR with Huggle before, not paying close attention to the articles. I don't want that to happen again. Could there be a message box that pops up and prompts you to continue or abondon. That would save a lot of worrying. Thanks,  ΤheQ Editor  ^Talk? 21:22, 6 November 2014 (UTC)

Can you describe how you think this will be an issue? I can think of a few reasons why this might not be much of an issue:

• STiki is chiefly about finding and reverting vandalism. Obvious vandalism is exempt from the 3RR. Most vandalism is obvious.
• The STiki workflow means that the revert is normally a few minutes or hours after the original edit, unlike in Huggle. The vandal has normally got bored and gone away before the revert happens, reducing the chance of follow-up vandalism.
• The STiki workflow means that follow-up vandalism is likely to be passed on to a different STiki user.

Yaris678 (talk) 09:10, 7 November 2014 (UTC)

I agree with Yaris' logic here. Through 600k+ reverts I cannot think of a single time that 3RR has been brought to my attention, and it seems exceedingly unlikely given the criteria above. I don't feel this is something that needs to be implemented at this time. West.andrew.g (talk) 17:03, 7 November 2014 (UTC)

STiki not working in shared IP

I don't know about this, but recently, I tried opening STiki up on a shared IP address and it showed me the error message. At home, it always works but I can't seem to ge it to work in shared IP addresses. Is it because that I can't operate it under a shared IP or I can't operate it under an IP that is blocked. Is there any way to fix this? Thanks,  ΤheQ Editor  ^Talk? 20:55, 6 November 2014 (UTC)

Hi TheQ Editor,

What is the error message that you get? That will help Andrew to diagnose the problem.

Yaris678 (talk) 09:11, 7 November 2014 (UTC)

Error: Backend Connection is required.  ΤheQ Editor  ^Talk? 13:49, 7 November 2014 (UTC)

There is no blanket problem with "shared IP addresses" on Wikipedia or STiki. Even if an IP address is blocked (including Tor nodes), that does not prevent someone with a registered account from using that IP address. The more likely issue here is the configuration of the shared IP address and its router. Chances are this shared IP resides at some institution (school, business, etc.) that has blocked the MySQL port (3306) from sending/receiving traffic. This can be done for security reasons, content policy, bandwidth savings, etc. You may be able to speak with a network administrator about opening that port in the institutional firewall, but this is nothing STiki has control over (STiki is never even seeing your connection attempt). Thanks, West.andrew.g (talk) 17:10, 7 November 2014 (UTC)

Vandalism warnings & block

I used STiki version 2.1,to warn following user User talk:125.34.54.177 for vandalism, I selected Vandalism classification in Login panel for this purpose. To my observation warnings for vandalism were issued as "User warning for unconstructive editing found using STiki". Initially i thought user might have been blocked from editing as i have issued him many warnings(as what happens in other tools like Huggle, Igloo etc.) but when i saw his talk page, no final warning was added, So i used Twinkle to issue him Final warning & reported the case at Wikipedia:Administrator_intervention_against_vandalism#User-reported. Is there any option which could be added in STiki; where in case of such emergency(where User/IP is vandalizing wikipedia) we can issue him warnings in increasing order of their wrong actions like General Note >Warning>Caution>Final Warning>Request Block & so on such that Bots/Admin could block User/IP immediately( !dea4u  11:26, 13 November 2014 (UTC))

@!dea4u: STiki has considerable logic to auto-increment warning levels in an intelligent manner (designed to play nice with Huggle's system and other tools), and some aspects of that failed here. First, STiki should have never created a second section labeled "November 2014". There was already one with that exact title, which STiki created just seconds earlier. STiki's policy and that of other tools is to append warnings to the existing section (assuming there is one that matches the month/year). Why this happened is a bit perplexing, but 'replag' (replication lag on the WMF servers) is a leading candidate since the two warnings were made only a couple of seconds apart (the failure to escalate the warn-level on the second warning also corroborates this). This might not be STiki's fault, but STiki poorly handled the situation after that.

At every subsequent warning STiki asked "does this user talk page have a 'November 2014'" section on it?". My code was always returning the first such section, parsing it to find the highest level (the level 1), and saying "give this user a level 2 warning". Then that warning was getting appended the 2nd "November 2014" section. Rinse and repeat; the process continued through several warnings. To wrap-up, identically named sections were a problem spot, and I've coded up a fix that will be pushed in the next release. Thanks, West.andrew.g (talk) 01:03, 14 November 2014 (UTC)

'Numerical updates': cases for inspection?!

Hello co-STiki-patrollers, I have a question that keeps coming back to my mind while patrolling. Often enough, an edit (on top of the queue) gets presented which updates certain numerical data: like a footbalclub, the number of goals made goes up from 8 to 9, when we move from 2013 to 2014. Or a baseball pro has a new score, up from 88 to 90, as we move from 2012 to 2014. Or a certain movie has new box-office results. Etcetera etcetera. Variations are endless. This is obviously not obvious vandalism: at first sight, the figures look plausible. So only a thorough check somewhere else will uncover whether this is a constructive edit or not. I actually hate such edits. I do check sometimes; but at other times I say to myself: please, let the soccer fans or movie afficionados concerned do the checking themselves - it is just so time-consuming. Subsequently, I press 'Pass' (leaving it to someone else). What are your opinions about this?! How do you co-patrollers handle such edits?! Thanks for any feedback. Super48paul (talk) 12:04, 5 November 2014 (UTC)

Same here, I used to worry about it at first, but then soon started just pressing "Innocent" for such edits. While we are talking about certain edit types which pop up, I got one: those edits by IPs or newusers who blank articles and redirect them--what do you do for this? -Ugog Nizdast (talk) 15:27, 5 November 2014 (UTC)

Oh well, much less in number than those 'numerical' edits. Anyway, I just go in and check and hope I take the right decision... Super48paul (talk) 15:52, 5 November 2014 (UTC)

Hi Paul, In this situation, I normally Google it. e.g. search for Joe Bloggs goals scored. I normally find a sports stats website or similar that has the answer.

Most of the time the edit is innocent, but I like to do the search so I feel like I can catch stealth vandalism.

If I can't find the answer fairly quickly and the new number looks plausible I will press innocent. (Pressing pass would just mean that other STiki users have to do the same search.)

Yaris678 (talk) 09:21, 7 November 2014 (UTC)

Of course Yaris' suggestion to actually validate the number is the best policy, but absent that, I think an "innocent" label is appropriate so long as the change in numerical value is minor. These are pretty unsatisfying cases, I agree. In fact, it shouldn't be too hard to write a user filter (similar to the one we already have for edits by privileged users) that examines if numerical changes are the only edits to an article. West.andrew.g (talk) 17:28, 7 November 2014 (UTC)

Tracked as T#049. Thanks, West.andrew.g (talk) 17:38, 7 November 2014 (UTC)

OK, thanks for the suggestions everybody. Just a few last remarks. 1. On encountering a minor numerical edit, that looks more or less OK, I will henceforth press Innocent (and not Pass and shift the burden to someone else). 2. About the proposed filter: would it be an idea to introduce that filter indeed, but make an exception for numerical-only-changes that change numbers and make them very much larger or very much smaller (say by a factor 10 or more)? With me such large changes always trigger the alarm bells.3. Deciding on such numerical-only-edits will remain a matter of judgment I presume. Super48paul (talk) 10:02, 8 November 2014 (UTC)

I'd recommend caution before assuming these edits are innocent, because even small changes to numbers and dates surprisingly often turn out to be inconsistent with other parts of the article (lead, body, infobox, tables, persondata) or with an adjacent citation. One can imagine a young person saying "look mates! I changed this and nobody noticed!" Recommend checking these edits where possible, especially when made by a new user or IP or one with previous warnings: Noyster (talk), 11:17, 8 November 2014 (UTC)

i think an ideal situation would be having the omission of "numerical" edits simply be an option. so by default, these edits are still presented for assessment, but the user could have the option to tick a box and turn thr filter on. this way, the editors who just want to "pass" all of them can skip a step in the process, while users who have time/patience to be more thorough can handle these edits. maybe there could even be an option to only show numerical edits, for users who want to do some real menial labor. of course, these are just some ideas, and i'm not sure how easy they would be to implement. ~ Boomur [☎] 15:06, 8 November 2014 (UTC)

I agree with Boomur. I get these edits thrown in quite often and end up clicking pass in most cases. --Rsrikanth05 (talk) 14:49, 16 November 2014 (UTC)

CHANGELOG for 2014-03-25 release

Greetings STiki-ers... An emergency release was issued this morning because of slight extensions the WMF did to their login procedure (seems geo-location is now part of the process). Our code was not generic enough to handle this rather minor change, breaking login in some respects, and causing STiki-initiated edits to be associated to user's IP addresses. If there is any concern a STiki user was "outed" in this fashion, contact me privately and I'll use my admin bit to REVDEL the edits into oblivion. This version will break previous ones; old versions should no longer work and pop a dialogue about the new version. Aside from this:

• The "Revision Filter" menu title was changed to "Displayed Edits" in order to clear up some abiguity over sub-menu items.

I realize there were some other minor items on the TODO list (null edits, AGF messages). Those have been pushed to the next release due to the haste with which this copy needed to be released. Thank you for the continued support. West.andrew.g (talk) 16:11, 25 March 2014 (UTC)

Unnecesary "don't template the regulars message"

I got a "don't template the regulars" message when reverting this edit in STiki. This seems a bit odd because I had already unselcted "warn offending editor?"

(I had also already blocked the vandal, although I don't necesarily expect STiki to check for that.)

Yaris678 (talk) 15:06, 24 November 2014 (UTC)

Good catch, and it is an easy fix (if that is the desiresdoutcome). However, I wonder if the real power of the "DTTR" dialog has nothing to do with people changing whether or not a warning is issued, but instead notifying a STiki user they are about to revert someone with a certain degree of experience (perhaps giving the edit a second look with a widened margin of "good faith"). If this is the case, maybe we should change the wording slightly and pop the dialog regardless of the "warn user?" checkbox status. Thoughts? West.andrew.g (talk) 19:08, 24 November 2014 (UTC)

Yes. Not sure what the message should say. Maybe something like this.

This user has X edits. Are you sure you want to revert? Sometimes, with more established users, a more bespoke response is appropriate. e.g.:

• Revert without a template message
• Leave a specially written message on the user's talk page
• Start a discussion on the article talk page
• Start are discussion at a noticeboard such as WP:ANI
• Block (if you are and admin), or report at WP:AIV.

It depends on what the editor's other contributions are like.

Yaris678 (talk) 12:54, 25 November 2014 (UTC)

Hello everyone: I think the message could be rephrased like has been said (this is a regular editor - are you sure you want to revert him/her?); gives one an incentive to think twice. But after that thinking-twice I have enough buttons to live with (good faith with several messages; vandalism without any message). If needed, just switch to the diff and you find every entry and button that one could need to leave messages etc. So do not complicate this issue - just change the wording, that is all. Super48paul (talk) 14:13, 25 November 2014 (UTC)

Tracked as T#050. Thanks, West.andrew.g (talk) 15:38, 25 November 2014 (UTC)

Thanks Andrew.

Paul, I wasn't suggesting that STiki should enable automation of all the things in the bullet-pointed list. The idea was that the list is part of the message to users. To help them think of what might be appropriate in the situation.

Yaris678 (talk) 18:43, 25 November 2014 (UTC)

OK OK Yaris, so we agree on this..Super48paul (talk) 19:48, 25 November 2014 (UTC)

Single space in front of good faith messages causes rendering problems

Some of the pre-formatted messages have a space before the message, causing them to render like this:

 Hello, this is a warning.

Instead of this:

Hello, this is a warning.

Could you please fix this? Thanks, Melonkelon (talk) 06:29, 1 December 2014 (UTC)

 Done -- A new version has been uploaded under the previous version/filename with the fix. Thanks, West.andrew.g (talk) 15:45, 1 December 2014 (UTC)

Spacing issue on Mac OSX

Hi, thanks for the awesome update! I use OSX 10.9, and with the update some parts of the interface are not completely visible. This includes the 4im button, the watchlist options dropdown, and the links in the edit properties box. The latter you can fix by resizing the whole interface, but the left side (login panel, classification) doesn't seem to be resizable. This isn't a big issue for me because I happen to know that that's the 4im button, etc, but I thought I'd let you know. One thought is if the left side cannot be resizable then perhaps we could reduce the width of the Back button. Here's a link to a screenshot: drive.google.com/file/d/0B7RNXFFBKTc3c0tWQVV6bUpyRVU/view. Side note – I didn't upload to enwiki or commons as I wasn't sure of copyright concerns. It seems we'd inherently need permission from you. Thanks a million! — MusikAnimal ^talk 15:39, 1 December 2014 (UTC)

As a preface, GUI development is super un-fun work. Producing something that looks natural and aligned as resolutions change and whitespace disappears probably consumes 2/3 of the STiki code-base (as opposed to interesting anti-vandal logic). Your entire display is a bit "spacier" than mine, which is frustrating given that: (a) I write tons of constraint code to keep components displayed in full, but tightly aligned, and (2) I expect the cross-platform nature of Java to standardize things better </rant>.

Has your "back" button always been that wide? On my machine (by code design) it is probably not a pixel wider than the vertical text it contains (and then everything in that panel fits nicely). Would you be willing to email me to open a thread whereby we can exchange screenshots and new versions to troubleshoot? Thanks, West.andrew.g (talk) 15:59, 1 December 2014 (UTC)

Yes, I believe the back button has always been that big. Things never aligned perfectly but that is of little concern. The important part is the functionality which is clearly there. Here the only thing I see bothering someone who's never used the tool is that we don't see all of the 4im button. The rest of it they'll figure out, and I don't think you should wear yourself out trying to get it perfect ;) You can email me at Special:EmailUser/MusikAnimal and I'll be more than happy to work with you further. Best — MusikAnimal ^talk 17:19, 1 December 2014 (UTC)

Out of curiosity, how many STiki users see something more like MuskiAnimal's screenshot than the "official" one from the project page: [2]. Ignore the fact my screenshot is a bit outdated with the new version release. Is this a Mac only thing? I run Linux + Windows. West.andrew.g (talk) 17:55, 3 December 2014 (UTC)

STiki not functioning

I have been using STiki over the last few days, and went back to one article to see how the vandalism reversion was logged. To my surprise, neither this, nor any other of the article edits I have been able to check on, were affected by my classifying them in the STiki interface. In other words, when I click on "Vandalism" or "Good Faith Revert", nothing happens: the article remains the same. (Some of the many recent articles that should have been reverted but were not are Chemical bond, Christmas traditions, and Phylum)

The other symptom I've noticed is that the "Back" button does not come into focus or function (it remains greyed out).

I'm a little disappointed that a good many reviews were wasted. Any idea what's happening? HGilbert (talk) 03:31, 3 December 2014 (UTC)

@Hgilbert: Greetings, and thank you for your work. It appears all your actions are being logged by the STiki tool (and captured on our "leaderboard"). However, when I spot check the RIDs (you have provided feedback for) on the encyclopedia, I see many of them have been reverted by the STiki tool, but associated with an IP address instead of your login account. There are a couple of IPs in this set that are nearly adjacent in address space, but I'll decline to mention these to protect your privacy (contact me privately if you'd like to know them).

This looks symptomatic of your "edit session dropping" (essentially, the WMF servers are logging you out when they shouldn't, rendering the authentication tokens STiki obtained on your behalf worthless). This page's archives mention this issue a couple of times recently, and there is evidence (including third-party evidence) this is something the WMF servers are screwing up. We've always assumed this "session dropping" to be an unusual event. However, your history indicates otherwise, with it happening to you across multiple days and IP addresses.

Do you do any unusual login/logout behaviors? Run any other external tools in parallel that require login? What version of STiki are you using? The new version released yesterday-ish can detect this as described in item T#048 (see the CHANGELOG thread above). Could you download the new version; spot check your contribution history from time to time, and let us know if you get a pop-up indicating the problem has come back (or the problem comes back and you get no pop-up)? West.andrew.g (talk) 05:28, 3 December 2014 (UTC)

I have downloaded the most recent version (mine was well over a year old) and it seems to run without problems. The back button still does not function, however.

I am often logged in to WP simultaneously on my browser; could this have been causing the behavior? HGilbert (talk) 17:27, 3 December 2014 (UTC)

The back button *never* becomes activated? By design the back button will disable itself when: (1) There is no previous edit (i.e., when STiki starts or you change queues), (2) After you have pressed the the "vandalism" or "AGF" buttons (trying to undo the revert action and any warnings would be messy business), and (3) After you have just pressed the "back" button (the depth is limited to one). If you classify an edit as "innocent" or "pass", then the back button should be enabled and you should be able to go back that one edit. Is that not the case?

Being logged in inside the browser should be no big deal; I think we all do that. I was just looking for something odd. Thanks, West.andrew.g (talk) 17:51, 3 December 2014 (UTC)

Thanks for this clarification; the back button is functioning as designed, then. It seems that updating to the newest version has cleared up the problem entirely. Thanks! HGilbert (talk) 20:36, 3 December 2014 (UTC)

Phabricator?

Are there any plans to move the bug tracking over from a table on the project talk page to something that's designed more specifically for bug tracking, like Phabricator? APerson (talk!) 05:27, 8 December 2014 (UTC)

Not at this time. We've only had ~50 tickets in STiki's history so a dedicated platform may well be more cumbersome than it is worth. Moreover, there is some convenience in having it adjacent to our project discussion. I think the current approach well serves non-technical portions of the user base, and is immediately apparent to those who might drop in to make a duplicate request/report. West.andrew.g (talk) 16:56, 10 December 2014 (UTC)

How would you characterise STiki's effect on collaboration?

I notice this change from

STiki gives a collaborative approach to reverting vandalism.

to

STiki supports a collaborative approach to reverting vandalism.

What do people think is the best description?

For me the word "supports" is a bit wishy-washy. STiki actually changes the flow of information to practically enforce a collaborative approach. I like the word "gives", but I thought it would be good to discuss it here and see what people think.

Yaris678 (talk) 19:00, 25 November 2014 (UTC)

Or implements?! Super48paul (talk) 19:57, 25 November 2014 (UTC)

As indicated in my edit summary, give is not idiomatic English; it reads like something written by a non-native speaker of the language. The customary verb characterizing the affordance of a piece of software is in fact support. Alternatives might be allow for or facilitate. ARK (talk) 10:05, 26 November 2014 (UTC)

I think I'm saying is that STiki involves more than an affordance. To use the first example in the linked article, a knob affords twisting but it doesn't enforce it. I like Paul's word "implements". Similar options would be "employs" and "practices". "Effects" would be good, but it could be confused for "affects". Yaris678 (talk) 10:28, 26 November 2014 (UTC)

Or: effectively implements?! Super48paul (talk) 12:20, 26 November 2014 (UTC)

STiki offers a collaborative approach to reverting vandalism. ARK (talk) 14:18, 26 November 2014 (UTC)

I suggest "provides"... "Implements" is also good. "effectively implements" is superfluous. --Greenmaven (talk) 22:25, 26 November 2014 (UTC)

Yes. "provides" is good... although... there is a shorter word that means the same thing... "gives". Yaris678 (talk) 09:46, 27 November 2014 (UTC)

Stiki enables, provides for, employs. How do they seem? Or empowers? --Rsrikanth05 (talk) 20:03, 28 November 2014 (UTC)

"Provides for" is an interesting one. Similar to "support" really, but slightly different connotation... like it is less likely that the collaborative approach would exist without STiki. "Empowers" doesn't work for me. "Employs" is a new way of looking at it. It's like the collaborative way of working was already there and STiki just uses it. Kind of the opposite of "provides for" but also kind of true. Makes me wonder if there is a word that means something does both. Likes "Fits in with"... "coheres with".... although we've still got the problem of it not being clear that this collaborative approach wouldn't exist without STiki.

I think "confers" kinda works, but is a bit obscure.

I still like "gives".

Of all the words that ARK suggests, I think I prefer "facilitates".

Yaris678 (talk) 19:18, 30 November 2014 (UTC)

O.K. Discussion seems to have stopped. I've gone back to "gives", but happy to discuss further here. Yaris678 (talk) 14:08, 3 December 2014 (UTC)

Sorry, but "STiki gives a collaborative approach" is just not idiomatic English. Several other suggestions are better: supports, facilitates, provides. "Supports" is not "wishy-washy"; it is a standard term in the documentation of computing systems. Greenmaven (talk) 05:50, 5 December 2014 (UTC)

Ok. My vote goes to "facilitates". Greenmaven (talk) 06:03, 5 December 2014 (UTC)

O.K. I've used the word facilitates and tweaked the other words to simplify it slightly. Yaris678 (talk) 13:19, 11 December 2014 (UTC)

A bug in warning messages

Stiki adds an extra space that results in a clumsy appearance of (the newly added) warning messages. A typical example [3]. Materialscientist (talk) 12:09, 3 December 2014 (UTC)

Hi Materialscientist.

Did you download your copy before 15:45 (UTC) on 1 December? This could be the bug discussed as #Single space in front of good faith messages causes rendering problems. That was fixed but if you downloaded after that point then it mustn't've been done for all messages.

Yaris678 (talk) 13:36, 3 December 2014 (UTC)

Yep, pretty sure I caught all of these in that initial fix Yaris referenced. It didn't seem worthwhile to issue a new "date of release" and cause confusion, although I guess I maybe should have appended some type of numerical identifier to the filenames. Thanks, West.andrew.g (talk) 16:27, 3 December 2014 (UTC)

Thanks, that helped, but Stiki still does a lot of this [4] (piling up warnings, breaking section headers due to a missing space - I know it could be superfluous depending on the previous edit). Materialscientist (talk) 21:59, 9 December 2014 (UTC)

This is very strange. If I look at the next edit the diff suddenly recognizes the line breaks and the message displays correctly. Anyone know what's going on here? My best guess is that STiki is using the wrong newline code. Yaris678 (talk) 09:42, 10 December 2014 (UTC)

In the initial diff that Materialscientist provided there is a single carriage return -- by design -- after the previous warning before the section header that STiki placed (if there wasn't, the first two equals signs would likely be on the previous line). STiki's source code has been adding a single carriage return before placing new sections for a long time; so I think its worthwhile to question what has changed. Moreover, a single carriage return should be sufficient, as casual sandbox experimentation will reveal.

One thing that looks odd to me is the way Mediawiki is parsing these diffs, specifically the "2014 (UTC)" portion. Intuitively, returning to [5], STiki was responsible for the trailing "2014 (UTC)" instance at the document's end, but the diff-parse suggests it pre-pended a ""2014 (UTC)" to its section creation, and then awkwardly "in-line inserted" (vs. "appended") a warning without a full date to instead use the date that was associated with the previous warning (tough to describe; sorry). Clearly, this is not how the edit happened in practice. This is something I've only seen very recently, and I suspect this weirdness may be confusing the MediaWiki parser about the section creation.

There is no issue with the newline code. It's no problem to add a second carriage return so there is a blank line in the wikitext in these cases. However, some systems (including STiki and Huggle) leave a line of trailing whitespace after warnings that could create a larger-than-expected gap. Regardless, I think someone should open a Mediawiki technical thread or bug report. The fact the document parses two different ways as the result of trailing text like this is quite odd behavior. West.andrew.g (talk) 16:46, 10 December 2014 (UTC)

Hi Andrew, I don't think it is a question of one new line or two. I think it is the type of new line. Believe it or not, there are at least two new line characters in common use. I believe that MediaWiki uses the character that is commonly used in Unix, which is different to that used in Windows.

Take a look at this diff. I swear I did not change the text at all... and yet we don't get a null diff. I think that when you edit manually, MediaWiki must automatically replace the "wrong" new line character with the "right" new line character. This theory also explains why, on the left of the diff, you have an apparent new line after the heading and yet it is all shown in one box... i.e. it all treated as one line by MediaWiki.

My guess is that the code that generates the "December 2014" heading uses the wrong new line character. Has this code changed at all recently? Maybe the MediaWiki API used to correct the new line characters it was given but this has been removed... that would also explain it.

Yaris678 (talk) 17:24, 10 December 2014 (UTC)

My code has been using the "\r" code (carriage return) in the Java string formatting to achieve these line breaks. This is noteworthy, because myself and other programmers usually default to "\n" (new line) to achieve the same effect. This leads me to believe (and I can almost recall), I tried "\n" in STiki's early development, found it not to work when parsed by Mediawiki, and then shifted to "\r" and found it to work. So yes, something new in the Mediawiki parser may be to blame here (and I'll see what "\n" does these days). Help:Formatting#Paragraphs might suggest an alternative method, although that prints the formatting instructions in the wikitext, rather than just making the whitespace appear (the latter probably being preferable). Thanks, West.andrew.g (talk) 21:00, 10 December 2014 (UTC)

I made about 25-50 reverts last night (see my contributions) using a version that replaced "\r" with "\n". Going through the talk page notifications, I observed no issues, though I am unsure if I hit any cases that would have been problematic previously (not really sure what characterizes these cases yet, or how prevalent they are). Does anyone see differences in my work and that being produced by the current STiki version? How bad are these issues, do I need to push out a new release? West.andrew.g (talk) 15:55, 11 December 2014 (UTC)

I think this problem is pretty wide-spread. I can see the problem with both Widr and Flyer22. I picked these people because they are frequent users. I wasn't aware of them having this problem before. The Widr example is interesting because it shows that the problem is there even when no section heading is created. I say roll out the new version. Yaris678 (talk) 09:41, 12 December 2014 (UTC)

 Done -- New version up, let's see if that fixes things. Thanks, West.andrew.g (talk) 20:59, 12 December 2014 (UTC)

Requesting permission to use STiki tool

Hello, I would like to request permission to use the STiki tool in spite of a relatively few number of edits. I've been involved quite a bit recently in vandalism reversion as you will see from my contribs, relying on the Lupin anti-vandal tool. Thanks! Mediavalia ^talk 17:20, 12 December 2014 (UTC)

 Done -- @Mediavalia: STiki access has been granted. The user has done exclusively patrol/anti-vandal work since joining the project. In the course of this, he/she has demonstrated appropriate use of the warning system, AIV reporting, and the detection of inappropriate usernames. Java expertise lends potential for back-end contributions. West.andrew.g (talk) 21:10, 12 December 2014 (UTC)

Thank you very much! Mediavalia ^talk 23:02, 12 December 2014 (UTC)

Force people to download the latest version of STiki?

I notice that there has been no further bug reports since the latest version of STiki was made available on the 12th. I think that it would make sense to use the feature of STiki that prevents old versions from working and tells people to download the latest version. I say this for two reasons:

• People that have got a version from before the 1st of December will not have the "assert=true" check and so could potentially give away their IP address unintentionally.
• People that have got one of the two versions that were released on the 1st of December will have issues with the user messages they give, which could potentially confuse other users.

Yaris678 (talk) 12:59, 14 December 2014 (UTC)

Good idea; I had experienced very buggy behavior from an older version, which disappeared as soon as I updated to a more recent one. HGilbert (talk) 13:14, 14 December 2014 (UTC)

 Done. Thanks, West.andrew.g (talk) 03:43, 15 December 2014 (UTC)

Now easier to see the changes made to the good-faith-revert messages

Hi All,

When Andrew updated the page on good-faith-revert messages a while ago, he apologised for making a messy diff. I have temporarily brought back the old messages in the new order and then brought the new ones back again. This means that this diff now shows the changes more clearly. I thought this would be handy to improve the transparency of the change.

The page works like any other page so if there is a change you don't like you can change it back or discuss it on this talk page. Changes don't get put into code automatically though so Andrew still gets the final say on what's in STiki.

Yaris678 (talk) 18:17, 20 December 2014 (UTC)

Public?

I have recently been granted rollback privilege. I am new to STiki and I am uncertain regarding two of its classifications—"pass" and "innocent". When we click one of them, does it go public. I mean does this store history somewhere?--FrankBoy _(Buzz) 16:51, 30 December 2014 (UTC)

No, only if you revert an edit is your action stored in the page history of that article. "Pass" and "innocent" just register within the workings of STiki: if you select "pass" the edit will be displayed again to another STiki user, but if you select "innocent" it will be removed from the STiki queue: Noyster (talk), 17:16, 30 December 2014 (UTC)

(edit conflict) : Those individual clicks are recorded privately on my server and not publicly released. Internal to my tool that feedback is used to: (1) Determine if someone else needs to review the edit (no duplicate reviews), (2) For ongoing algorithmic refinement (i.e., training of machine learning models), and (3) Analyzed in aggregate to prevent tool abuse (if someone submits 1000 "innocent" classifications per minute, we have a problem). Externally, aggregates of your classification behaviors will become publicly available at WP:STiki/leaderboard. Thanks, West.andrew.g (talk) 17:22, 30 December 2014 (UTC)

Classification query

Got a question myself. Quite often when using STiki I find it necessary to go into the article itself and make an edit that may be more than, less than, or different from a straight revert of the diff on STiki. So which classification to choose when returning to STiki, or doesn't it matter?: Noyster (talk), 13:36, 31 December 2014 (UTC)

I know what you mean, as I have had to make manual edits/changes myself. Other cases include situations which require a revert across more than one vandal account/IP. This cannot be done via standard rollback, and so the only options left are "Pass" or "Innocent". It would hesitate to use the former, because there's no need to pass on the diff to anyone else, but at the end of the day, one assumes that the pending diff will be removed from the system when a further edit has been made by an established user to the article. Orphan Wiki 13:48, 31 December 2014 (UTC)

If an article edit is made external to STiki while that article is displayed in the STiki window, any subsequent (attempted) edits via STiki will fail due to an edit conflict. This conflict will be reported in the "last revert" panel. No matter which button is pressed, STiki will record the feedback internally, for reasons described in the thread immediately above. For that reason, it is preferred to press the classification button that most accurately describes the diff displayed. Thanks, West.andrew.g (talk) 19:48, 31 December 2014 (UTC)

Noyster, Orphan wiki, To expand on what Andrew has said, when I am in the situation you describe, I edit the article using the normal wiki interface. I then go back to STiki and press the button that best describes the edit displayed. Sometimes this can be tricky. To go through some examples:

• If the displayed edit is vandalism but the there were edits before that were vandalism too, I press vandalism. (simplest cases)
• If the displayed edit is vandalism but the there were edits before that were good-faith but in need of reverting, I press vandalism.
• If the displayed edit was good-faith but needing a revert and the edits before also needed reverting, I press good-faith revert, even if some of the other edits were vandalism.
• If the displayed edit is half-undoing some previously done vandalism, I usually press good-faith revert. I can see arguments for the other options. It feels right to me because the displayed editor was probably acting in good faith but the edit is semi-unhelpful because it buries the remaining vandalism. If there is a short time between the displayed edit and the vandalism, it seems more likely that the burying was deliberate so I am more likely to press "vandalism".
• If the displayed edit is innocent and doesn't need reverting, I usually press innocent. I would use this if I had undone a previous edit or done "manual" edit that was unrelated to the displayed edit.
• If I have manually edited the article to correct errors introduced by the displayed edit then I will either press "innocent" or "good-faith revert". It mostly depends on how severe the correction was. If in doubt, I usually go for "good-faith revert". Although I haven't, strictly speaking, reverted the edit, I would like STiki to highlight similar edits in future.

In all cases, as Andrew says, the important thing is to do the editing to the article before pressing a classification button in STiki.

(See also feature request T#040, above)

Yaris678 (talk) 11:54, 1 January 2015 (UTC)

Different messages to vandals

Hi there, I'm new to STiki. I understand STiki looks at the vandal's talk page to determine the warning level, and I would like to ask if there is a way to select the type of warning placed on the vandal's talk page; for example the blanking of pages warning. heyzec! 05:07, 1 January 2015 (UTC)

This is not possible. However, there are a couple of options you may wish to consider.

• Install WP:Twinkle. This lets you give all sorts of messages in an efficient way. You can then unselect "warn offending editor" in STiki and press "vandalism". When you go to the vandal's talk page and use Twinkle, it will have already filled in the name of the article you reverted in the form for the user message.
• Do a good-faith revert. STiki has several good-faith revert messages that can helpfully inform the user where they went wrong.

Note that good-faith revert messages are not warnings and shouldn't be used for clear cases of vandalism. In these cases the standard messages produced by STiki are usually sufficient but if you feel like being more specific then Twinkle is probably a good option for you.

Yaris678 (talk) 12:05, 1 January 2015 (UTC)

To add one thing: A vandal shouldn't need a description of how they have erred, it should be obvious. Moreover, we need to use standardized warnings on talk pages because all tools look for these as part of their warning escalation logic. We could add some additional notes/text inside of those warnings, but the vast majority of these will never even be seen. Thanks, West.andrew.g (talk) 20:32, 1 January 2015 (UTC)

Hi Andrew,

I don't think hz wants to do non-standard messages as such. I think the question relates to Wikipedia:Template messages/User talk namespace/Multi-level templates.

As a matter of interest, if a user posted (for example) a uw-biog1 message on a user's page and then STiki reverted a different edit, would STiki give a uw-vandalism1 or uw-vandalism2? Some of the warnings seem very similar to vandalism. For example, the difference between a test edit and vandalism is mostly in the interpretation, so it would make sense for STiki to escalate if it found warnings for test edits.

By the way, I agree that there isn't much point in being specific about the type of vandalism. But if hz wants to be specific then hz may as well do it in the most efficient way. (Having said that, I don't know how helpful my advice was, given that the page User:Hz.tiang already said that hz uses Twinkle.)

Yaris678 (talk) 21:35, 1 January 2015 (UTC)

Add {{Uw-nor1}} to AGF messages

I've found myself want to use {{Uw-nor1}} a lot when using STiki. Could this be added to the list of common AGF messages? Cheers, --L235 (talk) Ping when replying 04:19, 4 January 2015 (UTC)

I wouldn't mind if this option were added, but at some point the wish to have a message for every case runs up against the need to keep the list to a manageable size. We have Unsourced and Unsourced-BLP messages; we can always see when a new addition is unsourced, but often can't tell if it really is original research, or if the bod read it somewhere and didn't tell us where: Noyster (talk), 10:33, 4 January 2015 (UTC)

I'm inclined to agree with Noyster on this. L235, can you give an example where uw-nor1 would help but the unsourced content message would not?

I can think of a theoretical example, but it is so complicated that it would be better to write a bespoke message in that sort of situation. But maybe I am missing something.

Yaris678 (talk) 13:55, 4 January 2015 (UTC)

Sure. I'll find some. It was just that I was STiking yesterday and noticed about 10 edits that it would have been more helpful than {{uw-unsourced1}}. One thing I learned when doing AfCs is that keeping things as specific as possible is a good idea. Cheers, --L235 (talk) Ping when replying 19:07, 4 January 2015 (UTC)