Commons:Village pump/Proposals/Archive/2018/07

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Speedy deletions: Promotional content

Proposal

I propose to add the following general speedy deletion criterion:

X. Files and pages created as advertisements
This includes only content uploaded to promote goods and services, outside our project scope. Files that illustrate contemporary or historical advertisements do not fall under this criterion.

Rationale: Deleting promotional content is uncontroversial, but currently has to go through a full deletion request - in theory. This increases the burden on administrators. Deleting within a few hours discourages uploads. And in practice, these kinds of files are already often speedy deleted. I tried to word this to make clear that only our typical "Call this number for our fake product: XXX-YYYY-ZZZ" falls under this, not legitimate advertisements that can be used to illustrate period ads. Please suggest improvements below. Sebari – aka Srittau (talk) 12:44, 22 July 2018 (UTC)

Discussion (Promotional content)

✓ Done Sebari – aka Srittau (talk) 12:55, 28 July 2018 (UTC)
This section was archived on a request by: Sebari – aka Srittau (talk) 12:55, 28 July 2018 (UTC)

Speedy deletions: Selfies

I propose to add the following file speedy deletion criterion:

X. Personal photos by non-contributors
This includes low-to-medium quality selfies and other personal images of users that have no constructive global contributions.

Rationale: These kinds of uploads are very common and deletion is uncontroversial. Currently, they have to go through a full deletion request and bind extra administrator resources, especially since they are often tagged as speedy deletions. Additionally, users uploading these images tend to reupload deleted photos or upload new photos under the same name. The latter can currently not be speedy deleted (but often are), and have to go through another round of deletion requests.

I worded this proposal to exclude high quality photos that can be used to illustrate a certain demographic and images of contributors to Wikimedia projects, because deletion is more controversial in those cases. Sebari – aka Srittau (talk) 12:57, 22 July 2018 (UTC)

Discussion (Selfies)

I support this in principle. The usual counter argument is that "small numbers of images (e.g. of yourself) for use on a personal user page" are allowed, and that speedy deletion may discourage someone who is just about to create a user page and become one of our most productive users ever. Of course, back in reality, those users are about as common as unicorns. I believe "useful contributions" should be understood to mean constructive edits outside of one's own user, user talk page and sandbox areas and excluding drafts that are unlikely to be accepted. —LX (talk, contribs) 13:41, 22 July 2018 (UTC)

✓ Done If it turns out the wording needs refinements, because admins interpret this criterion more broadly than intended, this can be adjusted later. --Sebari – aka Srittau (talk) 13:03, 28 July 2018 (UTC)
This section was archived on a request by: Sebari – aka Srittau (talk) 13:03, 28 July 2018 (UTC)

Speedy deletions: Rework category criteria

Proposal

I propose to replace the category speedy deletion criteria with the following:

1. (removed)
2. Improperly named category
Categories with incorrect names may be speedily deleted after their contents have been moved to a properly named category. If the old category name is also correct, a redirect should be left in place. See Commons:Rename a category#Should the old category be deleted?
3. Empty category
If a category is empty, is not a redirect or disambiguation, and has not been marked with an explanation of why it should be kept, it may be speedily deleted.

Rationale: Currently, there are three criteria for speedy deletions: G1 for empty categories in general, C1 for renamed and duplicate categories, and C2 for improperly named categories. C1 and C2 don't require the cat to be empty. This proposal merges C1 and C2 to only allow speedy deletion of improperly named categories (typos etc.) that are empty now. In other cases, a redirect should be added, and a full DR can be used to discuss the merits of deleting the redirect.

Speedy deletion of empty categories is already possible (and routinely done) under criterion G1. This has been controversial in the past. (See for example this discussion.) Adding a separate item not only moves this into the correct category and is directly linkable, it also allows a bit more discussion on when an empty category should not be speedy deleted. Sebari – aka Srittau (talk) 13:24, 22 July 2018 (UTC)

Discussion (Rework category criteria)

  •  Support Accidental creation is often synonymous with improperly named categories, and renaming or duplicate issues can be addressed by redirects. So I don't see a need for the current C1. De728631 (talk) 20:37, 22 July 2018 (UTC)
    • Thank you for phrasing it like that. That was my original reasoning for merging those two, but this got somehow lost while drafting the rationale. Sebari – aka Srittau (talk) 20:57, 22 July 2018 (UTC)
✓ Done
This section was archived on a request by: Sebari – aka Srittau (talk) 13:13, 28 July 2018 (UTC)

Speedy deletions: corrupt files

I propose to amend file criterion #7 like this:

7. File is empty, corrupt, or in a disallowed format
Empty file pages are subject to uncontroversial speedy deletion, unless they are being used as redirects. The same is true for corrupt or invalid files or files in a disallowed format.

Rationale: Corrupt files have no educational value and should not remain on Commons. Speedily deleting these files is already common practice, and the dropdown for file deletions already contains wording to this effect. Sebari – aka Srittau (talk) 14:21, 22 July 2018 (UTC)

Discussion (corrupt files)

 Support And that is fine for me as long as that is cleared up. -- Sixflashphoto (talk) 20:50, 22 July 2018 (UTC)
@Jeff G.: in case of Flickr uploads (that seem to break a lot lately), it's actually easier to reupload after deleting the failed upload. - Alexis Jazz ping plz 21:20, 23 July 2018 (UTC)

It should be clarified that clarified that this does not include files affected by bugs in Mediawiki's thumbnailing or rasterisation functions (CMYK issues, black boxes in SVG files etc). Srittau: Please also advertise these proposal discussions at Commons talk:Criteria for speedy deletion. —LX (talk, contribs) 21:05, 22 July 2018 (UTC)

