Meta talk:Requests for CheckUser information/Archives/2007

Active discussions

Page organization confusing

The use of project names as headings is rather confusing, and the instructions leave considerable ambiguity (especially as some of them appear only in HTML comments while editing). From what I see, the intent is to have a single "Meta" heading at the top of the requests, followed by a reverse-chronological list of projects that don't have their own CheckUser process. But that introduces three problems:

  • Because there are often multiple active requests for a project, people seem to feel the need to use variations on the project names. (Mediawiki can handle duplicate names in the table of contents properly, but there is no visual distinction.)
  • Even with project-name variations, there is no hint of the particular subject of the CU request in the TOC, undermining the usefulness of the TOC. (E.g., is that "English Wikiquote" request for the Poetlister discussion, the Kazoo incident, or the anime sockpuppets?)
  • The instructions don't make clear how to handle multiple active Meta requests. Should they be subheadings under the fixed "Meta" heading? Should there be multiple "Meta" headings in reverse-chrono order instead?

I would ask maintainers of this critical page to make the desired organization a little clearer. Thank you. ~ Jeff Q (talk) 17:42, 21 June 2007 (UTC)

I agree. I just moved a couple of headings that were related to Meta around and gave the cases names. I'm loathe to suggest introducing the boilerplated subpage mechanism that en:wp uses, it's a bit daunting... Commons uses a simplified one and things seem to stay organised well, but even that may be a bit much. Perhaps a rewording of the instructions to say group requests by project, as subheadings, and use the suspected sockmaster in the request name (level 3) might be teh way to go? I'll at least try to straighten out the meta one (which I added recently as it was getting lost... having meta here on the same page has advantages and disadvantages...) ++Lar: t/c 21:20, 21 June 2007 (UTC)
I shuffled things around a bit. Not done but take a look, I did quote, and chinese. if it's icky, revert, if it's good maybe take it the rest of the way for some of the other projects? ++Lar: t/c 21:48, 21 June 2007 (UTC)
I still think it is not in good structure. In my point of view, and regarding this page's high usage (that is how I find it) and its need for a better archiving system, it would be approprite to move towards either of the following two methods:
  • The loggin system, like the AfDs on English Wikipedia right now: PROJECT/DATE/TITLE
    Here the titles need not to be unique, because the DATE part makes the whole page address unique.
  • A more simple, yet sub-page based system: PROJECT/TITLE
    Here the titles should be unique. What you have done already is a way to make them almost unique: putting one of the account names in the title. (it is unlikely that a single account would be checked more than once, and even if it happens, it can still happen on the same sub-page).
What do you think? Huji 22:09, 21 June 2007 (UTC)
It is convenient for stewards to know at a glance whether there are other requests for the same project, so that one can process them all before removing local checkuser access. However, there's no need for a complex organization or instructions to do so. I suggest the format shown below, with headers like <user name>@<wiki name>. This is very flexible and simple to understand (examples below).
Contents
  1. Current requests
    1. Tom Thrampit@meta
    2. Billy Joe@test wiki
    3. Several users@enwiki
    4. Crosswiki
    5. Crosswiki
    6. A bunch of users on different wikis
    7. Pathoschild@en wikipedia
  2. See also
One thing to note is that organization is more difficult right now because there is a backlog. I'm very busy lately, but I'll be available again in two weeks or so to keep the page cleared. —{admin} Pathoschild 23:19:12, 21 June 2007 (UTC)
If you go with <user name>@<wiki name>, I recommend the username be one of the suspected offending usernames, not the one registering the request. It's been my observation that some editors handle many if not all of the CU requests coming from a project, so it's likely there would be duplicate headings if it's done with the requesting user. The offending users would almost certainly be unique, as any found to be sockpuppets would likely be permanently blocked. ~ Jeff Q (talk) 04:16, 22 June 2007 (UTC)
Pathoschild, I can also help with reorganization of the backlogs, if I'm allowed to. Huji 08:47, 22 June 2007 (UTC)
JeffQ: Yes, that is what I meant. I see no reason to organize by requesting user.
Huji: Feel free to edit or discuss any wiki page. :) —{admin} Pathoschild 12:32:19, 22 June 2007 (UTC)

