Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
introduction		Help deskVillage pump
copyright • proposals • technical		Administrators' noticeboard
vandalism • user problems • blocks and protections

Shortcuts: COM:VP/P· COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

COMMONS DISCUSSION PAGES (index)
Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Proposal: Allow bureaucrats to remove administrator permission[edit]

Clear consensus in favor of allowing local bureaucrats to remove sysop permissions. King of ♥ ♦ ♣ ♠ 05:47, 28 August 2020 (UTC)

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

Currently Commons bureaucrats can grant but cannot remove sysop permission. I believe Commons community is large enough and we have enough active bureaucrats to handle desysops locally. This will make desysop log store locally instead on Meta. Stewards can still act in case of emergencies if no local crat is online. Note that this proposal does not support crats removing sysop in cases other than uncontroversial procedure (inactivity removals, RfDA, in case of emergency). -- CptViraj (talk) 06:02, 30 May 2020 (UTC) Fixed per Pandakekok9. CptViraj (talk) 06:24, 30 May 2020 (UTC)

Discussion[edit]

  • Symbol support vote.svg Support as the proposer. -- CptViraj (talk) 06:02, 30 May 2020 (UTC)
  • Symbol support vote.svg Support Long overdue! 4nn1l2 (talk) 06:11, 30 May 2020 (UTC)
  • Symbol support vote.svg Support About time. And just for clarity, can a local crat still emergency desysop a rogue admin even without the inactivity or RfDA procedures? pandakekok9 06:14, 30 May 2020 (UTC)
    Yep, fixed. Thanks :) -- CptViraj (talk) 06:24, 30 May 2020 (UTC)
  • Symbol strong support vote.svg Strong support Revoking sysop permissions by bureaucrat here and not by a steward is faster (and I'm Symbol keep vote.svg agreed about it), but how about with revoking bureaucrat permissions by bureaucrat? Nieuwsgierige Gebruiker Overleg • CA 06:46, 30 May 2020 (UTC)
    "Allowing bureaucrats to remove bureaucrat right" is prohibited by system administrators, see m:Limits to configuration changes. -- CptViraj (talk) 07:05, 30 May 2020 (UTC)
  • Symbol support vote.svg Support - Bureaucrats close such requests, and the removal of administrative rights by stewards usually needs a successful de-RfA closure by a bureaucrat. So, if they should first close the request (their closure is somehow "official"), why shouldn't they remove the right as well? Ahmadtalk 07:34, 30 May 2020 (UTC)
  • Symbol support vote.svg Support for 'procedural' rights removals. Emergency actions would need a more detailed proposal and agreed policy, especially if the removal decision is based on any non-public data of any kind. As a procedural corollary, though removing the 'crat group has a systems issue, by default if a 'crat removes another 'crats sysop rights, the desysoped 'crat is by existing policy automatically no longer a functioning 'crat, even if technically the flag is still there. --Fæ (talk) 12:32, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose If bureaucrats can't be trusted to return sysop rights after 24 hours, they shouldn't be able to do this. Also, the bureaucrat team has 7 members, but one or two are active in that role. So no, you won't get a "faster" response. 1989 (talk) 14:35, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose With the level of infighting that Commons has had lately - this is a very bad idea to remove stewards from the picture. --Rschen7754 15:53, 30 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. Lymantria (talk) 16:00, 30 May 2020 (UTC)
  • BA candidate.svg Weak oppose, per Limits to configuration changes, this will only be done if there is both multiple active bureaucrats, and a demonstrated need. Given the only real reason for bureaucrats being able to remove the bit is speed, and we only have 7 bureaucrats, I'm not sure we meet these criteria. ~~ Alex Noble/1-2/TRB 16:39, 30 May 2020 (UTC)
  • Symbol support vote.svg Support - Seems natural. I have high trust in our local bureaucrats and it strengthens the local community. --Schlurcher (talk) 07:54, 31 May 2020 (UTC)
Thanks. Please elaborate how this is relevant here? --Schlurcher (talk) 08:32, 31 May 2020 (UTC)
Though I wasn't here when Russavia was WMF banned in 2015, as far as I read the archives, he seem to had been a good bureaucrat. The only reason he resigned was because of the controversy of hiring Picasso to make a painting of Jimbo. He didn't abuse his tools nor made a bad judgement on a significant issue on Commons AFAIK. He did committed sockpuppetry though, but that's because he suddenly got banned by the WMF without warning. We still don't know what got him banned. I only had a few interactions with him via IRC, and that was only about helping with translating stuff to Tagalog. He seemed like a nice guy, too bad I wasn't able to know him much before he got banned.
But as Schlurcher said above, I don't see how Russavia is relevant in a proposal about granting crats the ability to remove admins. That was a 3 years or 2 years ago problem (the last I saw him sock was in 2017 or 2018 I think). If you think we shouldn't trust the bureaucrats just because of one former member who long resigned like 6 years ago, that ain't fair to other bureaucrats who had done their community role well for years. Russavia only served for like 2 years as a crat. The rest of the crat team served and still serves longer than that. pandakekok9 09:44, 31 May 2020 (UTC)
Bad cases make bad law. If any oppose votes here are because of what happened with one rogue account many years ago, where there never was any misuse of bureaucrat status or sysop tools, then that's very bizarre.
All current 'crats are demonstrably trustworthy, the only criticism is that there aren't many active 'crats. Hardly a reason to reject this proposal. --Fæ (talk) 10:17, 31 May 2020 (UTC)
the only criticism is that there aren't many active 'crats. Hardly a reason to reject this proposal. Er, that's actually a reason why such change won't be implemented by the sysadmins, see m:Limits to configuration changes#Changes that are likely to be declined. We do want some more active crats, but I think we have enough to prevent any crat abuse. pandakekok9 10:23, 31 May 2020 (UTC)
  • Pictogram voting comment.svg Comment You'll sometimes say stewards are allowed to remove bureaucrat permission or maybe kick someone out... --Red-back spider (talk) 10:00, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Granting and removing rights should ever be possible by the same users. If there are doubts that this could take to long we should look for some of the very active admins becoming promoted. --GPSLeo (talk) 10:01, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Anyone who has the technical right to grant a sysop should have the same right to remove it following a clear consensus. Regards. T CellsTalk 19:02, 31 May 2020 (UTC)
  • Symbol support vote.svg Support, Wikimedia Commons is large enough to stand on its own feet. Bureaucrats are highly trusted users and while I don't always agree with some individual decisions of some permission holders, the removal of the sysop flag can only be done with the support of a sizable number of community members, so there is not much of a chance that this will be abused. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:59, 31 May 2020 (UTC)
  • Symbol support vote.svg Support Bureaucrats on Commons are trustworthy and they have adequate knowledge on doing this. --A1Cafel (talk) 09:13, 3 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. Trijnsteltalk 20:15, 4 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Per Rschen7754. -- Geagea (talk) 05:47, 10 June 2020 (UTC)
  • Symbol support vote.svg Support Of course. Regards, ZI Jony (Talk) 08:24, 14 June 2020 (UTC)
  • Symbol support vote.svg Support This is a common feature of what it means to be a bureaucrat and it also means that this project can be self-policing. —Justin (koavf)❤T☮C☺M☯ 01:43, 21 June 2020 (UTC)
  • Symbol support vote.svg Support "The man who passes the sentence should swing the sword"-(Ned Stark) Seriously, since the buraucrats have the community right to close the procedure they should also have the technical right to finalize it. -Geraki TLG 16:53, 16 July 2020 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. ツ please ping or talk to me 21:04, 18 July 2020 (UTC)
  • Symbol support vote.svg Support I understand the words of opposers, but I feel Stewards have way too much responsibilities, just easing them from this particular task wouldn't hurt. Bureaucrats on Commons are highly trusted, they should not be assumed to abuse this right. Ainz Ooal Gown (talk) 16:50, 19 July 2020 (UTC)
    • 20 desysops a year really doesn't make a difference in their workload. --Rschen7754 18:05, 7 August 2020 (UTC)
  • Symbol support vote.svg Support. Commons 'crats (should) have more knowledge of Commons policies than Stewards. Having this handled locally could prevent unnecessary drama. —Mdaniels5757 (talk) 18:40, 15 August 2020 (UTC)
  • Symbol strong support vote.svg Strong support - We are a large project and can deal with our own dirty laundry. Regardless of whatever minor burden it may place on stewards, it is an unnecessary burden. There is no argument I can support for the perpetuation of an unnecessary burden merely because it is minor. If we find we have too few crats to handle the job, then we should elect more. In a perfect world, we would have little need for stewards at all, as every project would be capable of being, and become self-sustaining. There is no need for us to keep the umbilical cord attached when we've long ago been weened off the bottle. GMGtalk 13:06, 16 August 2020 (UTC)
  • Symbol support vote.svg Support.--Vulphere 07:59, 21 August 2020 (UTC)
  • Symbol support vote.svg Support. I think Commons is a big project enough to not require stewards do this always. – Ammarpad (talk) 06:26, 23 August 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
  • I think the consensus in this section was not strong enough for such a radical change, which dramatically alters the power structure of the wiki. Nemo 14:37, 30 August 2020 (UTC)
    • From the phab ticket, it seems the stewards agree with you. 1989 (talk) 00:56, 31 August 2020 (UTC)
      So let's reopen it, and advertise it on COM:BN, COM:AN, COM:VP, and perhaps a sitenotice.   — Jeff G. ツ please ping or talk to me 01:29, 31 August 2020 (UTC)

Turn MOTD into MOTW[edit]

Since Commons cannot churn out one featured video (FV) a day, I suggest to turn Media of the Day (MOTD) into Media of the Week (MOTW). The current problem is that some MOTDs are of low quality not becoming of the Main Page. Even we can't write English captions for all of our MOTDs. The solution is to focus on quality rather than quantity. Each week we can show high-quality featured videos with captions in English and hopefully many other languages.

See also Commons:Administrators'_noticeboard#nudity_on_front_page. 4nn1l2 (talk) 08:33, 1 June 2020 (UTC)

  • Symbol support vote.svg Support as the proposer. 4nn1l2 (talk) 08:33, 1 June 2020 (UTC)
  • Pictogram voting comment.svg Comment We actually have a lot of quality video or audio content here. — Racconish 💬 09:36, 1 June 2020 (UTC)
  • Pictogram voting comment.svg Comment The main page gets around 125 thousand views in a day, in comparison en.wp's main page gets 5.5 million. It asks a lot of the small community to maintain and select the content on a daily basis and give it all a meaningful review or vote (thereby avoiding manipulation by disposable sock accounts), so moving MOTD to a weekly cycle makes a lot of sense. Thoughts from those active in maintaining the main page should carry significant weight in this consensus. --Fæ (talk) 09:40, 1 June 2020 (UTC)
Amended to comment, based on Racconish's objection. --Fæ (talk) 13:36, 1 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose strongly. motd need not be featured videos. there are certainly more than 365 high quality, free videos that are produced in the world or expire into pd each year.--Roy17 (talk) 09:53, 1 June 2020 (UTC)
    Commons may have enough content (I have my doubts), but certainly does not have the manpower to present them all in a neat way. Just in the previous month four MOTDs went to the Main Page without English captions. Although they had French captions, English captions can be read by many more people. See Template:Motd/2020-05. 4nn1l2 (talk) 10:11, 1 June 2020 (UTC)
    I had seen that but I was not sure what the consensus was and I was concerned to avoid antagonising the uploader. Have added English captions to his June MOTDs. — Racconish 💬 10:38, 1 June 2020 (UTC)
  • Further comment. I am a little concerned about giving too much importance to technical considerations as opposed to historical, documentary or merely educational value. We do have a handful of contributors who do use the venue to show some of their own productions which might not always meet EV criteria, but I think we should be very careful in establishing formal criteria, if there is a consensus to go that way, in order to preserve the highlight on diversity. — Racconish 💬 10:05, 1 June 2020 (UTC)
  • Symbol support vote.svg Support in principle. We theoretically have enough high-quality media to feature one a day, yes, but in practice we do not have enough volunteers to curate it on a daily basis. I agree with some reduction in frequency, but 7x might be a bit drastic. One every 2-3 days would be the sweet spot, but I'm not sure how to name such a thing. -- King of ♥ ♦ ♣ ♠ 15:37, 1 June 2020 (UTC)
    Alternative suggestion: We currently are promoting FPs at a rate of 2-3/day, so most of them will never have their time in the spotlight. Since "media" technically includes images, perhaps we can alternate between days with an FP in MOTD (i.e. running two FPs at once) and days with a video/sound/other in MOTD? -- King of ♥ ♦ ♣ ♠ 15:44, 1 June 2020 (UTC)
Another suggestion: let's take a real recent situation, {{Motd/2020-02}} + {{Motd/2020-03}} and look at it carefully. I see no void there, therefore no evidence the daily rythm is problematic. But I am sure we can evidentiate some problematic nominations or template issues (not in English, without wikilinks, etc.), and then try to avoid these problems by stating some guidelines for nominators. In an nutshell, I think what we might need are simple guidelines. — Racconish 💬 17:05, 1 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral I If we have enough volunteers to curate MOTD for each day, than by all means lets do it, but I am also fine with reducing the frequency or allowing FP to be included in MOTD. --Jarekt (talk) 18:05, 1 June 2020 (UTC)
I dont get any of the arguments here.
1. not enough FV
no, motd dont need to be FV. many videos or audio files are not selected for the little known FV—I never give a damn and I'm sure many ppl dont care either—but that doesnt mean they are low quality.
2. no english caption
captions need not be english. I dont care if it's french czech or polish. none of them are my native. very rarely would i see a caption in my native, and even if someone wrote it i wouldnt find it coz i use the english UI. Commons doesnt prefer any language. I dont care much about the captions either. it's motd not caption of the day. i can enjoy a video even if nobody summarises it. if i find it interesting but not understand the language i could find out more by looking at its source.
3. not enough volunteers
that's factually wrong. I know for a fact that there are always czech polish and Erzya users adding captions timely for the past one year. what you are complaining is that sometimes the english caption is not added in time, or that you dont like the video/audio file chosen.
Solution for your actual problem: Take it upon yourself. Add the caption yourself. Select videos you like yourself. Challenge the ones you dont like on VP yourself.
this proposal is gonna cut the number down from 365 to 52. that's ABSOLUTELY NO.--Roy17 (talk) 00:08, 2 June 2020 (UTC)
if you really have trouble finding nice vids, go to these cats. there are plenty and they will never run out.
  1. Category:Films in the public domain
  2. Category:Music videos
  3. Category:PD US Government especially Category:PD US Military and Category:PD VOA, which has not just english-language and american vids but vids in many languages covering all sorts of topics around the world.--Roy17 (talk) 00:33, 2 June 2020 (UTC)
365 motd a year is not too much but actually not enough. if the world is divided into subnational first-level units, there're several hundred (50 states of US, regions/provinces of france/germany/spain/china/india etc.). each region can only have motd less than once a year. if every 10 million ppl (roughly the population of sweden/belgium/cuba/jordan/UAE) were to have one motd, then the queue would be two years.--Roy17 (talk) 11:28, 2 June 2020 (UTC)
  • Pictogram voting comment.svg Comment A weaker proposal: How about making FP sets eligible for MOTD? They were featured as a set for a reason, because they work better together than individually. As such, they don't really belong in POTD: either you include everything and it's not really a "Picture (singular) of the day" or you have to choose one of them, diminishing the value of the set. A set is effectively an interactive slideshow, which is more appropriate for MOTD than POTD IMO. The word "media" has the nice property that it can be singular or plural. -- King of ♥ ♦ ♣ ♠ 20:42, 4 June 2020 (UTC)
  • Symbol neutral vote.svg Can't we have both? Media of the Day has 365 (three-hundred-and-sixty-five) different media files, reducing this to 52 (fifty-two) would greatly reduce the diversity of files presented, I know, that's the proposal, it's better to have a few quality files than a lot of lesser quality files, but higher amount of files can better showcase the great range of media files present on Wikimedia Commons. Perhaps the MOTW can be located on the top and we'll move the MOTD to the bottom, where those that check out the main page can still see a different MOTD every day, while the more excellent files would be located front and centre above. Those who are interested enough in Commonswiki to begin with will simply scroll down. Short low quality videos that showcase "science in action" or peculiar animals that currently make it to the main page tickle my interests, so I'm not a fan of removing them, while allowing fot the continued existence of the MOTD will let there be "more winners" thus more people that will look for "maybe not the greatest, but certainly the most interesting and educational" type of videos we have now. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:04, 5 June 2020 (UTC)
    I'm not in favor of having two audiovisual files on the main page when we only have one static picture. Like it or not, the vast majority of our content (featured or otherwise) is pictures, and putting up even more AV media on the main page (417 a year) isn't what we should be aiming for IMO. -- King of ♥ ♦ ♣ ♠ 13:10, 5 June 2020 (UTC)
  • I prefer MOTD over MOTW. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 11:51, 10 June 2020 (UTC)
  • Symbol support vote.svg Support Changing MOTD to MOTW. The current daily release is clearly not working this month and even in the months prior not all of the english captions where filled. Some change is needed, keeping the status-quo is not an option.--Snaevar (talk) 15:23, 4 July 2020 (UTC)
  • Symbol support vote.svg Support And then limit to featured videos. --GPSLeo (talk) 16:06, 4 July 2020 (UTC)
  • Symbol support vote.svg Support I think the week time period will also allow for actual discussion on the media as well. I don't think we necessarily need a requirement to have featured media be a criteria at the moment but that can be considered later. -- Ricky81682 (talk) 19:39, 5 July 2020 (UTC)
    I think what we can do is always favor FV over other videos. So if FVs are getting promoted at a rate of faster than 1/week, then FV will become a de facto requirement. If the rate is less than that, then we can supplement FVs with suitable videos chosen by consensus (which the slower process will allow more time for). -- King of ♥ ♦ ♣ ♠ 05:19, 6 July 2020 (UTC)
  • Symbol support vote.svg Support.--BevinKacon (talk) 17:29, 8 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose Media of the Day serves two purposes: 1) To recognise uploads 2) To stimulate new uploads. If somebody sees something on the main page that is "not becoming" of a main page, then it can and should challenge them to upload something better. Also I feel that a main page is just another page of the project. It is a special page only because it should welcome somebody here, but it should not be special in ways that make it into a separate project. We host media that is shown on the main page, and that is good. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 08:57, 9 July 2020 (UTC)
    We all agree that MOTD is better than MOTW if we can manage it, but the problem is that there is not enough labor to support a daily update. Forget quality; we can't even ensure that the MOTD template is updated with anything at all, as the incident on July 4 showed. -- King of ♥ ♦ ♣ ♠ 19:36, 9 July 2020 (UTC)
  • I was quite shy about nominating things for Media of the Day, but I guess I should not be. I will be keeping an eye on things from now on. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:50, 16 August 2020 (UTC)
