Wikipedia:Administrators' noticeboard/SSP-RFCU merger proposal

From Wikipedia, the free encyclopedia

Moved from WP:AN#SSP/RFCU merger proposal   (revision link)

[edit] Overview

Links

• Wikipedia:Suspected sock puppets (talk)
• Wikipedia:Requests for checkuser (talk) (non-case subpages)

Summary

SSP and RFCU both work to the same aim, addressing cases of suspected sockpuppetry or multiple account abuse. All such cases should consider behavioral evidence; the sole difference is that some merit checkuser evidence too.

Rather than two processes, two sets of pages, two archives etc, it's proposed to have one process for all SSP's. Then use a tag (drawing on RFCU) to request CU attention to a given case, that acts as a simple and effective filter to prevent all but genuinely appropriate requests.

Proposed safeguards to manage CU usage

RFCU works to ensure that

• only valid cases are lined up for checkusers (eg needs a specific "letter" etc, filters all except genuine CU cases).
• checkusers can see the RFCU backlog.

Both of these are preserved, kept similar, and made a bit easier:

I.	User request	Add to the case: ; Checkuser request {{RFCU|Letter}} followed by your reason, and signed with ~~~~. This will add your request to Category:SSP cases awaiting clerk or admin review.
		Administrators and clerks only may directly seek CU action by adding "{{...|Self endorse}}" to the tag.
II.	Clerk or admin check	A clerk or patrolling administrator will review your case and will update it to either {{RFCU|Letter|Endorse}}, or {{RFCU|Letter|Decline}}, with their reason. Endorsing will add the request to Category:SSP cases awaiting CheckUser. Checkusers will watch this category.
III.	CheckUser	Finally, if a Checkuser agrees and comments on the case, then the tag will be updated one more time to {{RFCU|Letter|Checked}}, with their comment on the case.  Or {{RFCU|Letter|Decline}} if declined.

This should filter the cases every bit as accurately as they are filtered now, allow backlog review, and prevent abuse. FT2 ^{(Talk | email)} 09:49, 13 April 2008 (UTC)

Draft at User:FT2/CU 2, with draft guidelines (including CU requests) at /Guidelines.

[edit] Suggested addition

On one hand, merging the pages sounds like a great idea, but on the other, there is a concern that there will create an AN/I-like mess of requests.

How about if we merge as requested, but an additional page is created.

So anyone can post to RFCU, but only those which are "endorsed" can be moved by the clerks to a page reviewed by checkusers.

In addition, we could/should discuss what the name of the request page should be, as the current name may not be quite as appropriate. For one thing, it sets the expectation that every request should be for CU, which isn't the case, even under the proposal above. - jc37 18:48, 18 April 2008 (UTC)

[edit] SSP/RFCU merger proposal - discussion

I've been thinking about some simplification here. It seems daft in a way, to have two sets of pages, both essentially for dealing with socks or suspected socks. What we really need is one set of pages for all sock concerns, with a tag for "requesting checkuser investigation" (+ rationale if needed) for those cases that merit it.

Can I solicit views on the idea of merging these?

FT2 ^{(Talk | email)} 22:22, 12 April 2008 (UTC)

What are the possible negatives of merging them? The pros seem sort of simple and obvious: less process, less places to look for information. Lawrence § t/e 22:45, 12 April 2008 (UTC)

Support merger - distinction is pretty arbitrary. At the moment it can make the process of hunting socks fairly long winded and input-heavy from checkusers and experienced sleuths answering queries. Cheers, Casliber (talk · contribs) 22:51, 12 April 2008 (UTC)

Support; indeed, lingering SSP cases could be swiftly closed by a well-timed CU, and CU are justified by the kind of evidence one would normally post to SSP (and then have to copy to CU to request it). A merge would be a well aimed stone. — Coren ^(talk) 23:16, 12 April 2008 (UTC)

• I also support - I think that they are all too similar mostly, but what would we call it? Majorly (talk) 23:24, 12 April 2008 (UTC)

Possible. Need to flesh out the idea more. — Rlevse • Talk • 00:21, 13 April 2008 (UTC)

Assuming this does go through, I imagine we'd be merging everything into SSP, possibly adding a section/category/noticeboard/whatever to quickly notify CUs of subpages which might benefit from their abilities. – Luna Santin (talk) 23:49, 19 April 2008 (UTC)

• Hmmm, I'm not so sure on this. I fear it could lead to quick CUs, against the meta CU policy. Sometimes we need discussion before we bring in CheckUsers to looks for links. At present, SSP leads to discussion, then movement to RFCU if it is required - I don't really see a need for a change. Ryan Postlethwaite 00:30, 13 April 2008 (UTC)

