Question for functionaries

On tonight's Empty Category list, Category:Wikipedia functionary statistics showed up. Typically, I tag empty categories the next day but it is unusual to see Wikipedia project-related categories on this list, it's almost entirely categories for either main space articles or for other categories so I thought I'd bring it up in case you had an ongoing use for this category.

Yesterday, I noticed in the Deletion log, that quite a lot of templates and template-related pages that contained functionary stats from the past few years were deleted. I'm not sure if this was a decision supported by functionaries themselves or just the result of a discussion among the few number of editors who participate in TFD discussions. Liz Read! Talk! 01:10, 16 November 2021 (UTC)[reply]

Cross-posted from Wikipedia talk:CheckUser. Liz Read! Talk! 01:16, 16 November 2021 (UTC)[reply]
To keep discussion together, please reply at Wikipedia talk:CheckUser#Question for functionaries. Thryduulf (talk) 03:20, 16 November 2021 (UTC)[reply]

Short term IP OS Blocks

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hello, regarding Wikipedia:Oversight#Oversight_blocks - It is customary for oversighters to submit their OS blocks on the oversight listserv for peer review: recurring list discussions have found little utility in requesting review of short-term IP blocks of this nature. Any objection to calling this out, perhaps as: ...to submit their OS blocks (other than short-term IP blocks) on the oversight listserv...? Reviews are of course always allowed and can be opened by anyone, just looking to update this "best practice" guidance. Thank you for any feedback. — xaosflux Talk 11:08, 18 January 2022 (UTC)[reply]

Support addition: Seems like a sensible modification—I'm fairly confident that even then, given how rare oversight blocks tend to be, at least one other oversighter would notice and raise any concerns should they feel the need -- TNT (talk • she/her) 14:40, 18 January 2022 (UTC)[reply]
I think the discussions on-list have been more about the necessity of giving an IP a short-term OS block rather than the necessity of reviewing those blocks. I do not think we need to codify this edge case in either instance, though; the sentence isn't saying that we always get reviews of OS blocks anyway. Primefac (talk) 15:29, 18 January 2022 (UTC)[reply]
Agree it doesn't require it, but it does document what the best practice recommendations are. I haven't seen enough listserv discussions that short-term ip blocks shouldn't be used in general. — xaosflux Talk 15:37, 18 January 2022 (UTC)[reply]
I think it would be useful, if we add this, for us to have a common understanding of "short-term block". Myself, I'd say anything up to a week; if an IP needs to be blocked longer than that for OS purposes, then we're probably going to move to a multi-month block. I'm not sure if we need to codify this, though. Risker (talk) 01:19, 19 January 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFO edit request

Per HTML5, please change

((caution|<center>'''The fastest way to request oversight is to ((big|<u>[[Special:EmailUser/Oversight|email the oversight team]]</u>.))'''</center>))

to

((caution|((center|'''The fastest way to request oversight is to ((big|<u>[[Special:EmailUser/Oversight|email the oversight team]]</u>.))'''))))

Display comparison. Should look the same unless you have a deprecated tag highlighter enabled or are using a browser that doesn't support this deprecated syntax.

Old:

New:

at Wikipedia:Requests for oversight. Thanks. -- Tamzin[cetacean needed] (she/they) 09:30, 23 January 2022 (UTC)[reply]

 Done Primefac (talk) 09:48, 23 January 2022 (UTC)[reply]

Safeguarding

Per this discussion at ANI, I wanted to open a discussion here about having a clear way to deal with personal information posted by children or potentially vulnerable adults. The consensus in that discussion was to amend WP:OSPOL to add a second-level bulletpoint under Phone numbers, home addresses ... etc. that reads Personal information may be removed for safeguarding reasons if posted by children or vulnerable individuals. In addition to this, to add a new section called "Safeguarding" to the WP:CHILDPROTECT policy, which gives a brief explanation that concerns should be dealt with under the oversight policy. Theknightwho (talk) 00:00, 5 February 2022 (UTC)[reply]