How many times in history has an MOTD been created only after that day? Could the perceived lack of curating effort be a result of the pandemic? Can those saying lack of manpower provide some stats on the actual problematic MOTD entries from 2009 to now?--Roy17 (talk) 20:38, 18 July 2020 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. ツ please ping or talk to me 21:06, 18 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose. There are a lot of media which has high quality and meaningful message and they should posted at the mainpage to allow more people to watch them. MOTW are absolutely not enough.Yolopertz (talk) 00:47, 19 July 2020 (UTC)
Pictogram voting comment.svg Comment: Weekly means one-seventh of Daily. It is a huge decrease. Maybe daily is too frequent but weekly is too few.—-Hoising (talk) 10:57, 19 July 2020 (UTC)
Symbol oppose vote.svg Oppose. I do not like that. In my opinion current system works enough well. Taivo (talk) 07:21, 28 August 2020 (UTC)
  • Symbol support vote.svg Support per above. --A1Cafel (talk) 04:25, 4 September 2020 (UTC)

Making transclusion easier[edit]

I just made Template:Motd/Day/preload and Template:Motd description/preload to make it easy to add a new MOTD and its English caption. I had wanted to make a gadget to streamline the process for a long time, now I've just come up with these makeshift buttons. Problems yall are grumbling about are solved.--Roy17 (talk) 00:09, 19 July 2020 (UTC)