No obvious reason to expect that. right now anyone can go to RFCU as it is, or seek checkuser, so the exact same holds and should hold - not frivolously, or when it is not actually likely to be useful, or when fishing, etc. Usual norms should apply. Just no point in having 2 separate sets of pages for virtually identical issues is all, with the difference being 'evidence was sought/provided from checkuser in this sock inquiry'. Some details will probably be needed to be considered, but that's what this is for after all, to solicit views on the concept. FT2 ^{(Talk | email)} 01:22, 13 April 2008 (UTC)

• Seems like a good idea, but I wanna see/know what the CUs and CU-clerks think primarily. Their the ones who'll actually have to implement this. MBisanz ^talk 00:38, 13 April 2008 (UTC)

• A lot of SSP cases are thrown out, obvious socks, already blocked, dynamic IPs, etc. It is more of a place for admin action or even catharsis than a progression to review by checkuser. The requests are likely to choke the CU page without a more streamlined process for closing cases, prompt archiving, and admin action. But otherwise there seems to be no principle for not merging. -- zzuuzz ^(talk) 01:44, 13 April 2008 (UTC)

• • Lord, no. SSP performs an important filtering function, preventing some cases from reaching RFCU that are either obvious or unwarranted. SSP is also the only way to deal with accusations where the master account is too old to check, or where results are inconclusive. When the result is, for example, "inconclusive, different ISP but same geographical area," there needs to be a level of independent review of contributions--checkusers usually do not, and probably should not, perform this function on top of the technical check. I'm afraid people would start to expect the checkusers to perform more of the contribution reviews that make up the bulk of SSP cases. And lastly, I've seen a number of SSP cases that are little more than heated arguments between partisans, full of unsubstantiated allegations. I do not want to import that to RFCU. There is long precedent for confining RFCU pages to the technical evidence and shifting the back and forth to the talk page. As it stands, checkusers can drop in to SSP and add evidence to a case they think is worthy, and RFCUs can be filed citing SSP evidence. I don't see any need to merge them. Thatcher 03:12, 13 April 2008 (UTC)

Cases can easily be rejected for checkuser if they don't meet criteria. I don't see a problem with that aspect. It's detail only, to ensure that a checkuser request cannot be made on such pages without good cause. There's many ways to do that - for example, "only a RFCU clerk can endorse that checkuser is appropriate in a given case". At its simplest level the way you do it is a tag for "cases awaiting checkuser" - and that only clerks are allowed to place. Or a page for "casese awaiting checkuser that only clerks are allowed to transclude SSP's onto. Since any user can open a case at RFCU, we're not exactly opening the floodgates. A little bit of management and a hurdle, to prevent users themselves adding undue CU requests (as we presently have), is enough. Thats the named problem solved. FT2 ^{(Talk | email)} 06:34, 13 April 2008 (UTC)

Draft at User:FT2/CU 2, with draft guidelines (including CU requests) at /Guidelines. Rough approach to handle spurious cases:- users may request checkuser involvement by {{RFCU|Letter}}, citing a letter and reason as at present; but only when the tag is updated to "|endorse" by a clerk or patrolling admin (or self endorsed if the user is themselves an admin) would it then appear in the category "SSP cases awaiting CU attention". This should filter the cases every bit as accurately as they are filtered now, and prevent abuse. FT2 ^{(Talk | email)} 09:49, 13 April 2008 (UTC)

I'm fully in agreement with this merger: it simply "fits". SSP and RFCU, whilst different in the format they operate by, are essentially two different methods for establishing sock puppetry connections; SSP utilises behavioural evidence, CU utilises technical evidence (geographical links, log entries, etc.) To address concerns from Thatcher ("SSP performs an important filtering function"), I wouldn't say it's fair to label SSP as a filter for RFCU; the two fill the same role, but in different ways. Furthermore, "heated debates" can very easily be stopped; a simple ban on such discussions, and a directive to Clerks to move all arguments to the talk page, or indeed off the sock puppetry process altogether, would suffice. The issue you raise, whilst notable, and ones that I think need to be addressed, are essentially procedural ones, and they are certainly easily solvable.

