Jump to content

Wikipedia talk:Oversight/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 5Archive 6Archive 7

Screenreader users sometimes choose to be presented with a list of links separate from the page, with only the link text leading to the URL. With that in mind, "as described here" to lead to another page looks like poor wording because of the ambiguity of "here". (Even in context, it's not immediately clear whether "here" refers to the link target or to the page the link text is embedded in.) Would there be consensus in rewording for clarity, eg by making the whole note read "Note: The suppression team does not respond to threats of harm. [[Wikipedia:Responding to threats of harm|Report a threat of harm to yourself or to others]]."? The Crab Who Played With The Sea (talk) 21:25, 14 November 2022 (UTC)

I have reworded to make it more clear there is a link there, and where it points. Primefac (talk) 09:53, 15 November 2022 (UTC)

Email response

Hi there. On 10 February, I was erroneously blocked by administrator Daniel Case, who subsequently reverted the block: https://wiki.riteme.site/w/index.php?title=Special:Log&type=block&page=User:Bastun

After a request from administrator Alison, he subsequently RevDel'ed the block, and requested oversight of the block, but then reported that it couldn't be oversighted and shouldn't have been RevDel'ed, and reversed that. (See https://wiki.riteme.site/wiki/User_talk:Bastun#Block )

As I have been editing here for over 15 years without a block, and had a clean block record until now, I am obviously not happy about this.

Note also the provisions of the EU's General Data Protection Regulations. Included in the seven principles of GDPR are two that are very relevant: a) the requirement for *Accuracy* (and the consequent right to have incorrect information amended or deleted!); and b) the principle of Accountability (which means that Data Controllers need to ensure that they not only comply with the principles, but also have appropriate processes and records in place to demonstrate compliance.)

Other jurisdictions have similar laws in place. See https://www.dataprotection.ie/sites/default/files/uploads/2019-11/Guidance%20on%20the%20Principles%20of%20Data%20Protection_Oct19.pdf for the Irish Data Protection Commissioner's interpretation of the GDPR.

While my preference would be for the block to be fully oversighted in the logs, I would accept Revision Deletion if the former isn't possible, and would now like to formally request that one or the other is done.

Please note my bringing up GDPR is *not* a legal threat and I have no intention of bringing this issue up with anyone outside Wikipedia/the WMF.

Kind regards, BastunĖġáḍβáś₮ŭŃ! 18:19, 28 February 2023 (UTC)

P.S. I am posting this here because my email of 13 February (sent to user "Oversight" via wiki page) has still not received an acknowledgement or a response (which may be my issue, I don't know), and I have just warned another user that they may breach 3RR. I would appreciate a reply either here or by email, either works, but I would like a response. BastunĖġáḍβáś₮ŭŃ! 18:19, 28 February 2023 (UTC)

@Bastun for anything you want acted about "GDPR" or any other sort of governmental law or regulation you must contact meta:Wikimedia Foundation Legal department (the legal@... email address or the Registered Legal Agent physical mail address). As far your notes above, it is correct that logs should almost never be removed. See Wikipedia:Revision_deletion#Log_redaction. If there was a "bad" logged action, transparent proof of that is used to hold administrators making such an action accountable. — xaosflux Talk 18:34, 28 February 2023 (UTC)
Also, a response to your last email about a ticket ending in ...625 was sent on 20230213T1222. — xaosflux Talk 18:48, 28 February 2023 (UTC)
I'm not an oversighter, and don't know what either of you have said to each other. The log clearly shows that you were mistakenly blocked, and there's no reason to think that's inaccurate. If anyone holds that against you, which would seem highly unlikely, then they're an idiot. I myself have a block log, which I encourage you to peruse, and it hasn't affected me one bit. There's lots of highly respected people roaming around with erroneous block logs. We even have a userbox, Template:User accidentally blocked, so you can wear it with pride. -- zzuuzz (talk) 19:31, 28 February 2023 (UTC)
Jimmy Wales blocked you?? Good grief - that's quite the war story indeed! I'd no idea that happened - Alison talk 19:44, 28 February 2023 (UTC)
Hi Xaosflux, thanks for the quick response. I see there is a response in my inbox, which, annoyingly, went into my spam folder. Thanks for the link, too, to RevDel - I'll have a read later (late for a meeting!) BastunĖġáḍβáś₮ŭŃ! 19:59, 28 February 2023 (UTC)
I've got my own 3RR/oops lets reverse that - block in my block log from waaaay back in 2006! — xaosflux Talk 20:09, 28 February 2023 (UTC)
I'd also like to point out that the GDPR accuracy principle mentioned above is in fact being met: the block log accurately shows that you were blocked, and then unblocked. The unblocking admin also pointed out in their unblock that the block was a mistake, satisfying the requirement for amending incorrect information. GeneralNotability (talk) 22:51, 28 February 2023 (UTC)
Heh, thanks, zzuuzz - I am now en-templated! ;-) Cheers, BastunĖġáḍβáś₮ŭŃ! 12:00, 1 March 2023 (UTC)

Edit filter to block additions of phone numbers

Per Wikipedia:Edit filter/Requested/Archive_21#Telephone numbers added to articles I created Special:AbuseFilter/1244 with the goal of blocking new users from adding phone numbers, which is a persistent problem. I think having a filter to block phone numbers is a massive improvement on the status quo, which is that these phone numbers often don't get reverted in a timely fashion, and even if they do, they are almost never suppressed (or even revdelled).

But the since the logs of the filter are visible to all admins and a small number of (trusted) non-admins, this does create somewhat of problem since the filter collates a list of material most of which should in theory be suppressed (Special:AbuseFilter/247 might have a similar problem). To be clear, the filter doesn't make the content more visible, but it does collect it in one place. Until phab:T290324 is done there's no way to set the logs to be only visible to oversighters. So I'm wondering if y'all oversighters think it's fine for me go ahead with trying to make this into a disallowable filter, or if I should wait until there's a way to hide the logs more (or I suppose we could have a bot automatically suppress the logs).

(@HJ Mitchell: since it seems he suggested using trying an edit filter for this purpose.) Galobtter (pingó mió) 21:02, 5 April 2023 (UTC)

@Galobtter a phone number alone somewhere is not necessarily suppressible, it depends on what kind of number it is and what context it is used in, so I'm not too worried about this (especially with the current state being these get published, then maybe revdeled, then OS is requested). This would be one of those logs I'd expect admins to patrol, block users as needed, and still report to OS as needed. — xaosflux Talk 21:11, 5 April 2023 (UTC)
Thank you for trying this out, Galobtter. Something to keep in mind is that phone numbers come in a wide variety of formats and configurations, ranging from six to more than a dozen digits. I don't think it's realistic to think it possible to filter out phone numbers without messing up other legitimate uses of number strings. Sometimes the creation of a filter gives a false sense of security that an issue is being addressed. I'm also concerned that oversighters may have to review those filter actions to verify that they're actually removing a phone number rather than either a valid string of numbers, or a completely random one that wouldn't qualify for suppression. Just FYI, one of the most common places to find telephone numbers is in edit summaries; I think that might actually be richer territory, since we don't see nearly as many valid number strings in edit summaries. Just a thought. Risker (talk) 21:38, 5 April 2023 (UTC)
Thanks for your thoughts, Risker. Regarding I don't think it's realistic to think it possible to filter out phone numbers without messing up other legitimate uses of number strings.: of course, without a human checking every edit it's impossible to perfectly distinguish these cases, but my goal is to catch most phone number additions while rarely stopping other use cases (in general you'd want a disallow filter to have <1% false positive rate); I wouldn't have come here if I wasn't reasonably confident that what I had could become a disallow filter. Currently what the filter does is look for phone numbers that have a combination of numbers and spaces; while dashes are of course often used in phone numbers, that often conflicts with dates, and most of the phone number additions seem to be from South Asia/outside of the U.S., where it a lot less common to use dashes in phone numbers. The most common false positives I found here were in links, citations, and files, so the filter excludes edits involving or adding those.
With all that done, currently my estimate is that ~90% of the edits caught by the filter are phone numbers, ~10% are number vandalism, and small percent remaining is false positives, which is pretty good IMO. Since the edits would not be suppressed by the filter, I don't think oversighters would need to review the filter actions. Also, I did look at summaries too, but this does require some work since reverts often include the revision ID in the edit summary, and there are other reasons revision IDs appear in the edit summary too. Galobtter (talk) 06:47, 10 April 2023 (UTC)
Perhaps take a look at this filtered edit, which is a good example of what would concern me. I'm reviewing the flagged revisions right now, and that one was at the top of the list. Not sure how you'd get around that, will leave it to your considerably greater knowledge. :) Risker (talk) 03:22, 11 April 2023 (UTC) Also this one. These two were from the first 10 completed edits noted in the log when I opened it. Risker (talk) 05:38, 11 April 2023 (UTC)
As it always seems, the moment I talk about a filter, it keeps running and seems to produce all the false positives :) Thanks for looking through the filter hits; I excluded the examples you gave and others by excluding any number additions inside templates or tables. This didn't seem to produce much false negatives. I think the frequency of numbers in running prose is a lot less, so hopefully this works better. Looking at the filter again though, the number of true phone number additions in articles per day does seem pretty low; there are more talk page additions but a surprisingly high number of them seem to be now stopped by Special:AbuseFilter/1245 (with the caveat that about 15% of the hits are suppressed so I can't see all the true positives). Galobtter (talk) 19:47, 11 April 2023 (UTC)
As a potential test case, here is a rare good-faith edit which might be mistaken for phone spam. Certes (talk) 14:31, 11 April 2023 (UTC)