@LX: Good call. Could you make a proposal on how to word that? Also, I left a note at the talk page. Sebari – aka Srittau (talk) 21:25, 22 July 2018 (UTC)
"This does not include files that are rendered incorrectly because of current defects in the Mediawiki software." —LX (talk, contribs) 21:29, 22 July 2018 (UTC)
A more practical approach: "Empty file pages are subject to uncontroversial speedy deletion, unless they are being used as redirects. The same is true for files that are corrupt or invalid when viewed in full resolution, or are in a disallowed format." Rationale: simply clicking the file to get the full upload resolution will circumvent the rastered preview, so you can detect original flaws without the need to know about current MW bugs. De728631 (talk) 21:34, 22 July 2018 (UTC)
  •  Question Doesn't G1 "Test page, accidental creation, or page containing nonsense or no valid content" already cover this? - Alexis Jazz ping plz 21:20, 23 July 2018 (UTC)
    • You are right, this could be used to delete those kind of files. Nevertheless, I'd prefer to subsume it in the file-specific criteria to make it more explicit, and add more context as in the proposals by LX and De728631. Especially given the fact that we don't need a new criterion, but can amend an existing one. (Which has been used in the past to speedily delete those files.) Sebari – aka Srittau (talk) 21:36, 23 July 2018 (UTC)
  •  Question Some files are only partially broken and could potentially be saved by cropping away the broken sections (example file, this is actually pretty common). Whether or not they should be deleted depends in how broken they are, what portion of them can be salvaged and whether the content is worth the effort. Would this kind of file be covered by the proposed criterion? I think it might be better to have a normal DR for them … --El Grafo (talk) 10:04, 24 July 2018 (UTC)
    • From my point of view this is exactly the situation where you would want to employ this new CSD. Cropping partially broken files may only worsen the situation when it leaves the file with little to no useful content. A clean new start with a whole file is always preferrable to tampering with broken graphics, so these should be speedy deleted without the need for a formal DR. De728631 (talk) 10:11, 24 July 2018 (UTC)
    • As De728631 said, half-broken files are the common case, and in the majority of cases there is nothing useful safe. Of course, as with all speedy deletion requests, I'd expect admins to exercise judgement and to not speedy delete "saveable" images. Maybe we could add this to the wording. Sebari – aka Srittau (talk) 11:00, 24 July 2018 (UTC)
      • @Srittau and De728631: sometimes users upload files, something goes wrong and they never try again. For example, a whole bunch of Niagara photos (some good ones too) was lost like File:Winter Niagara fall.jpg. Those particular files couldn't be saved (no file page or license due to technical failure). If something useful can be cropped from the broken upload and it's own work, it shouldn't be speedily deleted. - Alexis Jazz ping plz 21:03, 24 July 2018 (UTC)
        • That is why speedy deletion requests are not blanket cheques that require deletion once they have been made. The reviewing admin can still deny the speedy request, but at least we ought to have the possibility to speedy delete those files that are obviously beyond saving. De728631 (talk) 21:09, 24 July 2018 (UTC)
  •  Support --Yann (talk) 11:35, 24 July 2018 (UTC)
  •  'Support - I can't see anyone uploading disallowed files but if they somehow manage to then this would have a use I guess. –Davey2010Talk 22:24, 24 July 2018 (UTC)
  •  Question Are we disallowing raster graphics in SVG files?   — Jeff G. ツ please ping or talk to me 02:15, 25 July 2018 (UTC)
    Only if they are fully raster, as Template:FakeSVG, I would support. -- User: Perhelion 04:55, 25 July 2018 (UTC)
    I wouldn't want this as a speedy deletion criterion. It seems a full DR is best suited to handle those cases. Sebari – aka Srittau (talk) 13:52, 25 July 2018 (UTC)
  •  Support Natuur12 (talk) 13:42, 25 July 2018 (UTC)
  •  Question What is the definition of the "corrupt file", is a file that is damaged or encoded with some non-standard utility corrupt? What if the information in it is educationally useful, but current MediaWiki software has issues displaying it for whatever reason? I guess I am saying that corruption comes in different shapes and sizes and the video file that is missing audio for a few last seconds is not the same as random bits uploaded as a bitmap file. ℺ Gone Postal (〠 ✉ ✍ ⏿) 15:47, 25 July 2018 (UTC)
    Please see the discussion above and the additions by LX/De728631 for those points. As always, admin discretion. Sebari – aka Srittau (talk) 18:11, 25 July 2018 (UTC)
    Ok, thanks a lot.  Oppose I see that most likely this proposal will win, but I am very scared to have something like Speedy Deletion being something that is so broad. The problem is that the chances of it being abused are enormous and there will be no way to counteract such abuse because ... you know ... "per COM::DAMAGED". ℺ Gone Postal (〠 ✉ ✍ ⏿) 20:07, 25 July 2018 (UTC)
    Gone Postal: Actually, I don't know. Can you elaborate? How and to what end would administrators abuse such a criterion? If administrators are so abusive, why would they care about whether or not such a criterion exist? So shouldn't we already be seeing abuse like that? And if such abuse actually were to occur, why could it not be counteracted by undeletion and removal of administrative privileges? Can you point to any deletion discussions or out of process speedy deletions where files were falsely claimed to be corrupt? —LX (talk, contribs) 21:07, 25 July 2018 (UTC)
    @LX: Ok, here's the scenario: Aliens come to Earth and there is only a single person there with the camera, luckily for us this person records the whole thing, unlickily for us this person develops some video codec that nobody else uses, but with the code published somewhere. This user then reencodes the video into that codec, and packs it into a webm file by self-written tool, but due to that person interpreting webm standard documentation the tool breaks something in the container's header. All the video tools report that the file is a webm file with no streams inside of it. The only positive thing in this story is that before going insane from the experience the person does upload this video to Commons. But low and behold, an administrator within couple of minutes looks at the file and speedy deletes it. Not because the admin is evil or hates Aliens, simply because ... you know ... "per COM::DAMANGED". If the deletion request would have been made, somebody may have recognised that the stream data is still there and the attempt would be made to recover the data. But as it stands we have lost the record of the momentous occasion, and would have to make due with recreations made by kids discovering video-blogging and trying to get views on their channels. Something tells me that it already would be quite hard to ask administrator to undelete a video file that wasn't playable with the rationale "Let me try to take a look at it to confirm that it isn't playable", but after this proposal passes (once again I have little reason to think that it won't based on all the support votes) the admin might actually see you as disruptive for attempting to recover the data. ℺ Gone Postal (〠 ✉ ✍ ⏿) 03:09, 26 July 2018 (UTC)
    Yeah okay, thanks for clarifying. I don't think the word "abuse" means what you think it means but... I'll let you do the worrying about aliens. —LX (talk, contribs) 09:30, 26 July 2018 (UTC)
    Abuse means doing something with your power that isn't intended originally and damages the project (in this context). Aliens were a sarcastic example, substitute it with any event that we would want to have here. ℺ Gone Postal (〠 ✉ ✍ ⏿) 11:14, 26 July 2018 (UTC)
    @Gone Postal: but the admin is in a good mood and temporarily undeletes the file. The contents are restored, everyone is blown away by the video because, you know, aliens. Then, someone tags it as "no permission" because "dubious own work claim" and one week later it's deleted again. - Alexis Jazz ping plz 15:42, 26 July 2018 (UTC)
  •  Support Christian Ferrer (talk) 18:42, 25 July 2018 (UTC)
  •  Support --jdx Re: 09:38, 26 July 2018 (UTC)
  •  Question I share User:Gone Postal view. What about partial corrupt uploads? 20% of image might be corrupt, but the rest is an amazing photo?--BevinKacon (talk) 18:45, 26 July 2018 (UTC)