To address MBisanz's request for clerks to comment, I can satisfy that request: I've been helping out as a clerk for many months now, and I can firmly say that the clerks can handle this. Indeed, the bringing in of SSP to RFCU (and, by extension, the clerking process) will allow for a more streamlined, organised system of establishing sock puppets: the technical side of the process (currently RFCU) will not suffer any loss, and the behavioural-evidence side (currently SSP) will benefit in that it gains the services of the clerks—one that I would say is very important. This new system will simply allow a more streamlined system for establishing sock puppetry; a report that is rejected by a checkuser as (for example) fishing, can immediately be processed by either: 1/ an administrator; or 2/ that checkuser, but wearing his "admin" hat, and not using Special:CheckUser. This proposed merger is going to improve the sock puppetry system no-end, and I'm excited at the prospect of it being implemented; I can certainly say it'll be interesting clerking it post-merger :) Anthøny 20:49, 13 April 2008 (UTC)

• Oppose... I don't see any reason to merge them, they're quite separate processes. While almost all CUs reference SOCKs, not that many SOCKs reference CUs... the system works fine as it is IMO. —TreasuryTag—t—c 10:05, 14 April 2008 (UTC)

They grew up as different processes, but they cover nearly identical situations and flow into each other heavily. In each case there is an intention to allow users to report and get views on suspected puppetry and suspected multiple account abuse. In all cases on-wiki evidence is important and needs to be considered too. Some of those, evidence from IP logs will be applicable, some it won't. That's the only difference between the two of any note - whether they do or don't include evidence X in looking at otherwise identical versions of the same kinds of situations. You just don't need two different processes and two sets of pages to check, depending whether the sock inquiry will consider evidence X or not. You just make sure users can't request CU evidence unless well founded and endorsed (as normal anyway). FT2 ^{(Talk | email)} 10:18, 14 April 2008 (UTC)

• I think this might not be a great idea. It would lead to WP:RFCU being clogged by cases that could be dealt with under WP:DUCK. Stifle (talk) 10:46, 14 April 2008 (UTC)

  Cases of suspected socking - whether checkuser is asked for or not - won't even be seen by checkusers unless actually necessary (or they want to). If CU evidence is requested for a given case, they tag the SSP case with {{RFCU}} which functions exactly as WP:RFCU does - it codes, filters, and can be tagged as |declined (by a clerk/admin) if inappropriate. Only the few cases where it's |endorsed does the request then appear on checkusers' radar for CU evidence to be added. FT2 ^{(Talk | email)} 11:59, 14 April 2008 (UTC)

  Thanks for clarifying that. Now neutral on the matter, given that I monitor neither noticeboard. Stifle (talk) 17:43, 14 April 2008 (UTC)

• Support - makes sense. Lara❤Love 13:03, 14 April 2008 (UTC)

• Support This will not add backlog to check users because only cases that need them will have a template. I think the clerks will do a fine job. Lets simplify. _(1 == 2)^Until 13:42, 14 April 2008 (UTC)

• Tentatively, I'd oppose this change. I'd like to see some outline of actual problems that result from the current setup, aside from the cognitive inelegance involved. It does seem that while the overall question is the same for both processes, they tend to attract and deal with separate types of cases - many of the SSP cases are based on behavioral patterns and other types of evidence because checkuser evidence is inconclusive or unavailable (stale, proxies, etc.). Combining the two processes makes the dual system easier to navigate for newbies, but it also means that a lot of the crap that gets filtered at SSP will make it into RFCU - not a good end result, in my opinion. Avruch ^T 15:04, 14 April 2008 (UTC)

I have to say I disagree. I don't think a careful reading would suggest such issues would "make it into RFCU"? I would ask you read carefully, and if willing, explain exactly what you see allowing that. I think this has to be a slight misunderstanding rather than a genuine issue, hence discussion might resolve it. FT2 ^{(Talk | email)} 16:34, 14 April 2008 (UTC)

Replied to your e-mail. I don't think I am misunderstanding the proposal, but if so please help me see what I am missing. Avruch ^T 17:13, 14 April 2008 (UTC)

The other point that I guess is not related to whether I am understand your intent here is this: Is there a harm associated with the way these processes are currently operating? An SSP backlog that could be addressed by the merger, some other issue? Avruch ^T 17:28, 14 April 2008 (UTC)

Excess process, multiple pages, SSP evidence not being quite so readily to hand on RFCU cases or needing checking in 2 places when considering a potential sock situation. At the same time it's also being used to improve how the cases pages operate. This benefits checkusers (less work), users bringing cases or accused (simpler to seek CU on a case but also tighter controlled how it fits in), patrolling admins (more interesting and more involvement on cases involving CU requests), and in part, the community as a whole (CU becomes "just one form of evidence in a case" rather than an entire case itself, at the same time repeat cases become better managed and tracked). More streamlined. And all current benefits of each are clearly kept. So quite a few advantages anticipated. Seriously, I think all parties will measurably benefit and yet it completely keeps all that's good in each current process too. FT2 ^{(Talk | email)} 11:09, 1 May 2008 (UTC)