Voluntary self disclosure by adults

Not related to any specific case, just something that's been on my mind. To what extent should we be suppressing personal information that adults voluntarily disclose about themselves? We obviously act with extreme prejudice with personal information that children disclose about themselves (because we presume they don't realise the potential consequences) or which is inadvertently or improperly disclosed about adults, and rightly so. But where an adult (or someone we presume is an adult) discloses information, should we routinely suppress it? Does this hold for all types of personal information? For example, should we treat a generic webmail address (eg randompseudonym@gmail.com) the same as a physical address; an address the same as a phone number? My general impression is that we suppress most of this type of thing. My personal opinion is that perhaps we're a little over zealous and that, in general, if someone discloses personal information/contact details we should err towards leaving it unless they ask for it to be removed but I'd be happy with any consensus that emerges. HJ Mitchell | Penny for your thoughts? 19:03, 13 April 2023 (UTC)

My opinion, and one that I am reasonably confident is shared as general consensus amongst OSers, is that we assume that someone posting their personal information (email, phone, address, etc) are not aware how problematic such an edit can be, and thus we remove it for their own good. If they re-add, or otherwise question why the removal was done, and thus indicate that they are aware/cognisant of the issues, then there is no issue. In the half-decade I've been doing this, I can think of less than a dozen times in which this has happened (and it's usually minors/students who make this claim). Given the huge rise of harassment I've seen (doxxing and the like) in the last year or so, I would be extremely hesitant to have anyone's personal email be any more visible than strictly necessary. Primefac (talk) 19:10, 13 April 2023 (UTC)
Related, it also depends a bit - as it is hard to tell if what someone posts is actually their personal info, or just some personal-looking info. — xaosflux Talk 20:26, 13 April 2023 (UTC)
It may also be an unwitting third party's personal data, in which case it seems more important to remove it than data willingly shared by its owner. Certes (talk) 22:33, 13 April 2023 (UTC)
If it's indeed the case that adding emails is generally undesirable anywhere on Wikipedia, then we should extend Special:AbuseFilter/247 to all namespaces - I even tested this at filter 877, if people want to see the kind of edits that would block.
This practice does seem reasonable to me, since we also don't know if people are actually posting their own phone number/email, or someone else's. Galobtter (talk) 23:39, 13 April 2023 (UTC)
I think (email) addresses, phone numbers, etc fall into four categories:
  1. Personal information with is disclosed maliciously. This should very nearly always be suppressed (the rare exceptions will be things like avoiding a Streisand effect).
  2. Personal information which is disclosed without apparent appreciation for the consequences. This should usually be suppressed but exceptions are possible.
  3. Personal information which is intentionally disclosed with (apparent and/or believably claimed) appreciation for the consequences and no suspicion of wrongdoing. This should not normally be suppressed.
  4. Publicised contact information - for example contact details for companies, agents, etc. This needs considering on a case by case basis, but where it is determined that it shouldn't be in the encyclopaedia simple removal will usually be sufficient and revision deletion is enough for some of the rest but it is not impossible some may need suppression.