✓ Done I've gone with De728631's wording of LX's amendment. Sebari – aka Srittau (talk) 13:20, 28 July 2018 (UTC)
This section was archived on a request by: Sebari – aka Srittau (talk) 13:20, 28 July 2018 (UTC)

Proposals to improve the appeal options for blocked users and making sure they're properly informed

In light of recent events and many older ones that didn’t get the same level of scrutiny it’s clear that Wikimedia Commons’ possibilities to appeal a block need to be widened and users need to be more informed on how they can appeal. One such solution could be creating a UTRS for Wikimedia Commons, this system should be able to be accessed to all Commonswiki sysops and would eliminate the current issue where users who can’t appeal on-wiki to use an alternative revenue.

Because of the way the block that lead to this was conducted I would suggest an extra layer of scrutiny for both the deciding sysop and the blocked user by not making the readability of the UTRS appeal publicly accessible but with every appeal the appealing person will get the option “Do not make this appeal accessible to non-administrators”, this would also be necessary for appeals that concern private information. Of course as not every blocked user knows that these options exist (and in fact some users only learn of the en-wiki UTRS after their first appeal has been denied), both a full fledged guide to appealing blocks could be created and possibly a template for blocked/banned users’ "Miranda rights" could be left at all currently blocked users’ talk pages.

It’s also possible that the same UTRSBot from the English Wikipedia could deliver the templates here or maybe a separate Commons UTRSBot would have to be created. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:52, 10 July 2018 (UTC)

Comments and votes (UTRS)

  • By searching the "Contact us" button. It's the same you would have to do when banned on any other website when you don't know how to appeal a block. Natuur12 (talk) 18:35, 10 July 2018 (UTC)
Well, my biggest issue is the next one about notification. I think there should be some information on the block notice about the {{Unblock}} template or the email address if indef'd.–CaroleHenson (talk) 18:41, 10 July 2018 (UTC)
  • Comment - There has been a misunderstanding of the blocking templates. No bot places the template on the user page.W:Wikipedia:Template messages/User talk namespace/Blocks. When an admin blocks an editor, they are required to manually place a template on the blocked user's page. If the blocking includes removal of talk page access, that is part of the template the admin places on the user page. In the case of removal of talk page access, the template has a message of how the user can appeal the block. In the link I provided, see the pink template. Maile66 (talk) 00:02, 11 July 2018 (UTC)
    • The templated block notifications here at Commons are substantially different from the ones at the English Wikipedia. In fact none of them has a hint at how to appeal the block, and there is no special version for blocked users without talk page access either. De728631 (talk) 00:18, 11 July 2018 (UTC)
I wasn't confusing them. Donald Trung made the comment above, "It’s also possible that the same UTRSBot from the English Wikipedia could deliver the templates here." I was clarifying that the templates on English Wikipedia are not delivered by bot, but manually by the blocking admin. Therefore, whatever you come up with here has to be targeted to the Commons method of blocking. Maile66 (talk) 00:24, 11 July 2018 (UTC)
Ah, that's alright then. And I have to correct myself: {{Promotional user block}} and {{Checkuserblock}} do have unblock instructions. De728631 (talk) 00:27, 11 July 2018 (UTC)

Blocked users deserve notification of right to appeal

Due to a current issue where the issue was raised that most users on Wikimedia Commons with no talk page or e-mail access have no right of appeal I have decided to continue with my attempt at creating a standard template that all blocked users should receive on their talk page placed there by a bot similar to User:Wikimedia Commons Welcome. Part of this proposal is that it will be added retroactively to all user talk pages to currently blocked users.

Original English Wikipedia proposal this is based on

The “Blockbox” for blocked users.

It appears that you have been blocked.

Please read the guide to appealing blocks.

* If you are currently unable to access your talk page you may request an unblock via the Unblock Ticket Request System or the #wikipedia-en-unblock chat channel.
* Checkuser and Oversight blocks may be appealed to the Arbitration Committee.
* If you were blocked by Jimbo Wales then you may appeal directly to him and/or the Arbitration Committee.
* If this is a Sockpuppet then you should confess your main account (or IP) now so you may receive a reduced penalty.
* If you have been blocked for a username violation then you can simply create or request a new account or request to be renamed here or at #wikimedia-rename, if however the username was made in bad faith then first request a rename and then you may appeal the block; further reading Wikipedia:Changing username.
* If you have been blocked for adding promotional material or spam then please read about our policy on this and our external links policy before requesting an unblock.
** If you continue to violate this policy then the next time the duration of your block will increase. If you believe the link(s) you added aren't spam then you may request for it to be removed from the blacklist.
* If your options are currently still unclear then please read the more technical how to appeal a block.

Personally I envision this box to be light blue with a red title. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:52, 10 July 2018 (UTC)

Wikimedia Commons’ notification of right to appeal

Someone more familiar with how and why the blocking tools and their appeal works could create it.

