Hi SQL. I'm not sure if you're around at the same timezones as I am, but I regularly arrive to an AIV backlog around this time, particularly on certain days, when there are actually very few admins around and even rampant vandals can go unattended for a few hours. To say that enough admins have eyeballed the reports is optimistic. I'd like to see the standard 6 hours extended to 8. I note you and others have previously expressed a preference for this figure, so without a strong consensus against it, perhaps you could have a tweak. At least, register my concern about 6 being too short. Thanks. -- zzuuzz ^(talk) 07:24, 28 April 2018 (UTC)[reply]

@Mz7, TomyBallioni, Edgar181, HJ Mitchell, Tazerdadog, and Luk: - As above, my personal preference is 8 hours, and I think Zzuuzz makes a good point. What's your opinions? SQL^{Query me!} 07:44, 28 April 2018 (UTC)[reply]

@TonyBallioni: Second try at spelling stuff right. SQL^{Query me!} 07:45, 28 April 2018 (UTC)[reply]

I don't have any strong opinions either way. I think I originally suggested 8 hours might be too long because it is rare for a report to go 8 hours without any admin eyes, but it seems Zzuuzz is right that at certain times of the day, there are less admins who watch AIV available. Mz7 (talk) 07:49, 28 April 2018 (UTC)[reply]

As an aside - do reports in that timezone really not even see even one single set of admin eyeballs in 6 hours? If so, we are in some sort of desperate need for change. Or are the more-borderline reports being ignored in this timezone because they're borderline on a good day - and eventually the bot will deal with them? SQL^{Query me!} 07:57, 28 April 2018 (UTC)[reply]

I've asked for stats on this before, without success. Anecdotally, I have noticed for many years that there is an issue while the US is asleep, and especially at weekends. I wouldn't say that no admins are around, as some obviously are, but I have always thought there was an insufficient number, and in this case not enough to meet the 'enough eyeballs' criteria. Rampant vandals will be blocked before 6 hours, but others which can (or perhaps should) be blocked but aren't urgent will often wait. It's very noticeable to me - I sometimes enjoy the peace and quiet catching up on admin tasks on a weekend morning, other times I seem to be the only person battling rampant vandals. I have an alternative suggestion, which is to set up an intelligent cron job which can deal with US weekends. -- zzuuzz ^(talk) 08:22, 28 April 2018 (UTC)[reply]

Looking over the the last 10 that were removed by the bot - there was indeed one that went un-blocked which I probably would have blocked at the time. Some more eyes on those 10 reports going back to 4/1 might be a good idea. SQL^{Query me!} 08:29, 28 April 2018 (UTC)[reply]

No strong opinion on the appropriate timeframe. Both 6 and 8 hours are reasonable. Tazerdadog (talk) 10:49, 28 April 2018 (UTC)[reply]

In my experience, any report that has been left for more than a few hours is not a blockable offense. Personally I think waiting even 6 hours to clear them is long. I'm in the US and typically editing during busier hours though. -- Ed (Edgar181) 11:19, 28 April 2018 (UTC)[reply]

• I was actually thinking we should lower it to 4 hours. I consider overzealous blocking and reporting of high school kids and the like to be worse for the encyclopedia than the vandalism itself. If something has sat here for that long with no action and is not ongoing, we shouldn’t be blocking. If it is ongoing, I’m confident it will be back here within minutes. If we actually mean what we say about blocks being preventative, and AIV only being for clear vandalism, someone who hasn’t edited in 8 hours (or longer) on a dynamic IP shouldn’t be blocked, even if they would have been eligible when initially reported. Accounts are more complex, but I’d much rather take the chance and not block a stale minor vandal and potentially gain a contributor down the line, than block someone for doing dumb stuff that they stopped doing 8+ hours ago and that poses no real threat to the encyclopedia. Maybe I’m too optimistic here, but I see no real downside to waiting to block until someone is actually active and a lot of downside. TonyBallioni (talk) 13:52, 28 April 2018 (UTC)[reply]
• Ideally, and I know we don't live in an ideal world, but ideally, the bot would have a sliding scale of retention times, perhaps between 2 to 8 hours, and would change based on how active we (admins) are at blocking accounts reported on AIV already, and how active we are at blocking in general. I don't know whether a compromise approach to this might be to decide on appropriate retention times based on analysis of activity levels for various times, and have the bot change accordingly. Nick (talk) 14:50, 28 April 2018 (UTC)[reply]
  • I like that idea (poor SQL) but I think something based on recent admin edits/activity would be better than on AIV blocks. Pretend you have a board filled with 10 bad reports. None of them are blocked because none of them are good, so the bot lets them stay 8 hours. You end up with them staying there and then you get one of the panic threads at AN because no one has blocked the "vandals".
    I dunno. I'm definitely on the less-likely to see vandalism and block side of the spectrum (I was even when I used STiki and wasn't an admin), so I can get the concerns others might have who view things differently than me. I'm afraid though, having watched SQLBot in process, an 8 hour timeframe would largely make the bot useless, and we'd be back to the semi-weekly "the sky is falling" threads at AN/ANI, which it has actually done a pretty decent job of stopping from occurring. TonyBallioni (talk) 14:59, 28 April 2018 (UTC)[reply]
  • @Nick and TonyBallioni: - I like this idea. I'll have SQLBot start updating this query here on every run, and we can start to look at what those values should be. SQL^{Query me!} 15:17, 28 April 2018 (UTC)[reply]