If it is unclear which category something falls into then we should generally (always?) treat it as being the highest it could be. Thryduulf (talk) 00:29, 14 April 2023 (UTC)
  • The historical interpretation as long as I've been an OS'r and when I was an admin/working in NPP was that we assume new editors don't know how the project works, and as such will suppress since release of information requires consent, and if you don't know how the software works and its implications to your privacy, that consent is difficult to give. In other words, I agree with Primefac. TonyBallioni (talk) 01:01, 14 April 2023 (UTC)

Email additions from new users

People's thoughts would be appreciated at Wikipedia:Edit_filter_noticeboard#Expanding_247_(email_additions)_to_all_namespaces?. Galobtter (talk) 07:47, 15 April 2023 (UTC)

Delete account

Moved from Special:Permalink/1151653269

Can you please explain how can someone delete their wikipedia account and request you to remove all of their data? Kicmenamozdina (talk) 10:57, 25 April 2023 (UTC)

Unfortunately, our software currently does not permit deletion of accounts. However, it does not hurt anything to leave accounts unused; you may simply stop using the account.
If you wish to remove your email address from your account, you can unset it at Special:ChangeEmail. If you wish to remove your userpage, please add {{Db-userreq}} to the page (including the brackets), and one of our administrators will delete the page. If you wish to rename your account, please see the instructions at Wikipedia:Changing_username. Additionally, you might qualify for the right to vanish.
If there is personal information on another page that you wish to be removed, please email the Oversight team.
Otherwise, all you have to do is stop logging into the account. I hope this answers your question, and I am sorry to hear that you have decided to stop contributing to Wikipedia. If you wish to return, you may simply begin using the account again.
If there is anything else we can help you with, please let us know. Best regards, and thank you for using Wikipedia. Primefac (talk) 11:34, 25 April 2023 (UTC)

