Jump to content

Wikipedia talk:STiki/Archive 8

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:STiki

This is an old revision of this page, as edited by MiszaBot II (talk | contribs) at 06:46, 4 September 2012 (Robot: Archiving 1 thread from Wikipedia talk:STiki.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10→Archive 15

AIV reports on stale final warnings

Hi everyone. Quick question. When the tool is reporting an IP to AIV after a final warning is found, does it take into account when that last warning was issued? The reason I ask is because, if the last final warning on an account was from several weeks prior to a report, such as [1] this report here [2] would likely be declined as stale, unless it happened to be a fresh pattern of disruptive edits or fresh of a recent block [3]. Was wondering what the current length of time between final warning and an AIV report was. Also is there a way to vet whether the report is sent, or whether one wanted to send a different warning. An example would be if someone incorrectly placed a final warning on something like a content dispute, or an immediate final for something small like a test edit. Currently, I'm not sure exactly what kind of warning (#1, #2, #3, #final, or AIV report) until the request has been sent. Am I missing something in the interface that would help with this, rather than opening up the user talk page link and user contributions before each warning? Thanks in advance. Calmer Waters 16:57, 30 July 2012 (UTC)

I notice there has been no reply to this. I think that is because no one knows quite what to make of it. I think STiki was developed under the assumption that there was a pre-existing consensus around the system of a new heading each month and four warnings in that month being required before a request is made to AIV. I think that assumption comes from how Huggle works, but please correct me if I am wrong. This system is obviously flawed in that one can do 4 acts of vandalism at the end of the month and 4 at the start of the next month. You have now raised a different issue, which is that if you do some vandalism at the beginning of the month, it may be considered "stale" and hence irrelevant by the end of the month. I think it would be good to have a wider discussion to work out what the system of warnings should be. I would say that ideally it would depend slightly on the context. Perhaps we could agree on something that looks like this:
  • A registered account that is only used for vandalism should be nominated/blocked after only one or two warnings, or zero warnings in the most egregious cases.
  • An IP address should in general be allowed four warnings in any period of, say, two weeks. However:
    • If there is a history of several months of vandalism with negligible constructive edits the IP should be nominated/blocked, irrespective of the number of warnings in any specific period within the several months.
    • If there is a history of a large number of constructive edits then the IP would require 4 warnings in a shorter period, say 5 days.
    • If the IP has recently had a block expire, fewer warnings are required. Maybe something like 0 warnings if vandalism resumes the same day and 1 warning if vandalism resumes with a week or after any time if there has been no constructive editing in the interim.
Obviously, the above would be slightly complicated to implement in code across different tools but I think it would be doable.
Does anyone know what ClueBot NG does at the moment? This example you used shows it starting a new section relating to the same month.
Yaris678 (talk) 12:15, 1 August 2012 (UTC)
I am in a bit of a hurry at the moment, but what Yaris said seems correct. Everything increments internal to a single month. The fact that CBNG adds duplicate section names, rather than just appending to the to the existing one is also problematic (as it currently coded). STiki's code computes the current month/year and then looks for a section with that title. In the case there are two of them with the same name (which the API doesn't accommodate well) it only grabs the first. Thus, in this case, it saw the 4im warning in the calendar month and reported to AIV. This can be fixed, and broader improvements can be made. We need to reach some consensus on" "after x time without a warning, restart the warnings, or at least do not escalate the severity." The month-spanning issue is also relevant. Thanks, West.andrew.g (talk) 17:04, 1 August 2012 (UTC)
I agree with Calmer Waters here. I've had a few reports declined because the diff that I reverted was a few weeks old. If possible, for non-admins, there should be a prompt requesting if the user wants to make a report to AIV. Than, the STiki user should examine all of the edits and determine if they are vandalism, how old the vandalism is, if the user has been warned sufficiently, etc. For admins like CW, there should be the same prompt requesting to block. Electric Catfish 18:51, 1 August 2012 (UTC)
I can see why the warning system would go off of the last numbered warning for the month we are in. I believe Cluebot does the same thing; except, that it will allow a user to reset the count. For example, if the #4 warning has become stale, it's something minor like "agthf", or the IP shows signs that the address is dynamic (such a string of good edits weeks after the last warning was given but a different type of vandalism shows up, one may issue a #1 or #2 warning, which to the best of my knowledge, resets the count of both Huggle and Cluebot in regards to future warnings or reports (unless the next editor uses the prompts to do something else). I would suggest at the very least maybe an opt-out option of automatically reporting to AIV (maybe like the Good faith opt-out to warn). Also does it read the last warning to see if a final warning is in the month before reporting, or does it look for any final warning for the given month (ie. would it report this warning pattern next #2,#3, #4, #2)? Kindly Calmer Waters 04:43, 2 August 2012 (UTC)
The users and IP who keep removing the warning templates on their talk page such as this [4] (edits) is another concern, --DBigXray 12:12, 2 August 2012 (UTC)
Agreed. Although you do have to admit that it is a slightly odd thing about Wikipedia. Talk pages are, in theory, about communicating with each other, not about keeping a log. I guess that is part of the reason why my idea below includes a count of the number of reverts that a user has had.
The system being as it is, it would be helpful if STiki (or any anti-vandal tool) looked at the history of a user talk page, rather than just the current version.
Yaris678 (talk) 13:56, 2 August 2012 (UTC)
Tracking talk page history has latency considerations; why I have avoided it in the past. Same thing with the user-centric revert history queries that some are discussing. Simply counting visible templates on a user-page (and timestamping them), though, is straightforward. IMO, the removal of a warning template from a talk page (especially one of a non-autoconfirmed user) should be a firm rule/flag in the edit filter. There shouldn't be an expectation that one has to look at the talk page history for every user they are about to warn. This is unreasonable for manual reverts and is especially unreasonable considering the use of edit assistants. I mean, if I wanted to get away with vandalizing Wikipedia.... WP:BEANS. West.andrew.g (talk) 07:11, 4 August 2012 (UTC)