Comments and votes (notification of right to appeal)

What would be acceptable language for notification from your perspective?CaroleHenson (talk) 17:31, 10 July 2018 (UTC)
The hasty and inappropriate !vote into which we've been carelessly thrust is not a venue for that discussion. Every line of the "box" is inappropriate, including even the patronising false modesty of "It appears that you have been blocked" of the header. I'd be happy to offer input if this were withdrawn for something genuinely thoughtful later to be presented for approval. Эlcobbola talk 18:02, 10 July 2018 (UTC)
Alrighty then, not much helpful information here... other than I'm getting that you don't think that there should be so much information in the block box... nor use of the words "It appears".–CaroleHenson (talk) 18:19, 10 July 2018 (UTC)
Commons appears to be very resistant to change, even when it's clearly necessary. There's no reason we can't have a discussion on how to improve the above proposal here. I don't know of any better venue than the village pump. clpo13(talk) 18:24, 10 July 2018 (UTC)
  •  Comment Rename it. "Miranda Rights" is not correct. Miranda Rights is strictly in American law, and it only refers to the right to remain silent when arrested, and the right to an attorney. Right to a trial by jury is in the US Constitution. But this proposal should not be named after something that is strictly American. Maile66 (talk) 19:21, 10 July 2018 (UTC)

#commons-unblock IRC channel

Also while we're discussing unblock options wouldn’t it also be better if there was a separate IRC channel for users to appeal their blocks? Similar to the one used by the English Wikipedia or the Japanese Wikipedia and the same rules would apply, but as it’s open to sysop-abuse where the same sysop could follow a user and ban them from all channels have this channel be publicly logged so both the appeal and the users being appealed to can be scrutinised. Of course there are some blocks that in fact can’t be discussed in the open and for that a separate #Commons-unblock-private could be created which would not be publicly logged. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:52, 10 July 2018 (UTC)

Comments and votes (IRC)

Withdraw my vote, per Fae. Yes, it is really annoying to come to channels and find noone there. There are likely better options than this.CaroleHenson (talk) 14:24, 11 July 2018 (UTC)
  •  Oppose I see no need. Status quo is perfectly fine. --Steinsplitter (talk) 16:32, 10 July 2018 (UTC)
  •  Oppose The use of IRC is philosophically abhorrent on a collaborative project. Openness and transparency are important; no wiki business should be conducted offsite or out-of-view unless of a genuinely private nature. It's embarrassing that IRC is used at all, and so too a proposal to expand or encourage its use. Эlcobbola talk 16:51, 10 July 2018 (UTC)
  • I don't see a need to have a dedicated channel for such thing. — regards, Revi 17:11, 10 July 2018 (UTC)
  •  Oppose No secret IRC-unblock cabal please. Natuur12 (talk) 17:22, 10 July 2018 (UTC)
  •  Oppose per elcobbola. Storkk (talk) 17:35, 10 July 2018 (UTC)
  •  Oppose per this analysis of IRC. Unblock requests need to be verifiable but if IRC is not logged, that's not going to work. De728631 (talk) 22:45, 10 July 2018 (UTC)
  •  Oppose I'm a little leery of this for two reasons above. Donald Trung says it's open to stalking by the blocking admin. And it looks like it's not a permanent record. Too iffy to be effective. Maile66 (talk) 23:37, 10 July 2018 (UTC)
  •  Neutral If you want to go ahead and create an IRC channel like this, there is nothing stopping you. However those of us who have been around Wikimedia IRC channels for a long time, are aware that there are a lot of nearly dead channels that are so unwatched that a comment there is likely to permanently go without a reply. Such a channel is likely to be unusably quiet. In practice a user that does not understand a block of their account, or is looking for someone to post an unblock request, they can go to #wikimedia-commons anonymously and ask to have a private chat with an admin without saying anything specific in the public channel. This is probably the most practical advice to give to anyone. As they will not be cloaked they should be advised that someone may be able to find their IP address, but if that concerns them they could log in to IRC at a library or cafe as a simple work-around. Note that administrators should never be asked to do anything that may appear to work around a WMF Office action. --Fæ (talk) 09:53, 11 July 2018 (UTC)
  •  Oppose per Elcobbola and Natuur12. --AFBorchert (talk) 12:58, 14 July 2018 (UTC)
  •  Oppose per Natuur12. --Ruthven (msg) 08:31, 15 July 2018 (UTC)
  •  Comment #wikimedia-commons is not a very active channel, so I don't see the need to create a separate one anyway. Yann (talk) 13:55, 16 July 2018 (UTC)

UploadWizard isn't clear enough about re-uploading

I've noticed that many new users will re-upload a file after it's deleted, which of course is improper. I knew there was a warning about this when they attempt to re-upload, but I didn't know the message. I did some tests, and here it is:

It says to check the deletion history before reuploading. So the user does, and they see "Copyright violation". They don't believe it is one, so they re-upload. Often they keep re-uploading, either until they are threatened with a block on their talk page, or they are actually blocked. I think if we change this to be more instructive, referring them to COM:UDEL, they will be more likely to follow our procedures. Less work for admins, less frustration for new users.

It doesn't appear possible to edit the message on-wiki, so we'll need consensus for a new message and then open a Phabricator ticket. Any thoughts and suggestions on this possible change would be helpful. Guanaco (talk) 00:53, 20 July 2018 (UTC)