When it is too late

I got a question? How long until it is too late to get oversight for example, you forgot log in. It happened to me once in November 2021 but I didn't know about this until a year later then I was told it was too late when I requested it? Cwater1 (talk) 14:32, 1 July 2023 (UTC)

"Generally within the last three months", from [note 2]. Primefac (talk) 14:34, 1 July 2023 (UTC)
I see now. It would probably be hard to two and two (IP and User) together considering it was one time. Next time, if I accidently forget to log in and edit, then I should request oversight as soon as possible. Cwater1 (talk) 14:37, 1 July 2023 (UTC)
Correct. These days IPs are rarely static, so two edits spread a year (or more) apart are very unlikely to be connected. Primefac (talk) 14:49, 1 July 2023 (UTC)

Discussion at Wikipedia:Village pump (policy) § Redirects involving BLP privacy issues

 You are invited to join the discussion at Wikipedia:Village pump (policy) § Redirects involving BLP privacy issues. user:A smart kittenmeow 21:08, 24 September 2023 (UTC)

IP addresses

can Wikipedia delete some ip addresses on Wikipedia? 155.137.27.93 (talk) 19:57, 26 October 2023 (UTC)

Potentially. Please email the Oversight Team with your request. Primefac (talk) 20:09, 26 October 2023 (UTC)

Protected edit request on 3 November 2023

Please add a line along the lines of 

This address should only be used for requests to oversight content '''on the English Wikipedia'''. For other wikis, check the local oversight or suppression page.

Since it seems that some users accidentally send their requests here when it is intended for other wikis. Happy to share examples with the OS team if needed. DannyS712 (talk) 21:12, 3 November 2023 (UTC)

 Done Primefac (talk) 21:18, 3 November 2023 (UTC)

All oversight blocks are indef

At the moment all oversight blocks are indefinite. In ~95% of the cases this has seemed appropriate to me. Indefinite is not infinite and in most cases the behavior is so egregious or so repeated that indefinite feels like the right way to stop disruption. Once in a while it feels like too much and sometimes I think the fact that we only do indefinite means we don't block someone, because it feels like a disproportionate response, or we let a problem get worse that a shorter block applied more quickly may have stopped. I am wondering if this practice of the OS team should be reconsidered. Barkeep49 (talk) 14:31, 1 March 2024 (UTC)