AF228 and an invisible AF[edit]

On the other hand, since AF228 and an invisible AF prevent non autopatrolled users from creating description templates, why not extend it to any potd/motd templates? Then you dont have random people creating new entries. Another problem solved.--Roy17 (talk) 00:09, 19 July 2020 (UTC)

Change commons search view from list to Grid view[edit]

Currently Wikimedia commons is displaying search result in list view type. This is not what other popular services are doing.

Check out Google images, Flickr, 500px and Shutterstock (all links search for "plants"). Now search for plants on commons.

In my opinion list type view is not well suited for commons but for search engines like Google/Bing or encyclopedia like Wikipedia. It's not easy to find the image that I am looking for on commons, lists can't display more files than grid view. If you want to compare images you are forced to use the galleries/categories, new users/unregistered are usually unaware of categories / galleries. And you know what, we don't have categories or galleries for every possible search. There's also a lot of text on search results (on commons) which is utterly useless, I'm not criticizing the developers (Sorry, if you think so.) this was implemented a long time ago.

Please use *{{s}} ~~~~ to support or *{{o}} ~~~~ to oppose. Please add reson for oppose or support.

Proposed by User:Eatcha

Votes to change search view type to grid view[edit]

  • Symbol support vote.svg Support Eatcha (talk) 14:16, 5 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose: Hell, no. It’s both ugly and stupid. -- Tuválkin ✉ ✇ 18:30, 5 June 2020 (UTC)
  • Symbol support vote.svg Support As long as all of the information that's currently available about the item is still available (I use most of it often, and these other services often seem obsessed with showing as little as possible) and the grid is uniform and not irregularly sized (another thing image services like to do that only makes sense if you're showing only the image). On my 1920x1200 monitor search only utilizes a fraction of the screen space, so it would be nice to take advantage of the rest. – BMacZero (🗩) 17:43, 8 June 2020 (UTC)
Symbol oppose vote.svg Oppose Going to have to change my vote because I just saw the likely implementation at Special:MediaSearch and, wouldn't you know it, it fails both of my caveats. – BMacZero (🗩) 17:51, 8 June 2020 (UTC)
Symbol oppose vote.svg Oppose but it's good to have as an option. I use that "useless" text much more often than looking for images, when you are searching for categorization reasons. Carl Lindberg (talk) 05:32, 10 June 2020 (UTC)
  • As long as it clicking on an image at the current implementation of grid view at Special:MediaSearch takes me to the file description page (which is annoying and not how image search on Google works), I oppose making grid view a default option for images, and I strongly oppose it as the default view for all namespaces in case that's what the proposal is about. I might consider supporting it as the default view for images if my concern is solved. Note that I don't oppose making this an option/opt-in. --pandakekok9 06:09, 10 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral/GA candidate.svg Weak support as long as "power users" are given the option of switching to old-style-search through their preferences. If images took a little bit less time loading, I'd totally support it. Strakhov (talk) 22:12, 18 June 2020 (UTC)
  • Symbol neutral vote.svg Neutral. if and only if Special:Search is retained and directly reachable. I don't care what the default is, but it needs to be an easily-controlled option. If all I want to do is find an image with a certain look, this is conceptually a decent way to do it. But having images different sizes or croppings is a problem (gives undue visual weight based on certain dimension details of the original), having it be infinite-scroll and all sorts of other dynamic effects are likewise usability problems for me--so Special:MediaSearch is unacceptable in its current form. But I want to see all those source snippets too. Current Special:Search lets me see the source snippets I often care to see at least as much as the image. And I can choose how many to see and bookmark where I am in the results for future reference if I'm workint through a list for some purpose. DMacks (talk) 21:10, 2 August 2020 (UTC)