(outdent) I grouped a few more. Since you have to edit the entire page to group, that's a good time to change to SockingUser@WikiName style headings (or SockingUser on WikiName which is how it is now) and next time I take a pass, I will. People are still adding at the top instead of at the top of the wiki's section though. What is our rule of thumb for archiving these? Note that commons and en archive inclusions but the individual requests, since they are on individual pages, never go away. ++Lar: t/c 12:38, 22 June 2007 (UTC)

I don't think grouping by wiki is the ideal solution; there are 713 Wikimedia wikis, and grouping by overarching project is not useful (since checkuser rights must be assigned by individual wiki). See my example above; my proposal is to use the user@wiki header format without grouping.
I'm not sure what you're asking about archiving. Once a request has been closed (whatever the result), it is archived to Requests for CheckUser information/Archives/<year>/01. —{admin} Pathoschild 12:48:24, 22 June 2007 (UTC)
I don't have a lot of investment into per-wiki groupings, whatever works is fine by me so using ungrouped but with both wiki and incident information, as you suggest, would be dandy too... Except for Meta itself.. I'm halfway thinking that it needs a local, separated page, which is structured more like commons, since the volume seems to be on the increase and Meta requests don't need stewards to address, all the others do. But maybe the volume increase I perceived is an abberation. As to archiving, that mechanism works fine but it's harder to find older cases later as the links given at the time of the incident go bad once the material is moved to an archive. Links to separate subpages never go bad. But separate subpages just are a lot of work in general compared to single pages. The one page mechanism used now is simple, which is a huge advantage, as it requires less complex instructions. Since many of the requesters are not speakers of English as a first language that is very important. ++Lar: t/c 14:53, 22 June 2007 (UTC)
Meta - I'm the aberration! I kind of agree with Larry - I think Meta maybe should be separate from the others. For the others I'm not sure. Useful to group in case a steward does one then sees another but time is also an issue. Keeping it simple is important - just look at what happens on wikis that are (allegedly) fluent in English, never mind those that are not! --Herby talk thyme 15:02, 22 June 2007 (UTC)

Per-wiki or not? That's the question.

I just reordered some of the requests, to the per-wiki style we have (marginally) agreed upon here. However, as you may notice, this has messed up the chronology of requests; e.g. the latest Ukranian Wikipedia request which is not yet answered, appears on top of many answered requests from other wikis. This will of course make it (at least a little) harder for Stewards to locate unanswered requests on this page. Because of this, I agree with Pathoschild's method. Any comments? Huji 13:26, 22 June 2007 (UTC)

I see what you mean about the chronology problem. Once some of the older requests are archived that might help. But as I say, whatever works. ++Lar: t/c 14:53, 22 June 2007 (UTC)
Regarding the discussion happened above, and to maintain the links after archiving, we can even shift ot subpage system, as I mentioned above. What is wrong with subpages? Huji 16:28, 22 June 2007 (UTC)
The subpage system makes maintenance a nightmare, causes complex bureaucracy that is difficult to understand and more so to remember (particularly for users not fluent in English), and makes archive search tools virtually impossible. It changes "Add a section below" to a multi-step procedure with templates, categories, and specific page names requiring a certain mastery of technical-fu. With all those disadvantages, the only advantage is that links are permanent— but only if the users remember to link to the subpage, not the section on the main page. A user who can link to the subpage can probably link to the archives, too. —{admin} Pathoschild 16:37:38, 22 June 2007 (UTC)
I'm not sure I agree with that last bit as one can link to a subpage while the incident is occurring, and the name doesn't change, but to link to the archive before the incident is archived is not possible, as the link changes once the item is archived. You and I have disagreed about whether that's a drawback significant enough to matter before though. In general I'm not a fan of archiving by moving, so that's a bias. But I do think that subpages here is vast overkill at this time. ++Lar: t/c 17:41, 22 June 2007 (UTC)
OK. So I'm satisfied that we are not going to move to a subpage-based organization. Nevertheless, the question remains unanswered, if we are going to follow the per-wiki method or the chronological method mentioned by Pathoschild. Huji 18:41, 22 June 2007 (UTC)

