This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Hi. There are open discussions regarding whether we should count MediaWiki namespace edits and edits to fully-protected pages as admin actions in admin inactivity runs. Posting this because of unclear consensus, please participate in the discussion, so we can have clear policy at the time of next run. Thanks! -- CptViraj (talk) 11:50, 1 July 2021 (UTC)
Is it possible to add a compass, that would help describe in which direction photograph was made? Actually there is only field to write direction as numbers.VVerka5 (talk) 17:33, 16 July 2021 (UTC)
I don't see how this would be helpful, Generally speaking most people would be interested in the camera/image location than what direction it was taken from although you can download compass related software. –Davey2010Talk19:51, 17 July 2021 (UTC)
Thanks. I look at it now, but it isn't precise (eg. no WNW, WSW direction, so "just N" or "just NW" precision i can say without geolocator tool). Also i remember, i was try to add Heading-value as points of compass, but then it wasn't accepted by uploader (i don't know was it error or something other and i wasn't try - sometimes i just add Heading-value as points of compass in text of photo.VVerka5 (talk) 16:24, 20 July 2021 (UTC)
{{Location}} supports those: It is given as degree values 0–360 (clockwise with north as 0) or a compass point abbreviation (up to four letters) as defined in Points of the compass. The site linked above supports up to three-letter compass point abbreviations, which is generally sufficient for our purposes here. Pi.1415926535 (talk) 17:40, 20 July 2021 (UTC)
Subcategories partly hidden behind the Cat-a-lot menu
Could the middle and right columns of subcategories be shifted left a bit, so as to leave more space for the Cat-a-lot menu, so that the right hand column of subcategories is not partly hidden behind the menu? See screenshot (right) illustrating the problem. - MPF (talk) 09:43, 22 July 2021 (UTC)
As long as all of the browser window is used and cat-a-lot does not redraw it, something will be covered. Are you suggesting we reserve a portion of the view for cat-a-lot as if it were always active? That would be an expensive solution. A better solution would be to allow the cat-a-lot menu to be dragged around. –LPfi (talk) 18:32, 22 July 2021 (UTC)
I was thinking it would be handy if it had a temporary hide/unhide feature, but I see it's already there: an underscore beside the X button. --ghouston (talk) 01:35, 23 July 2021 (UTC)
@LPfi and Ghouston: - the cat-a-lot menu can be dragged to the right to take it off the subcategories, but then you lose access to the - → + buttons as they are off the edge of the screen. It can also be closed with the 'x', but then you can't use it; the problem is the need to see what's hidden behind the menu while using it. It can also be resized smaller, but that loses you access to the most useful part of the list (the subcategories) while keeping just the rarely-needed parent categories in view. One good option would be to have the irrelevant parent categories that no-one is going to want (things like 'Biology categories with duplicate wikidata items' and 'Uses of Wikidata Infobox providing interwiki links') excluded from cat-a-lot altogether; those long-winded category names increase the size of the cat-a-lot menu substantially (it is as wide as the longest name), but are never going to be used in cat-a-lot. - MPF (talk) 16:19, 24 July 2021 (UTC)
@LPfi, Ghouston, and RZuo: But you can't use it when it is dragged. What I'm wanting is to be able to see the currently hidden parts of subcategory names, while I am using cat-a-lot. All that's needed, is to shift the middle column of subcats 10% left of the middle, and the right-hand column of subcats 20% left of the right edge, so there's a bit more free space for the cat-a-lot menu to occupy - MPF (talk) 21:12, 2 August 2021 (UTC)
Being able to drag it around is hugely useful, as is being able to minimise it when choosing files. I didn't realise dragging is possible as there is no handle. The minimise feature also behaves oddly: when I minimised and restored the box, it got back to the corner of the window, but with the minimise/close controls below the box, and thus outside my browser window. Dragging the box or maximising my window solved the problem, but unless you know they are still there, the solution isn't obvious. Neither feature is mentioned in the documentation at Help:Gadget-Cat-a-lot. –LPfi (talk) 08:27, 3 August 2021 (UTC)
Leveled Warning Templates for Copyright Violations?
Currently on Commons, we use two message templates to warn uploaders of copyright violations (copyvios), namely {{Copyvionote}} and {{End of copyvios}}. However, per this ANU discussion, Andy Dingley raised the issue that strong wordings (possible blocking, last warning, etc.) on the messages may scare off new users who made mistakes for their first time, especially when these templates are used abusively. I also admit that I also used it wrongfully when I used End of copyvios on a new user who uploaded 17 blatant copyvios, thinking that it was the appropriate warning for these kind of users, which made the user thought that the user's account is blocked.
So, my thought is that, should we introduced a series of leveled warning templates for copyvios, just like what we have for the series of {{Test}} templates? For example, perhaps the warning mechanism can be modified like this?
Copyvionote (modified): Merely used to notify users that they have uploaded a possible copyvio. Also proposed to have ... and persistent violators will be blocked from editing removed due to the pure notification nature of this template, in line with other copyright-related warning templates like {{Image permission}} and {{Image source}}.
Some sort of leveled copyvio warning templates (like Template:Copyviowarning-1 and Template:Copyviowarning-2?): Based on the Test series templates, with lower leveled ones providing more guidance to copyright and link to COM:VPC, while higher leveled ones containing warnings of being blocked from editing.
End of copyvios: Used as the final warning for persistent copyvio uploaders who ignore previous warnings.
And as an extra, perhaps a guideline can be issued on when to use different leveled copyvio warnings, like for what amount of copyvios uploaded should users use what level of warning.
That's a great idea. I think the first warning can still have a soft reminder like "Persistent violators may be subject to blocks."
One other issue I noticed: I don't think we should be using the {{Copyvio}} tag at all (along with its talk page message {{Copyvionote}}, which does not provide any indication on how the user is supposed to rectify the issue) when there is reason to suspect that the uploader is or is acquainted with the author or subject of a photo. Instead, {{No permission since}} (along with {{Image permission}}) works beautifully, with helpful links to OTRS. Just now I came across a case where I feel like we were a bit BITEy to a new user: [1]. Assuming the Commons account is not an impersonator, accusing her of lying and stealing photos from her own Instagram is not cool. Our motto should be: Trust, but verify. The mindset and tone we should adopt when talking to uploaders is that they are telling the truth but just need to provide evidence of that. -- King of ♥ ♦ ♣ ♠05:29, 23 July 2021 (UTC)
I see, thanks for your reminder. What's needed next will probably more internationalization like what we have on our End of copyvios template: {{File copyright status}} only provides English warning/notification text.廣九直通車 (talk) 07:19, 23 July 2021 (UTC)
Template:Copyvio is the no-brainer template for each and any kind of copyvio, especially if you don't know anything about English. On the description-page of this one-size-fits-all template is no mention of any other possible templates, perhaps with a bit more fitting content for the concrete type of copyvio. So: Don't bother with intricate legalese in English, Simple English should be the norm for all templates and the description pages, plus a possibility for translation. Anything not in Simple English is exclusive for those monolingual anglophones, that should not bother us at all. We are international, English, and especially anglophone legalese os business gibberish, shozuld be avoided by any means. Grüße vom Sänger ♫ (talk)09:35, 23 July 2021 (UTC)
No, {{Delete}} is the one-size-fits-all template. Whenever there is doubt about whether it is actually a copyvio or a reasonable chance of a copyright issue being resolved via OTRS or further investigation (e.g. photo uploaded by the subject, suspicious EXIF, username which matches that on an external website), {{Copyvio}} is wrong because it assumes bad faith and does not give the uploader a chance to correct the issue. Use {{No permission since}} if the issue can be completely resolved via a proper OTRS permission, or {{Delete}} in all other cases. When in doubt, you should not reach for {{Copyvio}}, but rather {{Delete}}. -- King of ♥ ♦ ♣ ♠19:38, 23 July 2021 (UTC)
Or perhaps alternatively, should we at least require the user who place {{Copyvio}} on some file to give the link by making the source= parameter mandatory? After all, {{Copyvio}} is for dealing with unambiguous copyvios which can be found on elsewhere with unfree licensing/permission.廣九直通車 (talk) 12:32, 24 July 2021 (UTC)
Sounds reasonable. The source should not need to be a URL though: you might know it is because what you saw offline – yes, there is a reality also out there :-) –LPfi (talk) 16:25, 24 July 2021 (UTC)
The free text explanation could of course be another parameter. And this wouldn't catch pointers to a google search, but it might get some people think twice. –LPfi (talk) 16:27, 24 July 2021 (UTC)
In most cases, yes, it should be a requirement. Exceptions include:
When the picture itself is obviously non-free. For example: Google Maps logo/interface featured prominently on a map or satellite image. Screenshot of software known to be non-free (Windows, Mac, Adobe, etc.). NOT: When a map/satellite image is of unknown origin. Screenshot of unidentified software.
When the EXIF metadata implies a very low probability of the image ever being released under a free license. For example: AP/AFP/Getty in the metadata. NOT: Random author that does not appear to match the uploader, "All Rights Reserved", FBMD, Alamy (stock agency notorious for stealing Commons images).
So according to the discussion above, it seems that the following actions can be taken:
Internationalize {{File copyright status}} as the entry warning template for first-time offenders. While {{End of copyvios}} can be read in 41 languages, File copyright status is only written in English, limiting the readability to users who can't understand English.Working
Categorize files tagged with {{Copyvio}} without a link into another category to attract extra attention of processing administrators. While I know that copyvio nominations without the source parameter filled in may be OK (eg. the uploader uploaded a copyvio with external link provided), such kind of nominations may also indicate improperly filed nominations.
Revamp {{Copyvionote}} to add more information on how to provide permission (eg. OTRS, declaring content on the source page to be CC-licensed). Cf. content on {{Image permission}}Done
Add guidelines on the documentation pages of:
Copyvio, that the template should not be used on controversial deletions nominations like FOP- or TOO-related ones.Done
End of copyvios, that the template should only be used on uploaders who ignore previous warnings. It shouldn't be used on first-time offenders, even if the copyvio uploads seems to be large in amount (tbh if they ignore them and continue with their large-scale copyvios, send them to COM:ANB for disruptive edits).Done
I am still concerned that the language of the templates is too harsh. Last time I checked, UploadWizard still asked who was the creator of the file, with no mention anywhere about the underlying work. I am sure many newcomers claim "own work" because of that, and get treated as liars. I was once involved with an institutional upload, which had been prepared for months, but got warning templates, on the file (no permission since) and on the user talk page. OTRS had been negotiated with the rights owners and an OTRS template was added at upload. I suppose good faith should have been assumed, which was surely not evident from the warnings, and the accompanying advice ("if you created this file yourself ... If you did not create the file yourself ... you must specify where you found it ... provide proof ...") quite confusing. I was baffled by that treatment, and glad that we hadn't asked the institution to do the upload. Shouldn't OTRS pending clearly enough show that the process is on way and understood by the uploader? The templates suggest that something went wrong, and should explain what went wrong (I suppose that in this case, the problem was just that the OTRS letter wasn't received yet). –LPfi (talk) 17:13, 4 August 2021 (UTC)
New users go through File:Licensing tutorial en.svg, the tutorial for Special:UploadWizard when they upload their first files. IMO the tutorial is clear enough to tell them (the part of "We can’t accept works created or inspired by others"). Perhaps what can be done next is to place File:Freedom of Panorama world map.svg on the tutorial (with necessary introduction and modification) to inform them what countries allow artwork and building FOP (eg. China, Canada, Australia, etc.), what countries allow only building FOP (USA, Japan, etc.), what countries have no FOP (France, Italy, South Korea, etc.)?廣九直通車 (talk) 03:36, 5 August 2021 (UTC)
Policy of a default of standard blocks to reduce reliance on checkuser blocks
This proposal is to qualify the Wikimedia Commons blocking policy on checkuser blocks(1) with the additional sentence:
When no data critical to a block decision needs to be kept confidential, or when relevant data that justifies a sufficient block action is already public, such as the identification of related sock accounts, a standard block managed by administrators will be the default in preference to a checkuser block.
The key benefits of this technical procedural amendment are that fewer blocks will require ongoing management by the small Commons checkuser team, the block appeal process will be simpler to understand and discuss in the wider community, and there will be improved transparency and accountability for the blocking process in these cases where specific records of checkuser evidence is not fully critical to block or unblock decisions. This may also encourage administrators with checkuser access to limit their use of their trusted role as checkusers by handing off block or unblock decisions to the Commons admin team, or simply making a recommendation where the checkuser evidence is controversial or not 100% conclusive on its own; for example when logs of comments in browser header data may be perceived by some to be "rude" but only supplements critical patterns of bad faith public comments by an account that can be handled by a conventional block.
No, it very much is a current problem. This was the recent practical issue with this case. There was no especially good reason for a controversial block like this, where all the information about it was public, to be only discussed in secret with checkusers. Where policies embed unnecessary secrecy, they should be improved to ensure all reasonable transparency. --Fæ (talk) 13:31, 30 July 2021 (UTC)
Support per all above - CU blocks are useful when for certain reasons data has to be kept secret but they're not useful when in the case of Alexis there was nothing that had to be kept secret, CU blocks can simply be done as an authoritarian thing like it was done with someone above. –Davey2010Talk14:41, 30 July 2021 (UTC)
Support as a principle, but I hope not with the intent of ever taking disciplinary action against someone with checkuser privileges who might get this wrong. - Jmabel ! talk14:56, 30 July 2021 (UTC)
Agree, I was more imagining this amendment mostly making checkusers consider this a more normal option, and making a polite discussion more reasonable to have, rather than a debate or litigating the evidence; like "Could this be made a non-CU block as there's lots of public evidence in this case, please and thank you? Er, okay, done. Thanks!" --Fæ (talk) 15:07, 30 July 2021 (UTC)
Oppose When there is confidential information that warrants a CU block, there is no chance to make it public, so by nature it is impossible to publicly support a CU block. IMO this is a complete nonsense proposal. --Krd18:26, 30 July 2021 (UTC)
The point is that in the Alexis Jazz case, the CUs found a sock and disclosed that publicly, and blocked him for it. It appears that there is no private evidence in support of that block other than that which is necessary to prove that Alexis Jazz = Grilling the Sheriff. In such a case, CUs do not actually have any more information than the community as a whole, and so should not be afforded a privileged position in the review of these kinds of blocks. -- King of ♥ ♦ ♣ ♠18:41, 30 July 2021 (UTC)
Without me saying if there was or was not any additional information, from what do you conclude that there wasn't additional information? From that the CU team didn't document anything, especially no confidential information they are not allowed to disclose? --Krd18:55, 30 July 2021 (UTC)
I consider it basic accountability for the CU team to disclose publicly whether there was material private evidence that went into the block which has not been revealed publicly, and the rough nature of such evidence. Without this documentation, CU blocks should not be used. The "everything is classified" mentality has worked terribly in the real world, and I don't want it to pollute our wiki. -- King of ♥ ♦ ♣ ♠19:15, 30 July 2021 (UTC)
Fair opinion, but please allow me to disagree. I'm a bit proud that in such an open environment like our's, we are still able to keep confidential information undisclosed to protect the privacy even of abusers. --Krd19:53, 30 July 2021 (UTC)
King, I wonder if you could give an example of the evidence that you would like to see disclosed, that meets all of the following criteria:
the CUs are allowed to disclose that evidence (per policy),
it is actually useful to the community (e.g., to future admins or uninvolved editors; by this, I mean to say that it's not basic/background information about what CUs do), and
it would not be helpful to blocked/banned people who are trying to evade detection (e.g., does not say "matching IP address", because then the sockmaster knows to seek a different IP address).
I suspect in a vast majority of CU cases, the answer will just be "no material undisclosed evidence". This means that the accounts are publicly linked, and there's nothing complicated going on like suspected sleepers, proxy-hopping, etc.
Anyways, I think what I'm really going for is this: In obvious cases where they feel they have no more useful private info to make use of, CUs should consider making a normal block. In more complex cases, CUs can continue to require unblock reviewers to check with the CU team before unblocking. But if the community reaches a consensus to unblock, CUs should not have veto power over the community. In that case, if the CU team believes that the user should remain blocked, they can make a case to the community, disclosing however much information they wish, to influence the consensus. But ultimately the community reigns supreme. The CUs can choose to disclose nothing at all, and then it is up to the community to take them at their word or reject it absent further evidence. -- King of ♥ ♦ ♣ ♠20:33, 30 July 2021 (UTC)
Nothing in this proposal suggests that anyone has to "publicly support a CU block". This oppose seems unrelated to the actual sentence being proposed to clarify BP. It would be great if folks could take a moment to understand what the proposal is, before voting on it. --Fæ (talk) 10:27, 31 July 2021 (UTC)
OpposeCommons:Blocking policy#Checkuser blocks: Our policy is sufficiant, a checkuser block is supposed to be made "on the basis of technical checkuser evidence". By definition those evidences are private informations, so as it was well said by Krd there is nothing to discuss. Furthermore such policy will give the chance to anyone about to be blocked for abusing multiple accounts to escpade a checkuser block by making public some infos before to be blocked. It's not for nothing that currently the potential unblockages after CU blocks have to be reviewed by a CU.... they have to check... hence their name "checkuser". Furthermore I'm clearly not enthousiast to change a policy just for one case, because it is clear that the block of Alexis Jazz is the departure of that. Christian Ferrer(talk)21:04, 30 July 2021 (UTC)
Also note that only case, Alexis Jazz, have been unblocked quicky after their first unblock request, so I wonder why this proposal would have changed something, i.e.: a user has disruptive behavior → the user gets blocked → private infos are being kept privates by CUs, as it should be → the user aknowledged his behavior and made an unblock request → the user gets quickly unblocked. It will be hard to make me understand how the process have failed here. And I wonder if it possible to have a list of different examples where this proposal would make a usefull difference, explaining why and how. Christian Ferrer(talk)05:17, 31 July 2021 (UTC)
Support The limitation on reversing checkuser blocks is due to the private nature of checkuser evidence; if the evidence isn't private then there's no need for a limitation on unblocks. IMO this is already covered by Commons:Blocking policy#Checkuser blocks, but evidently that isn't crystal clear, so the additional clarification of this proposal is helpful. -M.nelson (talk) 23:35, 30 July 2021 (UTC)
Support, on Wikimedia websites we have a culture that can best be described as "Blocks are easy and unblocks are hard nearly impossible", very few indefinitely blocked/banned users ever get unblocked/unbanned and a common thing users do is sock to evade the block, if they get caught this then becomes a Checkuserblock and that makes an already difficult unblock process even more difficult. Officially blocks and sanctions only exist to prevent disruption, but if a user was blocked 10 (ten) years ago for uploading copyright violations, sock to continue and then get Checkuser blocked, and then returns after a decade to upload good images and return with absolutely none of the same issues they had prior we shouldn't be punishing them for believing in the educational spirit of Wikimedia Commons by letting them appeal through a very difficult process. While this won't make all unblocks easier this will make some unblocks easier and something tells me that the best way to stop a Sockmaster is by letting them return legitimately, this saves everyone work. Letting an unblock be dependent on half a dozen users rather than a few hundred isn't beneficial for everyone and if all the information of the CheckUser case is already publicly available then CheckUser input doesn't really add anything. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:16, 4 August 2021 (UTC)
@Donald Trung: "all the information of the CheckUser case" has never been "publicly available" for reasons of privacy. The functionaries sign legal agreements to that effect and police themselves as a team, as we elected them to do. If we need more of them, we can elect more. If they misbehave, we can vote them out. — Jeff G. ツ please ping or talk to me11:37, 4 August 2021 (UTC)
Just to avoid any misunderstanding, this proposal makes zero changes to how confidential checkuser information is kept confidential. --Fæ (talk) 08:42, 6 August 2021 (UTC)
Neutral I think this is actually covered by existing policy -- as noted by Christian above, a CU block is not to be used unless there is non-public supporting evidence -- "on the basis of technical checkuser evidence". Therefore I see no reason for it, but equally, no harm in it. In a way, it's a little strange that it presumes that there is a need for this additional rule because CUs do not always obey the existing policy, but trusts the CUs to obey the new rule. . Jim . . . (Jameslwoodward) (talk to me) 13:15, 26 August 2021 (UTC)
It's not an additional rule, the proposal uses "qualify", i.e. "extra detail or explanation". It seems remarkable how folx, including checkusers, have read presumptions in the proposal that, as the proposer, I know are not there. --Fæ (talk) 17:52, 26 August 2021 (UTC)
Discussions
i think the checkusers should specify the sock master either in the block log or on the user talk page. sometimes it's quite hard to find out who exactly operated the sock.--RZuo (talk) 13:21, 30 July 2021 (UTC)
Comment I think on Commons, checkuser blocks can always de facto be overturned by community consensus. This is not true on English Wikipedia, where any admin who tries to implement such a community consensus might find themselves desysopped by ArbCom. Our desysopping process belongs to the community alone, so we obviously would not desysop an admin over an action that was taken with the support of a majority of the community. -- King of ♥ ♦ ♣ ♠14:29, 30 July 2021 (UTC)
No, the Wikimedia Commons checkuser team believes they have the authority to desysop any administrator that removes a checkuser block without their permission. COM:BP does not state this, but it does say that only checkusers can remove a checkuser block. This amendment better defines the scope of that authority.
The current interpretation of policy is that checkusers can ignore any community consensus about their actions, though the community could ultimately remove Commons checkusers by running desysop votes, which they could not ignore or override. However, no Wikimedia Commons vote or community consensus could do anything about global stewards or WMF staff who choose to give themselves checkuser access or take other actions. --Fæ (talk) 14:33, 30 July 2021 (UTC)
The key difference is that English Wikipedia has ArbCom, and Commons doesn't. On Commons the only desysopping mechanism is via a Request for de-adminship. Checkusers do not have the technical ability to desysop users, and there is no policy that would allow a crat or steward to desysop an admin upon request by a checkuser. -- King of ♥ ♦ ♣ ♠14:42, 30 July 2021 (UTC)
In any case, this proposal appears to be an attempt to regulate CU behavior, but it is unclear what the enforcement mechanism is. Is it a strictly a behavioral issue, i.e. checkusers who repeatedly violate the provision and improperly label a block as a checkuser block will be subject to community de-CU? Or is the community allowed to challenge the status of an existing block as a checkuser block, and have it declared a normal block regardless of what the checkuser originally said? -- King of ♥ ♦ ♣ ♠14:48, 30 July 2021 (UTC)
Well, theoretically perhaps. But consider that one of the 'crats is in the Commons checkuser team, hence in their private email list. Further, the checkuser team could defend their authority by placing a checkuser block on any sysop who reverses their decision, then threaten to place checkuser blocks on any sysop that tries to reverse that. No doubt the 'crats would pretty much have to support checkuser decisions made in private anyway. I seriously doubt any of this would ever happen, as I presume that the vast majority of sysops, as well as checkusers, would understand it as a symptom of a serious breakdown in trust.
With respect to your last point, the community does not formally have any power to challenge a checkuser block, but as in the recent case, ignoring serious community discussion about a possibly unfair block, or claiming a community consensus has no "technical" authority, is a very bad place for checkusers to choose to remain standing as ultimately, they can all be desysoped and we (the wider community on Commons) can vote in a new set. --Fæ (talk) 14:55, 30 July 2021 (UTC)
I don't think "removal of all CUs when they defy the community" is a good final enforcement mechanism (as I think you are implying; it seems you are just suggesting an exhortation for CUs to "play nice" before it gets to that stage). Instead, we should just amend the policy to make it clear that the community always has the authority to overturn checkuser blocks via consensus. -- King of ♥ ♦ ♣ ♠15:05, 30 July 2021 (UTC)
That's a separate discussion, but could be a separate proposal. However, I doubt it would pass as there are always cases where CU evidence really should stay confidential, such as when there are legal issues or serious personal harassment that is inappropriate to discuss in public. CUs should be fully trustworthy to make those judgement calls, if not, then there's a problem with the nomination and election process. --Fæ (talk) 15:10, 30 July 2021 (UTC)
And the community would respect the CU's judgment in such cases as long as a reasonable explanation is given why the info needs to be kept private. We can view your proposed wording as a guideline not only for checkusers, but for the community. That is, we trust checkusers to label their blocks correctly in line with the policy in a vast majority of cases, but the community has the final say on whether something is a checkuser block. -- King of ♥ ♦ ♣ ♠16:36, 30 July 2021 (UTC)
Yes, rereading your words here, ultimately accountability is to the wider community and a necessary responsibility of the wider community. The fact is that checkuser rights have been abused in the past (I'm thinking of cases on other projects) and if either the checkuser policies or their implementation leads to unfair treatment of users, then the wider community needs to be able to know those failures have happened and needs to be assured that corrective and preventative action has and will be taken. Too often the failures are classified as "confidential" or have "private" implications when an open examination of the facts would be far more beneficial long term and reporting the facts would involve no exposure of private data.
After over 15 years contributing to these projects, I fully understand that failures happen and systemic bias is impossible to eliminate; that doesn't mean we should not seek to improve. --Fæ (talk) 09:58, 4 August 2021 (UTC)
Thanks for chipping in AFB. This proposal does not hinge on that case. However that block was controversial at the time it was placed, and it gave the appearance of being heavy-handed as the evidence of socking was uncontested and a matter of public record. As such there remains no obvious justification for insisting that a checkuser block was necessary or that a non-checkuser block would not have been sufficient. There should be a lesson to be learned from that case, it's surprising to see the level of defensiveness by the checkuser team against this incredibly minor proposal, that only clarifies current best practices and makes absolutely zero difference to how the community trusts checkuser judgment over what is or is not necessarily confidential information or when a checkuser block is justified and necessary.
By the way, with re-reading the statement by James you kindly referenced, I read "permanent block" as a block, if it was supposed to be a ban or something else, this should have been explained. It remains unexplained as to why a "permanent block" could not have been managed as an ordinary block, perhaps with a recommendation from the CU team as to minimum duration. In reality it looks like a 6 month or 12 month block minimum might have been the recommendation at the time, had the CU team chosen to let that be managed by the sysop team. There is an obvious parallel here with how Arbcom does not directly block users, but makes a recommendation based on evidence and that some of that evidence may remain confidential. There's nothing wrong with handling things in that more transparent way, in fact, there are obvious benefits of demonstrating trust in the wider sysop team and a certain suitable humility in the way that trusted roles like checkuser keep their exercise of special authority or powers to a minimum and only when completely necessary. --Fæ (talk) 08:40, 6 August 2021 (UTC)
Well, even you state that this “proposal does not hinge on that case” it appears to be something like a lex Alexis Jazz and cases like this are pretty rare at Commons. I want to remember that this case was serious and it took (at least for me) some time to see the cross-wiki extent of that case. A “permanent block” is still the maximum here at Commons as we have no Wikipedia:Banning policy (Q6140266) as en:wp. But I still think that Alexis Jazz can be grateful that he wasn't globally banned. In summary, I do not think that we need a policy extension as proposed. I wish, however, we would have it the other way, i.e. if there are no objections by the CU team, we should have an open discussion like we did before where I proposed some preconditions for an unblock.--AFBorchert (talk) 09:55, 6 August 2021 (UTC)
However, it should be noted that you are linking to public statements, therefore the information is public and not in a practical sense reliant on any confidential information. (I'm going to avoid re-litigating any case here, so let's be generic) If someone's behaviour crosses the line into harassment, unlawful material, legal threats or cross-wiki disruption, these are firmly and clearly addressed using existing policies on blocks, global bans or WMF office locks. The decision on whether a case needs a checkuser block, is not down to how "serious" the behaviour is but on whether a block action is reliant on confidential checkuser information.
We know of many cases where contributors, even past administrators, have been "tired and emotional" for whatever reason, and make stupid but hurtful threats of harm to others or themselves. Everyone would agree that obvious cases of long term abusers should result in global bans or locks and associated sock accounts that continue that abuse for very good reasons get quietly locked without public discussion. As a founder of WMLGBT+ I am aware of plenty of cases where people are targets of long-term abuse, including the threatening use of real-life information, over many years, and it is a necessary part of our policies to ensure that people who are targeted with abuse or persistently unfairly treated have support and protection to contribute in a non-hostile environment. Thumbs up to all that.
However just as WMF T&S are re-examining the conditions where they can better provide for natural justice (i.e. a right to a fair hearing, protection against bias and provision for reasonable individual reform) the avoidable use of checkuser blocks should be a matter of community examination and improvement. The forthcoming implementation of the UCoC may be an opportunity for this to happen across projects.
In all cases we should follow an approach of necessary and sufficient enforcement and especially when cases may be an aberration which for all we know may be due to transient mental health issues, obsessive behaviours which may improve over time, or where the process of a proper appeal may reach a joint understanding of how a person can contribute without creating a hostile environment for others.
This reads as a bit of a tangent to this one line proposal, but the point of this proposal is a slight nudge in this direction of fairness and better transparency. I expect you have an interest in seeing these types of improvement, I hope that the majority of the checkuser team do, however for many reasons Commons policies in this area appear entrenched and hard for volunteers to revise or even discuss without so much work it's no longer really a job for an unpaid volunteer. --Fæ (talk) 10:27, 6 August 2021 (UTC)
Again, {{Checkuserblock}} has been used 121 times in total including a good deal of IP addresses and non-user pages. In the blocking logs we will find significantly more cases without an associated notice on the talk page but this is mostly reserved for socks with little activity. The non-trivial cases are rare and a checkuserblock, as I understand it, is per definition based on non-disclosed information. This has naturally to be reviewed by the checkusers who have access to the full non-public information. Hence, I still do not see why we need to revise policy here. And you surely do not want to discuss “transient mental health issues” in public, or do you? --AFBorchert (talk) 13:36, 6 August 2021 (UTC)
This proposal is a minor clarification of policy. How many accounts it affects is not that germane.
If there is something you wish to raise in a different thread, I'm happy to be part of a public discussion about ensuring our project's policies do not have an implicit bias against volunteers with mental health issues or who are not neurotypical. I'm no expert, though I have friends and family members that make these judgments and assess claims based on mental health every day. There are folx on our WMLGBT+ network that have experienced bias against them because of perceived mental health status and on some of our projects simply identifying as LGBT+ can make you a target of allegations of having a mental disorder. As for me, I think I've only had death threats and allegations that I'm sick, that seems to be the normal hostile environment we are supposed to put up with if you hang around long enough. --Fæ (talk) 15:50, 6 August 2021 (UTC)
Proposal to create a new user group that can view deleted files
Page-viewers can view deleted pages and request undeletions, but cannot undelete any files themselves.
I would like to propose the creation of a new user group known as "Page-viewers", these users would be able to view deleted pages and have a button that states "Request undeletion" which will create a request at the undeletion requests in the same manner that all other users can nominate pages for deletion. Now because page-viewers get access to copyrighted content they will have to be elected in the same manner as administrators, but because this user right has a lot less responsibilities it will likely be easier to pass for those who need the right.
The need for page-viewers, as more files ascend to the public domain Wikimedia Commons has a larger amount of files that have once been deleted that are now in the public domain. When Wikimedia Commons was created in 2004 a lot of files that were then copyrighted are now in the public domain and not all deleted files are tagged with "Undelete in 20XX". As more files will enter the public domain in the future I believe that while initially only a small number of users will be granted this right (probably only a few dozen in the coming decade), I expect this to be a much more viable right in the long-term future.
Furthermore, I remember several years ago that there was a proposal to let OTRS volunteers have the ability to view deleted files, this proposal failed primarily because of the fact that many users commented that "OTRS members are not trusted users regarding to Commons point of view as they are not appointed by the Commons community." This would fully solve the trust issue with this as OTRS members would have to be vetted by the Wikimedia Commons community to be able to view deleted files and they still won't be able to undelete files directly.
Who should be page-viewers?, By preference, most page-viewers would be license reviewers with years of experience and/or already have a good record of requesting undeletion. As noted above OTRS / VRT volunteers that are trusted by the Wikimedia Commons community should apply as well. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:23, 12 July 2021 (UTC)
Support in principle. There have been many times that I've been trying to help newbies who had a file deleted and wanted to learn more about why. Often it's straightforward, but other times it's less clear. The nuance of a deletion cannot be understood through the deletion log in many cases, and it would be useful to be able to just take a quick look. There have also been many times where I wanted to learn more about Commons' history with a particular subject (say, freedom of panorama). It would be useful to be able to see where lines have been drawn in the past by seeing what has been deleted. This is, of course, all in addition to Donald's reasoning. One point, though: I don't think this should require an election. Just add it to COM:PERM and set forth some requirements. — Rhododendritestalk | 21:36, 12 July 2021 (UTC)
Strong oppose At Commons the most prominent deletion reason is copyright violation, so the content is deleted because it may not be published. It would be against the intention of everything we like to achieve here if we allowed additional users to view such content without having a definite rule set who this right shall be granted and used. The current regulation is that only admins may view deleted content, and we have procedures how to appoint and remove admins. Project goal is not to establish as many new rules as possible, please keep it simple and request regular adminship if you need it. --Krd04:23, 13 July 2021 (UTC)
Oppose There is a reason why files get deleted. Deletion means that nobody should see it, because it violates the law or the rules of commons. And besides that, there is a set of users that already have the right to view deleted files, and they are called admins. All it does is that already deleted files will be discussed a second time... a third time... All the while there are thousands of new files every day that need review and there is a backlog of months on files that are nominated for deletion. If you honestly "need" that kind of user right, there is a way to get it: get elected as admin.--Giftzwerg 88 (talk) 07:06, 13 July 2021 (UTC)
How does the backlog on deletions have anything to do with this? And what's wrong with discussing deleted files a second time in some cases? It's no different than having a second DR on the same file, which happens sometimes for good reasons. We should not stop valid undeletions on grounds of backlogs or whatever.--Prosfilaes (talk) 00:15, 2 August 2021 (UTC)
Oppose as per Krd and Giftzwerg - Most deletions are copyvios and I also agree that admins should be the only ones to see the content and to have it undeleted. Apart from that DR amongst other places are already full to the brim - Do we really need another backlogged venue? Obvious answer is no. I appreciate Rhododendrites' sentiments above but I still believe there's no need for this right. –Davey2010Talk19:42, 14 July 2021 (UTC)
Oppose Unless we hear from the WMF Legal team that they would be fine with this. I think that, from a copyright point of view, the legality of an user group (admins) still able to view content that was "deleted" for copyright reasons could already be questioned, but I hope this will continue to be allowed, as only in this way we are able to process undeletion requests and restore files that went into the public domain after deletion or were wrongfully deleted. But for copyright reasons, this user group can not be made too large. It must remain restricted. Maybe a very small "page viewers" group would still be okay, but then, it would seem to add unnecessary complexity - just elect a few administrators more. Gestumblindi (talk) 09:48, 21 July 2021 (UTC)
Oppose per Krd. Most of the deleted material are copyvios and we need to limit the number of people who are able to access these files to avoid a conflict with copyright law. Hence, this is not about whom we possibly trust but how do we keep nearly all deleted material restorable to support COM:UNDEL and to restore files where the copyright expired. This is also one of the reasons why we have a policy where the admin bit is removed from those who are inactive. --AFBorchert (talk) 17:29, 23 September 2021 (UTC)
Support While I do agree with the sentiment "Just have more administrators", administrators do many other things and are not chosen simply because they can identify files that need to be undeleted. And having "copyright administrators" (licence reviewers on steroids) would just be cumbersome. ℺ Gone Postal (〠✉ • ✍⏿) 05:55, 17 October 2021 (UTC)
Notes: Following a village pump discussion I have decided to change the proposal to be among the many "admin lite" / "sysop lite" user groups I wish to propose and I will no longer propose that this user group be divided into "levels" (as I had originally done, where it would be divided into 3 (three) levels where some users can view more sensitive pages and only those are elected) as this user right will be fully electable if accepted, meaning that maximum trust is already required. This solves both any potential legal ⚖ issues raised by the WMF and not "water down" the trust required for those who deal with such sensitive files.
They will have an election process identical to administrators, but I imagine that they will receive less scrutiny as they will not be able to block/ban users, delete pages, undelete pages, give user rights, Etc. So the question is only if we trust them enough to see sensitive content, which is still a huge responsibility and needs to be properly vetted and I expect only those with good reputation to acquire the trust of the Commonswiki community. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:59, 12 July 2021 (UTC)
@Rhododendrites: , the election part is very much necessary, as otherwise the WMF will essentially "veto" it, as you can see in the linked archive to the previous proposal from 2017 and the decades such discussions have gone on Wikipedia, it is necessary for this user right to be vetted for it not to become a legal liability for the Wikimedia Foundation (WMF). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:51, 12 July 2021 (UTC)
Could you highlight where in the discussion it arises that the WMF would veto community processes other than elections? Allowing people who have already been granted OTRS access the ability to view deleted files would circumvent any vetting for that tool in particular, and many OTRS volunteers aren't active at all on Commons. But here we vet reviewers, GW toolset users, template editors, etc. locally, in addition to admins... just not through elections. — Rhododendritestalk | 21:58, 12 July 2021 (UTC)
Specifically at "Symbol oppose vote.svg Oppose mostly because the WMF has repeatedly stated over at enwiki that they will shut down any attempt to grant editors the ability to view deleted files unless it stems from a community process. Even if this got approved, the WMF would just shut it down. ~ Rob13 Talk 02:20, 10 March 2017 (UTC)", also in the Village pump discussion where I received feedback from Alexis Jazz on Wikipedia I noted these concerns. Trust is indeed always involved with user rights, but this is a legal issue and essentially would open the door for more "admin lite" / "sysop lite" user groups through similar processes in the future. Wikimedia Commons has large backlogs and having more users take the workload off of admins should be welcomed. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:10, 12 July 2021 (UTC)
@Krd: , replying to "It would be against the intention of everything we like to achieve here if we allowed additional users to view such content without having a definite rule set who this right shall be granted and used." the process would be exactly the same as asking for regular admin rights and many OTRS / VRT members that now frequent UnDR will likely request it, asking for regular admin rights means that we should trust these users with also deleting, undeleting content, blocking/banning users, giving user rights, Etc. which requires a lot more trust, but this user right only requires trust in dealing with deleted files and the users will be vetted in a manner identical to the admin process, it wouldn't introduce any more complicated rules, just apply existing rules to a group of users that want a single admin right, kind of how rollback was exclusive to admins many years ago, but because this content is more sensitive still requires wide community support on a person to person basis. Plus this would also fulfill the ability "for the OTRS agents to finish their work without needing admin assistance in every case" you supported ten years ago at "Commons:Village pump/Proposals/Archive/2011/11#OTRS member permissions" just now they would need community support before viewing such files.
Also, I think that a lot less users would pass RFA if all admins had checkuser and bureaucrat rights because those require more trust than "regular" admins, new user rights are usually created for a reason, because we wouldn't trust a user to do A to must have the ability to do B if they only have experience with A. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 04:45, 13 July 2021 (UTC)
None of your arguments is in opposition to mine. I still think that VRT members could have this as a part of their role, not by a separate process, but this is unlikely to happen. As far as an open process is concerned that is available to anybody, I'm opposed. We cannot grant participation in copyvio sharing just honorary. Even the possibilities introduced for VRT members (undel req page on VRT wiki, etc.) are not used at all, so at first a real need shall be shown. Do you have any numbers how many VRT agents are active on commons who are not admins and not likely to pass a RFA? --Krd05:53, 13 July 2021 (UTC)
Jeff G. is a VRT volunteer that failed RFA 4 (four) times, but I think that they are very unlikely to not be elected to become a Page-viewer, yet their name often pops up at UnDR and they even his own preload for UDR's. If an entire category gets deleted because the author's / sculptor's death was 65 (sixty-five) years ago and then someone wants to request undeletion five (5) years later then they can already filter out the good uploads from the bad (as in the one with more issues such as other copyrighted features or simply blurry photographs) saving the undeleting administrators time and work. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:45, 14 July 2021 (UTC)
Does "page" actually mean page, or does it mean "media file" in this proposal? Would it not make sense for the proposal to be requesting access to deleted media files rather than a right to undelete pages? --Fæ (talk) 19:24, 14 July 2021 (UTC)
@Fæ: , depends on what access is needed, Wikimedia Commons is primarily media orientated but I don't see any benefits in disallowing them to also see other pages. Regarding the final question, that is what the proposal is, these users wouldn't be able to undelete anything only view deleted pages and then they would still have to ask administrators to undelete it for them. As I expect them to be elected from experienced license reviewers I don't expect them to file any bad requests to delete an image of a statue or work of architecture made by a Russian that died 60 (sixty) years ago or something because rookies likely wouldn't get this right. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:45, 14 July 2021 (UTC)
I don't know how that would work. My experience with sysop tools is that with "View and restore deleted pages" you undelete files to look at them, though you can be selective with which revisions are made visible so can restore a file with just a blank text page. I think there's no easy interface to show users deleted files without making them visible on-wiki. Happy to be corrected if there's some special Commons utility. --Fæ (talk) 19:56, 14 July 2021 (UTC)
Could do with some screenshots of a test file to show what we are talking about. I don't think this is in the standard mediawiki software, that is to say, even if the rights exist, the functionality of the software may not do what you expect.
(Supplemental) At the back of my mind there's a discussion of this from several years ago. A benefit of forcing users to undelete on-wiki during, say, an UNDEL challenge, is that single user only previews of deleted files would be unlikely to leave any logs. Just as Checkusers have special requirements due to the potential for abusive use, there are abuse scenarios when there are no public logs that this raises, including files thought unlawful, abusive or damaging if harvested and published elsewhere. As a proposal, this needs to be underpinned by the detail of the workflow to ensure people understand the extra risks to this project and our contributors that this might introduce. --Fæ (talk) 20:34, 14 July 2021 (UTC)
Okay. I have no idea how this works as it cannot be via the View and restore deleted pages interface. The only options are undelete, undelete specific revisions, or suppress deletion visibility i.e. some deleted file versions can be less public. If a sysop can do this, I would like to see the specific guidelines that sysops are supposed to follow for when to use it and how. --Fæ (talk) 15:25, 22 July 2021 (UTC)
Example for "Page history" and "File history"
@Fæ: For admins, it's actually possible to view "deleted" images via the View and restore deleted pages interface without having to restore them. I have included an example screenshot to show how this works: You will notice that there is a "Page history", and below this, a "File history". If I click on the date in the "File history", I can access the deleted file. It's displayed immediately, no need to perform a restore action first (but stays "deleted"). I guess it would be impossible to handle undeletion requests and similar cases properly if this weren't the case. Gestumblindi (talk) 18:11, 22 July 2021 (UTC)
Thanks, I now see it in practice. The target link includes a "&token=172d043ef..." style token link. I would guess there's a log of these deleted file accesses somewhere, the point of the autogenerated tokens, so they can be audited if there was a security issue. It would be interesting to know how the logs can be checked and whether they are public, even if the deleted files are not.
It seems obvious to me that sysops should not be surfing through deleted files out of curiosity, especially if the deletions might be down to privacy-related requests or hounding. --Fæ (talk) 11:40, 23 July 2021 (UTC)
@Davey2010: , this is to reduce backlogs and not create them. These users can help admins at UnDR's by viewing copyright violations and voting them down, perhaps these users might even be able to close denied undeletion requests reducing the administrative backlog. Further "Most deletions are copyvios", well, copyright doesn't last forever and it eventually expires and not all files uploaded that could be undeleted in 2025 are tagged as such and it would be unreasonable to expect the few hundred administrators to also patrol already deleted files to see if they should be undeleted. Many files that are deleted are files from the 1950's and 1940's with improper sources, a Page-viewer can research a file based on what they can see, you can't file an undeletion request for a file you barely know anything about. Also note that things like authorship and sources are also in file descriptions (because not all new users know that they shouldn't add "Own work" if it comes from their own collection). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:52, 14 July 2021 (UTC)
The proposal states "have a button that states "Request undeletion" which will create a request at UDR so therefore UDR would get backlogged wouldn't?, UDR needs a massive overhaul (ie it needs to get rid of the !voting side) but that's another discussion for another day.
Fair point but I would simply hope the editor reuploads historic content in the appropriate year - not have someone go through all old files and !vote undelete as to be blunt that's just wasting your life away ...., I'm just not seeing a need for this right to be honest, –Davey2010Talk20:12, 14 July 2021 (UTC)
One can always hope, but many people are active only a few years and won't come back when it is time for restoring the file, and only some will keep the file and keep track of when it should be reuploaded. If it is a photo of one's own it may be buried among thousands of other files before the Commons copy is DRed, and the user may not know when the underlying copyright expires – the closing admin is much more likely to know, and those details are often not told in the DR. These are some of the reasons for us to have to-be-undeleted categories in the first place. Ideally those would always be used by the closing admins. –LPfi (talk) 18:27, 22 July 2021 (UTC)
Even if a community voting procedure is added to the proposal, I'm still opposed to it. If you're trusted to view deleted files, then you must be an admin. Period. Unbundling of sysop shouldn't be taken lightly. pandakekok911:49, 23 July 2021 (UTC)
If the concern is that there are many deleted files that may require review in the future, could an alternate proposal be to ask DR closers to indicate when the work is expected to enter the public domain in their closing summary? For example, we could perhaps have a template called "undeletion review", where {{undeletion review|date=2030}} will add the text "This DR is up for undeletion review in 2030" and add Category:Deletion requests up for undeletion review in 2030. Mysterymanblue 17:28, 24 July 2021 (UTC)
The proposal seem to implies that the vetting procedure for these "page viewers" would be similar to license reviewers, which obviously is less strict in its vetting process than RfA. Hence the "privacy nightmare". The privilege to view deleted files is not something that should just be given so easily. As some opposer pointed out, a lot of our deletions are due to legal issues.
But what if we make the vetting process as strict as RfA? Well then your proposal is moot then. If you're trusted to view deleted files, you must be trusted to have the full set of admin tools then. pandakekok913:29, 8 August 2021 (UTC)
It is not the same, trusting a user the ability to permanently kick out other users requires a lot more trust than viewing pages others can't. Bureaucrats and Checkusers essentially go through the same process, should we give all admins Bureaucrat and Checkuser rights because they are trusted anyhow? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:14, 4 September 2021 (UTC)
Working
Done
Support as proposer. --Fæ (talk) 10:49, 30 July 2021 (UTC)
Oppose as a solution is looking for the problem. --Mirer (talk) 13:27, 30 July 2021 (UTC)
Neutral I think this is actually covered by existing policy -- as noted by Christian above, a CU block is not to be used unless there is non-public supporting evidence -- "on the basis of technical checkuser evidence". Therefore I see no reason for it, but equally, no harm in it. In a way, it's a little strange that it presumes that there is a need for this additional rule because CUs do not always obey the existing policy, but trusts the CUs to obey the new rule. . Jim . . . (Jameslwoodward) (talk to me) 13:15, 26 August 2021 (UTC)
Comment I think on Commons, checkuser blocks can always de facto be overturned by community consensus. This is not true on English Wikipedia, where any admin who tries to implement such a community consensus might find themselves desysopped by ArbCom. Our desysopping process belongs to the community alone, so we obviously would not desysop an admin over an action that was taken with the support of a majority of the community. -- King of ♥ ♦ ♣ ♠ 14:29, 30 July 2021 (UTC).svg){kind=icon}
Who should be page-viewers?, By preference, most page-viewers would be license reviewers with years of experience and/or already have a good record of requesting undeletion. As noted above OTRS / VRT volunteers that are trusted by the Wikimedia Commons community should apply as well. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:23, 12 July 2021 (UTC)
Strong oppose At Commons the most prominent deletion reason is copyright violation, so the content is deleted because it may not be published. It would be against the intention of everything we like to achieve here if we allowed additional users to view such content without having a definite rule set who this right shall be granted and used. The current regulation is that only admins may view deleted content, and we have procedures how to appoint and remove admins. Project goal is not to establish as many new rules as possible, please keep it simple and request regular adminship if you need it. --Krd 04:23, 13 July 2021 (UTC)