So lets look at variable timing

I've collected data for a while. Here's the results (by UTC Hour):

   [0] => 64
   [1] => 62
   [2] => 58
   [3] => 52
   [4] => 46
   [5] => 44
   [6] => 42
   [7] => 41
   [8] => 44
   [9] => 47
   [10] => 49
   [11] => 53
   [12] => 62
   [13] => 67
   [14] => 72
   [15] => 75
   [16] => 76
   [17] => 76
   [18] => 77
   [19] => 77
   [20] => 78
   [21] => 78
   [22] => 74
   [23] => 67

• Average active admins: 62
• Max admins active: 107
• Min admins active: 2
• Records used: 5174

In chart form:

Here's what I'm thinking:

~60 admins active is roughly the median. As we approach 80 admins active, shorten down to a minimum of 4 hours. As we approach 40 admins active, lengthen out to a max of 8 hours.

I haven't worked on this for a while, so I'll reping TonyBallioni. SQL^{Query me!} 02:13, 28 August 2018 (UTC)[reply]

If there's one thing I'm consistently terrible at in this thread, it's pings. @Zzuuzz and Nick: were missed because I can't template right... SQL^{Query me!} 02:14, 28 August 2018 (UTC)[reply]

Oh look, SQL being all fancy, yeah, if you can figure out a variable timing piece, that sounds like a good idea. I'd also like it to autoremove any report with the string "genre warring" in it, but doubt that would get approved . TonyBallioni (talk) 02:16, 28 August 2018 (UTC)[reply]

Interesting. So my initial comment was right on time :) I'd assume that that more admins are relatively inactive during the summer, roughly in line with the vandals, but I'd also be interested to see a weekday/weekend breakdown, if that's something you can plug in, because I'll bet that's a variable. I'd also be interested to see what proportion of admins deal with AIV reports. But it's a useful proposal. Thanks for the crunching. -- zzuuzz ^(talk) 09:39, 28 August 2018 (UTC)[reply]

SQLBot Error on AIV?

There appears to be an issue with the above bot. It should not have removed just my edit here. If the report with my edit was considered stale, it should have removed the user (Daffa Dilantra) my comment applied to and my comment. KnightLago (talk) 20:16, 18 August 2018 (UTC)[reply]

@KnightLago: Unfortunately, this happens when a bot helps with a busy page. You saved your edit at just the right time in the milliseconds between the bot reading the page, and writing the new page. SQL^{Query me!} 20:23, 18 August 2018 (UTC)[reply]

Understood. Not a big deal. Thanks. KnightLago (talk) 20:25, 18 August 2018 (UTC)[reply]

Link to the test page | Archived TP Discussion | Obsolete notes

So, it's taken a long time (mostly occupied by putting off working on it), but I got a web tool running of the old aivanalysis I would run offline. It works by manually walking and evaluating every one of the 1.5 million revisions to WP:AIV, and saving to a MySQL Database which takes about a week of machine time. I split it into ~1 year chunks, each chunk running a separate process on the open grid. At the moment, 2007, 2008, 2016, and 2017 are still processing, but there are 416,252 processed reports to work off of. Hammersoft, 72, Serial Number 54129, you had comments in the previous discussion, I figured I'd let you know about the update.

There are still some known bugs that affected early versions of the old tool that I'm working on.