@Guanaco: "Reupload anyway, I solemnly swear that I am the copyright holder (photographer, image designer, producer, etc.) under penalty of purjury." should make them think twice.   — Jeff G. ツ please ping or talk to me 01:04, 20 July 2018 (UTC)
@Jeff G.: Well, sometimes they actually are the copyright holder. Even then, reuploading is the wrong solution. And it's probably best if we avoid making an unenforceable legal threat. Guanaco (talk) 01:14, 20 July 2018 (UTC)
Could you provide me with an image that would trigger that warning? A URL of a recently deleted image perhaps? I want to try something with the qqx "language" switch. --Majora (talk) 01:06, 20 July 2018 (UTC)
@Majora: File:Reupload test.png should suffice.   — Jeff G. ツ please ping or talk to me 01:09, 20 July 2018 (UTC)
@Majora: This is the file I used for testing, as Reupload test.png: [1]. Guanaco (talk) 01:14, 20 July 2018 (UTC)
As I thought. No need for a phab ticket, Guanaco. The upload wizard uses system messages stored in the MediaWiki namespace. That message can be found here: MediaWiki:File-deleted-duplicate and is easily editable by an administrator. For some background the qqx "language" is a type of debugging mode for MediaWiki. When you add ?uselang=qqx to the end of any page URL it shows you where all the system message come from in the MediaWiki namespace. --Majora (talk) 01:45, 20 July 2018 (UTC)
@Majora: I edited MediaWiki:File-deleted-duplicate. This changed the message for Special:Upload but not Special:UploadWizard. Guanaco (talk) 02:12, 20 July 2018 (UTC)
It changed it. It just broke it though. The upload wizard's message now outputs nonsense because it doesn't like the link. It outputs:
<div id="mw-file-deleted-duplicate" class="plainlinks">A file identical to this file ([[:$1]]) has previously been deleted. You should check that file's [{{fullurl:Special:Log|type=delete&page={{urlencode:$1}}}} deletion history]. If you disagree with the reason for deletion, please make an [[Commons:Undeletion requests|undeletion request]] instead of re-uploading.</div>
--Majora (talk) 02:15, 20 July 2018 (UTC)
I don't think the mediawiki namespace can call templates like that. That space loads first since it is the system messages so things like {{Fullurl}} probably won't work. Try it without the templates. --Majora (talk) 02:22, 20 July 2018 (UTC)
@Guanaco: I think you should delete that page so it defaults back to what it was before and we move this testing to test wiki or the beta cluster. That way we aren't affecting live system messages. --Majora (talk) 02:41, 20 July 2018 (UTC)
@Majora: Right. ✓ Done. I had no idea it would break, as all of this code works fine as standard system messages, but apparently not UploadWizard. Guanaco (talk) 02:45, 20 July 2018 (UTC)
I asked Natuur12 to grant me sysop on the Commons beta cluster so I can test some edits to that system message. It is the middle of the night where they are right now so they probably won't get to my request until tomorrow. --Majora (talk) 02:55, 20 July 2018 (UTC)
It would be jolly nice if the alert message included the deletion comment, which already includes a link to a DR if it exists, and provided a link to the deleting administrator's user talk page so that the uploader is encouraged to ask about the deletion before trying re-uploading. As the deletion comment and the account name of the (most recent) deleter is easy to pull out of the wiki database, this is not an especially complex amendment. --Fæ (talk) 08:26, 20 July 2018 (UTC)
It doesn't appear that any additional information is stored during the process, Fæ. Unlike other system messages, like those used in blocking that have $1 through $7, this message only appears to have $1. The use of $2 did not render any additional information. Although I did get it to work with a link to the deletion log, Guanaco. The templates were indeed the problem. Doing it without them such as in 
[https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Log/delete?type=delete&page=$1 deletion history]
works correctly on the beta cluster. --Majora (talk) 16:05, 20 July 2018 (UTC)
@Majora: For some file names, {{Urlencode}} is required or the link won't work incorrectly. Guanaco (talk) 23:30, 22 July 2018 (UTC)
Could you give me an example for testing purposes? --Majora (talk) 23:31, 22 July 2018 (UTC)
File:Is this a flag? & is it Serbian?.svg should reliably break every time, unless encoded. Guanaco (talk) 23:47, 22 July 2018 (UTC)
@Guanaco: The urlencode parser is definitely the problem. After talking with the devs on IRC they recommended that I file a bug request to get it fixed. I have filed it. If you want to follow it see: phab:T200173. --Majora (talk) 00:52, 23 July 2018 (UTC)

Public Domain Day - 1 January 2019 and every year after

en:Mickey Mouse in the public domain 2024 - en:Copyright Term Extension Act
Copyvio!! Wait wut?

We all in Commons know 1923 as a cut-off year for public domain. This changes in 4 months on 1 January 2019 when the new cut off year becomes 1924. The founding of Commons was in 2004 so the general advice we have been giving for the past 14 years is now going to change, then change again every year.

I just created Commons:Public Domain Day as a place to coordinate whatever needs to happen every 1 January from now on to update years in documentation and also to plan to accept content newly entering the public domain. So far as I know there is no other staging place for preparing for this, but please speak up if there are already plans in place somewhere.

If anyone can post tasks to do to that page then that would help to coordinate efforts. Exciting times! Blue Rasberry (talk) 15:56, 25 July 2018 (UTC)