Votes to enable grid view as an opt-in or as an optional feature[edit]

  • Symbol support vote.svg Support // Eatcha (talk) 08:26, 10 June 2020 (UTC)
  • Symbol support vote.svg Support Christian Ferrer (talk) 07:40, 14 June 2020 (UTC)
  • Symbol support vote.svg Support Why not. I assume this means opting-in to changing the behavior of the search box, since users can already "opt in" by just going to Special:MediaSearch. – BMacZero (🗩) 18:32, 18 June 2020 (UTC)
  • Symbol support vote.svg Support Why not. Strakhov (talk) 22:12, 18 June 2020 (UTC)
  • Symbol support vote.svg Support, per my comment below. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:20, 20 June 2020 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. ツ please ping or talk to me 21:07, 18 July 2020 (UTC)
  • Symbol support vote.svg Support as long as it is optional. Will appreciate a 'clean' grid with relevant captions. Thanks.--Navinsingh133 (talk) 20:51, 2 August 2020 (UTC)
  • Symbol support vote.svg Support as a "visual display" toggle in the search and results pages. I don't want it, but if it has user demand and developer support, no objection to making it avaialble to those who want it. But it's fundamentally a problematic approach for me in terms of concept and usability/implementation, so best to leave users in control. DMacks (talk) 21:14, 2 August 2020 (UTC)
  • Symbol strong support vote.svg Strong support Gee, I've been waiting for my entire Wikimedia career for someone to propose this! It is much easier to see and navigate! Thank you to whoever propose this! Barnstar incoming! Regards, Jeromi Mikhael (marhata) 11:45, 19 August 2020 (UTC)
  • Symbol support vote.svg Support. Also please add the posibility to sort on upload date (most recent files first), and maybe on file size and image size too. Eissink (talk) 12:10, 19 August 2020 (UTC).
  • Symbol support vote.svg Support.--Vulphere 07:58, 21 August 2020 (UTC)
Symbol support vote.svg Support. If this is technically possible, then why not. It gives a user additional possibilities. Taivo (talk) 07:27, 28 August 2020 (UTC)
  • Symbol support vote.svg Support --A1Cafel (talk) 04:26, 4 September 2020 (UTC)

Discussion[edit]

  • In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. -- Eatcha (talk) 14:16, 5 June 2020 (UTC)
  • Pictogram voting info.svg Info There is currently a new search system in development using a grid view Special:MediaSearch. --GPSLeo (talk) 14:49, 5 June 2020 (UTC)
  • Pictogram voting comment.svg Comment, this should be optional, discoverability is an issue on Wikimedia Commons, but the current list search, while not perfect, is best for searching for categories, galleries, and templates, as well as various other types of pages, while Wikimedia Commons exists for its media, pages like "{{PD-USGov}}" should be easy to find. Personally I think that we should incorporate more "search features" into the website itself, such as a "view all" option for categories and an option to also add files from sub-categories to this, solutions like these would make searching easier. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:49, 7 June 2020 (UTC)
  • It appears that most users hate Special:MediaSearch beacuse it's not similar to Google's or beacuse we have files other than media(images,videos,sounds) and grid isn't ideal for searching pages/templates. I am adding a new proposal for enabling the prototype as opt-in feature. Thanks for your valuable inputs. -- Eatcha (talk) 08:24, 10 June 2020 (UTC)
  • I don't understand how we can discuss enabling a feature which doesn't exist yet. How am I supposed to know whether I'll like it? Even if you agree with the general idea, there are millions of ways to do it wrong. Nemo 14:41, 30 August 2020 (UTC)

File names containing ®, ™, ©, and other intellectual property signals[edit]

We appear to have about a thousand files containing the trademark registration symbol (®) in their file names (e.g., File:Portrait Innovations® ^ Claire's - panoramio.jpg, File:® MADRID P.L.M. CAJA MÁGICA-PANO-SUR - panoramio (3).jpg), a few dozen with the trademark registration symbol (™), and hundreds more with the copyright registration symbol (©) (here's one with both of those, File:Rua Custódio Ferreira da Costa - PU1JFC ™ ©.JPG). I propose that, other than as a stylistic element, we should remove intellectual property signals like these from file names, for several reasons:

  1. It is not the job of Commons to project or protect intellectual property claims of file uploaders
  2. It is confusing to have works on a free media site with titles that may appear to contradict the terms of our licenses
  3. We don't know (nor should it be our responsibility to know) whether a name or work actually has the registration signified by the mark
  4. Trademarks and copyrights lapse or expire eventually, so the use of the mark eventually becomes inaccurate for all of them
  5. Removing them reduces the instances of otherwise unnecessary title elements that are difficult for users to type on a standard keyboard

Unless there is already a rule to this effect of which I am unaware, this seems like a common-sense approach to me. BD2412 T 16:13, 26 June 2020 (UTC)

  • Symbol support vote.svg Support Provided that actual "copyvio" material (such as non-free logos or incompatibly licensed media) is removed at the same time. ShakespeareFan00 (talk) 17:50, 26 June 2020 (UTC)
  • Symbol support vote.svg Support Perhaps we should also just blacklist those symbols in the future, no reason to include them in a filename. -- King of ♥ ♦ ♣ ♠ 19:58, 26 June 2020 (UTC)
    • I would definitely support that also. BD2412 T 22:13, 26 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose There is nothing wrong with a © for example. See {{Attribution}} for example. If it is not our job to tell someone if there is a trademark then we should delete {{Trademarked}} for example. It is just a file name and it is not important. So no need to waste time renaming thousands of files. --MGA73 (talk) 21:43, 26 June 2020 (UTC)
And we can delete {{Wikimedia trademark}} also :-) --MGA73 (talk) 21:47, 26 June 2020 (UTC)
This has nothing to do with whether the content of the file is subject to trademark protection, only whether the itinerant symbols should be used in filenames. BD2412 T 22:12, 26 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose It is the job of Commons to denote the intellectual property claims of file uploaders; that's why we put a proper license on works. Likewise, copyrights lapse on all these licensed works, but we still include the licenses on the page. I'm not seeing the value in mass file renaming, given our usual restraint in file renaming.--Prosfilaes (talk) 22:23, 26 June 2020 (UTC)
    • It seems that quite often the symbols use in the file names do not correspond to any actual intellectual property claims of file uploaders, much less the proper license for the work. BD2412 T 22:45, 26 June 2020 (UTC)
  • Not sure that would be a great policy, but not strongly opposed.
    1. It's not the job of Commons, but it might be the job of the uploader.
    2. None of them contradict any of our licenses. Trademark-related symbols are completely unrelated, and copyright symbols simply state that copyright exists, which is necessary to license it. PD files don't need them, of course.
    3. The uploader might know. Removing them may seem to indicate we don't think they are accurate.
    4. Trademarks don't necessarily expire. They can be renewed indefinitely (but must be renewed fairly frequently). Removing copyright symbols for PD works, sure.
    5. This seems like a reasonable concern. On the other hand, filenames can be any language, and languages in non-latin scripts (or even accents) can also be just as hard to type, and we should not be touching those without reason.
  • I would definitely try to avoid these characters when constructing filenames from source text -- it seems like the Panoramio examples might be instances of that. But if an uploader intentionally puts one there, not sure it should be policy to remove them. You might even claim that it is removing copyright-protection information. Carl Lindberg (talk) 23:04, 26 June 2020 (UTC)
  • Symbol support vote.svg Support Changing existing files except if and only if that information is moved to the file description page and Symbol support vote.svg Support blacklisting those symbols in file names for future uploads. Frankly, if it's not something that can be typed on keyboard by your average user (accounting for that different countries include different characters on basic keyboard layouts), it shouldn't be in a file name, because it unnecessarily hampers re-use. A file name is also not an appropriate place to store copyright/license information, that's what the description page is for. The Squirrel Conspiracy (talk) 05:46, 27 June 2020 (UTC)
  • Meh. If those symbols doesn't mislead the user, there's no reason to remove them from the filename. They can be removed if there's another qualifying rationale at COM:FNC, or if the symbol is misleading (like © in a public domain work, unless © is related to the file itself). Blacklisting those symbols is a good idea though, since there's really no reason why those symbols should be present in the first place if the file description can do the same job but better. --pandakekok9 07:08, 27 June 2020 (UTC)
