Forwarded to the list per request.
The message pertains to her initial inquiry of November 2008:
http://lists.wikimedia.org/pipermail/foundation-l/2008-November/047414.html
-- Ral315
---------- Forwarded message ---------- From: dee dee strategicdesign2001@yahoo.com Date: Sun, Oct 25, 2009 at 12:25 PM Subject: Re: Have you dealt with this Systemic Secretive Checkuser Abuse yet? If so, how? To: Ryan Lomonaco wiki.ral315@gmail.com Cc: foundation-l-owner@lists.wikimedia.org
Ryan,
It is 2 simple but important issues: the supportive details are all included in this email.
Here is the current and past practice in a nutshell as expressed by one of the former Regular contributors: "* The vast majority of checkuser requests are, and always have been, performed quietly and without a request at RFCU. Frivolous requests are routinely rejected through these back-channels, and no more information is given than would be given at RFCU. Why is this a problem? <b>[[User Talk:JzG|Guy]]</b> <small>([[User:JzG/help|Help!]])</small> 18:14, 1 December 2007 (UTC)
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28policy%2...
Issue 1: The official and public description of CheckUser lays out a transparent process for justifying when and how it may be used. In practice, it is often used in secret and quick "back door" process. First issue is the misrepresentation to the public and all contributors as to how and when Checkuser may be used.
Issue 2: Whether it is ethical or democratic to be using this "back channel" process.
I suppose another issue is why it has been so difficult to get the Foundation to address the matter.
Dee Dee ** http://www.flickr.com/gift/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Issue 1: The official and public description of CheckUser lays out a transparent process for justifying when and how it may be used. In practice, it is often used in secret and quick "back door" process. First issue is the misrepresentation to the public and all contributors as to how and when Checkuser may be used.
The same standards outlined on the CheckUser Policy page apply to all checks - whether requested in public, requested in private, or done by a CheckUser without any request at all. If those standards are not being met (which is a fact one would have to investigate) then it is a problem with the standards not being met - not the request process or lack thereof. So, you should begin by showing that there is actually a problem here before you take it as fact.
Granted, you may argue that forcing requests to be made public would force more stringent compliance with the standards, but you haven't even shown that there is an issue in the first place; you have merely assumed that it is so. Beginning an argument with a false premise is generally not going to leave you in a good position to win. If you were going to argue that public requests would curb abuse then you would first have to show that 1) there is abuse; and 2) that abuse arises from private requests or checks done with no request at all; and 3) that making all requests public would curb that abuse; and 4) that making all requests public would not have other adverse effects outweighing the benefits.
The additional question of whether the CheckUser policy page should mention these facts is an interesting one. I rather suspect you are referring to the page on English Wikipedia, which I haven't read in well over 1.5 years, I would imagine. If you think their page is inadequate, feel free to fix it or post to the talk page such that others can help you fix it. For the page on Meta with which I am quite familiar: there is no assertion about any request process, and it would be inappropriate for it to do so.
Issue 2: Whether it is ethical or democratic to be using this "back channel" process.
You haven't shown that there is a real issue with running checks that aren't requested in public. Therefore, your second issue simply arises from false premises.
You are a long way from proving your point, but I would encourage you to make that request on the talk page of the CheckUser policy page on English Wikipedia so it can be pointed out that while there is a public request process, most requests are made in private, or done of a CheckUser's own volition. That is true, and it may be a worthwhile piece of information - though I can think of reasons the enwiki CUs may not want it included. If the public request process isn't necessary then they may be innundated with requests in private. The public process serves as a filter to keep away spurious requests. By not advertising it, private requests tend to be more reliable since it would be people "in the know" who would make those requests.
But again: ask on the talk page. It is a wiki after all.
- -Mike
2009/10/27 Mike.lifeguard mike.lifeguard@gmail.com:
You are a long way from proving your point, but I would encourage you to make that request on the talk page of the CheckUser policy page on English Wikipedia so it can be pointed out that while there is a public request process, most requests are made in private, or done of a CheckUser's own volition. That is true, and it may be a worthwhile piece of information - though I can think of reasons the enwiki CUs may not want it included. If the public request process isn't necessary then they may be innundated with requests in private. The public process serves as a filter to keep away spurious requests. By not advertising it, private requests tend to be more reliable since it would be people "in the know" who would make those requests.
en:WP:RFCU was actually created to stop people bugging the checkusers so much ;-)
Checks are done because of public requests, but also because (a) there's an investigation by the arbcom and they want second or third opinions or (b) because there's a cross-wiki vandal and so people check on their local wiki as well. That's most of the cases on the functionaries-en and checkuser-l lists.
- d.
On Tue, Oct 27, 2009 at 9:27 AM, Mike.lifeguard mike.lifeguard@gmail.com wrote:
Granted, you may argue that forcing requests to be made public would force more stringent compliance with the standards, but you haven't even shown that there is an issue in the first place; you have merely assumed that it is so. Beginning an argument with a false premise is generally
[snip]
Checkuser can cause harm in two primary ways:
(1) The wrongful release of private information about an editor. (IP, Useragent, etc, or information derived from this private information "Mike is in Chicago"). (2) Besmirching the reputation of good users; generally causing drama.
The written CU policy deals mostly with setting policy to prevent type 1 harm.
For type 1 harm to happen it requires the checkuser both perform the check *and* blab about the results. For type 1 harm to be /meaningful/ the information had to be actually confidential: You can't really say you were harmed by a CU disclosing your IP if you'd been intermittently editing logged out with it for the past six months then logging back in and fixing your signatures.
I think all checkusers take preventing type 1 harm seriously, even though it is usually trivial for a motivated non-checkuser to obtain an editor's IP, since the harm requires both a check and a disclosure and we have reasonable policy covering it I don't expect type 1 harm to be the most frequent problem.
Type 2 harm is magnified by the uncertainty of checkuser: CU can't really vindicate with any confidence, _at best_ it can really only convict with a degree of confidence. It has been a common sport for some to accuse their enemies of sock-puppetry and clamouring for someone to CU them. When the CU comes back with the inevitable "nothing conclusive" that is used to sew additional doubt about the accused. Just the knowledge that someone saw fit to check is hurtful to a person and their credibility.
So, conducting checks in private is the best tool we have for minimizing type 2 harm: If no one but the CU knows that a check was performed, no feelings are hurt, no credibility is smudged. If CUs aggressively "turn down" requests made out of anger, even while privately performing checks in the more suspicious cases, then drama is reduced. The privacy in the checking process does create more opportunities for type 1 harm, but as Mike mentions, I've not seen any evidence that type 1 harm has been much of an issue in practice.
wikimedia-l@lists.wikimedia.org