I assume this wouldn't apply to oversight blocks of IP addresses? GorillaWarfare (she/her • talk) 14:46, 1 March 2024 (UTC)
Some points:
  • GorillaWarfare is correct, OS blocks of IP addresses are normally short. Dependent on multiple factors, they can sometimes be as short as a few hours, although most will run a few days or weeks. They are preventative blocks, but the time limit recognizes the ease and frequency of IP lease turnover.
  • Oversight blocks weren't a thing at all until a random admin overturned an indef block made by an oversighter. The block had been made because the (long-time, popular) editor had repeatedly published material that had required suppression. The admin thought the blockee had been punished enough. The blockee then promptly republished the material that required suppression. The admin involved failed to recognize that the point of the block was preventative, not punitive.
  • Oversight blocks of named registered accounts *should* be indefinite. The entire purpose of these blocks is preventative. They aren't lifted until the blockee demonstrates understanding that the blockable actions were a policy violation, and the blockee also agrees not to republish that material. Some OS blocks last about as long as it takes for someone to post "Oh geez, didn't realize that was not publicly known, my apologies, won't happen again, sorry!". Others haven't been lifted ever. In fact, most of them haven't been lifted.
  • I can't think of a case where there would be a limited-duration OS block of a named registered account. Is there any reason to think that a blockee has understood the reason for the block and the nature of the violation, and has agreed not to repeat the OS-blockable offense? Those things don't happen on a clock, they happen when they happen, whether in a few minutes or never. A time-limited OS block just sounds punitive to me, and doesn't do anything to prevent further identical problem editing/behaviour.
  • Oversight blocks are rare. Very rare. With the exception of limited-duration IP blocks, they are always reviewed promptly by the OS team, and lifted if determined to be inappropriate, regardless of how much time has passed. There are almost no OS blocks that are appealed to Arbcom. Admins without access to suppression tools have no rational way to determine whether the block was appropriate. It should be noted that some of the OS blocks involve policy violations so egregious that even an ordinary admin would have blocked the offending account with the intention of it being permanent.
