Talk:Oversight policy/Archives/2010

editorial reason/disrupt edit histories

Hi! What does that mean: editorial reason/disrupt edit histories? Some stewards read it as: If an account, even if it contains a libellous user name, has edits, we should not even hide its user name because edit history could look strange. But that's what Oversight is for: Removing disruptive user names so that they do not appear again (in books/whatever). With new interface RevisionDelete edit histories, imho, can never get disrupted by simply hiding a user name. Revisions are not any longer permanently removed. So also not useful revisions by bad user names. If we now hide bad user names, we have to decide whether we also should oversight their revisions or not. But we of course always should hide their names. So could we please specify both policy parts so that bad user names should always be hidden? And we just have to keep an eye on suppressing revisions' contents. Kind regards, —DerHexer (Talk) 21:53, 12 May 2010 (UTC)

I agree with DerHexer. I don't buy that a hidden name is disruptive to edit histories, and I see no compelling reason to keep them there. Is anyone going to be so outraged or confused by it? --Shanel 21:56, 12 May 2010 (UTC)

I also agree with DerHexer --Nolispanmo 09:55, 14 May 2010 (UTC)

---

Any other comments? Otherwise I'd remove that part. —DerHexer (Talk) 18:52, 23 May 2010 (UTC)

I don't think I've ever seen an example of how hiding a username would disrupt edit history. I cannot think of how that would be possible. Unless someone can actually find an example, I consider it to be a nice thought experiment rather than something that can actually happen. Accordingly, I see no reason to keep it in the policy.  — mikelifeguard@meta:~$  19:13, 23 May 2010 (UTC)

Criterion #4

Hi! I think that criterion needs to be updated now with enabled RevisionDelete for sysops.

Hiding of blatant attack names on automated lists and logs, where this does not disrupt edit histories. A blatant attack is one obviously intended to denigrate, threaten, libel, insult, or harass someone.

In my opinion the part where this does not disrupt edit histories should be removed, user names can never disrupt edit histories, confer section above. And I think that not all user names which in any way harass etc. someone should be oversighted. Sysops now can remove user names from edit histories and logs so that normal users are not any longer able to see them. So just those user names should be hidden which also sysops should not see. That would include, imho, libel as OSP §2 mentions it. So what do you think would be better to do? To specify §4 like

PART A Hiding libellous user names on automated lists and logs. (Any explanation?)

or merging with OSP §2 to something like:

PART B Removal of potentially libelous information either: a) on the advice of Wikimedia Foundation counsel or b) when the case is clear, and there is no editorial reason to keep the revision. Instead, libellous user names should always be oversighted.

Kind regards, —DerHexer (Talk) 09:49, 24 May 2010 (UTC)

Comments in favor of PART A

Comments in favor of PART B

1. —DerHexer (Talk) 10:13, 24 May 2010 (UTC) I prefer this one. Makes it short and simple.

Against either change

Comment I'm a bit skeptical about this. First of all, there is no "hideuser-light" option for admins. So blatant attack names that may be hidden under the current oversight policy, but may only be hidden from non-admins in this proposed policy, are still visible on Special:Listusers and other public lists.
Secondly, these usernames come from a very limited set of vandals. They are intended to insult specific users, though it can't be ruled out that they contain personal information. It's not always easy to tell if a username potentially contains personal information. E.g. "XY is a gay ass" can both be interpreted as an insult and as personal information. By hiding all of those usernames, we don't reward the vandal by giving him too much attention and careful weighting the possibility of the username containing personal and/or libelous information up. With the proposed change, the border of what to oversight gets more vague, like it has been before introducing #4. (E.g. where exactly is the border of "libelous information"? Is it only wrong allegations, or also attacks like "XY is an asshole"? English is not my mother tongue, so this might be a reason for my incertitude, but I think in general the term is vague)
I understand that there are good reasons for this change, but I think it will result in more work for oversighters and a less precise and clear definition of OS application. Kind regards, --Church of emacs talk · contrib 11:14, 24 May 2010 (UTC)

Hideuser-light at least is planned by vvv. But it's of course expected when it's done.
And I don't see the point why removing some possibilities to oversight something would result in more work for oversighters. Now the words denigrate, threaten, insult, and harass are neither clearly defined. If that means that every bad user name should be oversighted, it would result in much more work for them. And I neither understand why those user names should also be hidden from sysops; there are plenty more sysops which can remove such user names, and oversight should only remove the worst ones. Kind regards, —DerHexer (Talk) 11:22, 24 May 2010 (UTC)

Please do not design policies on the premise of a software feature that hasn't been even implemented. As numerous examples show, such features can take much longer than one would expect them to.
As for the amount of work: Hiding usernames is a quick process. Pondering if a username qualifies for oversight with an unclear policy takes time, especially if you have to consult other oversighters.
Perhaps the solution is optional oversight: Blatant attack names may be hidden, but RevisionDelete-light by admins also suffices. This gives oversighters a broader scope of discretion and speeds up the process, both by enabling sysops to help out and by eliminating the need of too careful considerations (which give vandals more attention than they deserve) and uncertainties whether a username qualifies for OS due to personal/libelous information. --Church of emacs talk · contrib 11:38, 24 May 2010 (UTC)