Using popup messages to STiki users to deal with this

Discussion originally posted at User talk:Calmer Waters#STiki warning messages

Hi Calmer Waters,

You have a reply at Wikipedia talk:STiki#IV reports on stale final warnings. It seems to have turned into an interesting discussion about how the system of warnings should work. So as not to interupt that, I will respond to the other bit of your message here.

You said "Currently, I'm not sure exactly what kind of warning (#1, #2, #3, #final, or AIV report) until the request has been sent. Am I missing something in the interface that would help with this, rather than opening up the user talk page link and user contributions before each warning?".

The answer is that you are not missing anything. The only way to tell what level warning STiki will give is to look at the user talk page and look for the highest warning listed under the current month. As Andrew alluded to, if there is more than one section named after the current month, the first such section will be interrogated by STiki. Obviously if no warning have been given in the current calendar month, a level 1 warning is given.

Yaris678 (talk) 17:28, 1 August 2012 (UTC)

Thanks for the heads up Yaris. I do appreciate it. I can understand how complicated it could be to make a program such as this. Was just bringing up an observation from the blocking admin perspective. You might be surprised at the amount of reports we have to decline as not actionable or require a lot more research than the noticeboard is intended for (ie. content disputes). Not that we won't block for those too, but some are better handled by those who deal with the topic regularly (especially when dealing with possible blocks for established users, which aren't so matter of fact). I would admit it is something as a whole the declining admins or editors should probably follow up more with the reporting editors. I do like how it does prompt a DTTR notice when dealing with users over 50 edits. Calmer Waters 20:37, 1 August 2012 (UTC)
Discussion of various ideas, which led to the one below
I think doing a popup message similar to the one for WP:DTTR is a good idea. If we have a clever system we can slightly short circuit the problems with calendar months too. Could we make it so that if STiki thinks it needs to do a level 3 or higher warning (which will be a small minority of cases since there is a lot of sigle-edit IPs) it calculates the data for and presents a message that looks like this?
This editor has been warned a number of times before, how would you like to proceed?
Information
Time period (days) 1   7   14   30   90
Number of edits 1 3 3 4 12
Number of warnings 1 2 2 1 8
Highest level of warning   2 2 2 2 4
Number of reverts 1 2 3 3 8
Number of blocks 0 0 0 0 1
Options
No warning Level 1 Level 2 Level 3 Level 4 (final) AIV
Any thoughts on this?
Yaris678 (talk) 09:47, 2 August 2012 (UTC)
Actually, thinking about it, the popup should also appear if the user has had more than, say, three reverts in the last 14 days. That would deal with the possibility of a user blanking the talk page, but it would also deal with cases where someone has been reverted multiple times but not actually warned. Certain standard reverts are kept track of anyway by STiki so it should be doable to use that information in this way. (Obviously if this is the cause, the message at the top of the popup should probably say "This editor has been reverted a number of times before, how would you like to proceed?"
I think it would also help to stick in wikilinks to the user contributions and user talk page to let the STiki user investigate further. i.e. something like...
This editor has been warned/reverted a number of times before, how would you like to proceed?
Time period (days) 1   7   14   30   90
Number of edits 1 3 3 4 12
Number of warnings 1 2 2 1 8
Highest level of warning   2 2 2 2 4
Number of reverts 1 2 3 3 8
Number of blocks 0 0 0 0 1
Further info
User contributions   User talk
Options
No warning Level 1 Level 2 Level 3 Level 4 (final) AIV
Yaris678 (talk) 07:34, 3 August 2012 (UTC)
I think Yaris' suggestion is a good one, in theory. In practice, building a table like this is a whole lot of querying! Especially if we have to look to see if the user deleted templates off of their talk page. Counting reverts can also be error-prone. A first step, I think, is reworking the automated logic to something we like. For example, we should increment the warning if the last occurred < 2 weeks ago, regardless if it spans a month. Warnings should be restarted if the last warnings was > 2 weeks ago (and an IP account). We should look at the *last* warning instead of the *highest* warning. We should consider what other tools do and try to make this agreeable with our approach. I think it is fine to pop a prompt to users if an AIV report is about to happen (and let them confirm). The table just might be information overload (no offense). Instead of processing all those statistics, I'd much rather just see the talk page (and feel this is probably easier for most editors to interpret). West.andrew.g (talk) 07:25, 4 August 2012 (UTC)
Changing the incrementing rules as you say and doing a simple report-to-AIV-/-don't-report-to-AIV popup make sense and I guess it makes sense to prioritise those changes. However, I would like to make three points that indicate that doing a table like this is something that we may want to look at, at some point.
  1. The fact of lots of querying doesn't matter too much if we only generate any extra querying when we do the popup. The popup will be a relatively infrequent occurrence.
  2. You could report the number of reverts in the simple way that you do it already. You would have to provide a caveat, but I think that is better than nothing. A more sophisticated approach could be developed later but we don't have to wait until then to get something out.
  3. While there is definitely scope for improving the formatting of the table (I think transposing it would be a good start), I wouldn't worry about information overload. Once people get used to a certain type of big table it starts to feel natural to them. A good example of this is football league tables. Masses of teams, all sorts of stats, but show it to any football fan and they'll understand the state of the league straight away.
Yaris678 (talk) 08:36, 6 August 2012 (UTC)
Since I mentioned transposing the table, I thought I'd have a go and see what it looked like. I think it's a big improvement.

This editor has been warned a number of times before, how would you like to proceed?

Information

 days    edits   warns   height  reverts  blocks
1  2  1   2   2   0  
7  4  2   2   3   0  
14  8  4   3   6   0  
30  11  4   3   7   0  
90  13  6   4   9   1  

See also

User contributions   User talk

Options

No warning Level 1 Level 2 Level 3 Level 4 (final) AIV

Yaris678 (talk) 16:27, 6 August 2012 (UTC)
"Height" represents highest warning template level, correct? How would it detect this if the user was warned without a template - ie manually? I think for cases like that it should (perhaps) refer you to their talk... Theopolisme TALK 21:30, 6 August 2012 (UTC)
Hmmm... it would obviously be very hard to assign a level to non-template warning. This system would only work where templates are used.... but that is the vast majority of cases.
I guess it could be argued that there is a potential that people would rely too much on the table though and that we should force people to do the manual interpretation, to prevent errors that would come from relying too much on the table. I would have some sympathy with such an argument because we are talking about a small minority or cases that get to the point where the message pops up, so maybe it's not too much hassle for the user to do the manual interpretation.
Yaris678 (talk) 08:54, 7 August 2012 (UTC)

When the popup should popup

OK. Let's forget about the table for now. Arguably it's more trouble than its worth, and we can always look at the idea again later if there is an obvious need. The main thing we want can be achieved without the table.

The first priority is for a popup if STiki thinks that AIV is in order. Arguably a level 3 or 4 warning should also have a popup because they are quite sternly worded and you don’t want to send them if you don't mean them. Finally, I think it is worth popping up a message if STiki's limited revert detection system thinks that a user has been reverted a lot recently. If the user has not got a high-level warning it may be that the user is blanking the page. If it is just that the reverts have all been without a warning it may still be worth going to a level 2. The thing about this is that it leaves all this interpretation up to the user so STiki doesn’t have to investigate the history of user talk pages and it doesn't run the risk of misleading people by reporting an inaccurate number of reverts.

So if we are going to do that, we want something like the following popup message:

<specific message>

How would you like to proceed?

See also

User contributions   User talk   User talk history

Options

No warning Level 1 Level 2 Level 3 Level 4 (final) AIV

Where <specific message> is one of the following:

message condition
This user has already received a final warning. STiki has determined that AIV is appropriate.
This user has already received multiple warnings. A final warning may be appropriate. STiki has determined that a final warning is appropriate.
This user has already received multiple warnings. STiki has determined a level 3 warning is appropriate.
This user has been reverted multiple times in the last two weeks. None of the above is the case but STiki has detected two reverts in the last two weeks.

Yaris678 (talk) 18:34, 7 August 2012 (UTC)

First of all, I should like to say thank you to Yaris for the time and effort you have spent on this. Secondly, this last proposal is excellent, and I for one would be delighted to be able to make use of it. We certainly need some assistance and this seems to avoid the previously mentioned complications. -- Gareth Griffith-Jones (talk) 19:20, 7 August 2012 (UTC)
Also want to thank you Yaris. Even just a popup or prompt before reporting the user to AIV would be very helpful. I would surmise that the reports are appropriate more often then not from a review of recent reports blocked to those declined from this tool; however, it would allow a chance to look a little more in depth before making an actual report. I think this diligence in determining that "yes this editor needs immediately blocked" is something that should be behind any request to remove access. These reports are not only a reflection on the editors being reported, but also on the ones making the report. I have seen a few editors fail a RfA based in part on the reliability of their reports to this noticeboard. Just something to keep in mind. :) Kindly Calmer Waters 03:01, 9 August 2012 (UTC)
Agree this can be added, I guess an option to enable-disable this extra feature must also be included--DBigXray 00:36, 13 August 2012 (UTC)
Agree on all points above with the possible exception of the "revert counting" message. If the purpose of this is to detect talk page blanking then there are more elegant ways. I will implement this dialogue as an opt-out option and improve automated warning logic as discussed much further above. Added as T#018 and I will ponder over this "revert counting" bit in my head for a while. A new version will not be pushed before Sept. 8 given academic deadlines and conference travel. Thanks, West.andrew.g (talk) 09:39, 13 August 2012 (UTC)