@Bluerasberry: Category:Undelete in 2019 lists over a hundred pages.   — Jeff G. ツ please ping or talk to me 16:25, 25 July 2018 (UTC)
Thanks, now it is listed on that project page! Blue Rasberry (talk) 16:30, 25 July 2018 (UTC)
@Bluerasberry: You're welcome.   — Jeff G. ツ please ping or talk to me 17:00, 25 July 2018 (UTC)
@Bluerasberry: there was something a while ago. Try searching the village pumps for trump and 1923. (I'm afk now) It was a few months ago. - Alexis Jazz ping plz 21:11, 25 July 2018 (UTC)
Hmmm - not sure about Commons. I see this on ENWP - en:Wikipedia:Featured article candidates/Donald Trump (Last Week Tonight)/archive1. Blue Rasberry (talk) 21:45, 25 July 2018 (UTC)
You’re probably thinking of this discussion on VPC: no mention of Trump, but the American political climate was touched upon.—Odysseus1479 (talk) 23:29, 25 July 2018 (UTC)
That's the one. - Alexis Jazz ping plz 01:06, 26 July 2018 (UTC)

Main Page link broken in Hindi

Hello. I've just discovered that when the interface language is set to hindi (hi) on commons, the url https://commons.wikimedia.org leads to मुखपृष्ठ which is a deleted page, and the actual hindi main page is at मुखपृष्ठ_(hi). The main page link in the left sidebar is similarly broken. The sidebar link can probably be fixed by editing/creating MediaWiki:Mainpage/hi, not sure about the default url. Can someone please look into this? Thanks.--Siddhartha Ghai (talk) 06:18, 28 July 2018 (UTC)

OK, fixed. I did the same for Marathi. I also restored the deleted page, just in case there are more links to it. Regards, Yann (talk) 06:38, 28 July 2018 (UTC)
@Yann: Thanks.--Siddhartha Ghai (talk) 08:31, 28 July 2018 (UTC)

Upload-only accounts

Wikimedia Commons is unlike any other Wikimedia project, first of the “mainspace” isn’t even the mainspace, in fact “File:” is, as most users who come to Wikimedia Commons come here to upload images, books, audio files, Etc. it would make sense that if a user were to be a problem in another respect such as starting a lot of bad deletion requests or beaches of civility then these users are blocked even if all of their uploads were generally good. It’s probably best not to name any examples but it’s not uncommon, but from the top of my head I would name Pieter Kuiper, Vert, and Amitie 10g. For that reason I would like to suggest an amendment to the blocking tools where if a user were to start for example request a lot of bad faith deletion requests and get blocked indefinitely but didn't upload any bad files then it’s simply not a preventative measure to block them from uploading files and editing “File:” and “File talk” spaces. As these users might be very active on other projects and uploading images (all projects) or uploading books (Wikisource) are often paramount to their ability to edit there it would simply be unfair to ban someone from uploading images if their continued participation would not only benefit this project but other projects as well (and likely even non-Wikimedia projects as files here can be used anywhere). For that reason I would like to propose Upload-only accounts that can exclusively upload images and other files to Wikimedia Commons and unless abused edit their talk pages. As categorisation is also important if their upload privileges aren’t abused after let’s say a week or month (or maybe after 100 uploads since their block, but if those 100 uploads happened in one or two days then 100 uploads + 7 days) they could also edit and create “Category:” and “Category talk:” spaces. As this is a mostly technical proposal I’m also requesting feedback from users experienced with the technical side of Wikimedia Commons if this is plausible.

Also note that the status of Upload-only accounts should not be given to Vandalism-only accounts or users who posted legal threats because of others modifying their images. It just makes sense for a project that’s globally so important to not hamper the development of these other projects by issuing full-site bans over non-upload related things.

Comments and votes (upload-only account)

Are all people black-and-white for you? - Alexis Jazz ping plz 22:45, 30 July 2018 (UTC)
  • Sorry, this is a non-starter. If someone wants to be unblocked on the basis that they will avoid all noticeboard or talk page discussions for a period, that can be a social agreement without having to invent new project groups and rights. By the way, there is nothing to stop someone who is blocked from following a true clean start process and doing the equivalent, so long as they avoid previous patterns of problematic behaviour and stick to remaining a positive content contributor. --Fæ (talk) 09:44, 11 July 2018 (UTC)
"that can be a social agreement without having to invent new project groups and rights." I don't think this is currently ever considered an option. So it could be implemented in some technical way or just written in a policy, although ideally both would be done. - Alexis Jazz ping plz 22:45, 30 July 2018 (UTC)
Is there a phab task for it? --Fæ (talk) 10:04, 13 July 2018 (UTC)
Quite a few. See m:2017 Community Wishlist Survey/Admins and stewards#Allow further user block options ("can edit XY" etc.). --Majora (talk) 20:26, 13 July 2018 (UTC)
  •  Oppose: Everybody who can upload files should have access to edit file pages and initiate or join discussions about the project: about files and their content, about categories, about rules. The idea of "silent and deaf uploaders" is very absurd and hazardous. We have rather problems with such uploaders who upload files, ignoring all rules, advices, warnings and discussions. --ŠJů (talk) 02:13, 22 July 2018 (UTC)
Which isn't a problem at all, if such upload-only accounts are used to upload bad content they will get a good old fashioned full block anyway. Anyone who would be granted such upload-only rights should refrain from uploading any questionable or poorly licensed content. - Alexis Jazz ping plz 22:45, 30 July 2018 (UTC)

Are there enough admins to handle a change in the process

As of today's date, English Wilipedia has 527 active admins: W:Wikipedia:List of administrators. That count in and of itself is not an indication of quantity of admin work being done by the active admins, just that they are still active. Commons:Administrators number 224. Does Commons have enough admins to handle the work load, if a new method of blocking is instituted here? Maile66 (talk) 21:22, 12 July 2018 (UTC)

Obviously depends on the method that is put in place but I doubt it. 224 is a wildly inaccurate measurement of the actual count of administrators that would handle such requests. It is a wildly inaccurate measurement period as most of the work here is done by a much smaller group of people. There are 224 admins on Commons total. Only 28 of them have green flags (extremely active) on Commons:List of administrators by recent activity and only 87 have done more than 20 admins actions in the last 31 days. --Majora (talk) 21:29, 12 July 2018 (UTC)
Based upon the votes above, there should be no worries. The only thing that is getting any traction at all is changes to the templates, which I am working on. It would be the same templates, but with some additional verbiage. I'm just waiting for a little more time for feedback before I post them, but right now they are here.CaroleHenson (talk) 23:04, 12 July 2018 (UTC)
That is a fair point. I was basing my response on if something like UTRS or the IRC channel came to be. I understand that they probably aren't but I still wanted to make the point that we have substantially less admins actually doing the bulk of the work than that 224 number appears to indicate. --Majora (talk) 23:40, 12 July 2018 (UTC)
Just have in mind, that, unlike the English Wikipedia, we are not required to add templates to the talk pages of blocked users (and often I agree that we do not need to, like obvious LTA cases). That templates have been amended (which is absolutely a good thing) does not yet mean that admins suddenly start using them much more than usual.--Ymblanter (talk) 07:22, 13 July 2018 (UTC)
Also, most admins on en-wiki, will naturally block with Twinkle, which adds the selected block message to the user's talk page and is much quicker to use. Ronhjones  (Talk) 19:28, 18 July 2018 (UTC)
ONLY 500-PLUS ADMINSǃ HOLY COWǃ THAT'S ALMOST A CRISISǃ Fortunately there are at least that many "inactive" Admins who seem to suddenly return to "active" status when they apparently sense the number of "active" admins is dropping dangerously low. And if ACTIVE ADMINS did a lot more "sysopping" and a lot less banning, blocking and deleting of content, there would probably be more "users" and a much larger pool of "talent" from which to create NEW admins. You know, if the number ever got down to a level where existing "active" admins were so overworked doing things that aren't their "job" and no longer had the time to engage in 24-7-365 "discussions", in which their "contributions" can and do run into the dozens of comments and thousands of words, they had to actually pick up that fabled "mop" and insert the fabled "bit" and ONLY do what they're supposed to be doing. Of which I'm sure MOST of the MOST "active" admins would QUICKLY TIRE. Or is that "RETIRE"? Doesn't matter. If you're that concerned about a lack of admins, you might want to check out all the other Wikipedias and their "admin counts" and compare them to English Wikipedia and see who's likely to have a "shortage" first. And by the way, there are quite a few English Wikipedia "admins" who certainly have plenty of free time to "contribute" and even offer to become or actually become more "globally involved" in other projects including Commons. Apparently there's not enough "mopping" to do at English Wikipedia after all. — Preceding unsigned comment added by BLOCKER78 (talk • contribs) 11:20, 4 August 2018‎ (UTC)
BLOCKER78: I think you missed the point. The 500+ figure is for English Wikipedia, so it's only relevant for comparison. That's not a shortage. Here at Commons, we have less than half of that – and far fewer active ones. This is a shortage. Also, you appear to have a lot to say about English Wikipedia for someone who has exactly three edits on any Wikimedia project and none on English Wikipedia. —LX (talk, contribs) 13:59, 4 August 2018 (UTC)
@LX: I tried to address the shortage, but was rebuffed. :(   — Jeff G. ツ please ping or talk to me 15:41, 4 August 2018 (UTC)
@BLOCKER78: Are you now or have you ever been using another username on a WMF wiki? If so, which one(s)?   — Jeff G. ツ please ping or talk to me 15:51, 4 August 2018 (UTC)

 Question - Do Commons admins use Twinkle? On English Wikipedia, in the tab view , there is a "Block" drop down. It opens a fill-in template for blocking. The first two check-box questions are "Block user?" and "Add block template to user talk page?" Complete the simplified template and "Submit Query", and it both blocks the user and places the appropriate template on the user page. Maile66 (talk) 19:46, 18 July 2018 (UTC)

Twinkle was half ported over per COM:TW but it was never fully changed over. The whole script would have to be gone through to ensure compatibility. All of the templates would have to changed over the Commons specific ones, the warnings would have to be changed, etc., and someone would have to do that. --Majora (talk) 20:20, 18 July 2018 (UTC)
If you install those links on COM:TW, then you get error windows popping up. Ronhjones  (Talk) 15:06, 19 July 2018 (UTC)
@Maile66, Majora, and Ronhjones: I would happily work on the templates and warnings, etc. if there were a glimmer of hope that the code would work. We would need to decide on the number of levels of warnings (currently 4 on enwiki and 3 here).   — Jeff G. ツ please ping or talk to me 15:47, 4 August 2018 (UTC)
en-Twinkle has changed a lot since the COM:TW was created. I note that the pages listed in en:Wikipedia:Twinkle/Localisation don't exist on commons, so COM:TW is a very old version. I think we would be best asking if one of the Twinkle experts on en-wiki could help out. Ronhjones  (Talk) 16:18, 4 August 2018 (UTC)
Perhaps I don't know everything twinkle can do but admin backlogs are not being overfilled with edits that are unpatrolled, en:wp cares a lot more about that then commons. I don't see how being able to block people with quicker speed and ease, something I didn't know was a problem on commons will help reduce the backlog. -- Sixflashphoto (talk) 16:25, 4 August 2018 (UTC)
@Sixflashphoto: Assuming that use of Twinkle here would save time for Administrators as well as other users like it does on enwiki, that would free up some time for each to do other things here, which could include addressing backlogs and giving more personal attention where and when necessary.   — Jeff G. ツ please ping or talk to me 19:13, 4 August 2018 (UTC)
@Jeff G.: If it's valuable enough for volunteers to put the time into making it work I'm all for it. I guess I just haven't seen someone say twinkle is useful and valuable enough for this or that backlog on commons and hence is worth putting time into making it work. -- Sixflashphoto (talk) 19:17, 4 August 2018 (UTC)

Allow to upload ODP file format

Open Document Presentation is a standard free/libre file format to create slides, useful a presentation support. Currently we do have many of this kind of material on Commons, often created with a software that support this file format, but only available in PDF, because we don't allow to upload the former. This is far from ideal, because it greatly reduce the adaptability of this material, all the more with free/libre software.

Note that this proposal only focus on ODP, and not extend to the other ODF formats, although each of them might be given a proposal at some point.

Related previous discussions :

Thank you in advance for your feedback, Psychoslave (talk) 13:54, 18 July 2018 (UTC)

Also relevant:

Discussion (ODP)

The current rationale for not allowing this type of file according to Commons:Project scope/Allowable file types is that "we are currently unable to prevent people from hiding harmful or otherwise impermissible content inside OpenOffice's ZIP based container format". Is that suddenly no longer an issue? I believe it would also be the first file format that requires third party software to view, unless Mediawiki has some way to display such presentations that I'm not aware of. Another question I have is whether the contents of such files be searchable the way PDFs are. I frequently find copyright violations in PDF presentations by searching for strings such as names of non-free licenses that the professionals at Wikimedia Foundation love to use. —LX (talk, contribs) 14:16, 22 July 2018 (UTC)

So I guess "harmful or otherwise impermissible content" refers to malware hidden in the file?! I'm wondering if User:Embedded Data Bot could handle this. Zhuyifei1999? De728631 (talk) 17:49, 22 July 2018 (UTC)
Embedded data bot just tags any data it does not expect to be there, whether malware or not. But it's difficult enough to determine if the data is expected or not. PDFs are bad enough. If ODP is based on ZIP, then please no; it would be worse. --Zhuyifei1999 (talk) 01:33, 23 July 2018 (UTC)
The current rationale for not allowing this type of file according to Commons:Project scope/Allowable file types is that "we are currently unable to prevent people from hiding harmful or otherwise impermissible content inside OpenOffice's ZIP based container format". Is that suddenly no longer an issue?
I think that the main problem is related to macro, you can hide malware in any file format, the real issue is arbitrary code execution not that files contains any code. So restricting to ODP without macro would simply make the concern irrelevant. If there are more precise information on what is judged an issue exactly and why it was judged impossible to resolve at the time it was decided not to accept ODP as a whole. At worst, it should be able to disallow ODP including macros, which are far less important feature than for spreadsheet for example. As it is, I don't see any major issue that would be relevant for ZIP files and not for PDF files for example.
I believe it would also be the first file format that requires third party software to view, unless Mediawiki has some way to display such presentations that I'm not aware of.
I am not aware of any file format delivered by Wikimedia which don't require a third party software to consult it. Even mobile applications for Wikipedia relies on third parties software stack to work properly. But the main output file format generated by Mediawiki is HTML which relies on browser made by third parties to be displayed. All the more, there are existing tools to convert ODP to PDF, so at the very least there is one straight forward path to generate equivalent consultation as the one proposed for PDF, altough maybe there are more optimized pipelines which might be practicables.
Another question I have is whether the contents of such files be searchable the way PDFs are.
Inside the ZIP, main content is usually XML embedding text, so it is highly searchable. Of course you can put only pictures in your slides, which are far less searchable, but this is not different from any other file format.
I frequently find copyright violations in PDF presentations by searching for strings such as names of non-free licenses that the professionals at Wikimedia Foundation love to use.
I think that it is not a file format problem. You can make copyright violation through any file format. As said ODP relies on XML, so possibly you might automate copyright violation detection, yes. And yes, someone could use feature of any file format to cover tracks of such a violation, but that is not particularly more the case with ODP.

I hope that it answer your demands @Zhuyifei1999: and @LX: . Please let me know and notify me if you need more feedback. --Psychoslave (talk) 11:49, 30 July 2018 (UTC)

Macros are another kettle of fish. What we're talking about here is the possibility of illicit additional payloads hiding in an apparently legitimate file, which are easier to hide in this file format than in others. We see a lot of activity from pirates trying to put payloads in images, and allowing ODP would make things really easy for them. I take it there is no plan for how to handle this.
When I said "third party software", I obviously meant third party software other than a standard web browser. Of course it's possible to convert ODP to PDF, but does the Mediawiki software currently do that and present them in the browser? I take it the answer is no.
And when I asked about whether ODP files are searchable, I meant whether they are searchable using Special:Search (which is what's needed to meet the use case I described), not whether I can unzip and grep through an individual file. The fact that I'm able to use the search feature to find copyright violations is a feature, not a problem. Since the answer wasn't a reassuring "yes, ODP files are fully indexed for the search function", I'm going to assume they're not.
 Oppose, since none of these issues have been satisfactorily addressed. —LX (talk, contribs) 20:28, 30 July 2018 (UTC)
The new 3D format isn't directly supported by browsers, yet we added it. It's a very simple format though. --Zhuyifei1999 (talk) 05:27, 31 July 2018 (UTC)
You mean STL like File:Sphericon.stl? Uh, yeah, those get a PNG preview, and the Media Viewer has built-in Javascript based support for viewing and interacting with them. No special software needed. —LX (talk, contribs) 09:19, 31 July 2018 (UTC)

Let's have a look at the closing statement of the previous discussion, as Sven Manguard summarized it nicely:

  1. A number of users have expressed that the inability to view documents without downloading them is a deal breaker. Participants have stated that the lack of such functionality places an undue burden on the users that patrol files for copyright and scope violations. There have also been security concerns expressed, with users unable to see if a file contains harmful macros before downloading that file.
  2. A number of users have expressed reservations that this would enable new types of files to be uploaded before any discussion has taken place on how these new types of file would fit in with the project scope, and how the scope might need to be changed to accommodate them
    — User:Sven Manguard
  • Regarding point 1, Bawolff made it pretty clear that, at least back in 2014, there was no thumbnailing for Open Document files readily available in Mediawiki. Given that there are several open-source Open Document thumbnailers around, this seems like a solvable issue though. The real problem is imho: as long as we keep rejecting Open Document formats, it seems very unlikely that any developer will spend any time on implementing thumbnailing. And I certainly won't blame them for that.
  • Rearding point 2, I think this would be less of an issue for the presentation formats, as we already have presentations stored as PDF. This is worth discussing, but not a blocker for me in this case. We can work on that while the devs work on the thumbnailer.

Macros are blocker, though. Is there no way to detect them, possibly after the upload by a bot? --El Grafo (talk) 12:49, 31 July 2018 (UTC)

So originally ODP were banned, due to concerns you could make a JAR file (java archive) that looked like an ODP file (If you look really long ago, before we became aware of this attack you could upload sxw type files wikinews:Special:MIMESearch/application/zip.) As far as I know, since MediaWiki 1.17 we can now detect this sort of thing properly so that is no longer a concern. Of course macro viruses are a whole other issue. We would require some custom adapter code to make ODP's work nicely with MediaWiki (Allowing the search engine to search through them like we do with pdfs and displaying pretty thumbnails, perhaps even embedding https://webodf.org/). All of that is fairly straightforward, but it does require someone to do it. BWolff (WMF) (talk)

At least is seems to be possible to detect marcos: [2]. --El Grafo (talk) 08:33, 8 August 2018 (UTC)
After a bit of research (correct me if I'm wrong), it looks like checking for macro code embedded in an od* file should actually be pretty easy: Unzip it and check if there are any macro libraries in it (usually stored in a subfolder called Basic; marcos written in languages other than basic should be stored in a similar fashion). If it's not possible to do this check on upload, a bot could just remove the libraries/code post-upload, as we certainly don't need macros in presentations (if at all). I'm not sure if it's possible to execute macro code that's stored somewhere on the web, though (and if yes how we could detect that). --El Grafo (talk) 09:27, 8 August 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2018/07&oldid=319146630"