@Pandakekok9: I agree that descriptions are better than file names. And that is why I think we should rename a lot less. :-) --MGA73 (talk) 07:53, 27 June 2020 (UTC)
These symbols are always going to be misleading to some extent. Copyrights and trademarks not only expire eventually, but are also jurisdiction-specific. A term may have a trademark registration that is valid only in Korea, or only in Peru, or only in Iceland, and is invalid in the rest of the world, or even claimed by someone else in another country. At some point, they will mislead. BD2412 T 14:39, 27 June 2020 (UTC)
  • Symbol support vote.svg Support It is somehow copyrighted and I see no reason to include it in the title. BTW, I like the proposal made by King of Hearts. --A1Cafel (talk) 16:55, 29 June 2020 (UTC)
  • Should be written in guidelines for good file names, but should not be an automated filter or renaming reason. --GPSLeo (talk) 08:38, 30 June 2020 (UTC)
    I'd understand why it shouldn't be the sole renaming reason, but why not an automated filter? pandakekok9 12:24, 30 June 2020 (UTC)
    Because it is just a minor style problem and nothing that should force creating redirects with all the problems redirects have. I do not want automated filters because sometimes these symbols might be useful to describe the content and I do not want to start blocking symbols because that would open discussions on blocking of many more symbols too. --GPSLeo (talk) 12:37, 30 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose too disruptive for little benefit. Points 1, 3 and 4 are actually arguments saying we should not pay any attention to it. Separate proposals for each character would be less disruptive.--BevinKacon (talk) 16:36, 30 June 2020 (UTC)