Minor GUI modification requests

Proposal 1 # rename "Comment:" as "Edit Summary:"

In its present and past versions STiki GUI shows the WP:Edit Summary as a parameter name Comment: rather than using the commonly used name Edit Summary:. I have noticed that this leads to confusion about Comment even among the established editors who are new to STiki, and they end up falsely concluding that "Stiki Does not show the edit summary in its diffs". Comment is generally referred to the comments placed on the talk page discussions.

Added as T#017. Next version push will be on Sept. 8, at earliest. West.andrew.g (talk) 09:23, 13 August 2012 (UTC)

Proposal 2 # Interchange the location of Parameters "Revision ID:"and "Comment:"

as the Revision ID is the least useful parameter to decide about the Diff and the Edit summary is the 2nd most important parameter on deciding about the diff, (Most important parameter is the Diff itself, of course.) Putting the Edit summary on Top of the Edit properties box will reduce the chances of new users failing to notice it. And it will also be helpful to the regular users, as after looking at the diff on top one needs to wade through all the Parameters of Edit properties box and come to the bottom to look at the Edit summary.

  • Agree as proposer --DBigXray 00:22, 13 August 2012 (UTC)
  • Not sure I'd like to hear what others have to say about this one. (1) I'm mentally trained to look in the current location so this may take adjusting for experienced users. (2) It could be argued that it is easier to notice the comment "at the very bottom", rather than the suggested move which puts it more "in the middle of the GUI" -- though I do see your argument. (3) Very minor and non-deal-breaking. But... it could look funny to have an frequently empty space at the top of the metadata panel (i.e., no comment present). (4) Does anyone use the "revision ID" for anything?! If so, why is it even there? We provide diff links and etc. Thanks, West.andrew.g (talk) 09:19, 13 August 2012 (UTC)