• Oppose Support pretty much per Thatcher and Stifle. This is a little liberal for me, simple intervention by an uninvolved administrator is all that is used in many cases (for example, when we see similar editing patterns etc.), I really wouldn't approve of using checkuser for every case, suffice to say that it 'may' be needed. As far as I can see, SSP pulls much of a different weight when compared to RFCU. The board allows for, as mentioned above, simple and for any other reason non-compliant cases (example, edit-warring over content) to be thrown out as easily determinable or a quick close as it may not fit the purpose of the noticeboard. SSP is for editors and acts more of a reference to an administrator, someone who is trying to gain attention to a certain cause without the need of having to go to ANI, AN or RFCU, so by making this into one process, we'll have administrators (and maybe other users as well) conducting these others on what complies with RFCU policy and what doesn't, which could easily lead to someone not bringing the case to the attention of the community–I know because I didn't have a clue what SSP and RFCU was back when I was a newbie, so are the rules going to simplified for the merger? RFCU often use SSP cases as a reference so a more detailed explanation is available. By merging the two, CUs will have to read through hours of diffs and comments, searching through editing patterns, creation of account times etc. when this could easily be done in SSP, and then be referred to RFCU when appropriate or there is an immediate danger to the 'pedia. Final thing, how can we persuade more people to become CUs? As I see it, its already a restricted selection and because the process involves identifying yourself to the foundation, then maybe we'll have CUs doing nothing but CUing, surely that's not a good thing? Rudget (review) 15:15, 14 April 2008 (UTC)

As several cases above, i think much of this is based on misconception. It starts by taking it to mean that "every" case will use CU (it won't, the strict requirements for CU and its minimal use stay exactly unchanged), comments this is over liberal when in fact usage should not change at all, asserts CUers will have to read "hours of diffs and comments" which in fact is not likely at all (same process for CU, even down to the same letters), and so on. As above, I think this must be a misunderstanding of what's actually proposed. Discuss and see if that's so? FT2 ^{(Talk | email)} 16:34, 14 April 2008 (UTC)

My bad. How will the selection of clerks be conducted though? Will they be the pre-existing ones over at RFCU already? Rudget (review) 17:22, 14 April 2008 (UTC)

Yes, RFCU clerks. Or SSP patrolling admins. Or really, any admin who wants to help patrol SSP/RFCU, unless there is some special need to be selective about RFCU clerks already that I'm unaware of. The task isn't that complex. Basically, patrol Category:SSP cases awaiting clerk or admin checking, and update the request tag by adding "endorse" or "decline" based on whether there's good and appropriate reason in the RFCU tag rationale and case evidence, for requesting CheckUser. (And if needed, provide a comment.) FT2 ^{(Talk | email)} 17:45, 14 April 2008 (UTC)

Would I be correct in suggesting that, when the case is "rejected" as a checkuser request, it would go into some sort of 'side queue' category, where it could be processed without the use of checkuser? That is, if it is rejected as being unsuitable for checkuser (eg., insufficient evidence, no suitable code letter, privacy policy restrictions, et cetera), it could still continue along the "production line", and be handled by a regular administrator using behavioural evidence? Anthøny 18:43, 20 May 2008 (UTC)

Yesno. Yes the idea's right, no there is no "side queue". An RFCU request would be made up of evidence of socking, plus a request that checkuser is used to add more evidence (or conclude the case). If checkuser isn't suitable or declined for whatever reason, then the case remains as it was before - evidence of socking, with CU not applicable and whatever comment the declining admin/clerk/CU-er felt necessary. This still gets considered (like any SSP) on its merits, which might be anything from "blatantly obvious" to "decline, fishing". No "side queues", no complexity. It places RFCU where it belongs, as evidence for a sock case. If declined, then its still handled by any admin based on the evidence anyway. As you say, it just means the evidence is purely behavioral, not including checkuser findings. FT2 ^{(Talk | email)} 11:09, 22 May 2008 (UTC)

Understood. Would it be beneficial to have a "side queue", as there already seems to be one for requests requiring checkuser attention? Anthøny 11:39, 22 May 2008 (UTC)

There's two categories, broadly covering "cases that need clerk/patrolling admin attention", and "cases endorsed for checkuser attention". I sthat the question? FT2 ^{(Talk | email)} 23:32, 23 May 2008 (UTC)

Got you now. :) That does answer the question; thank you. Anthøny 19:47, 24 May 2008 (UTC)