•  Fixed The 1= bug
•  Fixed The "User:", "User talk:", and "User_talk" bugs
•  Can't fix The oversight bug (this seems a little more like an issue with mediawiki, but I can work around it pretty easily by screen-scraping - This has been fixed, apparently. I could scrape Special:CentralAuth, but I'd rather not)
•  Can't fix The rangeblock bug (Which is likely not something I will be able to correct).
•  Fixed The non-registered user bug
• The renamed editor bug
•  Fixed There's an issue that I'm aware of - which is fixed in the code, but won't show until the next walk over AIV's revisions: In a limited circumstance (removing characters from a report), you now "own" the report.

Anyhow, as always, any feedback is appreciated. SQL^{Query me!} 03:04, 25 August 2018 (UTC)[reply]

Hi SQL. Thanks for the ping. I understand that this is a test page, so it might be something you're already aware of, but when looking at the list, I noticed a few reports dated 2012/13/14/15 which can't be correct since I only registered my account in 2016. There are only a few like this, but I can't say for sure about the accuracy of the rest without going through each one in detail (which would take quite a long time!). It lists the report correctly: example, but says the report was made at "20131029182917". Thanks, 72 (talk) 10:14, 25 August 2018 (UTC)[reply]

I think the pattern is that it is relating the timestamp to other AIV reports/entries of the block log. In the case of this report, it says it was made on "20071210101100", which is one minute away from a block made by User:Kafziel. 72 (talk) 10:21, 25 August 2018 (UTC)[reply]

• The report for me still shows the same problems, but some of them just aren't rectifiable (see my comments in the archived discussion). The renamed false negatives are perhaps rectifiable, and as you are aware that remains a (minor) problem. Overall, I still think this is a FANTASTIC tool. --Hammersoft (talk) 13:35, 25 August 2018 (UTC)[reply]
• I've fixed a lot of the issues. I've got to ponder on how to address 72's issue. SQL^{Query me!} 19:29, 27 August 2018 (UTC)[reply]

	The Technical Barnstar
	For the fantastic AIV analysis tool! Impressive technical work. Enterprisey (talk!) 01:40, 1 September 2018 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Interface administrators. Legobot (talk) 04:33, 2 September 2018 (UTC)[reply]

News and updates for administrators from the past month (August 2018).

Administrator changes

None

Asterion • Crisco 1492 • KF • Kudpung • Liz • Randykitty • Spartaz

Optimist on the run → Voice of Clam

Interface administrator changes

Amorymeltzer • Mr. Stradivarius • MusikAnimal • MSGJ • TheDJ • Xaosflux

Guideline and policy news

• Following a "stop-gap" discussion, six users have temporarily been made interface administrators while discussion is ongoing for a more permanent process for assigning the permission. Interface administrators are now the only editors allowed to edit sitewide CSS and JavaScript pages, as well as CSS/JS pages in another user's userspace. Previously, all administrators had this ability. The right can be granted and revoked by bureaucrats.

Technical news

• Because of a data centre test you will be able to read but not edit the wikis for up to an hour on 12 September and 10 October. This will start at 14:00 (UTC). You might lose edits if you try to save during this time. The time when you can't edit might be shorter than an hour.
• Some abuse filter variables have changed. They are now easier to understand for non-experts. The old variables will still work but filter editors are encouraged to replace them with the new ones. You can find the list of changed variables on mediawiki.org. They have a note which says Deprecated. Use ... instead. An example is article_text which is now page_title.
• Abuse filters can now use how old a page is. The variable is page_age.

Arbitration

• The Arbitration Committee has resolved to perform a round of Checkuser and Oversight appointments. The usernames of all applicants will be shared with the Functionaries team, and they will be requested to assist in the vetting process. The deadline to submit an application is 23:59 UTC, 12 September, and the candidates that move forward will be published on-wiki for community comments on 18 September.

The feedback request service is asking for participation in this request for comment on Wikipedia:Village pump (policy). Legobot (talk) 04:25, 3 September 2018 (UTC)[reply]

16:47, 3 September 2018 (UTC)

Hello, SQL. Please check your email; you've got mail!
It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{You've got mail}} or {{ygm}} template.‐‐1997kB (talk) 16:28, 4 September 2018 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Wikipedia talk:Blocking policy. Legobot (talk) 04:27, 5 September 2018 (UTC)[reply]