Also Revision ID can be altogether removed, as it has no practical use during RC patrol activity such as using STiki. --DBigXray 09:59, 13 August 2012 (UTC)
I think top of the box is the natural place for the edit summary. Agree that it makes sense to remove the RID number. Yaris678 (talk) 15:18, 13 August 2012 (UTC)

STiki PSA: Revert opportunities!

Greeting STiki users! Looking at the STiki usage reports that flow through my inbox 4x daily, I've noticed some our vigilant users may have taken a break and/or slowed their use. No complaints about this; "real life" happens. However, rather than seeing 5000+ classifications daily that number is now <1000.

The consequence? Very high hit-rates! Hit rates had fallen to < 10% under intense use (no doubt a little discouraging to segments of the user-base). However, they have been at 70%+ for the past few days. This could be a great chance to slay some "low hanging fruit" and get some reverts. Some of this may also be attributable to "summer vacation" ending for most U.S. school students (and anywhere else they have an equivalent). Remember to use the "Recent usage stats." functionality in the "Queue" menu to get an idea of how hard the queues are getting depleted. Thanks, West.andrew.g (talk) 05:18, 13 August 2012 (UTC)

👍 DBigXray likes this. Thanks for the heads-up After a long time had the "Original STiki Experience" --DBigXray 19:56, 13 August 2012 (UTC)
UPDATE:Party is over guys. Fraggle81 is Back. He was away for the last three days so I guess the Vandals were having a free ride. --DBigXray 20:31, 13 August 2012 (UTC)
Not back in true form, yet ;-). Last 24 hours showed ~900 classifications with a 45% revert rate. Still much higher than the 5000/10% we were operating at a little over a week ago. Thanks, West.andrew.g (talk) 05:06, 14 August 2012 (UTC)