I've converted the page to a format that combines the advantages of both systems. Requests are split between Meta (for local checkusers) and other wikis, and the latter use headers in the form "user @ wiki". I've updated the instructions. How does that look? —{admin} Pathoschild 17:29:30, 23 June 2007 (UTC)

Great. Are we going to reorganize the archives as well (or at least 2007 archive)? Huji 17:56, 23 June 2007 (UTC)
No need; the benefit in doing so for the main page doesn't apply to the archives. Besides, it's interesting to see how things evolved when looking through old archives. —{admin} Pathoschild 02:36:56, 24 June 2007 (UTC)

Hey folks, I'll be happy to work with whatever system you decide to go with. But could you please discuss and decide before you make any more changes? I keep creating links to my open request to aid discussions elsewhere, and they keep getting broken by the repeated reorganizations. ~ Jeff Q (talk) 21:16, 23 June 2007 (UTC)

Sorry about that. I'll make sure to add anchors for older links next time. —{admin} Pathoschild 02:36:56, 24 June 2007 (UTC)

CU & IP blocks

I was going to ramble on the page but thought better of it. Many moons ago when I was a brand new admin on Wikibooks (& then a new CU) a 'crat on there (Derbeth) was patient enough to put up with my queries and taught me much. One of the things he did teach me was the transience of the Cu log. As a result I started placing 1 minute marker blocks on IP where there was a vandal or whatever but no real info. This (& the fact that I block creators of spam bot pages on sight) has allowed me to get info from the block log that would not be available from CU later on (or contributions in the case of spam pages deleted). This week an IP created a spam page on Books - there in the block log a previous offence which helped my block decision. There have been a number of occasions on Books where IP "memo" blocks have meant I am better informed on a second offence.

So, in six months time when we discover the moon is made of cheese and aliens have taken over part of the planet (I know which part!) these spam accounts will no longer be in the CU data. Why then would we not place even a short memo block that may be of assistance to others or ourselves in the future? I am going off wiki now but will return in the morning to find out why I am wrong! Regards --Herby talk thyme 19:18, 22 June 2007 (UTC)

Interesting. This seems a topic for the mailing list but marker blocks seem a good idea to me. ++Lar: t/c 00:08, 23 June 2007 (UTC)
I'll keep the tone neutral on this (!!) but - as far as I am concerned - when are we going to do the job properly? I nearly posted this in haste yesterday but decided to reflect - I have reflected and feel the same.
Of the spam acoounts checked on Meta recently three of the four IPs were open proxies (now blocked on Books & Meta). The job (in my opinion) is not done when the check is made. In a sense that is the start. I guess 50% of the time I've used CU on Books it has lead me to an IP that is, or will be found to be, an open proxy or similar.
I accept the fact that I appear to be rare in wanting to work on vandalism crosswiki and advise other wikis of troublesome IPs but this tool can be used far more effectively than merely running a check.
Even with this I still feel markers are appropriate but the job is not over when CU is done. I will go and put on my flak jacket now --Herby talk thyme 08:06, 24 June 2007 (UTC)
You're welcome to revive the MetaProject on open proxies; the local chapters split off when I got tired of doing all the work. This would be a good place to note open proxies you find with your checkuser access. (I typically only check whether an IP address is open if there is open-proxy-like behaviour, like frequently changing ranges.) —{admin} Pathoschild 16:50:50, 24 June 2007 (UTC)
I guess I will continue to do things as my instinct and experience directs me within the limits of the information available to me. Thanks --Herby talk thyme 18:18, 24 June 2007 (UTC)
Return to the project page "Requests for CheckUser information/Archives/2007".