As another EnWiki admin/crat/cu/os, I would also appreciate the enhancement that Will suggests.

william.wiki.admin wrote:

I discussed this bug in the admins channel, and User:Ponyo, another en.wiki checkuser (albeit without a bugzilla account), would welcome this simple amendment.

WH.

Taking this bug.

Setting importance to low (the bug merits any attention, without having severity priority).

Adding shellpolicy keyword. We discussed the issue on IRC, Will H is going to ask on the checkuser mailing list an advice, and will summarize here the reply.

I am a checkuser on the English Wikipedia. I too would welcome this improvement.

How long are these logs being referenced?

william.wiki.admin wrote:

Could you clarify, MZMcBride? Not quite clear what you mean. Thanks.

neil wrote:

Yes please (I'm QuiteUnusual, a CU on en.wikibooks) - would be beneficial.

I think I have implemented it.

Added a label "recent user checks" so you have now:

User Test5 (talk | block | block log | uploads | logs | deleted user contributions | user rights management | check user IP addresses | recent user checks)

it's working now on my test wiki

william.wiki.admin wrote:

Yep, it is indeed.

WH.

marcin.cieslak@gmail.com 2012-06-14 14:05:52 UTC CC >marcin.cieslak@gmail.com
Assignee dereckson@espace-win.org marcin.cieslak@gmail.com

Dear Marcin Cieślak,

The bug tracker assignee field means "I'm working on this feature".

When you remove another person to put your name instead, it's like you enter in a room, you remove the seat under someone, push this person aside, then site back.

The correct behavior when a bug is assigned to someone is:

(i) check with the assignee if he's still working on the bug ("Taking this bug." at 11:04 UTC would probably means yes)

(ii) if really you want to take over an issue, to avoid to duplicate the work and play a race instead, you can politely ask to the current assignee where he's on the bug resolution, and organize the relay if needed

(iii) alternatively, the community will frown a little less if offer a patch to show your work

That will avoid what you're doing currently: telling someone "drop your code to the trash bin, I've miiiine instead!"

I think with these tips, you will contribute to a nicer development community.

I am really really sorry for jumping in and changing the assignee field.

I did that after I tested the bug (big thanks to the original submitter!)

Here's the (trivial) patch:

https://gerrit.wikimedia.org/r/#/c/11294/

I should have posted this instead of playing with bug's metadata.

(In reply to comment #0)

It would be welcomed to update the list of links concerning the target user
which one sees via Special:Contributions, that are (for me, as an en.wiki
admin/crat/cu/os):

(talk | block | block log | uploads | logs | deleted user contributions | user
rights management | rename user | oversighted contribs | filter log | check
user IP addresses)

I would like to see the addition of a link to Special:CheckUserLog, showing the
given user as the target in the CU logs <snip>

I think there are already too many links in the Special:Contributions list header.

It would be better to have such records showing up directly on the footer of Special:CheckUser/<Username>, just like Special:Undelete or Special:BlockIP.

I agree, but that should be another bug ("Redesign Special:Contributions links"). Putting this under Special:CheckUser misses the point as the whole point of this feature (to me) is to allow to quickly go into Special:CheckUser (and now Special:CheckUserLog as well) without having to re-type/paste the username.

There is an interesting proposal to fix this with the additional special page:

https://bugzilla.wikimedia.org/show_bug.cgi?id=22516

(In reply to comment #6)

Could you clarify, MZMcBride? Not quite clear what you mean. Thanks.

Sorry, I was asking how often CheckUsers look at the CheckUser log for a particular user.

This relates to how important it is to further clutter up the user interface and it also relates to whether the use of the log in this way is appropriate.

Will speak for myself only (on plwiki).

If there is a request for checkuser check from members of our community (whether on IRC, village pump or one of the mailing lists) I *always* check the log file first before checking target users' IP addresses or usernames.

I do this to find out if another plwiki CU has already started to deal with this problem - if so, my check might be redundant.

This way I intend to look *less* at the *actual* CU data (IP addresses vs usernames). Checking the log first is less evil in terms of invading someone privacy (in my opinion).

So actually I my workflow looks like this:

1. Special:Contributions
2. Special:CheckUserLog
3. (optionally) Special:CheckUser

(In reply to comment #14)

(In reply to comment #6)

Could you clarify, MZMcBride? Not quite clear what you mean. Thanks.

Sorry, I was asking how often CheckUsers look at the CheckUser log for a
particular user.

This relates to how important it is to further clutter up the user interface
and it also relates to whether the use of the log in this way is appropriate.

Although it would vary from check to check, the log is used often enough. I would say I consult it in about one in six checks, though that is a *very* rough estimate.

william.wiki.admin wrote:

Yes, something like that. It is an ideal way of checking to see if another CU is working on it and determining any other factors relating to its progress or history.

Note that we still have a link to oversighted contributions in those links. Not that I am necessarily advocating for its removal, but if we're talking about redundant clutter, what's the point of linking to a deprecated extension which hasn't been used for 18 months?

MZMcBride, perhaaps you might clarify, but I'm not quite sure what you mean by "whether the use of the log in this way is appropriate", as its use as discussed here in determining the date and nature of checks made is the inherent purpose for which it was designed.

WH.

(In reply to comment #17)

MZMcBride, perhaps you might clarify, but I'm not quite sure what you mean by
"whether the use of the log in this way is appropriate", as its use as
discussed here in determining the date and nature of checks made is the
inherent purpose for which it was designed.

There's an open question about the CheckUser log. It currently keeps the full log indefinitely, but the log contains a large amount of private information. Whether keeping this log around indefinitely is a violation of particular privacy policies (e.g., the Wikimedia Foundation's) is an ongoing discussion.

This open question is largely outside the scope of this bug, except that by adding an interface link, you're institutionalizing the questionable practice of keeping and referencing these logs indefinitely, in my opinion.

This log only contains the fact of the IP check, not the result of the check, so I think it doesn't contain private information if you use it correctly (you set the summary before the check), especially if you filter the log to a certain person (than you don't see the IP addresses checked immediately after the check of the user).

E.g: "Date, User:Hunyadym asked for the IP addresses of User:Iamthevandal (per CU request page, possible abuse of multiple accounts)"

william.wiki.admin wrote:

MZMcBride is clearly referring to the fact that if "WilliamH got IPs for WilliamH", and then the next logged action is "WilliamH got edits from 127.0.0.1", it is rather obvious that 127.0.0.1 is my IP address, and that remains in the log indefinitely.

Still, the link in its suggested form in this bug file still only links to instances of the username and the username along having been checked, for purposes that have already been described.

(In reply to comment #20)

MZMcBride is clearly referring to the fact that if "WilliamH got IPs for
WilliamH", and then the next logged action is "WilliamH got edits from
127.0.0.1", it is rather obvious that 127.0.0.1 is my IP address, and that
remains in the log indefinitely.

I've filed this as bug 37626. I consider it a blocker to implementing this bug, but I won't force the issue.