Request

Would it be possible to merge any reverts done from this account to user:Thine Antique Pen? Thanks! Thine Antique Pen (public) 21:17, 13 August 2012 (UTC)

TAP had a merger in past as well Wikipedia_talk:STiki/Archive_7#Merge. The above request is for adding not only the past edits but also any future edits by TAP public to TAP. So this will be a slightly different case than the last time. Please wait for Andrew--DBigXray 21:33, 13 August 2012 (UTC)
Hmmm. I assume one would want the "pass/ignore" markings to be shared between the accounts, as well? I'm thinking this is code probably best placed in the server-side stored procedures. Let me sleep on it. Thanks, West.andrew.g (talk) 09:25, 14 August 2012 (UTC)
 Done This has been completed. Transferred 51 classifications from the "public" account to the primary one. Any activity under the public account (i.e., future classifications and "ignores") will be mapped to the primary one. Also set up infrastructure to simplify this process should anyone else request in the future. Thanks, West.andrew.g (talk) 22:04, 14 August 2012 (UTC)

Permissions

Accepted With 858 Article namespace edits This user deserves the permission. His reverts are correct. Permission to use STiki will be granted shortly. Till then GoShow please make yourself fully familiar with WP:NOTVANDAL and WP:VANDAL. --DBigXray 18:55, 14 August 2012 (UTC)
 Done. Hope you enjoy the tool. Thanks, West.andrew.g (talk) 20:29, 14 August 2012 (UTC)