We had a similar discussion above at #OSPOL #1 updated. This is already within the policy as the decade-plus interpretation of the Oversight team is that people need to understand the implications of self-revealing their information on Wikipedia, and if they do not have the capacity to consent to self-reveal (such as minors or individuals who are vulnerable for whatever reasons) it will be treated as non-public personal information and suppressed. At least a few months ago, there is relatively strong opposition from the Oversight team to changing the policy as it would imply that the items listed at OSPOL1 were an exclusive list, which they are absolutely not. In this situation, I guess the analogous concern would be that we can't really say when something would fit under this criteria, and you don't necessarily want to box yourself in.
Also, for what its worth, these type of suppressions are one of the most common out there already. I've also alerted the team to this discussion on the oversight list. TonyBallioni (talk) 02:45, 5 February 2022 (UTC)[reply]
Thanks for the response. I feel I should emphasise that this concern comes primarily from the fact that for people not on the Oversight team (and for whom this policy won't be familiar), there is no obvious way to raise safeguarding concerns at the moment. That's the reasoning behind wanting to link WP:CHILDPROTECT here - so that people know to bring things to your attention. Adding something along these lines should help in making sure that reports end up being reported correctly, and don't end up at WP:ANI or wherever like the report this arose out of.
In terms of the non-exclusivity of the list, surely that's just a case of saying so in the policy? Theknightwho (talk) 03:16, 5 February 2022 (UTC)[reply]
For a bit of context here: I just went to the suppression log. These type of suppressions were the single most common reason over the last 500 suppressions (198/500 was self-disclosure by a minor; next most commons was non-public personal information with 185/500; Libel was 61/500; IP addressed were 32/500. Didn't look at the rest.) That's just by Ctrl+Fing for the dropdown text associated with minor children. I'm assuming some of the non-public information ones were of minors, vulnerable adults, or people who didn't understand how Wikipedia worked.
I guess my point of view is that if this is already the single most used suppression reason based on the last 500 log entries, I'm not really sure the problem that you think exists actually exists. We don't tend to go looking for things to suppress proactively. Most of this stuff is reported. I'm certainly in favour of linking to this page from any relevant child protection pages, but I also don't really like the idea of modifying the policy without a very good reason. It works pretty well as written. TonyBallioni (talk) 03:31, 5 February 2022 (UTC)[reply]
The issue is that few people outside of the Oversight team know that, and nothing signposts them here. Although I'm sure things do get reported, this has arisen out of an instance where that lack of signposting meant that the issue didn't make its way to you, and was posted to WP:ANI instead (by an administrator, at that). That is a very good reason to add clarification, and I'm honestly at a loss as to how that could be a problem when it would make no functional difference to how you or the rest of the Oversight team would operate. It would just make it somewhat easier for the rest of us to assist you in that. Theknightwho (talk) 03:41, 5 February 2022 (UTC)[reply]
I'll let other comment, but I guess the two things I disagree with your reply above about are that very few people know it and that it makes no difference. The fact that this is the single most used suppression reason is evidence that many people do in fact know that. I disagree that it makes no difference because any change to the OS policy has the potential to impact future interpretations of it. From best I can tell, the last substantive change to the policy was in 2009 (see diff.) I added this clarification in 2020, but that was purposefully kept out of the policy and is simply a documentation of our standard negative response to requests for rename suppressions to discourage people from requesting them. Actual changes to the policy itself haven't happened in over a decade for a reason: the existing policy has significant precedent behind it and the community is generally aware of what we do and don't suppress. Changing it invites debate over the meaning, which isn't really something we want when its a policy designed to protect real life people.
The solution I'd suggest to your concern is something like WP:DOB, mention in the relevant pages outside of this policy that people should contact the oversight team. That gives more visibility like you want, while preserving the policy that's worked for years as is. TonyBallioni (talk) 04:03, 5 February 2022 (UTC)[reply]
The way to circumvent debate over the meaning is to make it absolutely clear that any amendment is clarifying existing practice, and does not (and should not) reflect any change to it - this should be straightforward, given that you'd be simply adding a broad example to a non-exhaustive list that everyone agrees should be covered. If, as you say, there is a shared understanding of what the Oversight team does among the experienced parts of the community, then that isn't going to fall apart by clarifying anything. In fact, I don't see how it adds any new room for interpretation at all, so long as it does genuinely reflect existing practice.
Also, while I agree that something similar to WP:DOB is warranted on WP:CHILDPROTECT, it is unsatisfactory for the policy as written not refer to some of its most common applications, because it creates a communication barrier between the Oversight team and the rest of WP that is clearly evidenced by other commenters on this thread (not to mention numerous others on the earlier thread). As you point out: this is a policy that is designed to protect real life people, and so you cannot merely handwave away the idea of improvement by pointing at numerous successes, because the cost of any failures getting through is too high.
Fundamentally, if you're going to say "we already do that", then you as a team have the responsibility to make that clear to those of us who don't have the luxury of knowing all of WP's unwritten conventions.Theknightwho (talk) 19:25, 5 February 2022 (UTC)[reply]
@TonyBallioni: For the heck of it, why not create an explanatory supplement to WP:OSPOL with a bunch of examples? Because in all honesty people have been confused before. Aside from the ANI thread I've had to ask oversighters for clarification on the boundaries of childprotect on multiple occasions. I've reported dozens of stuff under that criteria (patrolling draftspace is not useless contrary to popular belief) and sometimes I'm still unsure. If we create a supplementary list of more specific examples, we're not limiting the mandate of oversighters and people can throw in all the detail they want. Chess (talk) (please use ((reply to|Chess)) on reply) 08:21, 5 February 2022 (UTC)[reply]
This isn't a bad idea, actually. I've opposed making the OSPOL more detailed because of the potential to cabin OSers' discretion, but my first reaction is that an explanatory supplement sounds like a decent idea. Best, KevinL (aka L235 · t · c) 17:22, 10 February 2022 (UTC)[reply]
I'm on board with this. Theknightwho (talk) 17:26, 10 February 2022 (UTC)[reply]

The issue came up because I spotted the behaviour but didn't quite know where to go with it. I only edit sporadically these days after dealing with a suicide note on WP about ten years ago (kind of dampened the "escape from real life" vibe) so am not as au fait with some policy as I used to be. I couldn't find any easily available policy on this one. Catfish Jim and the soapdish 18:43, 5 February 2022 (UTC)[reply]

"Surpressor"?

Hey, whoever Watchlists this page,

I have a lot of scripts and one of them posts the permission levels an editor has under their name on their User page and User talk pages. Any way, I went to an editor's page and instead of seeing "Oversight", I saw "Surpressor"! Has this name been changed at the WMF level or do you think this is a problem with the script? I assume the script is just reading information from account data so I think WMF has changed the name. I don't think this is an improvement! "Oversight" implies responsibility while "Surpressor", to me, has negative connotations of censorship or restriction. I know the job duties haven't changed but I wondered what the Oversighters thought about being now called "Surpressors"? It sounds like some kind of domination kink. Opinions? Liz Read! Talk! 22:39, 3 March 2022 (UTC)[reply]

The technical name for this group was changed from 'oversighter' to 'suppressor'; this is similar to how our group 'administrators' is technically called 'sysops'. If that script usually overrides to the local name, you can update it there (or ask someone else to). — xaosflux Talk 22:54, 3 March 2022 (UTC)[reply]
Ah, yes, well, that would be the logical solution! I was just surprised to see the word. I guess I was just unfamiliar with the change. Liz Read! Talk! 06:48, 9 March 2022 (UTC)[reply]
The relevant phab task is T112147, where you can read the background to the change and the various comments supporting and opposing it. Thryduulf (talk) 00:09, 10 March 2022 (UTC)[reply]
Help, help, I'm being suppressed! SubjectiveNotability a GN franchise (talk to the boss) 13:57, 10 March 2022 (UTC)[reply]

Requested move 9 March 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: Not moved per WP:SNOW (t · c) buidhe 21:11, 14 March 2022 (UTC)[reply]


Wikipedia:Oversight → Wikipedia:Suppression – Current nomenclature. NasssaNser - T 08:25, 9 March 2022 (UTC)[reply]

This is a contested technical request (permalink). Steel1943 (talk) 22:25, 9 March 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Wikipedia:OVERSIGHT" listed at Redirects for discussion

An editor has identified a potential problem with the redirect Wikipedia:OVERSIGHT and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 March 22#Wikipedia:OVERSIGHT until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Gaetr (talk) 13:52, 22 March 2022 (UTC)[reply]

Implementing results of the discussion from requested move

IMO the results were to not make the move and to continue to call it "oversight". recognizing that the technical name in the Wikipedia software is "Suppression" Pages that discuss this should do so accordingly. North8000 (talk) 22:17, 27 March 2022 (UTC)[reply]

Proposal for restriction of suppression criteria

In 2015 a proposal was made to expand WP:OSPOL #1 to allow the hiding of IP data of editors without an account on request (prior to this date only registered users who had edited logged out could request an IP hiding). The primary purpose of this addendum was to allow for new editors without accounts – who might either be on mobile or otherwise not see or understand the "logged out" warning – to request their IP be hidden. The RFC passed with no obvious opposition and has been standard practice for the Oversight Team since then. However, we have noticed in recent years an increasing prevalence of users asking for hiding of IPs that are either years old or span hundreds of edits (quite literally). After internal discussion, the Oversight Team feels that this goes against the spirit of the intentions behind the initial RFC, which was intended to allow new users to recognise their logged-out editing and correct the issue; by the time the edits are more than a few months old, or when an editor has made more than a few dozen edits, it is well past time that they should have noticed and (if they really were concerned) asked for suppression of their IP.

In other words, I (on behalf of the OS team) am proposing to limit this provision of OSPOL, IP data of editors without an account on request.[note 1], by appending ... provided that the edits were made recently and are relatively small in number.[note 2] after [note 1].

References

  1. ^ 2015 addition of editors without an account
  2. ^ Generally within the last three months and fewer than 20 edits in total

Please keep in mind that this proposal is not a hard cutoff, and like with most oversight-related inquiries will allow for exceptions to be made (generally for school-related IPs and the like where a very accurate location can be determined), but will give a better indication to editors of what is assumed to be acceptable for these types of requests. I am also not proposing this as a formal RFC because I feel that it is simply updating our policies with how the Oversight Team currently operates, though if there is any significant opposition provided in the next week or two I am willing to convert it to one. Primefac (talk) 09:16, 26 May 2022 (UTC)[reply]

Sounds like a reasonable change to me. --Blablubbs (talk) 09:26, 26 May 2022 (UTC)[reply]
Seems eminently sensible. firefly ( t · c ) 09:42, 26 May 2022 (UTC)[reply]
More