Last modified: 2013-11-08 12:05:12 UTC
Following a recent checkuser request that required over 3 hours of tedious manual labor (which I never did finish) - [[Wikipedia:Requests for checkuser/Case/Artaxiad]] - it's become obvious to me that checkuser needs a recursion feature. The feature should take a username or IP address, and repeatedly run checkuser on all subsequent matches to a certain user-specified recursion depth. Repeated entries (that is, a user or IP address that appears multiple times in the tree) should be excluded. The output should be a tree-list form, as shown at http://en.wikipedia.org/wiki/Wikipedia:Requests_for_checkuser/Case/Artaxiad#Raw_data (Note - the recursion depth in that case is 17). Usernames and IP addresses should be linked to their respective user pages.
I spent almost another hour tonight on http://en.wikipedia.org/wiki/Wikipedia:Requests_for_checkuser/Case/Libertyvalley
For performance reasons, unless Tim thinks it's OK.
I'd like to ask that this WONTFIX decision be revisited. It is OK, in my view, if the request itself is throttled to not put too much of a load on the system, and takes considerable elapsed time to return results, because the alternative of doing it by hand takes far more elapsed time.
I don't see why it would be a performance problem, as long as the total result set size was limited.
So can it be reopened then, or do you need a new bug submitted? The choices I see (as a non developer) don't admit of reopening via change resolution to ____ , but I'll be happy to check "reopen bug" instead... I just think maybe one of the devs should do it, I don't want to overstep.
My other problem with this is that it would be giving a very incomplete report, possibly with false negatives with no context. I suppose it is not useful enough that I'd want to code it...but if someone else wants too they can. Re-opening per Tim's comment.
(In reply to comment #6) > My other problem with this is that it would be giving a very incomplete report, > possibly with false negatives with no context. I suppose it is not useful > enough that I'd want to code it...but if someone else wants too they can. > > Re-opening per Tim's comment. > Opps, I meant "false positives", though there would be even more "false negatives" (as users' IPs don't stay exactly the same for long).
Thanks for the reopen. Perhaps the requirement wasn't stated clearly enough? This is just automating the "walking the tree" we do now in many cases. Judgement in interpreting the results (and deciding what further explorations to do or not do) would still be just as required. and the tree walking we do now is exactly as vulnerable (no more, no less) to false negatives and false positives as if it were automated. But getting the report 3 levels deep on one page instead of spread out over 35 tabs (which required 35 separate checks) makes our work a bit easier. I think I would make the suppression of repetition an option though, I probably would run the check with that suppression turned off.
You will still need to check CIDRs rather than single IPs. Also, a shear list alone doesn't have enough context to spot out false positives. I suppose the user can then check those users/IPs. It could occasionally be a decent starting point for catching a few users in large sock farms, like running a large fish net throw the water.
Also, the ability to input a list of usernames into recursive checkuser (instead of just one) would be very helpful.
Anything that reduces the legwork of complex Checkuser cases will be great. Perhaps I'm speaking from ignorance here (I'm not a Checkuser myself) but it seems to me it's not just a matter of time-saving, but surely also that the increased automation will enable the Checkusers to put their intellect into checking the results for false positives/negatives, rather than worrying about running the processes.
I filed another feature request - bug 12808 - which is related to this one. Preferably both could be implemented in a single patch.
Bumped up to *high*, given the obvious necessity for a checkuser interface that isn't second in tediousness only to running the queries by hand against the db.
(In reply to comment #13) > Bumped up to *high*, given the obvious necessity for a checkuser interface > that > isn't second in tediousness only to running the queries by hand against the > db. I honestly don't think this is high on any developer's priorities. If there are other improvements to the CU interface that can be made, it would be helpful to file them as separate bugs.