Not sure why this user has made Misleading_Edit_summary saying that he has used STiki, while in reality they were manually made.--DBigXray 20:43, 14 August 2012 (UTC)
* I don't have a problem with the attribution -- if he found the edits using STiki and then used the links to conduct some type of deeper investigation (i.e., changes not resulting in a complete identity revert). Not sure if that is what happened here, though. I'll dig a little deeper. Thanks, West.andrew.g (talk) 21:43, 14 August 2012 (UTC)
* Nevermind, I see. The timestamps don't agree. I hadn't approved him yet, and he doesn't seem to have rollback yet, either. West.andrew.g (talk) 21:45, 14 August 2012 (UTC)
* There is a *possible* benign explanation, but one I will not publish here until we see what he says. Thanks, West.andrew.g (talk) 21:50, 14 August 2012 (UTC)
I spotted them on a STiki javascript, but no worries, I said I caught on them I couldn't use the the buttons anyway--GoShow (...............) 04:56, 15 August 2012 (UTC)
What is a STiki javascript? Whatever it is, I didn't implement it and would be interested to see it. West.andrew.g (talk) 05:03, 15 August 2012 (UTC)
To summarize what GoShow wrote here... He downloaded the tool. And by opening and re-closing it, he was able to see the single "preview" edit popped before you login (which he couldn't do). He then followed the links to manually revert the edit. Brute-force and rather arduous, but creative nonetheless. Sorry, GoShow for starting to head down the road of bad faith for a moment.
@GoShow: "Java STiki" is the *only* STiki. You can now login using the same tool and use the classification buttons. Do not abuse it!
@Everyone: A more efficient way for a non-permissioned user to get some STiki insight would be to use IRC channel where STiki spews out its scores. See a high score? Copy-paste the RID and then use the browser interface to inspect and revert.
Thanks, West.andrew.g (talk) 05:23, 15 August 2012 (UTC)
No it is you sir who needs to be thankful anyway, pardon me for being too hyper about the java drama hotflashes, but thank you anyway.--GoShow (...............) 05:28, 15 August 2012 (UTC)
@Andrew, I made the same conclusion by the above clarifications. Was just making sure everything was alll right, as I felt this a bit wierd to be honest,
@GoShow, I have posted a welcome message on your talk you can check out the links, cheers--DBigXray 05:51, 15 August 2012 (UTC)

Wikibreak

Guys, I wont be editing much in the near future, hope others will keep a tab on the milestones and this talk page. cheers--DBigXray 09:36, 17 August 2012 (UTC)

Hope everything is okay and you return refreshed! I will try to keep a watch on those pages, though I'll mention that due to WikiSym I'll also be on a bit of a travel wikibreak from 8/22 until the beginning of September. I expect connectivity to be far better than my last travels, though, so it potentially won't have much of an impact. Thanks, West.andrew.g (talk) 20:55, 17 August 2012 (UTC)

IRC suggestion For new users requesting STiki

@Everyone: A more efficient way for a non-permissioned user to get some STiki insight would be to use IRC channel where STiki spews out its scores. See a high score? Copy-paste the RID and then use the browser interface to inspect and revert. West.andrew.g (talk) 05:23, 15 August 2012 (UTC)

Pardon the lack of my IRC experience, can you give us a link to connect to IRC for Stiki ? --DBigXray 06:21, 15 August 2012 (UTC)
Try this online client: [5], you'll want to enter "#arm-stiki-scores" as the channel (sans quotes). Scores on [0,1], and watch out for the really low scores in scientific notation. Thanks, West.andrew.g (talk) 07:07, 15 August 2012 (UTC)
The scores are cool, but copy pasting the diffs is not a very user friendly way, can it have links to the diffs such as this http://webchat.freenode.net/?channels=#cvn-wp-en ? --DBigXray 07:18, 15 August 2012 (UTC)
Not sure about that idea DBigXray. Rather than making it super-easy to avoid the STiki interface, how about we encourage people to get the experience to understand the diffs and the policies and then apply for rollback permission. Yaris678 (talk) 07:52, 15 August 2012 (UTC)
There is nothing wrong in encouraging people to understand about diffs, but the matter of the fact is copypasting diffs makes the process un-necessarily lengthy, and we will be adding unnecessary technical overhead and this might lead to a loss of enthusiasm among the new volunteers for antivalism activity as they would think its far too complicated. On the other hand #cvn-wp-en gives comment along with direct links, Evidently more human --DBigXray 08:17, 15 August 2012 (UTC)
Am I missing something here? Why would we want to make it easier for people to avoid the proper STiki interface? I can just about imagine that some people might find the IRC channel interesting but it is never going to top the interface for all sorts of reasons. Yaris678 (talk) 08:38, 15 August 2012 (UTC)(edit conflict)
Concur, Yaris! I have been trying to discover just where this whole strand – started elsewhere – is leading, and why it is here in the first place. My suggestion is that it should be struck from this article's page forever. Regards, -- Gareth Griffith-Jones (talk) 08:48, 15 August 2012 (UTC)
  • @Gareth It is not wise to give your Judgement straightaway without any clue of what is happening. I will suggest you to read and understand WP:IRC first. You will get an idea of what we are discussing here.--DBigXray 10:44, 15 August 2012 (UTC)
... Already had read and understood, thank you. -- Gareth Griffith-Jones (talk) 11:37, 15 August 2012 (UTC)
Ok, so Yaris was not aware of the context. Please see the preceeding thread to gain an insight on what led to this discussion. This discussion is for new users requesting permission to use STiki, but have no prior experience of anti-vandal reverts. of course we are not asking people to avoid STiki interface. --DBigXray 08:44, 15 August 2012 (UTC)
I had already read the discussion above about someone looking at edits that appear before you log in to STiki. I can see using the IRC channel might be a more efficient way to get the same effect. But we have restrictions on who can log into the interface for a reason so I don't see why we would want to make the IRC channel into an "interface lite". Yaris678 (talk) 09:07, 15 August 2012 (UTC)
Goodness... FWIW, the IRC channel, by design, was never intended for human consumption. WikiTrust and CBNG are spewing a feed of similar form but these are primarily so the the tools can communicate. (At some point, I think someone used this IRC so STiki's edit selection could be fed into Huggle? Or at least there was discussion of this). It's not a big deal to add a diff-link and I might do that. Regardless, this is not something that should be advertised for new users. Even for the least experienced of editors all we require is the most basic of CVU training to get an account approved. That is way more constructive than watching edits fly by at the rate of several per second. Also consider that for someone trying to edit like this, you'd be learning very little about the STiki experience, and more about the Huggle one: duplicate work as everyone rushes to find obvious vandalism instances. Thanks, West.andrew.g (talk) 13:54, 15 August 2012 (UTC)
I agree with that.
The modified Huggle that uses the STiki IRC channel is at Wikipedia talk:STiki/Archive 4#Huggle.
Yaris678 (talk) 14:29, 15 August 2012 (UTC)
Getting the derailed train back on track

I never said IRC needs to be advertised to users, when they are here for STiki. Andrew had started this discussion on IRC, and I felt its a good idea to take it forward. At the moment if a new user with 400 edits comes to request for stiki, we do a quick check of his contributions for reverts, If there are sufficient reverts, to show an understanding, we allow him to use STiki. If there aren't sufficient anti-vandal reverts then the editor is asked to read policy pages and make a few anti-vandal reverts from Special:RecentChanges which will be checked and then permission granted so that we can be sure the new editor will not do reckless reverts. Now Andrew in his message on top gave a suggestion to use STiki feeds. I feel this would be better because Special:RecentChanges shows all the edits good or bad, but the STiki IRC feed or #cvn-wp-en gives you filtered diffs, which will be efficient for the new users who are asked to make a few reverts to show their judgement and get permission.
Of course one can say that why take all this trouble, just simply redirect anyone who comes here to WP:CVUA and let them handle newbies, but then one should not assume that every new user would like to get adopted. WP:Adoption is a voluntary process, and I have seen few new editors who did not responded and lost interest in adoption for whatever reason. Also to me it seems awkward, that a user comes here asking for STiki permission and we tell him to get coaching/adopted. The new user came here with good intentions to help in fighting vandalism but found out that he will need to go through all this bureaucracy, and then if he changes his mind and goes away then all this fails its purpose. They did not need to go through adoptions when all they need to do is read a couple of pages and make few reverts to show their understanding. I hope I have clarified myself now, would be glad to address any other concern--DBigXray 21:18, 15 August 2012 (UTC)

Thank you for the clarification. I now understand why this could be useful. However, I can see that there may be problems doing it that way. Many users (myself included) don't have IRC client software which may lead us into all sorts of technical cul-de-sacs trying to explain how to view the channel. There is also the chance that people might get the false impression that this is what the STiki experience is like. I think directing people to Special:RecentChanges and the relevant policies is the way to go. Yaris678 (talk) 10:45, 16 August 2012 (UTC)
Yes, even I do not have an IRC client software, but anyone can use IRC through this website, #cvn-wp-en. Please give it a try you do not need to have an IRC account beforehand, just give a Nick and you may proceed. I dont feel there link to #cvn-wp-en is technically more complicated than Special:RecentChanges and former is much more effective. But this is just my opinion, we should proceed with a consensus.--DBigXray 11:06, 16 August 2012 (UTC)
What are we even seeking consensus for, again? Diff links have already been added in source (and will start appearing whenever STiki's server-side component gets a restart). Moreover, many people probably do have a desktop IRC client and do not even realize it. This functionality is included in most IM programs (Pidgin, Empathy, et al. ... maybe you haven't heard of these? Maybe I am biased by Linux. Is everyone just using GChat and Skype these days? ). Thanks, West.andrew.g (talk) 16:22, 16 August 2012 (UTC)
Consensus for what advice to give to a new user with 400 edits and no vandalism reverts. Should we ask him...
  1. to join WP:CVUA ?
  2. or read policy pages and revert using Special:RecentChanges ?
  3. or read policy pages and revert using #cvn-wp-en (has comments/tags)
  4. or read policy pages and revert using #arm-stiki-scores (has score value)
  5. or do a combination of some or all of above. But giving all options as advice will be far too complicated for new users.
Thanks for adding the diff links, waiting for it to be visible.--DBigXray 23:13, 16 August 2012 (UTC)
And yes, "visible" now. However, good luck clicking a link scrolling by at 30mph. Another reason for the below... West.andrew.g (talk) 20:49, 17 August 2012 (UTC)
Basically all of these start with the exact same criteria, "read the policy pages." The CVUA just introduces the extra step of someone testing you once you've done that. And I think this is a good thing because people will tend to skim, otherwise. You spoke of the fact someone might not want the "burden" of joining CVUA. Why not create our own 10-20 diff/question "quiz" regrading vandalism (we can make it a sub-page). Ask them to view these diffs, classify them, and provide short justification sentence why they chose that outcome. We grade them and grant access based on this result (or provide a touch more coaching, or send them to full-blown CVUA). Someone could have STiki interface access in ~15 minutes in this fashion. This would seem to achieve our "goal", which in my opinion, is to turn as many people into productive STiki interface users as possible (why get them hooked on recent changes patrol, or #cvn-wp-en, or some other tool?). Thoughts? West.andrew.g (talk) 20:48, 17 August 2012 (UTC)

In terms of the options DBigXray gives, I think that if someone has a low number of edits we should say:

We recommend that new users interested in using STiki should sign up for the counter vandalism unit academy.

If someone has between 400 and 1,000 edits, we should say

We recommend that new users interested in using STiki should sign up for the counter vandalism unit academy. However, if you reckon you know enough about Vandalism already, try seeing if you can spot and undo some in Special:RecentChanges

The quiz idea wouldn't be that easy because if we used the normal wiki interface it would be very easy to copy someone's answers.

We could do a quiz that uses a modified STiki interface. That would take some development though.

Yaris678 (talk) 12:25, 20 August 2012 (UTC)

I used to be bullied for being Welsh, and away at prep school in England

Has nobody noticed that I passed the 10,000 threshold two days ago ... poor me. -- Gareth Griffith-Jones (talk) 07:17, 17 August 2012 (UTC)

 Done--DBigXray 09:36, 17 August 2012 (UTC)
Congratulations, indeed! Top 5 among those still participating regularly, keep up the good work! West.andrew.g (talk) 20:51, 17 August 2012 (UTC)
Glad to help.
I find Stiki expands my use and enjoyment of the encyclopaedia in general – as I invariably open the link to the article whilst making the edit assessment, and then, as well as the page's "history", quite often, the editor's list of recent contributions.
Thank you, Andrew. Sincerely, -- Gareth Griffith-Jones (talk) 08:30, 18 August 2012 (UTC)
I agree. One of the side benefits of STiki is that you get to see all sorts of articles you might not otherwise look at. It's a bit like pressing the "Random article" link in the side bar... only you get to fight vandalism at the same time! Yaris678 (talk) 16:02, 20 August 2012 (UTC)
Great, isn't it ... I recall, Yaris, how you wrote on this page a while ago how you would like all STiki users to add a personalised detail or two to the edit summary that is posted with the AGF revert. Doing that, and what I have described above, gives me much more satisfaction than trying to race through as many offerings as possible. -- Gareth Griffith-Jones (talk) 16:35, 20 August 2012 (UTC)

fallback to port 80?

Some users are unable to use STiki because port 3306 is blocked. Would it be possible to make STiki default to port 80 in this case? This would be very useful. Thanks! --Ixfd64 (talk) 23:56, 17 August 2012 (UTC)

Notice that this is in the bug/feature table as T#004. Assuming you (or whomever) can't configure the firewall, proxy tunnelling would be one possible solution. A true solution for this is not difficult. Someone just needs to wrap all the native SQL calls to server-side stored procedures with PHP scripts, constructing an API to pass parameters and retrieve results. At the current moment, I have a few other (and too many) things on my plate. I will be frank in saying *I* won't be getting around to this any time soon; though I would be happy to assist anyone interested. Thanks, West.andrew.g (talk) 07:00, 18 August 2012 (UTC)
Wow. Spoken like a true computer scientist. • Jesse V.(talk) 16:32, 21 August 2012 (UTC)

CVUA student access request

Hi, may I request access for my CVUA student Zaldax (talk · contribs) please? Thanks in advance, Mdann52 (talk) 15:34, 23 August 2012 (UTC)

 Done - Sorry for the delay, travelling through CDG en route to WikiSym!. Thanks, West.andrew.g (talk) 10:49, 24 August 2012 (UTC)

Automatic AIV reporting

See the "Possibly compromised account?" section of the current version] of WP:ANI and the "68.185.89.83" section of the current version of User talk:Gareth Griffith-Jones. It's possible to set up this tool so that it reports people to WP:AIV without you editing the page, and this can lead to confusion. West.andrew.g is already looking into the issue, but this is probably something that all users should know about. Nyttend (talk) 00:37, 25 August 2012 (UTC)

Responding on the WP:ANI thread of this. Thanks, West.andrew.g (talk) 15:22, 26 August 2012 (UTC)
Erg, forget that, it has already been archived and my addendum doesn't really warrant reviving it. It's not as if STiki makes "magical" AIV posts with *no* notification; as mention of AIV will be made in the "last revert" panel when it happens. As our previous thread (now in Archive #8) discusses this should be made a more concious and pro-actively initiated action. No debate. Out of curiosity, how does Huggle handle this? Thanks, West.andrew.g (talk) 07:53, 27 August 2012 (UTC)
Huggle gives both the option to either submit a report to AIV regardless of warning count on the editor's talk page, as Huggle places the continuing edits of the editors you've personally reverted recently at the top of the queue (ie. rapid edit vandals that need to be immediately blocked); and if the user already haves one of the uw4 templates on the user's talk page (such as subst:uw-vandalism4im or subst:uw-delete4) it will prompt or ask the user that the editor has already been issued a final warning, and would you like to report it to AIV instead. You can either report it, place another warning, or not place a warning and skip to the next edit. The immediately report is one of a number of buttons located at the top of the screen. It will not report an editor without the editor specifically clicking that they want a report sent. Calmer Waters 02:57, 28 August 2012 (UTC)
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia_talk:STiki/Archive_8&oldid=510717805"