Page MenuHomePhabricator

Make filling in the "reason" field for CheckUser checks compulsory
Closed, ResolvedPublic

Description

Author: sam.korn

Description:
It is currently not compulsory to fill in the "reason" field when doing a CheckUser investigation. This requirement would not be onerous on the user doing the check and would greatly aid oversight.


Version: unspecified
Severity: enhancement

Details

Reference
bz18613

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:33 PM
bzimport added a project: CheckUser.
bzimport set Reference to bz18613.

Can you put this on the CU mailing list?

roger.davies.wiki wrote:

Posted to the CU and [functionaries-en].

I would suggest a $wg variable with the default to off. While it's noble to want a reason each time, it doesn't seem reasonable to force non-Wikimedia wikis that have CheckUser installed to have someone type in a reason each time. Wikimedia wikis can, of course, set it however the sysadmins / community decide.

FT2.wiki wrote:

Nice idea. In any event, like other action pages, fields to prompt uers to enter useful information is a good idea. I would have 3 fields for quick entry (compare: delete/block):

"Source". (On-wiki request, WMF hosted mailing list, private request by an enwiki functionary, private request by another project functionary, private request by anyone else, personal observation, recheck existing case, audit, other);

"Case". (Or wikilink to page, etc)

"Other info".

This is comparable to the block and delete pages, that have a dropdown box and also a box for "other information". In this case adding a dropdown box for "source", which is extremely useful for review.

mike.lifeguard+bugs wrote:

(In reply to comment #4)

Nice idea. In any event, like other action pages, fields to prompt uers to
enter useful information is a good idea. I would have 3 fields for quick entry

Oh, please no! One reason box is enough - /maybe/ a dropdown of predefined reasons could be useful in some cases (if optional). Your suggestion is pure bloat - just put it in the reason field.

Perhaps not compulsory, but a reminder, similar to the gadget on EnWiki?

FT2.wiki wrote:

(In reply to #5)

Have you checked the pages for blocking and deletion recently? These have multiple fields, and while none are compulsary, they do speed up entering useful information and (as Avi says) serve as a reminder.

Blocking for example - "Reason" and "Other/additional reason" (and a name field, 2 time fields, and 6 checkboxes).

Or deletion - "Reason for deletion" and "Other/additional reason".

Checkuser is a privacy based function, where fewer eyeballs see them, and accordingly a higher standard of checkability is needed. An edit with no edit summary is not much of an issue. A check lacking a clear explanation is different. A couple of optional fields to both prompt users to enter that data, and standardize it for ease of review, would be good. Not every project needs it, but some may wish to have it.

herbythyme wrote:

Per Mike - most CU checks on non en wp wikis are pretty straightforward - multiple reasons are (IMO) unecessary. However I fully agree that there should be a reason - I consider those who do not leave a reason very unhelpful to their fellow CUs.

The check and report code is duplicated in four places, which always makes me assume something'll break at some point. :)

Perhaps the check should be centralized, if it's common to all our submissions?

Duplication removed in r51040

Is this working as intended? I've come across some checks on en.wiki that did not have a reason filled in, and even accidentally submitted one myself.

Maybe because there is on $wgCheckUserForceSummary set on enwiki?

Ah, so it's one of those cases where the functionality gets created and then we have to file a separate site request to actually get it turned on?

Reopened - for some reason, this isn't working as intended even though wgCheckUserForceSummary was set to true on enwp in bug 27078.

(See https://secure.wikimedia.org/wikipedia/en/w/index.php?title=User_talk:Reedy&oldid=433048205)

After speaking with Aaron Schulz, the problem appears to be local config; re-closing; re-opening bug 27078.