Symbol oppose vote.svg Oppose what nonsense censorship is this?--RZuo (talk) 22:05, 30 June 2020 (UTC)
  • Symbol oppose vote.svg Oppose Most licences require you to preseve copyright notices. For example, you can find the requirement in all Creative Commons licences with the "BY" attribute. If we remove copyright notices from file names, there's a risk that we accidentally violate the licensing terms. --Stefan2 (talk) 22:42, 30 June 2020 (UTC)
    • In that case, do you think all files for which some kind of copyright is claimed should have "©" in the filename? Otherwise, we will be leading readers to think that some files having them means those not having them have no such claim. BD2412 T 17:42, 6 July 2020 (UTC)
  • Is it possible to make the presences of these characters a warning when trying to use them, which requires a specific override step to make sure you really wanted them? Like you get when trying to upload over the same file? Carl Lindberg (talk) 00:31, 1 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose It somewhat makes sense to have a clickthrough when one uploads the file with such symbols offering to 1) remove them 2) substitute them for '(c)' '(r)' and '[tm]' or 3) keep them as is. I would definitely oppose mass renaming, especially since I really hate .jpg extention that is automatically applied to .jpeg uploads during the rename. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 07:09, 2 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose, on generic (censorship) and specific (licensing) basis. And let’s get rid of the ban on SMP characters, where are located those pertaining to CC licenses. -- Tuválkin ✉ ✇ 21:42, 4 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose, while I fully understand the proposer's side-of-view and agree that Wikimedia Commons should try to make everything as simple as possible for re-users, Creative Commons files remain copyrighted © (excluding Creative Commons-Zero, obviously) and this symbol doesn't mean "all rights reserved" or "no re-use", many logos on Wikimedia Commons are registered trademarks and while they may be free to use, this is not always without certain legal restrictions. Plus, if a file actually represents the characters then their inclusion is very descriptive of the depicted file itself. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:08, 4 July 2020 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. ツ please ping or talk to me 21:14, 18 July 2020 (UTC)
  • Pictogram-voting-question.svg Question. How can I search for these? I tried things like Special:Search/intitle:© and got no hits. DMacks (talk) 03:58, 20 July 2020 (UTC)
    @DMacks: Try the Grep tool. Please use it wisely though, as it is quite resource-consuming. Gikü (talk) 15:28, 20 July 2020 (UTC)
  • Symbol support vote.svg Support this information does not belong in the file name, and in addition to often being misleading and hard to correct (a license template on the file's information page can be adjusted, if necessary, by any editor: file names require +sysop or filemover) they cause unnecessary problems in using the files. Any intellectual property-related factors should be indicated on the file's description page the same way other non-copyright restrictions are. @DMacks: try Special:Search/intitle:/©/ (but don't overdo it, it kneels the servers; there's a reason I don't link it). --Xover (talk) 10:45, 20 July 2020 (UTC)
  • Symbol support vote.svg Support Filenames should be descriptive (about f.e. what is depicted) and not prescriptive about rules. Copyright and trademarks in Commons are marked through the relevant templates in the file description page. © ® ™ do not add anything to a potential reuser's knowledge about the file. If they do, it is the false impression that a file with © in the filename is "more copyrighted" than another with the same license. Keeping them means that we should be checking if these symbols really apply to a certain file (obviously keeping the symbols in a filename where the file is PD and not trademarked, gives a more false impression). We should be leading reusers to check the file description page and not make conclusions looking at the filename. -Geraki TLG 06:21, 27 July 2020 (UTC)
    • I am sorry, but how does this make sense? You are saying that we should lead reusers to check the description page, when we are apparently attempting to see copyright restrictions provided in the name. I view copyright symbol as a shorthand that many people use. Why is "Mountains ©2020 John Doe.jpeg" is a bad file name but "Mountains photograph that is takeon in 2020 by John Doe.jpeg" a good one? My is "Microsofa registered trademark.svg" an appropriate name, but "Microsofa®.svg" is somehow misleading? This does appear to be a solution that seeks to find a problem that it resolves... and fails miserably. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 12:20, 10 August 2020 (UTC)
  • Symbol support vote.svg Support as a warn+confirm/override for cases where the image really does represent the symbol itself. In WP articles, we often see these symbols used for the underlying subject or name, not a specific portrayal of it. The symbol is thus unclear whether it applies to the file itself, the object in the image, the nonvisible details hidden within the image, or the term used to identify it. For example, consider a picture of a colorless liquid that is a IV solution of a drug: the image is copyrighted by the photographer, the drug-name is trademarked by the company, the drug is patented by the company but invisible in the liquid, and the label and package are too plaintext/utilitarian to be protected. PR flaks write the (R)/(tm) next to the drug-name every time they write it, but that's the *least* protected among the aspects of this image. Better to have the title be more direct and leave it to the Description to identify the various levels of licensing. Also, these details might be transient ((c) and (tm) can lapse), which means these filenames have an expiration date. DMacks (talk) 06:46, 27 July 2020 (UTC)
    • You do realise that this proposal still would allow the user to put "(c)" or "(r)" in the file name. Like I have said, this is a solution, that looks for the problem, finds one, but does not resolve any part of that problem. In other words "Somebody uploads files to Commons, and they are doing it in the second best way, let's anger uploaders, better for them to contribute nothing". ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:25, 31 August 2020 (UTC)
  • Symbol support vote.svg Support --oSeveno (User talk) 11:39, 10 August 2020 (UTC)
  • Symbol strong support vote.svg Strong support Taivo (talk) 07:33, 28 August 2020 (UTC)
  • Pictogram voting comment.svg Comment Don't say "intellectual property". Nemo 14:39, 30 August 2020 (UTC)

Create namespace alias TEM: for Template: on Commons[edit]

As endless discussions in https://phabricator.wikimedia.org/T237177 (Create namespace alias MOD: for Module: on Commons) finalized in "This would be providing an alternate way to refer to some namespaces. That's all. No one will be forced to change anything they are currently doing. Some people (those who know about the option) will simply be able to do things in a new way. No big deal, it seems really a small change with the result of being a great simplification at daily work – just like "cat:" is now:

  • mod: for Module:
  • tem: for Template:

To clarify an often mentioned misunderstanding: Even when tem is also a language code, it can never interfere when "tem:" is typed into the search field. There would also be no problem with "t:", which is always called to be "too short". In VPP were discussions at 2019/06, 2019/10 and 2019/11 about that, and it seemed that we got an accepting conclusion, but nothing happened since. So I am renewing that old request, hoping that it would not cause new endless discussions -- sarang♥사랑 06:17, 9 July 2020 (UTC)

  • Pictogram voting comment.svg Comment I still prefer the T: option. 4nn1l2 (talk) 09:52, 18 July 2020 (UTC)
@4nn1l2: As I said, an input into the search field like c: or m: or t: cannot disturb anybody, because as soon as the colon is typed it will be clear what is meant — and it had never been a problem to overtype the system's replenishments when they are not wanted. -- sarang♥사랑 16:47, 23 July 2020 (UTC)
And that's what I said :) I still support T:. Please note that uppercase and lowercase are the same thing at the beginning of a string. 4nn1l2 (talk) 16:58, 23 July 2020 (UTC)
As everybody can verify, neither t: or te: or tem:, nor m: or mo: or mod:, nor c: or ca: but cat: will (like com:) cause a replenishment. And the best, when in some future such input codes will be needed for something else, e.g. language codes, after cancelling the input abbreviation function they can be reused, such namespace aliases must not serve for ever! But they can ease the nowadays life for a while. -- sarang♥사랑 17:29, 23 July 2020 (UTC)
  • Symbol support vote.svg Support I support TEM: too. 4nn1l2 (talk) 17:56, 23 July 2020 (UTC)
  • Symbol oppose vote.svg Oppose solution for a non-existent problem. Multichill (talk) 13:08, 7 August 2020 (UTC)
Multichill, be happy that it's not a problem to you! But it would be if you type every day some hundred times the 9 characters "template:" – then you would also wish it a little bit shorter. I do not know what you are doing, but it seems not to be your every day work with categories, modules and templates. May be you got your abbreviations for your frequent needs, but these are in turn "non-existent problem" to me. -- sarang♥사랑 13:16, 20 August 2020 (UTC)
  • Pictogram-voting-question.svg Question So is there a language code that is "tem"? ℺ Gone Postal (〠 ✉ • ✍ ⏿) 12:27, 10 August 2020 (UTC)
Gone Postal, there is an exotic language code "te", but neither "t" nor "tem". As often said, we would prefer "t:" (like "c:" that we didn't get), but "tem:" would be fine, and will somehow fit to "cat:". -- sarang♥사랑 13:16, 20 August 2020 (UTC)
Symbol support vote.svg Support In that case. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:59, 20 August 2020 (UTC)
  • Symbol support vote.svg Support I support TEM: too. As a permanent user of various templates day-in-day-out it would be a tremendous help to have such a "shortcut". -- MaxxL - talk 16:46, 20 August 2020 (UTC)
  • Symbol support vote.svg Support I support TEM: too. It may of advantage to be a permanent user of various templates to vote here. For me it would be an enormous help to have such a "shortcut". --Jürgen Krause (talk) 17:04, 20 August 2020 (UTC)
  • Symbol support vote.svg Support In English Wikipedia, there is a WP: alias and it was used as a "shortcut". I'm not sure for cat: and mod: but i think they are used for the quick access "shortcuts" - similar to WP: - they cause no problems. If tem: do not cause problems, then why this is not implemented earlier? SMB99thx Oh-kay!! 05:59, 25 August 2020 (UTC)
  • Symbol support vote.svg Support. I consider this a very useful change. Taivo (talk) 07:35, 28 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose Increases confusion and promotes jargon-talking, for no real benefit. Spell out your links and be nice to newcomers, instead of talking in code. Nemo 14:42, 30 August 2020 (UTC)
err Hi Nemo, you misunderstood completely - sure you read it wrong: we are talking just about an input abbreviation that nobody will see; it has nothing to do with a link abbreviation!
We have since long link abbrevs, whether you like them or not; if you want to fight against them you might do, but elsewhere.
Your erroneous opposing concerns something else, another theme than this proposal! -- sarang♥사랑 11:14, 3 September 2020 (UTC)
  • GA candidate.svg Weak support The idea is good. However, due to my edit habits on zhwiki, I would prefer T: rather than TEM:.--A1Cafel (talk) 04:31, 4 September 2020 (UTC)
Of course it would be nice to have not only cat:, tem: and mod: but also (or better: instead ! ) c:, t: and m: – but don't let us be presumptuous, we will be happy to type 5 chars less -- sarang♥사랑 12:11, 4 September 2020 (UTC)
  • Symbol oppose vote.svg Oppose I agree with Multichill here. I do no like obfuscation in our codes, as it makes them hard to maintain. As a result do not like single letter templates, like
err {{A}}, {{C}}, {{D}}, {{E}}, {{F}}, {{G}}, {{I}}, {{L}}, {{M}}, {{N}}, {{O}}, {{P}}, {{Q}}, {{R}}, {{S}}, {{T}}, {{U}}, {{W}}, {{V}}, {{X}}
(how many people know what each one does?) or many alternative ways to refer to a page. Multiple rarely used namespace aliases contribute to code obfuscation. --Jarekt (talk) 13:06, 4 September 2020 (UTC)
  • Hi Jarek, it is obvious that you also misunderstood completely what we are discussing and proposing!
At this place, nobody wants to abbreviate the template namespace or any template name – that is another thing, that we can discuss at another place in peace.
  • At this place, we are just talking to shorten the manual input typing into the search field - nothing else! Especially you are frequently working with templates and modules, so you have to type very often the 8-letter-namespace Template:, Category: or Module:, when you do not use another convenience. Nobody will be forced to type less as wanted, and you may type {{Oppose}} when you dislike {{O}}, but some people would like to be swifter.
  • There will also be nothing to maintain, because nobody else can meet such an abbreviation; when I type cat: into the search field, it will not be written anywhere, it is just that I save to type the letters "egory" at this very moment. It will not be future impact to anybodys disadvantage, it is solely personal and momentary.
  • BTW, your reference of Multichill fails: he thinks that it will be a not required nonsense, and with respect to his opinion I am thinking otherwise. Currently his contribution is the only opposing one, because yours and Nemo's are basing on a misunderstanding. -- sarang♥사랑 14:04, 4 September 2020 (UTC)

Add support for uploading AVIF[edit]

w:en:AVIF is an open, royalty-free image standard that will soon have support from and use by Chrome, Firefox, GIMP, Netflix, etc. It has even smaller file sizes than WebP. —Justin (koavf)❤T☮C☺M☯ 07:56, 10 July 2020 (UTC)

  • Symbol support vote.svg Support, if it's free to re-use then it's fully compatible with "Commons:Licensing". I know that this is not really "a vote" on it as these discussions are meant to give arguments and / or counter-arguments for a proposal, but as this seems like quite a logical addition to Wikimedia Commons' feature set I think that this could also just be "proposed" at the Phabricator, although I'm sure that the people over yonder would state that local consensus would be needed, so I support this file-type's inclusion. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:55, 18 July 2020 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. ツ please ping or talk to me 21:16, 18 July 2020 (UTC)
  • Symbol support vote.svg Support --IM3847 (talk) 05:46, 3 August 2020 (UTC)
  • @Koavf: not really needed to propose it here. It will just give a bunch of Symbol support vote.svg Support lines an nothing will happen. Development time needs to be spend on tasks like phab:T257652. That might take a while. Multichill (talk) 13:07, 7 August 2020 (UTC)
  • Moral Symbol support vote.svg Support, practical Symbol oppose vote.svg Oppose. There isn't enough support in editing tools or in browsers to justify adding AVIF support right now. My testing has also indicated that AVIF encoding is extremely slow, which would make it a much harder sell to implement. --AntiCompositeNumber (talk) 02:07, 13 August 2020 (UTC)
  • Symbol support vote.svg Support.--Vulphere 07:55, 21 August 2020 (UTC)
  • What free software supports it? Nemo 14:43, 30 August 2020 (UTC)

RfC: Deprecate XCF file format[edit]

Wikimedia Commons currently has 1,426 files in the XCF file format. XCF is the native image format for GIMP, and is designed to store images so that they can be edited. However, due to technical limitations summed up in T260286, the thumbnailing system only supports XCF files saved in GIMP version 2.8, while GIMP 2.10 is current. Even partial GIMP 2.10 support is a long way off, and full support for GIMP 2.10+ files looks unlikely.
XCF support on Wikimedia was introduced in 2006 to ease collaboration and to allow for translatable text. Because modern versions of GIMP produce XCF files that aren't visible on Commons, it is more difficult to edit and overwrite XCF files. Translatable text is now well handled by SVG files. Almost all XCF files on Wikimedia Commons would be better as JPG, PNG, or SVG files. XCF files typically do not compress the image data well, leading to larger file size even compared to PNG. XCF files do not have conditional sharpening applied when they are resized, which can make them look blurry. Finally, the metadata in XCF files is not especially stable (versions of GIMP other than the one used to write it can have difficulty reading it) and is not read at all by MediaWiki. --AntiCompositeNumber (talk) 00:52, 13 August 2020 (UTC)


Should Commons deprecate the XCF format, prevent new XCF files from being uploaded, and encourage XCF files to be converted to a more suitable format?

Votes (XCF)[edit]

  • Symbol oppose vote.svg Oppose We should find a solution for this problem. XCF could always be linked to an other file in PNG or JPG format. But maybe restrict the upload, like for MP3 files, to the autopatrolled rights. --GPSLeo (talk) 17:46, 16 August 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose In fact this is once again an attempt to move in the wrong direction. I feel that we should always encourage a person to upload XCF file rather than exporting into PNG or JPEG. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:54, 17 August 2020 (UTC)

Comments (XCF)[edit]

  • i think we should just have both a rendered and non-rendered version of the file. The point of commons shouldn't just be to collect free educational media, but also to support remixing the media to make new media. Having source material in easily editable format supports that goal. Bawolff (talk) 19:42, 15 August 2020 (UTC)
    My point is basically that XCF rendering on Commons is poor currently, and is unlikely to improve significantly anytime soon. Until ImageMagick 7 is backported or becomes available in whatever Debian repo Thumbor is using, XCFs from the current version of GIMP won't be thumbnailed. I feel that continuing to thumbnail XCFs creates unrealistic expectations, and allowing uploads for a file format that isn't thumbnailed creates moderation problems. --AntiCompositeNumber (talk) 20:11, 15 August 2020 (UTC)
    Additionally, people aren't using the features of XCF that would make them easily editable in my experience. I've only seen one XCF that was more than a single layer raster file. --AntiCompositeNumber (talk) 21:15, 15 August 2020 (UTC)
    I did find a few more images that do make use of layers and text. My point still stands that they'd be better as translatable SVG files though. --AntiCompositeNumber (talk) 21:26, 15 August 2020 (UTC)
    The thing is that I see a lot of opposition to people including raster images inside SVG. If that were to change, then we can talk about using SVG for that. Also tools to edit SVG with raster images in them is not as simple as editing XCF file. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:52, 17 August 2020 (UTC)

Disallow copyvio speedy tagging for old images[edit]

Recently, I came across File:M Yacoub.JPG, which was tagged for speedy deletion because the image can also be found at [1]. However, the image was taken in 2008 and uploaded in 2012, and the uploader's other uploads (e.g. File:Magdi Yacoub.JPG, File:Khalid Abdalla.JPG) are consistent with the story that they went to a gala(?) in 2008 and brought along their Canon 400D, so I have removed the tag. More generally, the longer an image sits on Wikimedia Commons, the less likely it is to be a copyvio (since people would have noticed and gotten it deleted already), and the more likely it is for another website to copy it (legally or illegally). I propose that we disallow {{Copyvio}} tagging of images first uploaded to a Wikimedia project more than X years ago (X TBD), and require a COM:DR to give users time to evaluate whether the external website is indeed older and whether the uploader's claims of own work make sense. -- King of ♥ ♦ ♣ ♠ 04:15, 18 August 2020 (UTC)

  • Symbol support vote.svg Support I generally support that we do not mark older images with speedy deletions. Not just copyvio. But also "no source" and "no permission". Sometimes information is removed pr broken and can be found in file history. Sometimes archive.org can help. --MGA73 (talk) 05:21, 18 August 2020 (UTC)
  • Symbol support vote.svg Support in theory, Symbol oppose vote.svg Oppose making it an official policy or guideline. I'll generally DR things that fall into the "ye olde images" category over {{Copyvio}}, mostly for the paper trail. However, I've come across a few images that, for whatever reason, are old but blatant copyvios that have flown under the radar. If I can confirm them using archive.org, metadata is suspicious, uploader has no real history, etc. I'll generally still tag {{Copyvio}}. I don't see the point of adding yet another file to the weeks-to-months-long DR backlog in that case. --AntiCompositeNumber (talk) 16:04, 18 August 2020 (UTC)
    Maybe we can add a warning to the {{Copyvio}} template that automatically detects the upload date, and if it's old, reminds the patrolling admin to double-check before deleting. I've seen too many good images get deleted because the patrolling admin was careless. -- King of ♥ ♦ ♣ ♠ 16:14, 18 August 2020 (UTC)
    That's not currently possible just inside a template without changes to MediaWiki as far as I'm aware. --AntiCompositeNumber (talk) 16:55, 18 August 2020 (UTC)
  • Symbol support vote.svg Support We already grandfather files where the permission is sent to the uploader and not to OTRS for files uploaded before OTRS system was in place. And this did not break everything. DR system has its problems, but it is significantly better than the alternative (delete and then expect somebody to find that the deletion was in error). ℺ Gone Postal (〠 ✉ • ✍ ⏿) 16:21, 18 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose - A copyvio is a copyvio and does not become other by virtue of age. Speedy tagging is merely the expression of a concern; it is not an automatic deletion, and it is indeed the duty of the processing admin to evaluate the claim. If admins are speedy deleting images on bad evidence or otherwise for poor reason, the problem is with those admins, not the tagging. Prohibiting a reasonable practice because some admins are doing a poor job is absurd, and a failure to remedy the genuine underlying issue. Эlcobbola talk 16:36, 18 August 2020 (UTC)
    Speedy deletion is meant to: 1) reduce the amount of time an unacceptable file remains on Commons; and 2) reduce the burden of DR. For a file that's remained on Commons for several years, a few more weeks isn't the end of the world. And there are relatively few genuine copyvios from many years ago, so it won't cause a strain on DR either. The problem is not with individual admins, but with the system, as I see mistakes being made by many different admins. I like to think that I am more diligent than the average admin, but it comes at a cost of efficiency: I cannot hope to rival the Jcbs of this world in sheer volume. Someone has to do the dirty work of deleting hundreds of files a day, and anyone given that task will not be able to give each image their full attention; our procedures need to be tightened up at the tagging phase. So I'm suggesting that we carve out cases that are statistically likely to be incorrect taggings and require them to use a process where more people have a chance to examine the situation. -- King of ♥ ♦ ♣ ♠ 16:55, 18 August 2020 (UTC)
    No, speedy deletion is meant to "bypass deletion discussions and immediately delete files or pages" (COM:CSD) The purport of efficiency is nonsense. This merely shifts administrative burden from processing the speedy tag to processing a DR, the latter being more labor and resource intensive. Not only that, it adds an additional decision layer to the speedy tagger, who may be new or otherwise unexpecting of a rule as absurd as this (before x date doesn't quality?), thus adding an additional burden to the admin finding the speedy to judge the date, convert the speedy, and notify of tagger of the required. This is a nonsense proposal based on, apparently, a single example of a poor speedy nomination (which wasn't even deleted, proving, if anything, the current system works (!!!)). You've not bothered to offer even a second, let alone numerous sustained examples (or even examples of actual deletions due to this issue) to evidence an on-going issue. Эlcobbola talk 17:31, 18 August 2020 (UTC)
    We want it to be hard to speedy delete old files, because they are unusually likely to be incorrectly tagged. I would not have noticed it if the creator had made an appeal to COM:UNDEL. Generally, the only people who look at the speedy deletion categories are the admins who are overworked and likely to make mistakes. Meanwhile, DR daily logs are visited regularly by many people, giving them an opportunity to opine. Can you give examples of files which were correctly speedy-deleted more than five years after upload? -- King of ♥ ♦ ♣ ♠ 17:45, 18 August 2020 (UTC)
    Yes. And it is, of course, not my burden to disprove your theory, but rather it is for you to support. I notice you've, again, not bothered to provide any evidence of a problem. Эlcobbola talk 17:51, 18 August 2020 (UTC)
    Then, perhaps instead of completely disallowing copyvio tagging, we require the copyvio tag to be evidenced by an archive.org link or a credibly dated external page. As an additional example, see File:WM2006happybirthdayangela.jpg, which was deleted even after the uploader added source information. (This was a {{No source since}} tag, but it's a similar case and I agree with MGA73's comment.) A key question is where the burden of proof lies for a small image with no EXIF metadata. I would say that for a recent upload, the burden lies with the uploader to prove that it is own work, but for an old upload the burden lies with the tagger to prove that it is a copyvio (i.e. they must find the image being used at an external site which is older than the Commons upload). -- King of ♥ ♦ ♣ ♠ 18:03, 18 August 2020 (UTC)
    Yes, I would be supportive of that (dated link), especially as I don't consider that a change but rather an articulation of what we've been expecting all along. Эlcobbola talk 18:10, 18 August 2020 (UTC)
I agree that a copyvio is a copyvio. But most times when a file is marked as a copyvio there is not 100% proof that it is a copyvio. It is a tag saying that someone suspect that it is a copyvio. For example if I'm a photographer and take a photo that is used for the front page of a magazine and I upload the front page of the magazine then it is not a copyvio even if it looks like it is. If someone tag it with a "npd" I will have 7 days to send the permission but if someone tag it with a copyvio an admin can delete it 4 seconds later. If I send a permission and it is undeleted what are the chances that the admin that deleted the file will check the log of commonsdelinker and add the file to all the articles again? I bet that the chances are 0. It will never happen. If I uploaded the file a few days ago I can probably remember where I added the file. But if it was uploaded 8 years ago it can be used in many projects because other users added the file to articles. And they can have used the file to create other files. On Japanese Wikipedia they have a master map that is used to make hundreds or thousands of other files. If I think the original is a copyvio and I delete the original and hundreds or thousands of derivated files it will be very hard to clean up. If I start a DR instead then other users have a chance to say "NO WAIT!". --MGA73 (talk) 16:35, 19 August 2020 (UTC)
  • Symbol support vote.svg Support prohibiting copyvio speedy tagging for images older than 10 years. While I agree that admins should be more conscientious about acting on speedy tags, I don't expect that to significantly change in the near future. If an image has been hosted on Commons for more than 10 years, I think it deserves the benefit of the doubt and should get a full deletion discussion. Kaldari (talk) 17:41, 18 August 2020 (UTC)
  • Symbol strong support vote.svg Strong support. The mistake ratio concerning old files is relatively high. If a file was hare as a copyvio for years it could not hurt much it it is left here for few extra days. Especially as it would be marked as a suspected copyvio. Incorrect deletion, then undeletion and usage restoration is quite complex process and it requires much more effort than a DR vs. speedy. Ankry (talk) 18:11, 18 August 2020 (UTC)
    "The mistake ratio concerning old files is relatively high." Can you provide data to substantiate this? Or to substantiate the implication that DRs and speedies have different error ratios? Would you agree the majority of DRs are closed without having received comment beyond the nomination? If so, how, precisely would a DR be better vetted than the speedy, or more compelling in a UDR? Эlcobbola talk 18:19, 18 August 2020 (UTC)
    True, but at a minimum a DR must remain open for at least 7 days (unless it is speedy deleted). A {{Copyvio}} tag often gives the uploader little time to address the allegations, and the file might already be deleted by the time they see it. Finally, the fact that no one commented is not an indication that no one reviewed the situation; someone might have reviewed it and concluded that the conclusion was so obvious they don't need to waste time !voting to get the closing admin to make the right decision. -- King of ♥ ♦ ♣ ♠ 18:38, 18 August 2020 (UTC)
    I'm neutral on the whole discussion but about "Can you provide data to substantiate this?": note that Ankry is quite active in UDR and their opinion even without advanced proof is probably based on their experience and is surely quite relevant therefore. Christian Ferrer (talk) 18:46, 18 August 2020 (UTC)
  • I think a guideline for admins that older images should be checked much better, then recent uploaded images, before deletion would be enough. If it is not clear on the first view it is always possible to change it to a regular DR. --GPSLeo (talk) 20:52, 18 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per Эlcobbola, a copyvio is a copyvio. If anything should be changed, then the awareness of the deleting admin that it may be a case that required extra attention. Maybe a warning can be shown if the upload is longer than a few weeks ago? --Krd 06:31, 19 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per Эlcobbola and Krd, furthermore administrators are elected, and it is a fact that the elections are not so easy, they are supposed to be trusted for the decisions to delete or not. Maybe a note can be written in our policy Commons:Criteria for speedy deletion in order to encourage administrators to pay close attention to the files thus tagged which have been here for several years. Christian Ferrer (talk) 10:58, 19 August 2020 (UTC)
  • Symbol neutral vote.svg Neutral I might change the text of CSD to emphasize that finding other images on the net are likely only meaningful if they predate the Commons upload (or Wikipedia upload, if uploaded there first). I'm not sure we have guidance like that on the criteria page. The copyvio tag is only for obvious copyvios, which finding other image on the net after upload does not demonstrate. Proving that does get increasingly harder for older images, for sure. On the other hand, there are blatant copyvios that have simply escaped attention for years -- not sure we want to absolutely bar those from being quickly deleted. And yet back to the first hand, older images are far more likely to be in use (either on wiki, or external) and it is nicer to have an explanation for the deletion if someone comes looking to see why an image disappeared, and regular DRs leave a record while speedy deletion does not other than the deletion comment, which is often pretty terse. I do tend to prefer DRs for older images. I'm just not sure a blanket ban is a good idea, but maybe adding some guidance that discourages use of speedy deletion for older images unless it's quite obvious. I've always had a problem with the wording "apparent copyright violation", since that seems to say that speedy deletion is appropriate when there is a possible copyvio but the nominator is unsure. Those seem more like DR situations to me. Carl Lindberg (talk) 03:02, 20 August 2020 (UTC)
    "Apparent" is horrible wording, because it is a contranym: it can mean either "blatant" (e.g. "the problems are apparent") or "probable" (e.g. "the apparent winner of the election"). -- King of ♥ ♦ ♣ ♠ 04:06, 20 August 2020 (UTC)
    +1 to that! This should be clarified before anything else: does "apparent" in COM:CSD#F1 mean "obvious" or "suspected"? I always assumed it was the former, but apparently the answer is not as obvious as I thought (scnr). --El Grafo (talk) 13:37, 20 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per above. 1989 (talk) 20:39, 25 August 2020 (UTC)
  • Symbol support vote.svg Support. I work regularly in speedy deletion requests and I find mistake ratio among old files relatively high. And on the contrary, among old files are relatively few copyvios. So I generally do not delete old files speedily, but change speedy DR-s into regular DR-s simply with reason "The file has been years in Commons and deserves a regular DR." For me X=5 years. Taivo (talk) 07:46, 28 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose per above. If an admin is speedy deleting without checking dates, the admins rights need to be reviewed, not policies.--BevinKacon (talk) 15:09, 28 August 2020 (UTC)
  • Symbol support vote.svg Support -- Tuválkin ✉ ✇ 11:52, 30 August 2020 (UTC)
  • Symbol oppose vote.svg Oppose Copyvio is copyvio. The issue won't be resolved as it stays longer on Commons. We can still see some old files on Commons being deleted as copyvio. Moreover, {{Copyvio}} or COM:CSD#F1 only applies to files that are apparent copyright violation. I believe that the admin will do a double check before deleting a file. If the file is not an obviously copyvio, they can convert them to DR. There is no need to establish a policy or guideline. --A1Cafel (talk) 04:21, 4 September 2020 (UTC)

Rollback RFC[edit]

Hi, There's currently an RFC on the ROLLBACK wording at Commons_talk:Rollback#"When_to_use_Rollback"_RFC if anyone's interested,
Thanks, –Davey2010Talk 18:31, 22 August 2020 (UTC)

Consolidate Template:Videos from/of X by year[edit]

I am proposing to consolidate ~100 templates for countries into a single {{Videos from country by year}}, and then delete them. Please state your opinions at Commons:Deletion requests/Videos from X by year.--RZuo (talk) 08:26, 1 September 2020 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=448008307"