ad 1) Of course not, which is why §4 was implemented—not knowing if and when RevisionDelete will be enabled for sysops.

ad 2) True, without having fixed bugzilla:20189 removing user names from edit histories needs much more time than simply checking one field on Special:Block.

ad 3) Well, that should always be done when oversighters are not immediately available on IRC/whatsoever; first removing the problematic information and then contacting the oversighter. But I do not think that all sysops would do contact them then, that neither happens here on meta when sysops (resp. stewards) remove bad entries from Special:Log/globalauth with revdel-light. I nearly never was pointed on that, I regularily had to clean up the log.

But it's still not clear why harrassing or insulting information should be hidden from sysops; they regularily have to deal with them on deletions, rollbacks etc. Kind regards, —DerHexer (Talk) 11:48, 24 May 2010 (UTC)

Basically I support the proposal, but I'm not sure if it is good to replace the oversight process to sysop-level hiding, globally in particular. Some Wikipedias have over a thousand sysops and letting them share someone's personal information, instead of only dozens of oversighters may a huge change and unnecessary disclosure: most of them are anonymous and their identifications are even not known by the Foundation. --Aphaia 12:39, 24 May 2010 (UTC)

That request is just for insulting/libellous user names. User names which contain personal information should of course oversighted. —DerHexer (Talk) 12:42, 24 May 2010 (UTC)

Thanks for your clarification, so I seconded. While we have a risk of too lengthy documentation, I prefer to have what should be subjected to oversight on the same document, avoiding such confusions. --Aphaia 19:53, 24 May 2010 (UTC)

Public or non-public personal information

A request for comment has been open which might be of interest to this page.

Sincerely,

Virgilio A. P. Machado

Vapmachado 23:00, 26 July 2010 (UTC)

Removing private information, that users published themselves?

Hi. In the German Wikipedia Oversight team, we had some discussions, when users wanted information oversighted, that they had published themselves. There are basically three categories of cases where this happens:

1. By accident. For example, the user forgot to log in. In some cases, this allows conclusions about the work place and other private information.
2. By reconsidering. If the publication of the private information was some time ago, people might reconsider. Special case: Users who were underage when they published the private information.
3. By aggregation. This is perhaps on the borderline of belonging on this list, but sometimes users publish information that – on it self – is harmless. But when it is aggregated and evaluated, the resulting information is considered private. A classic example is a user creates an account with his real name, then abandons this account for a new one with a fake name. A connection of those user accounts (due to the similarity of the contributions) could be considered a private information.

The policy states that it is okay to remove "non-public personal information such as […] identities of pseudonymous or anonymous individuals who have not made their identity public, or of public individuals who have not made that personal information public."

So, if you interpret the policy very strictly, none of the above cases would allow Oversight. What do you think – should we allow oversight in (some of) those cases? Regards, --Church of emacs talk · contrib 00:14, 17 September 2010 (UTC)

Accidents (like revealing IPS) are currently oversighted; see e. g. w:Wikipedia:Oversight#Policy and s:de:Benutzer_Diskussion:DerHexer#Deine_Versionsl.C3.B6schung. I'd also say: Better safe than sorry, but policy should be clearer. Kind regards, —DerHexer (Talk) 00:19, 17 September 2010 (UTC)

ACK to DerHexer (case 1.) From my point of view the „big points” to clarify are 2. and 3. In some cases it could be a big problem for the user, if we do not execute an OS because of the strict policy. Right now we discuss every single case to do the best for wp and the user. Kind regards, --Nolispanmo 07:24, 17 September 2010 (UTC)

On a related issue, could you please, ladies and gentlemen, state your opinion on the request for comment that was open July 26, mentioned above? You may want to use a statement like: "Information available in the history of a user's page and elsewhere on any Wikimedia project is public, i.e., it is covered by the same content rules that apply to all Wikimedia material." If you want you could also use one of the available icons to represent your opinion before signing. I hope that is not asking too much and does not represent a heavy burden on the dedicated voluntaries that so altruistically donate some of their valuable time to this well deserving endeavor. Sincerely, Virgílio A. P. Machado. Vapmachado 15:29, 17 September 2010 (UTC)

Case 1: I have no problem oversighting such accidents, if the user sends a request quickly. I'd have a problem beeing asked to remove hundereds of versions if somebody asks for an oversight weeks, months or years after his accident.
Case 2: Difficult: The later somebody reconsiders his descision to public private information, the more versions might be affected and the more mirrors or wayback-machines may keep the information anyway. In worst-case we could oversight hundreds of versions for (almost) no effect. Users should take responsibility for their descisions; oversighters are not personal cleaners for anyone's youthful sins. However, we should consider an oversight if few versions are affected by weighing up the damage for wp and the user by either execute or not execute an oversight.
Case 3: I'm afraid there is no alternative to discuss every single (and rare) case do the best for wp and the user. Best Wishes, --Superbass 19:48, 17 September 2010 (UTC)