Wikipedia:Requests for checkuser/Clerks/Noticeboard/Archive1

• Wikipedia:Requests_for_CheckUser#User:Rex071404.2FUser:Merecat
• Discussion removed to history.

I'm removing the entire discussion to the history, and would appreciate a clerk going through and pulling out a list of all the suspects. It appears several of the comments are of the "also, so-and-so" variety, and it would be helpful to have a full list before diving in. Many thanks, a plate of cookies, and a flak-jacket to the clerk who takes it on. ;) Essjay (Talk • Connect) 18:46, 4 June 2006 (UTC)[reply]

I would do it, but its a horrible mess and I really need to logoff and do some real world work now. And I really wanted those cookies :-( Anyone else? the wub "?!" 18:55, 4 June 2006 (UTC)[reply]

From what I can tell:

• Rex071404 (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki)
• Merecat (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki)

both of whom have been permabanned, are accused of having the following socks:

• Neutral_arbiter (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki)
• Wombdpsw (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki)
• 69.46.20.59 (talk⁺ · tag · contribs · filter log · WHOIS · RBLs · proxy check · block user · block log · cross-wiki contribs · CheckUser (log))
• 216.22.26.46 (talk⁺ · tag · contribs · filter log · WHOIS · RBLs · proxy check · block user · block log · cross-wiki contribs · CheckUser (log))
• Zer0faults (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki)

Zer0faults vehemently argues that he is not a sockpuppet, and claims that his IP is 74.64.40.102, which is located in a different state than 69.46.20.59.

Whew! That is a bit of a mess! - Pureblade | ^Θ 19:34, 4 June 2006 (UTC)[reply]

Also, Cal_Burrattino (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki) made his first edit only two hours after merecat was banned, and due to his knowledge of wiki terms and interest in one of the same articles as Merecat had, is suspected of being a sockpuppet of someone, possibly Merecat. - Pureblade | ^Θ 19:43, 4 June 2006 (UTC)[reply]

• User:216.22.26.46 = User:Wombdpsw. They vandalize pages exactly the same: edit 216.22.26.46 and User:Wombdpsw. There are many complaints about User:Wombdpsw. —Preceding unsigned comment added by ActiveSelective (talk • contribs)

• Please note this page is primarily for checkuser admins to contact the clerks. The Merecat checkuser request has been done and is in the completed section of the main page. Thanks. Thatcher131 05:41, 5 June 2006 (UTC)[reply]

Clerk assistance required: I'm not sure if it's the lateness, or my lingering sadness over the Tigers losing 9-2 this evening, but I'm having real trouble figuring out who's accusing whom of what here. Mackensen (talk) 03:02, 2 July 2006 (UTC)[reply]

Above is quoted from there, currently working on this. Kevin_b_er 04:04, 2 July 2006 (UTC)[reply]

The above text written by me. Kevin_b_er 08:49, 2 July 2006 (UTC)[reply]

I've noticed we've switched from listing old checks at the top to listing them at the bottom. That's fine with me except one problem: It breaks the result script, placing the posted result at the bottom of the page, inside the <noinclude> tags, making it invisible. Could we either find a way to keep the noinclude'd stuff out of the current request's section or fix the script so the result is inserted wherever the cursor is (allowing us to place it in the right spot) rather than at the end? Essjay (Talk • Connect) 03:13, 5 July 2006 (UTC)[reply]

• The reason I started putting the newest request at the top (and I changed the Rfcua and Rfcub templates accordingly) is that when you click on "edit" on the checkuser page, it always goes to section one of the transcluded page, even if section one is noincluded and section two is the active request. I guess this is a bug in mediawiki. I'm sorry that it confuses the script but it seems that clicking into the wrong section has the potential to confuse all the ordinary editors who might post or comment. I try and watchlist the subpages and will be happy to fix any problems I find; I would also be happy to contribute to any ultimate solution but javascript might as well be sanskrit to me :) . If the mediawiki bug could be fixed then the new request could be put anywhere we wanted. Thatcher131 05:13, 5 July 2006 (UTC)[reply]

I think the simplest answer is to fix the script; rather than posting to the end, it should post to the current cursor location. Unfortunately, I don't know how to make it do that. Voice of All??? Essjay (Talk • Connect) 06:23, 5 July 2006 (UTC)[reply]

I recall their being a problem like this on another script, for something else. This is VoA's department though. Prodego ^talk 11:13, 5 July 2006 (UTC)[reply]

Noted. I'll work on this tonight.Voice-of-All 09:27, 10 July 2006 (UTC)[reply]

VoA and Mackensen have apparently decided that cases that are declined as fishing expeditions should be deleted rather than listed on the /Case page (see User talk:Voice of All), partly because the case page is getting quite long already. I was under the impression Essjay wanted to keep everything. I don't have strong feeling one way or the other, however I have certainly created a lot of subpages for fishing expeditions while converting the old archives to subpages. If we're not going to keep certain requests then I can go through the page and tag a large number, and I'm sure not going to do any more archiving until I know which way this is going to go. I don't know whether keeping declined requests helps the checkusers in any way, but while doing the old archives, I did find a declined request for Merecat that would have nailed him dead to rights two months before he was exposed. One suggestion, to keep the /Case page clean, we could list declined requests on a new subpage /Case/Declined, and keep only the answered cases on the main page (confirmed/inconclusive/unrelated). Anyway, awaiting clarification. Thanks. Thatcher131 00:21, 10 July 2006 (UTC)[reply]

I've deleted about 2 requests so far. One did not follow the format and had nothing to compare against (and was not an open proxy check either), and the other was by an IP on a fishing expedition twice. Generally, fishing is not usually enough to warrant removal, but if its not a serious request, then I'll just remove it. Whether archived or not, such cases should definetely not be added to /Case. Regular declined cases are useful when things become more certain for later requests.Voice-of-All 09:25, 10 July 2006 (UTC)[reply]

Perhaps. However no request should ever be denied by a non-checkuser. You are proposing that cases declined by checkusers not get archived to /Case, correct? I don't think that they should be deleted, but not archiving them seems fine. But Essjay's opinion matters most. Prodego ^talk 12:52, 10 July 2006 (UTC)[reply]

No. I never decline cases, only CUs. And I only delete invalid/very clear fishing expedition cases, as Thatcher described. Declined cases, as I said are usually useful later on, and should be archived in /Case.Voice-of-All 20:24, 12 July 2006 (UTC)[reply]

Well, the one case I know about is Wikipedia:Requests for checkuser/Case/Prometheuspan, which consisted of two separate requests of the form, "I'm sure he's a sockpuppet of someone, but I don't know who." It seems that VoA's criteria is that if it's a specific request, even if declined, it will be kept, but if it is a completely nonspecific fishing expedition it will be deleted. I would like some clarity on this. Some of the pages I have created from the archives seem to meet this apparent criteria and I can go through and tag them for VoA to review if that's the viewpoint of Mackensen and Essjay. Thatcher131 13:46, 10 July 2006 (UTC)[reply]

I prefer that everything be kept, for several reasons:

1. Keeping records of public check requests helps cover us; we know exactly what we said, and can point to it if necessary.
2. Tracking who is accused of what is almost impossible with the various systems that are used; not all socks get tagged when they are suspected, making it possible that our list might be the only place listing a connection. Knowing there was an allegation early on, even if rejected, is helpful when it comes up later.

It concerns me that if we start deleting anything, we run the risk of slipping into deleting more and more. I really, really don't want that to happen. I don't have a problem with listing cases like this separately, as Thatcher suggests, but I'd really prefer that nothing be deleted. Essjay (Talk) 16:56, 12 July 2006 (UTC)[reply]

There are currently over 300 subpages of /Case, with at least 100 old requests in April and May still to go. /Case itself is currently 38kb. I guess I would suggest archiving by year. On 1/1/07, move /Case to /Case/2006. I estimate there will be about 700-800 cases with the page about 100-120 kb, pretty long but shorter than ANI, for example. (revived cases could be listed in each year or the current year only; but that's looking pretty far ahead.) Splitting by answered/declined would require inspecting all the old cases, and both subpages would fill up eventually, just at half the rate. Thatcher131 17:19, 12 July 2006 (UTC)[reply]

Indeed, yearly archiving is a good idea: I would say do it monthly, but that presents the problem of having to search every month's archive if you're looking for anything, which is what we're trying to avoid. I'm really not sure on this one, I'd like to hear ideas. Essjay (Talk) 17:32, 12 July 2006 (UTC)[reply]

I'd go either way, but yearly is easier :).Voice-of-All 20:24, 12 July 2006 (UTC)[reply]

I'm for yearly. Monthly would take too much time for someone who needs to glance though this archive to find this request. Kevin_b_er 23:59, 13 July 2006 (UTC)[reply]

D'accord.Voice-of-All 01:55, 17 July 2006 (UTC)[reply]

I'm having a problem with Scribner (talk · contribs). He created two requests, Wikipedia:Requests for checkuser/Case/Striver and Wikipedia:Requests for checkuser/Case/75.35.200.166. Since both mentioned Starcare (talk · contribs), I merged them. This made Scribner upset and we proceeded to have a long dialog on my talk page. The bottom line is he thinks the 75 IP address will prove that Publicola (talk · contribs) is the sockpuppet of Pepsidrinka (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) and that Starcare is a sockpuppet of Striver. He has completely ignored my advice and recreated the 75 case with a name that seems to have an invisible extra character in it as Wikipedia:Requests for checkuser/Case/75.35.200.166 is different from Wikipedia:Requests for checkuser/Case/75.35.200.166‎ .

I can't tell if he is just being stubborn or if he realizes a direct request on Pepsidrinka and Publicola will be declined for the reasons I cited. He is also being moderately disruptive at Wikipedia:Requests for mediation/Shock and awe, User talk:Starcare and User talk:Publicola, in particular revert warring over sock puppet tags. You have to read my talk page to get the full picture of what he's on about; I still have no idea why he wants to run a check on the 75 IP and Starcare if he thinks the IP is someone else.

I need someone with the admin hammer to take over watching this. Firstly, the case with the invisible character should probably be deleted, and the previous case reverted to his preferred version. I would be inclined to add the explanation from my talk page so Mackensen doesn't have to waste any more time on this than he has to, but I don't want to push t any more with this guy and he needs to know I'm not the only one watching him. Thanks. Thatcher131 (talk) 05:50, 29 August 2006 (UTC)[reply]

When should old clerk requests be archived away? Kevin_b_er 07:32, 5 June 2006 (UTC)[reply]

• I would say either (a) as soon as the completed request is posted to the main board, or (b) 7 days after the checkuser is complete (the same time when completed/denied requests are moved from the main page to the archive). Thatcher131 12:04, 5 June 2006 (UTC)[reply]

I'm not good with templates yet myself but I have an idea for {{checkuser-completed|Name}} that would say something like "The checkuser request you filed for Name has been completed, please see WP:RFCU for the results." that could be subst'd onto people's talk pages. Maybe a separate {{checkuser-declined}} or maybe not. What do you think? Thatcher131 05:14, 5 June 2006 (UTC)[reply]

It specifically says on the page "Please check back on your requests". By telling them the result, we are making more work for us, and we are just giving them another excuse to be lazy. --GeorgeMoney ^T·C 05:27, 5 June 2006 (UTC)[reply]

OK. Thatcher131 05:37, 5 June 2006 (UTC)[reply]

I already did this last night, {{Checkuser complete}}. I figured it would be useful since there were a large number of people to inform once the backlog cleared. Yes it does currently say to check back on requests, but this doesn't mean a notice is a bad idea. The quicker people are made aware of the results, the quicker action can be taken and the request archived. As for being more work for us, I'm perfectly happy to do it. I think the reason it was never done before (and for that notice on the page) was that the actual CheckUsers had too much other work to do. BTW I didn't include a Name parameter in the template because many of the requests are quite complicated. the wub "?!" 10:07, 5 June 2006 (UTC)[reply]

Well, you might be right. We have to get Essjay's opinion, because he is our boss :) . --GeorgeMoney ^T·C 14:48, 5 June 2006 (UTC)[reply]

I'm fine with you guys notifying people; I stuck a big note on the page because I don't have time to track down each interested party and leave a note that the request has been done. If you guys are willing to do so, then by all means go ahead. I think it really came to a head for me when I saw someone post a new request to the page, posted right above a previous request where I had requested more information, and never respond to my request for information; that gave me a pretty good idea that people were paying no attention to what was being said. Essjay (Talk • Connect) 19:28, 5 June 2006 (UTC)[reply]

Although the guide says completed requests can be archived once acted on, I suggest leaving them for at least 5 days (maybe the full 7) to avoid being asked repeatedly by users who don't check the arcive.

Also, should clerks talk to each other here, or should we open one of the talk pages and leave this page for clerk requests by the CU admins? Thatcher131 13:00, 5 June 2006 (UTC)[reply]

It's good practice to leave things a few days; as long as the page doesn't get too long (at the point it grows to the length of ANI or RFA, it's too long), I'm fine with leaving them a few days. I've generally waited between three days and a week to archive.

As for discussing here, as long as it doesn't become a problem where people stop watching the page for requests because of too much discussion, I'm fine with discussing here. My original intent was for it to be a central location to let you guys know a request needed attention, but I think having it as a kind of general noticeboard is a good one. What I don't want to see is this becoming a place for others to argue with findings or clerk activities; I saw some editing of clerk comments last night by an IP involved in a check, and I don't want to see that happening. As long as it remains the case that we're all watching here, and nothing is getting buried, then I think using it for general notices/discussion is a good thing. If we need to, we can split it in to two pages, one for notices of tasks that need to be done, and one for coordination of clerk activities. We'll see how things develop. Essjay (Talk • Connect) 19:28, 5 June 2006 (UTC)[reply]

I think four days is a good number to archive completed checks after. If we do institute notices, which I support, that will be more than long enough to let all parties see the results. - Pureblade | ^Θ 19:40, 5 June 2006 (UTC)[reply]

I have created {{checkusernotify}} which contains links to notify a user of stuff: GeorgeMoney (talk) ^{Confirmed · Inconclusive · Declined · Need More Info}. Click the links. --GeorgeMoney ^T·C 05:55, 7 June 2006 (UTC)[reply]

I couldn't figure out what this was supposed to do, then I saw on Essjay's talk that it would be for requesters to sign their requests with, so we could access some easy templates for notification. I'm sorry but I don't think I like it and I would prefer it not be offered. Sometimes checkuser results are too complicated to fit in a simple box. I may in certain cases if the circumstances warrant it, but not only should people be watching themselves, but the new subpage is automatically added to the requestors watchlist by default. I'm not sure I want to establish the precedent that requestors will always be notified. Thatcher131 23:16, 8 June 2006 (UTC)[reply]

My feeling is this page should be archived fairly often to keep it cleanish and shortish. To help, I created the above little archive box. If you like it, it can be moved to template space or subst'd; I don't care. I have an idea for a different picture, too, which I'll upload later today. Thatcher131 20:41, 8 June 2006 (UTC)[reply]

Good idea. Hope the archive box picture is eye-catching in this otherwise drab page. Anyway it may still be today for you Yanks, but its 2:15 in the morning here in India. So I'm gonna go catch some zzzz's. See you tommorow...or today?...never mind..;) --Srikeit ^{(Talk | Email)} 20:51, 8 June 2006 (UTC)[reply]

I hope the new image is acceptable. Thatcher131 00:48, 9 June 2006 (UTC)[reply]

We've introduced a few changes to the way checkusers are requested to make things work a bit easier. Now, instead of listing checks directly on RFCU, they will be listed on subpages. There is a convenient submission box on RFCU that creates the subpage, and preloads the template text. It also adds a tag (Wikipedia:Requests for checkuser/Inputbox/Sample/Tag) to the top of the page. This includes a big note reminding the person to add the entry to the queue on RFCU, and adds it to a special temporary category (Category:Checkuser requests for April 27, 2024), that will change automatically each day. Clerks are asked to check the category and make sure all pages listed there are included on RFCU. The tag will be removed by the checkuser when the result is posted.

There are a few points to notice:

• First and foremost: Do not create the category. Don't add any text to the category page, under any circumstances. It is a non-existent category used as a temporaray holding pen, and there is no need for it to be bluelinked. If it is never created, it never needs to be deleted.
• Instead of archiving to Wikipedia:Requests for checkuser/Archive, they will be listed on Wikipedia:Requests for checkuser/Case. Clerks should add a link to the subpage with the name of the puppeteer, and a list of the other related accounts. (See the format on the case page.)
• When a case is removed from RFCU and placed on the case page, the discussion on the subpage should be marked with {{subst:rfcua}} at the top and {{subst:rfcub}} at the bottom. This places an archive notice around the discussion, and includes it in <noinlcude> tags; in this way, if a new request is made on the same individual, only the new request will actually show up on RFCU.

I think this covers everything. If anyone has questions, please let me know. Prodego & Thatcher have helped with setting this all up, so they should be able to answer questions as well. Essjay (Talk • Connect) 05:48, 7 June 2006 (UTC)[reply]

Watching

Note that putting Wikipedia:Requests for checkuser on our watchlists will tell us when new cases are added but will not alert us to when people add followup comments. We will need to add each subpage to our watchlists or develop a habit of periodically scanning the main page. On the plus side, since the default edit mode is to add new pages to a user's watchlist, editors who create cases will find out by that route when their case is answered. Thatcher131 21:25, 7 June 2006 (UTC)[reply]

I've noticed in the last few days that several of the clerks have stated thier personal opinions in regards to certain checks while performing clerk tasks, and also, that some clerks are crossing into the checkuser territory by requesting additional information, etc. from the users making requests. Please don't do this!

Having clerks is brand new, and we need to do everything we can to encourage the community to look upon the clerks in a positive way. The best way to do this is for clerks to avoid the appearance of any kind of partiality. It's very likely that over time, you'll all be able to spot a request that is going to be declined at 100 paces, but it's very very important that you not leave comments on the request saying "This should be rejected" or "This doesn't look serious enough to me." We need the community to recognize that clerks are here to help things run smoothly, to see to the maintainence of the page, and that they are not an extra layer of bureaucracy, or some kind of request screening board. It doesn't take that much time for a checkuser to read over a request and say "no", so there's really no need for the clerks to assume this duty, and as individuals usually aren't happy that thier requests have been denied, it's best that we don't set the clerks up to be convenient targets for their unhappiness. I'd very much prefer that clerks not express any opinions on any checks, but most certainly do not express any opinions on requests where you are performing clerk duties.

Similarly, when extra information is required for a check, it's best that the request come from a checkuser, as we're in the best position to know what exactly it is we need. If we don't think there is sufficient cause stated for running a check, we'll say that, and indicate that additional background is necessary before a check will be run. As I said above, I think it's imperative that clerks be and appear to be completely impartial on all requests; if it begins to look like clerks are being set up as a barier between requests and checkusers ("You have to convince me before a checkuser will even see your request"), that is when the problems will start.

Much like the Arbitration Committee and it's clerks, lets all do our best to keep a strict delineation between clerks who are maintaining the requests and the checkusers who are making judgment calls on them. Essjay (Talk • Connect) 18:04, 8 June 2006 (UTC)[reply]

There have already been two cases where the parties specifically appealed to the clerks for help. That's probably an indication that we came on too strong the first few days. Thatcher131 18:55, 8 June 2006 (UTC)[reply]

Hi Thatcher, Voice of All, Kevin & me today were chatting on IRC about how when users have multiple cases & a new one is listed the edit link leads to the older case instead of the current one. VOA found a solution to that problem by using the <onlyinclude> tag & listing the newer cases at the top (see Lightbringer's case). that was what I was trying to do to the JamieAdams case. anyway I'll back off as you seem to be handling the requests. Will you make the necessary correction? Thanks --Srikeit ^{(Talk | Email)} 15:00, 16 June 2006 (UTC)[reply]

P.S Why don't you join us on IRC? #wikipedia-checkuser-clerks)

• I'm not on IRC (and technically, I'm at work now). I combined the JamieAdams reports into on field since they're so recent; it won't help the accusers to tag the previous section [noinclude] as it will disappear to most people. Normally when some time has past of course only the most recent report is trnascluded.

When Essjay and Prodego worked on the scripts I found that opening an old case created an edit window with the whole old case in it, instead of the template that you get when you open a new case. Essjay said there was no help for it and people would have to add their new info at the bottom, (outside of Rfcub and outside the [/noinclude]. Obviously people are getting confused already. If VOA has found a better solution, that's great. Can you explain it in more detail here? Also, does this mean the Rfcua and Rfcub templates need to be changed? Thatcher131 15:06, 16 June 2006 (UTC)[reply]

• • I'm curious about why VOA switched the order of the Lightbringer cases? Since opening a case on Lightbringer will always bring up an edit box with the old page in it, making it bottom-up instead of top-down means new cases should be added at the top, not the bottom. I guess that's ok. Maybe we should add an html comment in {{Rfcua}} so the editor will see it and know to add the new request at the top, rather than backing off and making a new page with some creative name. Thatcher131 15:22, 16 June 2006 (UTC)[reply]
    • Well that avoids the edit link problem from RFCU, though it also does switch up the order of multiple cases.Voice-of-All 06:39, 18 June 2006 (UTC)[reply]

The issue at hand appears to be an actual bug with the mediawiki software. Here soon I'm going to be filling a bug report, I'll report on its status. Kevin_b_er 06:41, 18 June 2006 (UTC)[reply]

I don't care if the case page is top down or bottom up. The Rfcua template could have an html comment that says "Add new report at the bottom" or "Add new report above this line". Which do you think people would be more likely to follow? Thatcher131 12:15, 18 June 2006 (UTC)[reply]

I also have two suggestions regarding the use of categories. Instead of tagging new requests in Category:RFCU today's date (which should never actually be created) why not create a real category:Open checkuser requests? I ran it past Essjay and he was fine trying it; he was worried that since it will be empty a lot of the time, someone will try and CFD it.

Another suggestion is to use Rfcub to tag all closed cases with the real category:Closed checkuser requests. This will create an alternate means of archiving requests and provide a backup in case someone removes the transclusion from the main page but forgets to add it to the index on /Case. I haven't had a chance to propose this one yet, though. It might need to be Closed checkuser cases|PAGENAME or something in order to index properly. Thatcher131 15:13, 16 June 2006 (UTC)[reply]

I say try both; add closed requests to a closed category, and new requests to a new category. Categorization is a good thing.™ Essjay (Talk • Connect) 05:38, 18 June 2006 (UTC)[reply]

After discussing this with Prodego we're not sure this is necessary. He showed me a way Special:Prefixindex to list all the subpages of the /Case page, so there is a means to find pages if they get "lost." Also, I could get the category to alphabetize properly but the cases will still listed by their full page name (Wikipedia:Requests...etc) which was ugly. Plus I would have to manually fix the 200 or so archived cases, and the category would eventually get huge (100+ per month it seems). I'm still willing to entertain the idea, though, others think it would be a significant aid. Thatcher131 00:58, 19 June 2006 (UTC)[reply]

Just a reminder (or announcement, since I don't think I made it clear upfront) that when clerks add or remove something from main RFCU page, they should note it with {{Clerk-Note}}, which produces  Clerk note:. This will help set it off as a clerk action, and alert the checkuser to what is taking place. Essjay (Talk • Connect) 21:51, 4 June 2006 (UTC)[reply]

I have also created a redirect template {{clerknote}} so people don't have to capitalize letters and put dashes when they want to use the template. --GeorgeMoney ^T·C 21:55, 4 June 2006 (UTC)[reply]

It's just my opinion but I would say that when we do something like minor formatting or correcting a page name that is essentially transparent and does not alter the request itself, we don't need to label it with the clerk note symbol; an informative edit summary is fine. I 'm concerned about looking like we have too big a role by commenting on nearly every request. Thoughts? Thatcher131 20:19, 16 June 2006 (UTC)[reply]

I would tend to agree; minor, cosmetic or functional changes don't need to be noted in the request. Notes should be left for things that really must be noted (like removing 100 lines of discussion to the history). Essjay (Talk • Connect) 05:39, 18 June 2006 (UTC)[reply]

I was always erring on the side of caution, but this is good. Don't need to leave a clerk note for moving from ...for_checkuser/Username to ...for_checkuser/Case/Username Kevin_b_er 06:35, 18 June 2006 (UTC)[reply]

Yeah, I can see why people get confused when reopening a case, but why are they changing the contents of the infobox, thsu the page name? Grr. Thatcher131 12:10, 18 June 2006 (UTC)[reply]

Currently, I integrated the last one wiht the old one for Objectivemon, but someone else used "second:" in an indented section to denote that it was the second time. Whcih one should we stick to? Maybe having "second:" is actually better.Voice-of-All 00:19, 19 June 2006 (UTC)[reply]

I think Essjay started using second when he converted January, but I have not always been consistent, especially when there are only a few names. Since the object is to be able to search for old cases by ctrl-F, either way would solve that issue; I would go with whatever looks nicest. Thatcher131 00:36, 19 June 2006 (UTC)[reply]

GeorgeMoney and I were looking at the closure templates because they weren't working right for me. I think I've solved the problem but for now, the templates must be subst'd. If not, the old page is transcluded along with the new if a new case is opened. It obviously has something to do with the include/noinclude/onlyinclude statements, but I can't figure out what. Maybe George and Prodego and VOA can put their heads together and figure out how to make the template work when subst'd or not, but for now please subst the templates and don't make any changes unless you test them first. (There are a few cases that weren't subst'd--I'll fix them now.) Thatcher131 00:40, 19 June 2006 (UTC)[reply]

It is partially caused by "<includeonly><noin</includeonly><includeonly>clude></includeonly>" in {{rfcua}}. It does not work if it is not subst'd, and if is not subst'd the bottom breaks. I don't know why it doesn't work if the top is subst'd and the bottom isn't. Anyone else? Prodego ^talk 00:44, 19 June 2006 (UTC)[reply]

Right now the bottom is a straight </noinclude> which seems to work fine when subst'd. There are some versions in the history with the split includeonly in them but when I reverted to those versions to test, none of them worked. I've set up a sandbox for testing that anyone is welcome to use. The links are on my main page. Thatcher131 00:50, 19 June 2006 (UTC)[reply]

When we originally created the {{Rfcua}} and {{Rfcub}} templates to close old cases, we set it up so that new cases would be added to the bottom of the page. This way the page could be more or less in chronological order. However, there seems to be a bug in the mediawiki software. If there is an old case and a new case, clicking edit on the checkuser page opens the top section of the transcluded /Case page, even if the top section is an old case closed by <noinclude></noinclude> tags. (Which creates a certain amount of confusion when people return to edit their case or leave comments on other cases.) The only solution seems to be to list the new case as the top section of the /Case/personname page. So I modifed {{Rfcua}} and {{Rfcub}} to tell people to add new cases to the top instead of the bottom. However, old cases from January to March were archived with the note asking people to list old cases at the bottom. I don't want to go through and re-subst them all, but we should be watching all reopened cases to make sure they are listed correctly and move new cases from the bottom to the top if necessary. Thatcher131 04:17, 29 June 2006 (UTC)[reply]

I changed the inputbox around a little. A big red warning should now appear if someone starts to create a page for a checkuser request and its not Wikipedia:Requests for checkuser/Case/Puppeteer. It doesn't work right if they enter Puppet/eer or something, but since /s aren't allowed in usernames, should be ok. This should cut down on the miscreated pages when there's a nice annoying warning. If you want to see it for yourself, try entering nonsense page or pages that aren't as I said, and it should give you a nice warning. If for some reason it busts completely, revert the changes I made to Wikipedia:Requests for checkuser/Inputbox/Header, but I did a fair amount of testing after my 5 minute botchup of the page on my own userpages to fix it up proper. Kevin_b_er 00:00, 26 July 2006 (UTC)[reply]

Good grief that's scary. We might frighten them off altogether :) Thatcher131 00:28, 26 July 2006 (UTC)[reply]

I changed the default text of a new request (at Wikipedia:Requests_for_checkuser/Inputbox/Sample) from Explanation of the request for CheckUser. to Replace this text with your explanation of your request for checkuser. PinchasC has furthur improved upon this and changed it to Replace this text with your explanation of your request for checkuser and examples of policy violations. Ignore some wierd crud between before my first through my last consecutive edit to the page, as I failed to do some fancy stuff in that area. This should cut down on the number of people not putting a freaking reasoning (or leaving those words verbatum in their request then putting their reasoning below it), and with pinchas' edits maybe they'll be more inclinded to put the policy violates (one can only hope). Kevin_b_er 00:00, 26 July 2006 (UTC)[reply]

Per a mini-concensus with other clerks in IRC, I have updated the archive page. Any questions etc. just ask here. Just follow the lead of all the current entries, and everything should be sweet. Daniel.Bryant 09:41, 3 October 2006 (UTC)[reply]

Yes, our new layout style is sweet. Go take a look and help make sure its fully clean for the new layout. My automated conversion process created a litter of bugs I think we've cleaned up, but there's still a few little things, and dates to be finished. --Kevin_b_er 02:21, 4 October 2006 (UTC)[reply]

I believe it would be helpful to seperate out any requests that include a combination of IPs and user names. In general, it shouldn't be necessary to run checkuser on IP addresses because policy regarding blocking of IPs is so liberal. IP data is implicitly released when we confirm a relationship among one or more user names and one or more IPs. The privacy policy erects significant barriers to doing this that are not present for user name pairs. As such, I believe we should consider asking users to refrain from including IPs in checkuser requests or at least splitting out such requests so they can be evaluated on their merits while the check of the names alone continues. The Uninvited Co., Inc. 23:25, 4 October 2006 (UTC)[reply]

There's rather 3 classes of requests with IPs to me:

1. They pretty much definitively want to tie a username to an IP (which needs to be serious I would think).

These are the crux of the issue of wanting to split them up, am I right?

1. An IP is thrown into a couple of usernames, but the requestor would care more about the usernames being tied than the IP

For requests similar to these, I've noticed Mackensen tends to just completely ignore the IP and process the usernames at his decision. The {{confirmed-nc}} template was created for stuff like this I would think. (We have lots of RFCU templates if you haven't noticed...)

1. "Please find the IP and block it!"

Requests for IP Check section at the bottom takes care of these requests, though if you notice, people don't always get the right sections. There was a fishing request in there a few days ago ("I don't know who but find who's using this IP.")

Sound about right? I think we could easily accomodate the first style for you. Kevin_b_er 00:26, 5 October 2006 (UTC)[reply]

My question to UninvitedCompany is, are IP addresses in username checks ever useful in making determinations? I frequently find myself explaining that IP addresses are rarely confirmed due to the privacy policy, and I created {{confirmed-nc}} for Mackensen for the purpose of answering mixed requests. When Essjay set the clerks up, he was concerned about clerks giving the impression that we were making decisions or acting as screeners. Clearly this has drifted somewhat, with clerks making substantive comments on justification and evidence (or lack thereof). If you are willing to have the clerks exert more authority, I would suggest two modifications.

• Allow the clerks to decline requests consisting only of one name and several IP addresses. A template with checkuser-approved language could be created ({{declined-ip}} for example) that would say something like; Due to the privacy policy, users' IP addresses are almost never officially confirmed. The sock puppet policy allows accounts that act like one to be treated like one, and admins have latitude to deal with disruptive IP addresses. This can be dealt with by ordinary admin action" (although that seems awfully wordy now that I have said it).
• If IP addresses are not useful to the checkusers in providing background, evidence, and so on, then empower the clerks to remove IP addresses from user name check, again with a clerk-note to the effect that IP addresses are rarely disclosed. (If IP addresses are sometimes useful, we should leave them in and you can use {{confirmed-nc}}.

Does this address the problem? Thatcher131 02:26, 5 October 2006 (UTC)[reply]

Yeah we've drifted a little, though I try to not to say anything subjectivy. I mean, when they do nothing but put one name, with hardly any evidence, and its not a blatantly vandalistic account, its rather hard to see it as ending up anything but fishing. (Though I could assertain that a checkuser request against Primetime, even if he had no sockpuppets to list, may somehow be justifiable considering his blatant, wanton copyvio.) But if we look at the constant possibility of exceptions to the rule, where it happens to be justified, there can be no blanket declines. But if there were allowances for declines on the part of clerks, then it would have to be absolutely predefined. But, as I just said, there's always exceptions to the rules. Anything outside of that is a judgement call, which is the exclusive job of those with that particular permissions flag. --Kevin_b_er 02:59, 5 October 2006 (UTC)[reply]

I could see the possibility that the IP addresses ARE useful! An example would be where the IP is tied to an account, and has made public edits. Yet the IP exhibits a CLEAR behavior of account 2, but was used only by account 1? Ahhh, you've just linked both accounts by behavior and technical, but you don't have to say how you came to that conclusion now do you. You can say that accounts are linked, and maintain silence about the IP. --Kevin_b_er 02:59, 5 October 2006 (UTC)[reply]

Anyone want to add another section to the table, stating that self-checks are rarely-performed? Daniel.Bryant 05:43, 7 October 2006 (UTC)[reply]