Hope that gives some background on *why* OS blocks of named registered accounts are always of indefinite duration (in the true meaning of the word "indefinite".) Risker (talk) 15:45, 1 March 2024 (UTC)
Like Risker, I'm struggling to think of a reason for a time-limited OS block of a registered account. Either we have had communication from the blockee that satisfies us that the block is no longer required to prevent the publishing of non-public information or we haven't. We might get that a few minutes after the block, we might never get it - we have no way of knowing. Thryduulf (talk) 16:00, 1 March 2024 (UTC)
Like Thryduulf, I agree with Risker. Primefac (talk) 17:43, 1 March 2024 (UTC)
Like Primefac and Thryduulf, I agree with Risker too. stwalkerster (talk) 20:13, 1 March 2024 (UTC)
Agree with Thryduulf and Risker. Most os blocks should be resolved by the person blocked demonstrating understanding. But if it is clear the person was already well aware of our rules surrounding personally identifying information and shows a willingness to out people in knowing contradiction with those rules, an unblock shouldn't be taken lightly in order to prevent further harm.
In the overwhelming majority of cases where an indef is proposed or appealed, I'm arguing for narrower restrictions or an additional chance, but not when it comes to outing. Unlike disruption or personal attacks, where a good apology/mea culpa can truly fix any harm caused, oversightable offenses cause potentially irreversible damage at the moment of posting. It should be a bright line.
The big challenge, however, is in cases like the one which led to this discussion being opened. One person was indeffed for directly outing in a discussion where several other people had already indirectly, but no less harmfully, outed the same person. An indef looks harsh there only because the outing had already taken place and was permitted to stand. I don't see a big difference between the blocked user's posts and the OP's posts, for example. By the time Fram said what he got blocked for, the cat was already out of the bag. Had oversighters/admins taken action on that thread immediately after it was posted, we would likely have Kashmiri saying "oh my bad, I'll send it to arbcom" and continuing to edit and would never get to the point where Fram got blocked simply for dropping the facade. In other words, the problem isn't the use of indef but taking selective action that doesn't actually stop the harm, penalizing just those who violate policy without the pretense. — Rhododendrites talk \\ 16:47, 1 March 2024 (UTC)
  • I do see areas where we can improve. For example, we have had a spate of OS blocks on young users who have been very insistent on including personal information about themselves into the encyclopedia (both on their user page, and elsewhere). The usual pattern is for oversighters to suppress, and then leave a note on the user's talk page discouraging a repeat. The block usually comes if they do it again. But I'm not sure we're clear enough in our first message that they'll get blocked if they persist in posting personal information. I don't think we can stop the OS blocks for this; for one thing, we run the risk of violating governmental legislation that could have major impacts on our projects. Some of the current or proposed legislation imposes heavy fines and/or taking down of websites entirely. I do think we can be a lot more clear, particularly with young users, that this isn't the place to talk about their school, their date of birth, their full real name, etc. To be honest, it wouldn't hurt to be a lot more clear with *all* users, especially as governments consider legislation that permits right-to-disappear. Risker (talk) 20:33, 1 March 2024 (UTC)
    Thanks for this thought Risker. This was indeed one of the cases where I thought a short block might be enough to make clear to the user that they need to stop. Best, Barkeep49 (talk) 21:33, 1 March 2024 (UTC)
    I particularly agree with Risker's last sentence. I think a lot of new users, especially younger ones or those from certain parts of the world (often the Indian subcontinent but not always), confuse a Wikipedia user page with something like a LinkedIn profile. It would be nice if new users saw something before they registered or before they created a user page that advised them against posting CVs/excess personal information or writing about their own company. HJ Mitchell | Penny for your thoughts? 17:08, 2 March 2024 (UTC)
    If possible (I don't know), an edit filter that detected a new user creating a user page that might be a CV (detecting this would be the hard bit I guess) and gave them a warning that Wikipedia is not the place to post a CV or personal information before they could save might help. Thryduulf (talk) 17:14, 2 March 2024 (UTC)
  • I am not a fan of time-limited blocks in most circumstances, and especially do not support it for OS blocks. I would rather have indefinite blocks which are lifted when the blocked user demonstrates that they understand the reason and won't do it again. I cannot think of a reason, nor has one been posted above to my satisfaction, that demonstrates a situation when a time-limited block would be better than an indefinite-but-appealable block. Z1720 (talk) 01:15, 2 March 2024 (UTC)
    The main reason against that idea is it would be a huge time suck that adds no value. PackMecEng (talk) 17:53, 2 March 2024 (UTC)
  • @PackMecEng: I agree with you, to a certain extent, but it's also a time sink if an editor receives a time-limited block, then starts reposting things on-wiki when the block is over. The question is: what is better for the community? My opinion is that the time sink to evaluate OS-unblock requests is better than the time sink to clean up edits on-wiki. However, I can see how others think differently. Z1720 (talk) 18:09, 2 March 2024 (UTC)
    My view on this is not one of the effort involved, it's one of safety. I want to be sure that if an OS block is required, the blocked user understands not to post OSable material again before they continue to edit. If it's more effort for all involved, then that's effort well-spent IMHO. stwalkerster (talk) 18:12, 2 March 2024 (UTC)
    As an OSer I agree completely with this. OS blocks are not super common, not all of them are appealed, and many of the appeals are very simple (it's clear the person now gets it or clear that they don't) so the actual amount of time discussion of them takes is not great at all. It's firmly in the territory of benefits outweighing costs as far as I'm concerned. Thryduulf (talk) 18:30, 2 March 2024 (UTC)
    As a proportion of all blocks, oversight blocks (unlike checkuser blocks) are actually vanishingly rare. HJ Mitchell | Penny for your thoughts? 19:16, 2 March 2024 (UTC)

Help!

I was trying to access the suppression log and I got the "permission error" message. Also when looking through oversighted edits, it is unclear who had oversighted, as the software refused to show me. Any assistance? Toadette (Let's discuss together!) 18:15, 20 March 2024 (UTC)

This information is private to Oversighters only. stwalkerster (talk) 18:16, 20 March 2024 (UTC)

Should there be instructions in the page to contact the Wayback Machine to ask them to remove oversighted content?

Oftentimes, oversighted content gets picked up by the Wayback Machine before it is removed. They will remove PII on request. Some Wikipedia users, especially new users, are unaware about the Wayback Machine. Could there be a reminder added to the page to check if the content was archived in the Wayback Machine, and contact them to remove it? Félix An (talk) 08:48, 16 April 2024 (UTC)

That's not our site, so not by name. But maybe something generic in the notes like:
  • The oversight process described above is specific for the English Wikipedia, for assistance on another Wikimedia project, please contact their oversight team directly. For assistance with content hosted on external mirrors and forks or archvies you would need to contact the external site administrators.
? — xaosflux Talk 10:01, 16 April 2024 (UTC)

Can we consider a formal rename of oversight to suppression (or something else)? (just a brainstorm)

The oversight extension has been deprecated for more than a decade, and very few people (particularly newer contributors) actually understand why the tool was named as such. A rename would be better for newer users.

A rename would entail moving this page from Project:Oversight to Project:Suppression, renaming the appropriate group roles, updating references of "oversight" to "suppressor" or "suppression team" across the project where needed, etc. It might also involve updating email addresses and mailing lists (but not discontinuing previous ones). "Oversight" is not even defined as we use it right now; oversight means "supervision or management" and is not synonymous with "suppression".

Suppression might have a negative connotation, but it is also important to note that suppression is only done for material that for one reason or another creates legal liability if accessible even by administrators. And I don't think there are many other terms that accurately describe what this is doing. We could differentiate between these different levels of deletion with stuff like level I deletion and level II deletion, but then the group name would be "level II deleter" and that does not ring nicely, and that might still not have an entirely positive connotation.

Maybe one can find a better term to reflect this role that is not negative or something? I can be certain that this role only exists for legal reasons, in the same manner "checkuser" exists. So finding a term that reflects this fact would be more helpful. Awesome Aasim 00:01, 3 April 2024 (UTC)

Noting for the record that this has been brought up several times before:
stwalkerster (talk) 00:24, 3 April 2024 (UTC)
How about this? We can maybe combine the "checkuser" and "oversight" privileges into one "functionary" role, since both roles are tied with the handling of private information, if someone is trusted with one they are trusted with the other. A functionary role would have access to the IP addresses accessed by accounts, ability to redact and technically suppress information, and oversight over each other's use of these tools. I have never seen a case where one with both roles lost just one or the other. (example: Wikipedia:Arbitration/Requests/Case/Reversal and reinstatement of Athaenara's block where a former functionary lost both roles because of lapsed judgement with the "checkuser" tool). Awesome Aasim 00:31, 3 April 2024 (UTC)
We have a number of OSers who are not CU, and a ton of CU who are not OSers. Combining these roles would give access to people who have, for one reason or another, indicated they neither want nor need the other role. Primefac (talk) 07:37, 3 April 2024 (UTC)
The two roles require different skill sets and not everybody has both. I am an OSer without CU, I don't have the technical skills to make use of the CU tool and I have little to no interest in learning them. So either people like me would have access to CU without meeting the usage requirements (pointless, arguably potentially harmful), I'd lose access to the OS tool because I didn't use CU often enough (not the greatest loss to the team, but still a loss) or I'd be forced to make bad use of the CU tool (with great potential for harm). Thryduulf (talk) 11:08, 3 April 2024 (UTC)
Suppression is the technical term and Oversight the common name for the same process. The words can continue to coexist, in the same way we call someone with the sysop privilege an admin. However, you make a good point that their duty is to perform limited and welcome suppression rather than general management. It's unfortunate that for reasons verging on marketing and political correctness we need (rather ironically) to suppress the S word. Perhaps we can find a better term which describes the role more accurately without offending anyone. Certes (talk) 09:32, 3 April 2024 (UTC)
It might be the same reason why we moved from "abuse filter" to "edit filter" even though many contributors including me still use AF. It is called that because its primary purpose is to catch potential vandalism, LTA, and etc. but not all edits the filter flags are "harmful".
The term that might be better is just "level II revision deletion" or something similar because revision deletion already removes inappropriate material from public view, and for most cases that is enough. If we need to go a step further (level I to level II) then that is what "suppress" would be. Awesome Aasim 16:16, 3 April 2024 (UTC)
suppression is only done for material that for one reason or another creates legal liability if accessible even by administrators this is not correct. The policy section of this page lists the situations where we suppress material, and privacy reasons are far more common than legal ones (both in terms of criteria and in terms of how often they are applied). Thryduulf (talk) 10:57, 3 April 2024 (UTC)
Once again, there are legal implications with having personal information visible to everyone. Most don't realize that personal information here is visible to everyone forever even if later removed. Which was the purpose of the oversight and later suppression tools. Other wikis (particularly commercial wikis) have other obligations like GDPR and when a user "vanishes" (like I have seen on Fandom), the username must be suppressed in all relevant logs for compliance, and any pages where personal information is present must be removed. It's called the right to be forgotten for a reason. Awesome Aasim 16:11, 3 April 2024 (UTC)
  • Just for the record, the action is formally called "hiding", not suppression, in our logs. I'd rather be called a hider than a suppressor. Both of them suck. In some languages, the local equivalent of "suppressor" doesn't have the Orwellian impact as it does in English, but I know for a fact (having met some colleagues from other languages) that they're none too fond of the implications of the name. The reality is that we aren't suppressing anything in any classic meaning of the term; we're preventing access to certain elements of information. We can't suppress the information in the sense that it is impossible for anyone to know the information was ever there. (Incidentally that's what the old oversight tool did, but very clearly the current suppression tools do *not* do.) So if someone has the strong urge to get into the semantics of the whole thing, they should start by insisting on the correct name of the activity, and then working their way down. I could almost accept a name like "access restrictor". Risker (talk) 16:22, 3 April 2024 (UTC)
    Maybe what might be better is "content administrator" and "account administrator" for OS/CU. Content administrator suggests that the user administers content decisions. In which case then we could rename "administrator" to "moderator" as that is essentially what the administrator tools allow. It would also distinguish between "system administrator" and "database administrator" which entail different roles and responsibilities. Awesome Aasim 21:12, 3 April 2024 (UTC)
    Administrators are far more "content administrators" than they are "system administrators" or "sysops"; oversighters make far fewer and much less wide-ranging decisions about content than regular admins do. The only "account administration" that checkusers do is blocking and unblocking - i.e. what administrators do. Thryduulf (talk) 03:12, 4 April 2024 (UTC)

How about this for the role namings and policy namings:

It may get a bit redundant if one has both but it resolves this historic happenstance and inaccurate description by using the same name to refer to both checkusers and oversighters. Awesome Aasim 23:18, 16 April 2024 (UTC)

I'm struggling to understand what the benefit of that change would be? Also note that there are functionaries without either tool. Thryduulf (talk) 09:58, 17 April 2024 (UTC)
There are functionaries without either tool aren't functionaries essentially users entrusted by both the community (or ArbCom) and the WMF to handle personal data? There could be a right called "arbcom" that lists Arbitration Commitee members, which would be a cosmetic-ish role. Awesome Aasim 19:13, 18 April 2024 (UTC)
All functionaries are entrusted to handle personal data, but not all are or were arbitrators. Wikipedia:Functionaries#Members notes that there are several Functionaries who are former oversighters and/or checkusers but not former arbitrators, TonyBallioni for example. They remain subscribed to list so they can offer their perspectives and advice when that would be beneficial, even though they don't handle personal data on a day-to-day basis. However this isn't really relevant to my question, which is why would "Functionaries (checkuser access)" and "Functionaries (suppress tool access)" be improvements over the status quo? Thryduulf (talk) 13:40, 19 April 2024 (UTC)
Because it distinguishes the technical role that gives the tool from the actual tools itself. It is the same reason we call administrators "administrators" rather than administrators, say, "deletors", even though they technically can delete. The same thing could be done for "rollback" and other roles. Any (insert name of tool)-er is one who (insert names of tool)-s, but it does not mean that every person with access to (insert name of tool) is a (insert name of tool)-er. Saying a person has "access" is much less technical, in the same manner that one has access to a vacuum or access to a pressure washer. Awesome Aasim 17:47, 19 April 2024 (UTC)
We already have "oversighter" and "checkuser"? What benefits does changing these bring? Thryduulf (talk) 18:59, 19 April 2024 (UTC)
Checkuser is unambiguously descriptive: one who checks user details such as IP address that shouldn't be public. Oversight has several meanings, only the last of which is relevant. It's a term of art that few non-Wikipedians would guess correctly. Certes (talk) 21:25, 19 April 2024 (UTC)
But why is that a problem? And why is "Functionaries (suppress tool access)" better, given that there are several meanings of "suppress", none of which are a great match for what "suppression" means on Wikipedia (sense 4 is the closest).
Consider also more prominent roles like "bureaucrat", "steward", and "extended-confirmed" whose names are wholly terms of art that few non-Wikipedians would guess correctly. Thryduulf (talk) 23:07, 19 April 2024 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Oversight/Archive_7&oldid=1253155011"