• Support - it shouldn't be necessary to make an entirely separate report to get a checkuser. PhilKnight (talk) 10:17, 15 April 2008 (UTC)
• Clerks can decide if a case reaches checkuser or not? This will just result in more private requests, especially if some 500-edit total newbie clerk (I appreciate that there are good clerks, but the occasional bad apple drops in as well) "rejects" a checkuser case and the only way (save rolling them back and warning them, which is probably what I'd do, actually) is to go via another method other than the on-wiki SSP/RFCU page. I don't like that at all. Daniel (talk) 09:28, 17 April 2008 (UTC)
  • I thought all RFCU clerks were admins? I haven't seen non-admin RFCU clerks, so perhaps I just assumed that was the case. If it isn't, and this proposal gets implemented, the clerk role should require admin status. Avruch ^T 19:16, 22 April 2008 (UTC)

I thought so too, my impression was clerks (appointed to the role) and patrolling admins, would be a fairly high criteria. Certainly not newbie low-expereince editors. Does that fix it? FT2 ^{(Talk | email)} 00:55, 28 April 2008 (UTC)

• Support - but may need some thinking through of exactly how the combined entity will operate, as SSP allows for discussion while RFCU is more a technical forum. However I'd argue that much of the discussion on SSP is relatively useless, especially on the less visited cases where it's simply become a forum for bad faith allegations by some random user against some other random user. Orderinchaos 10:13, 17 April 2008 (UTC)

Putting the combined pages under the control of clerks and patrolling admins, and maybe a bit tighter control of content, would solve that SSP problem too. Two fixes for the price of one :) "These pages are for the presentation and discussion of sock puppetry evidence, and for no other purpose. Any other content not directly related to that function may be redacted or removed by any administrator" should solve it, and improve the current pages at the same time too. FT2 ^{(Talk | email)} 00:59, 28 April 2008 (UTC)

• Neutral because I can work with the system either way. I'd say at least half of the cases on WP:SSP can be resolved without needing to look at checkuser. In practice it's more than half because asking for checkuser is a bothersome chore, requiring me to create a new page. If there were a template I could put on SSP reports that says, "Could a checkuser please look at this?", that would improve communication between the two pages without needing to merge them altogether, and without necessarily placing the burden of effort on a SSP respondent who doesn't want to file a full RFCU page. I understand that vindictive accusers could abuse such a template, which is an issue already raised, so it's probably not a good idea. For now I think the system basically works, except that the checkuser page receives much more love than the SSP page, and a merger would call attention to some SSP cases that are being ignored. That benefit might not justify the cost of merging two pages that don't perfectly overlap in purpose. Shalom (Hello • Peace) 17:45, 12 May 2008 (UTC)
• Support as it would make things easier. Sincerely, --Le Grand Roi des Citrouilles^Tally-ho! 17:08, 20 May 2008 (UTC)
• Oppose as it would make things harder, generally per Thatcher, Stifle, and Daniel, who all bring up good points. dihydrogen monoxide (H₂O) 04:50, 25 May 2008 (UTC)
  • That's the thing: it would not–the entire system of "sock puppet identification" would become easier to navigate, track, and utilise for a particular sock farm. Check out FT2's rebuttal to Thatcher, and the various other responses, for counter-arguments regarding exactly why it wouldn't become more difficult. Anthøny 09:53, 25 May 2008 (UTC)
• I am, in general, supportive of this merge, but I'm not sure about the exact procedure. It would, obviously, make a lot of sense to have a more simple and linear system. My only doubt is about the use of the category. I do not find the RFCU page as it stands cumbersome, whereas I think categories are cumbersome, not least because they don't allow for chronological ordering -- I often take a look to see if there are any long-outstanding cases that need examining. I suggest that, once the RFCU tag is added, the case page should then be transcluded onto both SSP and RFCU (whether this is done by the submitting user, by a clerk as part of a vetting process or by a bot is immaterial). Other than this concern, I am fully in favour of stratifying the system. Sam Korn ^(smoddy) 18:39, 1 June 2008 (UTC)
  • Reasonable comment. I think the main purpose of this discussion is just to get "core consensus" for the move. Any niggles that users have about specific aspects (such as those that you have yourself, Sam) can be ironed out when / if the proposal is implemented. I'd imagine there will be further review and discussion on various aspects of the new system when it is being developed, anyway. Anthøny 18:50, 1 June 2008 (UTC)