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; the latest archive is Commons:Village pump/Proposals/Archive/2024/10.
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.
SpBotarchives 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
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)[reply]
Support About time. And just for clarity, can a local crat still emergency desysop a rogue admin even without the inactivity or RfDA procedures? pandakekok906:14, 30 May 2020 (UTC)[reply]
Strong support Revoking sysop permissions by bureaucrat here and not by a steward is faster (and I'm agreed about it), but how about with revoking bureaucrat permissions by bureaucrat? Nieuwsgierige GebruikerOverleg • CA06:46, 30 May 2020 (UTC)[reply]
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? Ahmadtalk07:34, 30 May 2020 (UTC)[reply]
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)[reply]
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)[reply]
Oppose With the level of infighting that Commons has had lately - this is a very bad idea to remove stewards from the picture. --Rschen775415:53, 30 May 2020 (UTC)[reply]
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/TRB16:39, 30 May 2020 (UTC)[reply]
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. pandakekok909:44, 31 May 2020 (UTC)[reply]
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)[reply]
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)[reply]
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 CellsTalk19:02, 31 May 2020 (UTC)[reply]
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)[reply]
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. -GerakiTLG16:53, 16 July 2020 (UTC)[reply]
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)[reply]
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. GMGtalk13:06, 16 August 2020 (UTC)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
AF228 and an invisible AF
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)[reply]
Change commons search view from list to Grid view
Currently Wikimedia commons is displaying search result in list view type. This is not what other popular services are doing.
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.
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)[reply]
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)[reply]
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. --pandakekok906:09, 10 June 2020 (UTC)[reply]
Neutral/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)[reply]
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)[reply]
Votes to enable grid view as an opt-in or as an optional feature
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)[reply]
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)[reply]
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).[reply]
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)[reply]
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)[reply]
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)[reply]
Accept files published by the copyright holder with a Public Domain Mark
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
I'm closing this proposal as accepted, with 29 (including myself) in favour and 9 against (76% in favour), after about 2 months of discussion and voting. --ghouston (talk) 22:59, 26 August 2020 (UTC)[reply]
Files published with a Public Domain Mark (PDM) alone are not currently accepted at Commons: an additional reason must be found for why the file is in the public domain. This proposal is to accept files that have been published by their copyright holder with a PDM, using a new template:
{{PD-PDMark}}: "The copyright holder of this work has published it with a Public Domain Mark. Although the Public Domain Mark is not itself a public domain release, when applied by the copyright holder in this way it implies that the work has been released into the public domain."
{{PD-PDMark}}: "A Public Domain Mark has been applied to this work by its copyright holder. Although the Public Domain Mark is not intended to be used on one's own works, when it is applied by a copyright holder in this way it implies that the work has been released into the public domain."--ghouston (talk) 10:33, 24 June 2020 (UTC)[reply]
The third version is simplified based on a wording by User:Brianjd:
Since the original RFC from 2015 at Commons:Requests for comment/Flickr and PD images, which resolved not to accept files released only with a PDM, there have been recurring discussions questioning that decision, such as:
Note: following a point raised below, this proposal wouldn't make PD Mark a new option when an uploader is putting their own works on Commons, including when they are copying their own works from another site. They should use one of the existing public domain dedications, preferably {{CC-zero}}, but there are others including {{PD-self}} which are accepted. --ghouston (talk) 00:00, 27 June 2020 (UTC)[reply]
If this proposal is accepted, I suggest a slight change the wording:
The copyright holder of this work has published it withapplied a Public Domain Mark to this work. Although the Public Domain Mark is not itself a public domain release, when it is applied by the copyright holder, it implies that the work has been released into the public domain.
Support when the uploader is clearly the copyright holder. I would recommend everyone familiarize themselves with the existing conversation at Commons:Village pump/Copyright#Double standards for Public Domain Mark. I am not arguing that PDM is particularly rigorous. However, none of the Flickr licensing choices are. As you can see, the choices you have simply show up in a dropdown: All rights reserved, Public Domain Work, Public Domain Dedication (CC0), Attribution, Attribution-ShareAlike, etc. Unlike Wikimedia projects, there is no clickwrap agreement to ensure that the uploader has actually read and understands the license; they can just select an option and *poof* the file is licensed. None of the choices link to the official license you are using until after you've already selected it, raising the question of whether you can actually agree to a license that is only shown to you after you've chosen it. "Public Domain Dedication (CC0)" is the only license that even mentions the name of the license, and even there to most people CC0 is probably incomprehensible gibberish; most people cannot be expected to know the difference between the two PD options, so intent is what matters since the legal text is dubious anyways (again, how can you release a work under a license you've never read?). "Attribution" et al. do not even mention the fact that it is a CC license or the version of the license (until you've selected it); how do we know they didn't mean {{Attribution}}? There is also a slight nuance between the words "mark" and "work" (the latter being the actual wording used by the Flickr UI). If you choose "public domain mark", it has a little more connotation of just labeling something, but if you consciously choose "public domain work", the most reasonable interpretation is that you're making the statement "my work is a public domain work". In conclusion, so long as we continue to accept Flickr images at all, which are not rigorously licensed by any stretch of the imagination, we should not apply an artificially high standard to PDM. -- King of ♥ ♦ ♣ ♠06:22, 23 June 2020 (UTC)[reply]
It depends. The reason why the CC0 and {{PD-self}} (and related templates like {{PD-author}}) have a lax permissive fallback license is because some countries don't recognize "public domain" alone. In those countries, there must be an explicit permission to use the file for any purpose without any conditions from the copyright holder. If the external image is taken for example by a person who lives in the U.S., is taken in the U.S., hosted in the U.S., and the Commons uploader is from the U.S., then we could accept those PDM images. The same applies for those countries which recognize "public domain" alone as sufficient. All the conditions should be from countries that recognizes PD alone. If even one of them fails, we can't upload it. Files must be free in the U.S. and the source country to be uploaded and hosted here on Commons. pandakekok907:03, 23 June 2020 (UTC)[reply]
I don't think this is really tested much in court, at least outside the USA. I've never seen a copyright law that made any explicit provision for abandoning copyright, let alone explaining how it's supposed to be done. It would be an unusual sort of court case, where somebody would have to release something into the public domain and subsequently sue somebody for copyright violation, I guess. So I don't think it's possible to say that particular countries don't recognise public domain dedications. There are some that don't permit loss of certain "moral rights", but that also applies to licensing. --ghouston (talk) 07:47, 23 June 2020 (UTC)[reply]
It is indeed unusual for a copyright holder to sue someone for copyright violation even though they "released" it into the public domain, but I think it's totally possible. Otherwise, we don't really need such licenses like CC0 or Unlicense. A copyright troll who lives in a country that doesn't recognize PD dedications could mark their work as PDM, and bait others to use and copy it. After the bait succeeds, the copyright troll can sue them and profit from it. If we are going to accept all PDM works from any country, we should add a disclaimer noting that marking a work under PDM doesn't automatically mean it is released into the public domain in some countries, and warn the reuser that the work may still be non-free in other countries. pandakekok908:29, 23 June 2020 (UTC)[reply]
Anything is possible, but has it ever happened? Somebody trolling at that level could just as well upload their work to Flickr with a CC-BY licence and an alias. --ghouston (talk) 08:53, 23 June 2020 (UTC)[reply]
I would like to know which country would not allow it, really -- the economic right is always transferrable, and if you can sell the right I don't see how you can't abandon it. CC0 also tries to give up moral rights and other related rights, and those are indeed often not transferrable, and that is where a fallback license is definitely required (and even that may not always be operable). PDMark would just release the economic right and nothing else, so moral rights would still need to be followed (which we would normally do anyways). Moral rights are a non-copyright restriction though, so that is not a reason for deletion. Carl Lindberg (talk) 08:41, 23 June 2020 (UTC)[reply]
PDM doesn't say "public domain" though. If we go by the Flickr UI, it's "Public Domain Work" vs. "Public Domain Dedication (CC0)" - hardly a difference except for the CC0 name-drop which will be incomprehensible to a vast majority of uploaders. If we go by the legal text, it does not mention public domain at all and simply says "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission", so if one puts this on one's own work I think it should be sufficient. -- King of ♥ ♦ ♣ ♠14:07, 23 June 2020 (UTC)[reply]
Support when the uploader is clearly the copyright holder -- there is no way for that statement to be true unless the author has waived copyright. The intent to me is clear; CC-Zero is not particular well titled unfortunately, and most people know the term "public domain" and choose that instead as the title they recognize more. The wording of PDMark seems explicit -- copyright is irrevocably given up. To me it's certainly as good as PD-self or PD-author, etc. An explicit public domain declaration has been shown to give up all rights in the U.S. -- Carol Highsmith tried to sue Getty for selling her (declared PD) photos without giving credit, but since she had given up all rights she lost the case. The credit part would be required in other countries due to moral rights, but I really don't see how the economic right would work differently in other countries -- as far as I know there is no such precedent (whereas we do have a precedent the other way). It seems like it should qualify as the overt act mentioned at w:abandonment (legal)#Abandonment_of_copyright.
I would not allow automatic uploads from Flickr via the bots with the tag, and they should also require a human license review (maybe the bots could at least validate the PD-Mark tag without marking it OK), but I think they should be allowed when marked by the copyright owner -- seems like common sense to me, really. I might make the wording of a {{PD-PDMark}} (or maybe {{PDMark-author}} or {{PDMark-owner}}) tag more like "Although the Public Domain Mark is not intended to be used on one's own works, when it is applied by the copyright holder" (continuing with the rest of Brianjd's proposed wording), rather than saying it's not a release, because I think it does have that effect. Carl Lindberg (talk) 08:41, 23 June 2020 (UTC)[reply]
Support If I upload a file to Commons and add a license I'm requested to add a source and an author. If I do not then file risk deletion. When I upload to Flickr I'm not asked to provide source or author. We on Commons just assume that the uploader is the photographer.
So to me it makes no difference if I add CC or PDM. I'm not asked to tell WHY the file is CC or PDM. There is no active "I xx the copyright holder of this file hereby release the photo as CC" so I do not think it is a big problem if the author do not actively declare a "I xx the copyright holder of this file hereby release the photo as PD". --MGA73 (talk) 19:53, 23 June 2020 (UTC)[reply]
Support If the copyright holder publishes a file with a Public Domain Mark, the intention to release it as PD should be clear enough, even if it's not the formally right way to do it. Gestumblindi (talk) 22:53, 23 June 2020 (UTC)[reply]
I would like to change it back to the active voice: “The copyright holder of this work has …” This is consistent with {{Self}} and {{PD-self}}, at least, and emphasises the most important thing here: the copyright holder’s wishes.
In the second sentence, by a copyright holder and in this way seem to mean the same thing; one of these should be deleted.
I would like to move Although the Public Domain Mark is not intended to be used on one's own works to explanatory text (to be drafted later) (and reword the rest of the sentence accordingly).
So main text would say:
The copyright holder of this work has applied a Public Domain Mark. This implies that the work has been released into the public domain.
Yes, I think it's better to keep the wording simple on the template itself. It would be followed by: For details, see Commons:Public Domain Mark, were a lengthy essay can be written to discuss all the points raised during these discussions. --ghouston (talk) 00:22, 25 June 2020 (UTC)[reply]
Support, I've seen literally thousands of such images on qFlickr which were high quality images of museums and / or archaeological sites with this license, this weird double standard is a major disservice for Wikimedia Commons, it's essentially saying "We want free files, but not that free." Which is absurd. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:41, 24 June 2020 (UTC)[reply]
Support Talked about this for too long, time to do it. In copyright law there's always space to recognize "reasonable" and in this case where an uploader has made a reasonable assessment that the copyright holder has released their own work then a templated warning is sufficient. --Fæ (talk) 10:45, 25 June 2020 (UTC)[reply]
I like the text, but prefer PDMark-owner as the new template name, to distinguish it from "normal" uses of PDM -- otherwise people may think they can use it on *any* PDM-marked file on Flickr. Carl Lindberg (talk) 03:10, 26 June 2020 (UTC)[reply]
The name isn't great, but the convention seems to be that the public domain templates start with "PD-", see the contents of Category:Public domain due to copyright expiration for example. Maybe PD-PDMark-owner or PD-owner-PDMark. I'm not sure if we should also include the PDMark verison, currently 1.0. The existing template is {{Flickr-public domain mark}}. Also, COM:PDM redirects to a section of a page about Flickr: the section would need to be updated, and COM:PDM could redirect to a new Commons:Public Domain Mark page instead. --ghouston (talk) 04:25, 26 June 2020 (UTC)[reply]
Since "PDMark" already starts with "PD", it seems a little redundant just so it has the dash. More like CC0, it is the name of a particular wording, rather than a generic-use PD tag. And I do want to distinguish between when copyright owners use it versus any other use, which should still require a more specific tag. Flickr-public_domain_mark is still generic, and should probably continue to be a redirect to a speedy deletion, though it should of course mention the new tag if this passes. And yes, COM:PDM would need updating, for sure, as well some other pages that older DRs point to (such as Commons:Requests for comment/Flickr and PD images). I'm not opposed to PD-PDMark-owner though -- just seems a bit redundant, but if folks feel the "PD-" prefix is important enough to preserve, then fine. Carl Lindberg (talk) 05:06, 26 June 2020 (UTC)[reply]
I also slightly prefer PDMark-owner. If Cc-zero didn't exist I'd probably want to preserve the "PD-", but since the naming convention is broken anyways I see no reason to insist on it here. -- King of ♥ ♦ ♣ ♠05:49, 26 June 2020 (UTC)[reply]
I don't mind putting a restriction on this proposal, that you can't upload your own files to Commons with a PDM alone, it applies only to uploading the works of others already published on other sites. Perhaps in some cases the author of the work will have a Commons account: I don't think that should prevent a transfer to Commons by others, since they may have just uploaded a few files to Commons years ago. --ghouston (talk) 14:12, 26 June 2020 (UTC)[reply]
Agreed. I think CC-Zero or PD-self should be used for first-time-being-published uploads to Commons, but should not prevent transfers to Commons. Carl Lindberg (talk) 16:00, 26 June 2020 (UTC)[reply]
Oppose the proposal to allow files to be on commons without an legally binding and explicit release under a free license (or to the public domain). In the U.S., marking one's own work with the public domain mark would probably be a valid waiver of one's rights. This is likely untrue in other countries, seeFSF thoughts on informal releases. Marking one's own work with the Mark is more like an implicit license than an explicit license: it does not say "[I] irrevocably and unconditionally waive[], abandon[], and surrender[] all of [my] Copyright..." (CC0 1.0 legal code); rather, the PDM has no legal text at all, and says that the work was identified by someone as being in the public domain, and therefore reusers may use it accordingly. According to Creative Commons (who I would like to think know what they have written), "The PDM is not a legal instrument.... It should not be used to attempt to change a work’s current status under copyright law, or affect any person’s rights in a work.... PDM is not legally operative in any respect" (PDM FAQ). To see the difference, Compare "This work has been identified as being free of known restrictions under copyright law, including all related and neighboring rights." (PDM 1.0 summary) with "The person who associated a work with this deed has dedicated the work to the public domain by waiving all of his or her rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law." (CC0 1.0 summary), "To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights..." (CC0 1.0 legal code). All of that being said, if there is a consensus to allow works marked with the PDM onto Commons, I would like the template to use the name {{PDMark-owner}} with the following text: "The copyright holder of this work has applied a Public Domain Mark to it, which is thought to constitute an implicit waiver of their copyright in the United States. Other countries' courts may interpret the Public Domain Mark differently. This template should only be used on transfered files from other websites, and only on files where the Commons uploader is not the copyright owner. If the Commons uploader is the copyright owner, or this is not from another website, have the copyright owner explicitly release their work under a free license or dedicate their work to the public domain using the {{CC0}} dedication." --Mdaniels5757 (talk) 00:48, 27 June 2020 (UTC)[reply]
Keep in mind that the FSF guidance is about licenses, not an outright waiver of all rights, and is also about wording much less explicit than PDM. There is not much ambiguity in You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. It's similar to other PD statements that we do accept, and have always accepted ({{PD-self}} and {{PD-author}}). And while it was not intended to be a license, what Creative Commons intended does not legally matter, most likely -- more important is what the copyright owner intended. For one example, Creative Commons had their intended interpretation of what keeping the notice "intact" meant in a FAQ, but a court ruled that the actual license wording should be interpreted differently. I don't think it should be a general license here, but to me owners' intent is fairly clear when they use it on Flickr, and potential problems with such uploads are extremely theoretical at best, and fall well below COM:PCP. Carl Lindberg (talk) 01:52, 27 June 2020 (UTC)[reply]
Support I support this as an overdue acceptance of good faith efforts by flickr users/ photographers and Users here on the Commons to make their work more accessible to the world. I also support a process to identify and undelete all flickr uploads that were deleted, but now qualify for this new tag. I hope this process would be open for anyone to help get this job done. As for future flickr uploads of this potential new trove of available photos, can future uploads be made simple and/ or automated for the uploader using the Upload Wizard? Thanks to all in support. --Tibet Nation (talk) 01:01, 27 June 2020 (UTC)[reply]
Not sure about the upload wizard. We won't be accepting the PDM as a general license -- when used on old works created by others (the intended use, and the case for many files on Flickr) we still need a more specific, existing license tag to explain why it is public domain. Not sure we want to open up those images to being imported. Carl Lindberg (talk) 06:36, 1 July 2020 (UTC)[reply]
Definitely oppose adding this to the Upload Wizard. Part of the reason why we're in this predicament is because Flickr makes it too easy to select the PDM. Works should only be uploaded to Commons under the PDM by experienced users who know what they are doing. And yes, I plan to go through Category:Public Domain Mark 1.0-related deletion requests/deleted and overturn all the DRs where the only reason for deletion was that an image was under the PDM. -- King of ♥ ♦ ♣ ♠16:10, 3 July 2020 (UTC)[reply]
Support I reckon that's reasonable. The intention of the author of licensing in the public domain is clear in those cases. BTW: We've to check it it's OK for thoses countries where the public domain is borderline as a valid license (e.g. France) Ruthven(msg)07:00, 27 June 2020 (UTC)[reply]
Note that the official text says, "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission." So I think it ought to be OK even in those countries. -- King of ♥ ♦ ♣ ♠00:19, 28 June 2020 (UTC)[reply]
Oppose Looking at the Swedish copyright law, I see that the copyright holder has the right to transfer the copyright to someone else (Article 27). Transfer of copyright is sometimes known as 'granting permission', but the legal term is 'transfer'. However, I do not see any right to annul the copyright, and there are limitations in copyright transfer (for example when it comes to moral rights). A court would look at Article 43 where it says that the copyright expires 70 years after the death of the author and note that the work is copyrighted as the author is alive.
The next question is if the copyright tag counts as 'transfer of copyright' (permission). The problem here is that the legal text only states that the work isn't copyrighted, but it doesn't say that the author has granted any rights to use the work whatsoever. There could be issues if the author claims that he didn't know how copyright works and that he fixed the copyright tag after learning about this. For example, some new uploaders seem to think that anything publicly available is in the public domain. A person using the work could explain to the court that he was tricked by the author's fraudulent copyright tag and therefore believed that the work wasn't copyrighted. The court may or may not side with the person using the work regarding previous use of the work, but now that this person is aware that the copyright tag was wrong, he might not be able to use the work in the future. In other words, the unclear copyright statement might de facto make it into a revocable licence. However, Commons doesn't accept revocable licences. --Stefan2 (talk) 22:36, 30 June 2020 (UTC)[reply]
The thing is that we don't require an explicit statement of irrevocability in many other cases. Take {{PD-self}} for example, or the CC-BY 2.0 on Flickr, where the uploader has to do little more than select "Attribution" on a drop-down that doesn't even disclose what they are consenting to until they have already selected it (see my initial comment). PDM is being singled out for no good reason, I think. -- King of ♥ ♦ ♣ ♠22:41, 30 June 2020 (UTC)[reply]
I find it odd that a right can be completely sold or given away, but cannot be abandoned (i.e. given away to nobody). That seems strange to me -- is there any precedent for that being denied? To me, the right to transfer should imply the right to abandon/annul, though I could be wrong -- but I'm not aware of a counterexample. Moral rights, sure, those are not affected by the PDM at all (just the economic right), but that does not affect "free" status (moral rights are a non-copyright restriction). As for the legal text, it says You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. That sure seems like a grant of rights (though not necessary if those rights have in fact been abandoned). As for an author claiming ignorance, they can make the same claims with CC0 or CC-BY or any other license or statement. An abandonment is not revocable -- it doesn't need to explicitly say that. The BSD license doesn't use the word, yet it is not revocable either. Generally, you must make a license explicitly revocable if you want that attribute. Carl Lindberg (talk) 06:36, 1 July 2020 (UTC)[reply]
An example would have to consist of some European version of Carol M. Highsmith successfully suing an agency for selling her PD works without attribution - and for the court to rule that the agency has violated her copyright, not just her moral rights. I am not aware of any such case law. -- King of ♥ ♦ ♣ ♠20:26, 2 July 2020 (UTC)[reply]
Support The Flick user should know what they are doing. If they choose the license of PD-Mark, it is assumed that they release the photo to Public Domain. It is unnecessary to concern about the copyright status in US and their home country. BTW, it is a real shame that many good quality photos from Flickr can't be used just because of the PDM 1.0 restriction. However, some "Flickr-washing" account use PDM 1.0 as the license. If the PDM 1.0 restriction was lifted, there may be more Flickr-washing file. This required more patrol. --A1Cafel (talk) 02:41, 1 July 2020 (UTC)[reply]
Support. The license seems applicable to Wikimedia Commons, not withstanding possible issues outside US jurisdiction, but more or less similar restrictions seem to apply to the already accepted other licenses also. Eissink (talk) 15:30, 2 July 2020 (UTC).[reply]
Support but only if we are vigilant to restrict to cases where the uploader is the copyright holder and step up efforts against flickrwashing. Buidhe (talk) 06:33, 4 July 2020 (UTC)[reply]
Oppose The PDM is not a waiver or a "fallback license" in the same way that CC0 is. It's only a labelling tool, and it is *not* supposed to be used by the copyright holder; the copyright holder should use the CC0. See the difference in this comparison chart between the CC0 & PDM made by Creative Commons. If the Flickr community doesn't know how to apply the CC licenses and tools, the way to fix it is not by creating more misunderstandings around the CC tools. PDM should only be applied to works that are in the worldwide public domain because the term of copyright has expired or is not applicable. Scann (talk) 13:11, 6 July 2020 (UTC)[reply]
That is what it was meant for yes, but if a copyright owner is using it on their own works, the intent seems fairly clear -- and an abandonment of copyright is the only way that would make sense. The wording may also qualify as a fallback license, as well. The intent of Creative Commons has no bearing on all that -- just the intent of the copyright owner. It's not recommended, for sure, but that's a different question than it still being legally valid. Carl Lindberg (talk) 13:33, 6 July 2020 (UTC)[reply]
CC's interpretation of the licenses and tools it's super relevant to the discussion. First, I seriously doubt that the PDM would be accepted as a waiver of rights in other countries; I think the US and some common law countries might accept it as a waiver of rights, but seriously doubt this for civil law countries. Second, CC can and has participated in the past in official interpretations of their license suite, because that's one of their main responsibilities as the stewardess of the licenses, in court cases such as Great Minds v. Fedex. So it does matter what they think, because when you are at a court case you'll surely want to call them in to offer their interpretation of their tool/license. Moreover, I don't see why you'd break a tool that someone else created just because you have an untrustworthy source of copyright statements such as Flickr. This is a Flickr problem, not a PDM problem. You're not fixing anything here with this statement, just breaking things that do work. Scann (talk) 18:08, 6 July 2020 (UTC)[reply]
They may be asked about their interpretation, but if someone licensing a work thought it meant something else, then a judge would have to decide if that was reasonable too. When it came to the clause about the copyright notice remaining "intact", CC (per one of their FAQs) only intended that to mean that the text should remain intact, not the placement (such as embedded in an image). When that came to a court case though, the judge ruled with a different interpretation, since in the end it was only the words actually in the legal license that mattered. So in that case, no, CC's intent did not matter either. In this case, the copyright owner is putting a statement of You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. on their work. I would be interested in knowing how that would not have an affect in civil law countries -- if you can sell or give away the economic right, why can't you give it away? In the end, if the copyright owner intended to place their works in the public domain -- and I really can't figure out what else they could have meant by putting that mark on their own works -- then that is what they likely did. I don't think Creative Commons gets to decide if that actually makes it PD or not. Part of the problem is the names -- people know what "public domain" means but they don't necessarily know what "Creative Commons Zero" means. And yes, maybe Flickr could do better, by making it clear that PDM is not intended for your own works, the way everything else in the licensing list is. Maybe PDM shouldn't even exist, since works PD in one country may not be PD in another, etc. But it does, and users on Flickr use it, and I really don't see the difference between the statement there and {{PD-self}}, or other similar "public domain" statements we use {{PD-author}} for. Carl Lindberg (talk) 02:06, 7 July 2020 (UTC)[reply]
"and it is *not* supposed to be used by the copyright holder" - We would not be having this conversation of copyright holders were as educated on the nuance of licensing as we are, but the reality on the ground is that lots of people are using PDM because they understand what "public domain" is but have no idea what "creative commons" is. Many of these Flickr accounts have been unused for years, as well, so even if we were somehow able to come with a concise and easy to understand way to word the request, and get it to all these accounts, it's likely that many of the files will remain unusable. The Squirrel Conspiracy (talk) 16:00, 6 July 2020 (UTC)[reply]
With that criteria, then you shouldn't use anything that is CC BY on Flickr because last time I checked when Flickr announced that they were going to commercialize some of their photos that were under a CC BY, there was a public outrage around this. So it's either you accept the copyright holders decisions as valid or you don't. This argument could also be used by a copyright holder to say "no no but my intent wasn't really to use a CC BY; I didn't want to let the work be used with commercial purposes". Scann (talk) 18:08, 6 July 2020 (UTC)[reply]
Exactly, exactly, that's precisely my argument. If we carry your logic to its logical conclusion, then we would ban all Flickr images. If we continue to accept Flickr images, then we have no reason to treat PDM differently. -- King of ♥ ♦ ♣ ♠22:10, 6 July 2020 (UTC)[reply]
So your proposal is to break a tool that does work because of a platform that's doing things the wrong way. PDM has been clearly designed to be applied by someone that does have knowledge on the subject, to works that are believed to be in the worldwide public domain. Don't add to the copyright statements mess that Commons already is by inventing a new template for a tool that's perfectly clear for someone who has the knowledge on how it should be used. This is Flickr's problem. Scann (talk) 18:21, 7 July 2020 (UTC)[reply]
As Carl explained above, the intent of Creative Commons (i.e. the organization) behind creating the PDM doesn't matter. How is the following statement, when applied by an author to their own work, not clear? "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission." -- King of ♥ ♦ ♣ ♠20:35, 7 July 2020 (UTC)[reply]
Oppose per Scann and others: It's not a proper release. This feels like {{PD}} all over again. This fails the precautionary principle. This is like having a straw poll to decide that the world is flat: It doesn't matter how many people support it, it is still incorrect. Multichill (talk) 17:44, 6 July 2020 (UTC)[reply]
@Multichill: It's not {{PD}}, it's just a specific form of {{PD-self}} really. This is *only* for when the copyright owner uses it on their own works, not for any other situation, which of course would continue to require a more specific copyright tag. Carl Lindberg (talk) 21:22, 6 July 2020 (UTC)[reply]
Mike nobody picks "public domain mark" as their license, what happens is that for years Flickr users were presented with "Public Domain" as one of their license options. That sound great in general but than Flickr links "Public Domain" to CC PDM page, causing all this confusion. From the Flickr user's point of view they just released their photographs to Public Domain, but we are refusing to accept them because Flickr links that phrase to a wrong page. Flickr is notoriously clueless about copyrights, why else would they be still using cc-by-2.0 instead of 4.0, but that should not interfere with users intentions to release images to PD. --Jarekt (talk) 19:31, 6 July 2020 (UTC)[reply]
Mike I do not think we should assume that they meant CC-0. CC-0 is a relatively new invention. I think we should assume that their intentions was the same as the intentions of generation of Commons users that used {{PD-self}}. For example me in 2009 when I created File:Commons Overcategorisation Rules 01.svg I added {{PD-self}} to release it to Public Domain, when on Flickr you do the same by picking "Public Domain" license. I agree that CC-zero is much better (legally clear) way of achieving the same, but just like I should not be relicensing my file from {{PD-self}} to (possibly?) more restrictive CC-Zero, we should not assume that Flickr users who chose to release their files as "Public Domain" really meant CC-Zero. {{PD-Author}} is the template generated over a decade ago for files released on external sites as PD. --Jarekt (talk) 20:01, 6 July 2020 (UTC)[reply]
@Mike Peel: If I, as a photographer, "waive all my rights etc." (CC-0), why could I not then "identify that work as being free etc." (PDM)? I don't think you can say I don't have that right. Of course I'm playing devil's advocate here also, but the ambiguity is in the license, which is the reason we have this discussion in the first place. Eissink (talk) 20:03, 6 July 2020 (UTC).[reply]
@Mike Peel: No, we can't, and no, it shouldn't. The author chose the PDM-license and is not obligated to provide a license for his or her considerations. Thank you, Eissink (talk) 20:32, 6 July 2020 (UTC).[reply]
@Mike Peel: You automatically get those rights, and you also get the ability to abandon them (i.e. give them up, or waive them) if you want (or sell them, of course). That is almost certainly the effect of using such a notice on your own works. There was a court case where Carol Highsmith specified public domain status for many photos she donated to the Library of Congress, then Getty was selling them without attribution, and she lost her case over that -- they were in fact public domain at that point so Getty did not have to attribute them (in the U.S. anyways). You do need to have an overt, explicit act to make that happen, but placing this mark on your own works should do that. Carl Lindberg (talk) 21:22, 6 July 2020 (UTC)[reply]
Oppose Note that the persons who use the PD mark are obviously not familiar with the use of licenses otherwise they would have chosen a relevant license. There is something a little bit immoral in taking advantage of these people's unquestionable lack of knowledge about the licenses and potential protections that go with it. Simply try to contact the Flick authors who have content potentially good, to ask that they chose a valid license. Christian Ferrer(talk)18:20, 6 July 2020 (UTC)[reply]
Christian Ferrer, I do not think we should be protecting Flickr users from themselves as we with our superior legal knowledge would be taking advantage of them. Here on Commons we do not allow relicensing from less restrictive to more restrictive licenses and I do not think we should be asking others to do the same on our sites. Also some Flicker users choosing "Public Domain" know exactly what they are doing, for example see File:Jonathan roth 5182943.jpg by User:Slowking4 who has been on Commons since 2007. --Jarekt (talk) 20:12, 6 July 2020 (UTC)[reply]
Of all of the arguments here, I think yours is the strangest Christian Ferrer. Can you give me any possible explanation for why someone would tag their own work "public domain mark" other than that they intended to release it into the public domain? Most people outside of our bubble on this project have never heard of Creative Commons, but they have heard of "public domain", and seeing "public domain mark" and thinking it meant the same thing as "public domain" is the most reasonable possible interpretation. The Squirrel Conspiracy (talk) 21:07, 6 July 2020 (UTC)[reply]
After to have done hours and hours of maintenance work here, it is obvious to me that some people are completely foreign to the concept of copyright and to the concept of license, therefore at the question "God, why they do that?" 1/ I have no answer 2/ this question can be asked in many, many and many other situations without there being a possible answer either. Christian Ferrer(talk)03:58, 7 July 2020 (UTC)[reply]
If your argument is "we shouldn't take advantage of Flickr users' ignorance": Note the options that are actually available on Flickr. For "Attribution", there isn't even a reference to Creative Commons at all. How is it OK for Flickr to foist upon them some random "Creative Commons license" that they never heard of, when all they chose was "Attribution"? If we accept that kind of lack of rigor as OK, then I don't see how PDM, which says "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission," is not acceptable. (The problem with contacting Flickr users to change the license is that many of them are inactive; we don't want to deny ourselves access to content that the author intended to release into the public domain, just because they can no longer be found.) -- King of ♥ ♦ ♣ ♠22:10, 6 July 2020 (UTC)[reply]
Support if the copyright holder publishes a file that way, but the copyright holder need not be the uploader to Commons. There are photographers on Flickr who have released their files under a PDM, but they are not accepted on Commons. SarahSV(talk)20:48, 7 July 2020 (UTC)[reply]
Support I think it's pretty clear that someone marking files they have created with the public domain mark both intends to put them into the public domain and has the legal right to do so. --GRuban (talk) 19:53, 9 July 2020 (UTC)[reply]
Comment: What happens if the creator of the photo publishes an image under the PDM mark, someone uploads it to commons, and then the original creator republishes or changes the licence to a more restrictive one (say a CC BY-NC-ND licence). Will we remove the file from commons then? - Harsh06:52, 12 July 2020 (UTC)[reply]
I expect that we would say that once the creator has said that their work is in the public domain, it will stay in the public domain. Since they are no longer the copyright holder, they no longer have a right to license the file. If a court in a particular country decided that they didn't recognise the original public domain release then the new license would apply. This could also happen if say the work was widely used, the creator died, and the heirs decided to try to exploit it commercially. In this situation it would be up to the Wikimedia Foundation lawyers whether to accept a DMCA request, which would be a necessary first step in any legal action. --ghouston (talk) 07:32, 12 July 2020 (UTC)[reply]
I think what you say is not what is said on the page you linked to, where public domain dedication is not discussed, nor even addressed. Please explain yourself further, Multichill, because now it seems you're sending people into the (Dutch) woods and in the woods is nothing to be found. Eissink (talk) 14:38, 12 July 2020 (UTC).[reply]
It is not discussed because there is no such thing under Dutch copyright law ("auteursrecht"). It does discus licences. Don't forget that {{Cc-zero}} is a license so it's perfectly acceptable under Dutch law. Multichill (talk) 15:09, 12 July 2020 (UTC)[reply]
@Multichill: I don't see why the application of a PDM wouldn't count as "overdracht via (digitale) akte", but that's the last thing I'll say on the subject as far as Dutch law is concerned, because it's a secondary discussion from the main one here. Eissink (talk) 15:54, 12 July 2020 (UTC).[reply]
So far the only known case law is with Carol M. Highsmith in the US, where the court ruled that she no longer has any rights to her photos once she put them in the public domain. So we know that "public domain" is a lower bound in the US, so PDM is definitely OK for the US. I don't know of any case law regarding the retracting of public domain releases elsewhere in the world. However, unless a court elsewhere rules explicitly on the PDM, any case law showing that "public domain" is insufficient wouldn't necessarily imply that the PDM is not OK, because it is superior to simply calling something "public domain", containing a combination of "Public Domain", "No Copyright", and "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission." -- King of ♥ ♦ ♣ ♠15:17, 12 July 2020 (UTC)[reply]
There isn't anything special about copyright law in the Netherlands as far as I know. Copyright law never says anything about waiving copyright or dedicating works to the public domain. It's the same in the USA, yet courts in the USA apparently accept it. If it turns out at some point that courts in a particular country do not recognize any ability to dedicate works to the pubic domain, then we would presumably have to require that works from that country could only be accepted with a free license, not a public domain statement alone. --ghouston (talk) 23:08, 12 July 2020 (UTC)[reply]
It seems quite likely to me that a court in any country would interpret a statement like [1] as giving permission for people to do what they like with the work. --ghouston (talk) 00:20, 13 July 2020 (UTC)[reply]
Correct, that's my point, absent a court ruling specifically that the PDM is invalid as a copyright release I think it is valid worldwide. -- King of ♥ ♦ ♣ ♠00:48, 13 July 2020 (UTC)[reply]
Support PD mark clearly indicates the intent to make it freely usable. I don't think it's worth nitpicking the letter of the law here. Renata3 (talk) 03:05, 13 July 2020 (UTC)[reply]
Support I prefer that Template:CC-zero is used and other licenses of same meaning. I suggest that after deleting PD-PDMark, delete also {{PDMark-owner}} because it has inconsistent 01 name and 02 content meaning (if there is 01 owner then it cannot be 02 public domain). I agree with {{PD-self}}, {{PD-author}}, {{PDMark-author}} and similar licenses. However, because most of the users put CC 4.0 or something like that, I do not give nature photos I make into public domain but use {{self|cc-by-sa-4.0}} most of the time (I think I remember I uploaded some nature photos with cc zero, much smaller number then those with {{self|cc-by-sa-4.0}}); I would like that all of us on Commons (Facebook, Instagram, YouTube, Twitter, Flickr etc. users too) and others who make photographs, publish everything in public domain or cc zero after agreement to do that at same time all of us. --Obsuser (talk) 17:01, 13 July 2020 (UTC)[reply]
Oppose Per Scann, Mike Peel and others. The PDM is merely a remark that a work was somehow identified as being in the public domain. Neither is it irrevocable nor is it legally binding. Hence it is not a licensing option for Commons. And as has been pointed out before, there are legislations where you cannot simply waive your copyright or related rights and decide that your work is suddenly PD. This is why we have the disclaimer in {{PD-self}} and similar templates: "I grant anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law." So, as long as the PDM does not include any active statements by the copyright holder, we can't use it for allegedly own works by Flickr users. De728631 (talk) 22:19, 17 July 2020 (UTC)[reply]
PDM has the language "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission," so I don't see how that is any worse than {{PD-self}}. Now PDM doesn't have an explicit statement about irrevocability, but neither does PD-self, and we've used it for years without any major complaints. -- King of ♥ ♦ ♣ ♠15:49, 20 July 2020 (UTC)[reply]
@Jeff G.: That has always been a problem. But we allowed {{PD-self}}, {{PD-author}} and {{PD-release}} etc. despite those problems. The suggestion is that we treat PD Mark the same way. The PD-licenses that says its PD and if that's not possible you can use it for any purpose. The "license" says its PD and the fallback is the "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission." --MGA73 (talk) 17:13, 15 August 2020 (UTC)[reply]
Support When the file is clearly the uploader's own work, it seems fair to assume that they are intending to release it into the public domain and mistakenly choose PD-mark because it says "public domain". ~HueSatLum22:59, 21 July 2020 (UTC)[reply]
Oppose PD-mark is not a legal instrument. It does not have any terms, release any rights, grant any permission, or include a fallback license where a complete grant to the public domain is not possible. It does not include any information about why the work entered the public domain either. Are we being particular about wording here? Yes. That's how the law works: words have meaning. PDM has about the same legal weight as a road sign that says "Welcome to Agloe, NY". --AntiCompositeNumber (talk) 21:24, 4 August 2020 (UTC)[reply]
@AntiCompositeNumber: PDM contains the wording "You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission." As long as we have determined with sufficient confidence that the account holder is the copyright owner, when they place that statement on their own work, how is it not a release? We have long accepted such statements under {{Copyrighted free use}}. -- King of ♥ ♦ ♣ ♠18:24, 5 August 2020 (UTC)[reply]
@AntiCompositeNumber: CC pages don't say that because they did not intend this tag to be used on your own works -- if you don't own copyright, you can't change the rights no matter what you say. But if you do own copyright, the words become very important in my opinion -- so yes, I think this absolutely qualifies as a release of rights when you use it on your own works. The words don't become legally inoperative because of a CC FAQ; the author put a statement of rights on their own work which says there are no copyright restrictions, and even gives a list of uses which do not require any permission (consistent with that). I don't think the magic word "allows" or "release" really changes that. Carl Lindberg (talk) 02:03, 6 August 2020 (UTC)[reply]
We have never required an affirmative release in the sense of "I hereby license..." If someone puts "You may use all the content of this website for any purpose whatsoever" on their own website, we accept that under {{Copyrighted free use}} even though it doesn't explicitly mention releasing the rights. -- King of ♥ ♦ ♣ ♠02:55, 6 August 2020 (UTC)[reply]
New language for Commons:Flickr files#Public Domain Mark
The Public Domain Mark or PDM is a tool made by Creative Commons to mark works that are already known to be part of the public domain, but doesn't specify why they are. Sadly, quite a few photographers mistakenly mark their own photos with the PDM, and their intentions aren't always clear. Do they mean the photo is public, as opposed to private? Do they mean anyone can use it as long as they're not making money off of it or don't change it? (noncommercial/no derivatives) Or did they mean CC0? After multiple discussions[1], the consensus on Commons is to not accept PDM as a license. PDM is however frequently used on Flickr for actual public domain works:
The Public Domain Mark (PDM) is a tool made by Creative Commons to mark works that are already known to be part of the public domain, but it does not specify why those works are in the public domain. Some photographers mark their own photographs with the PDM, believing that they are releasing their work into the public domain. After multiple discussions,[1] the consensus on Commons is that Public Domain Mark is not a license, but that it is reasonable to conclude that when an author applies PDM to their own work, they are indicating intent to release their work into the public domain.
It's good, but for "PDM is frequently used on Flickr for actual public domain works" I'd use "PDM is frequently used on Flickr for works which are ineligible for copyright or where the copyright has expired" --ghouston (talk) 03:54, 1 July 2020 (UTC)[reply]
I would change "Many photographers mark their own photographs with the PDM" to "Occasionally some photographers mark their own photographs with the PDM", to emphasis that the practice is not to be encouraged for Commoners. -- King of ♥ ♦ ♣ ♠04:05, 1 July 2020 (UTC)[reply]
Maybe change "(...) works that are already known to be part of the public domain, (...)" to "(...) works that are known to be part of the public domain, (...)" – I don't see the value of "already" there, it's unnecessarily confusing, better keep it as simple as possible. Eissink (talk) 11:43, 10 July 2020 (UTC).[reply]
I agree this is a confusing situation, but it's worth noting that the language exposed by Flickr now is different to what it used to be: the two options presented to users are "Public Domain Work" and "Public Domain Dedication (CC0)". The former is the PDM, but the new phrasing makes it clearer I think that users select it and know that it means that the work is already PD. — Sam Wilson ( Talk • Contribs ) … 00:10, 11 July 2020 (UTC)[reply]
While the Public Domain Mark is not intended to be used as a license, community consensus has found that when a copyright holder applies the PDM to their own work, they are declaring their work to be in the public domain.
If a file is tagged PDM by someone other than the copyright holder, a more specific copyright tag such as one found at Commons:Copyright tags/General public domain must be applied. If this is your own work, please use {{Cc-zero}} instead.
PDM-ownerCreative Commons Public Domain Mark Ownerfalsefalse
Maybe change "(...), they are indicating intent to release their work into the public domain." to "(...), they are indicating the release of their work into the public domain." – I think the discussion learns that community consensus found that they have released their work, not that they have the intent to release the work (at some point). NB I'm not a native speaker of English, so I might overlook a meaningfull (legal?) interpretation of "indicating intent", but in common language "intent" seems to precede "fact" and I think we are looking for facts here. Eissink (talk) 12:01, 10 July 2020 (UTC).[reply]
I have changed it to "they are declaring their work to be in the public domain", which is very much in line with the actual UI presented to Flickr users: they can select "Public Domain Work" to apply the PDM to a photo. -- King of ♥ ♦ ♣ ♠00:33, 11 July 2020 (UTC)[reply]
I might move the last sentence to be another paragraph, and maybe smaller type, since it's not directly related to the status of the work in question, but more of a note of what is not valid for this tag to be used on. I might also mention that if it's possible, try to get authors to change to CC-Zero. Carl Lindberg (talk) 23:44, 10 July 2020 (UTC)[reply]
Looks good, definitely support the proposal, but I request a couple of modifications:
Make "community consensus" where the link is placed, please.
Use this for the small text: "If this tag is used by someone other than the copyright holder, a more specific tag, such as one found at Commons:Copyright tags/General public domain, must be applied. If this is your own work, please use {{Cc-zero}} instead." I also want to add bits of why CC0 is better than the PDM and asking owners to relicense under CC0, as with the documentation page, but I don't know how we should go about them.
"This tag" is incorrect, because it is referring to {{PDMark-owner}} instead of the PDM itself. The main use of the template would be for images imported from Flickr, where people don't apply "this tag" to their images. I've added the bit about {{Cc-zero}} per your suggestion.
I think that we all agree that PDM is not meant to be used as a license on Flickr but still Flickr user put it on. I also think that everyone agree that it would be better if users added an actual license.
The question is if we are willing to accept it or not. Some think it is like {{PD-self}} that we accept even if it is not a formal license. Other think we take a risk we should not take.
I see no clear arguments that we would break any laws if we accept PDM as a license. So I think it is more a matter on how safe we prefer to be.
It seems to me that only 1 user is likely to change opinion depending on the wording of the template. So I think we should close this and make the template now and then the (re)wording of the template can be adjusted on the talk page of the template. --MGA73 (talk) 13:20, 15 August 2020 (UTC)[reply]
@Jeff G.: I see no reason to ask them. If you know of any legal issues you are of course welcome to raise them above so we can evaluate/discuss them. --MGA73 (talk) 14:58, 15 August 2020 (UTC)[reply]
No, it doesn't, discussion here learns that PDM concerns "files which to the best of our knowledge are free or freely-licensed". If there might be "significant doubt about the freedom of a particular file" with PDM, such file can and should of course be deleted, but that's no different to files with false licenses. Eissink (talk) 22:05, 15 August 2020 (UTC).[reply]
I doubt that there's any legal risk for Commons itself. At worst, it receives a DMCA take-down request and WMF Legal can decide whether to honour it depending on the details of the case. For anybody who reuses the file elsewhere, they can read the template and make their own decision. They can already obtain the file from the original source with the same status, and Commons would just be restating what was said there. Direct legal actions against others not protected by the DMCA, such as reusers and the uploader to Commons, should be very uncommon if we can assume that the vast majority of PDM files have been released in good faith. For any remaining cases, I doubt that the complainant would have a very sympathetic case in court given that they stated that the file could be treated as public domain. --ghouston (talk) 00:35, 16 August 2020 (UTC)[reply]
It seems like the support outweighs the opposition, in any case, and that the discussion has more or less ended. Is there any reason not to close the proposal as successful? --ghouston (talk) 00:33, 17 August 2020 (UTC)[reply]
It's a supermajority !vote. To argue that this is not evidence supporting a consensus in line with all Commons' norms, is more than a little bizarre. --Fæ (talk) 16:31, 20 August 2020 (UTC)[reply]
The bar for accepting proposals is generally higher than a simple majority, but lower than the requirement for promoting an admin (75%). Since this exceeds even that, I don't see how you could possibly argue that there is no consensus. -- King of ♥ ♦ ♣ ♠16:34, 20 August 2020 (UTC)[reply]
The result is over 80% in favor of the proposal after an eight week vote, yet you think you can veto the outcome because you don't see consensus? Indeed very bizarre. Eissink (talk) 16:45, 20 August 2020 (UTC).[reply]
By this point, I think any further bickering on this proposal is going to delay the *likely* implementation of this proposal. The concensus is in favor on this proposal after it was up for several weeks - generally, by that point the discussion is dying down - at least this is what happened on a RFC in Meta that I was involved on. Because of this reason, i honestly think that this proposal should be closed and implemented, ASAP. SMB99thxOh-kay!!05:47, 25 August 2020 (UTC)[reply]
I agree, and I'd just close it myself, but then maybe somebody would complain that it wasn't closed by an administrator, so isn't valid. --ghouston (talk) 01:19, 26 August 2020 (UTC)[reply]
It is not the job of Commons to project or protect intellectual property claims of file uploaders
It is confusing to have works on a free media site with titles that may appear to contradict the terms of our licenses
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
Trademarks and copyrights lapse or expire eventually, so the use of the mark eventually becomes inaccurate for all of them
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. BD2412T16:13, 26 June 2020 (UTC)[reply]
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. BD2412T22:12, 26 June 2020 (UTC)[reply]
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)[reply]
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. BD2412T22:45, 26 June 2020 (UTC)[reply]
Not sure that would be a great policy, but not strongly opposed.
It's not the job of Commons, but it might be the job of the uploader.
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.
The uploader might know. Removing them may seem to indicate we don't think they are accurate.
Trademarks don't necessarily expire. They can be renewed indefinitely (but must be renewed fairly frequently). Removing copyright symbols for PD works, sure.
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)[reply]
Support Changing existing files except if and only if that information is moved to the file description page and 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)[reply]
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. BD2412T14:39, 27 June 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose I never use the suggestions I only sometimes accidentally click on one. Do not increase the size if there is no option to turn it off. --GPSLeo (talk) 10:09, 2 July 2020 (UTC)[reply]
Support Often this feature doesn't work as intended for me, but when it does it is very useful. ℺ Gone Postal (〠✉ • ✍⏿) 08:46, 9 July 2020 (UTC)[reply]
Support changing the default to at least 10, preferably more like 30–50, and increasing the user-configurable range (as described at Help:Gadget-HotCat#User configuration and by Speravir in the above-permalinked discussions) from the current 5–30 (which I have just experimentally confirmed) to 0–50 or greater, which I hope will satisfy MPF (who asked for 50) as well as GPSLeo and Donald Trung (who appear to want 0). ← PointyOintment ❬t & c❭19:20, 17 July 2020 (UTC)[reply]
Support default 10, and user-configurable range 1-50 (presumably '0' would disable Hot Cat altogether?!). Also make user configurability options conspicuous and easy to set (i.e., a tickable menu, not to have to add a line of strange code to a weirdo page with worries of what else that might unwittingly do) - I've been using Hot Cat for best part of a decade, yet only found out about the user options a month ago, and they weren't easy to set. - MPF (talk) 20:02, 17 July 2020 (UTC)[reply]
@MPF: presumably '0' would disable Hot Cat altogether?! I had intended 0 to mean that suggestions were disabled, but you could still use HotCat by typing in a full category name. (Maybe, if there is only one possible suggestion for what you've typed in, it would still suggest it in the entry box, as it does currently.) I agree about having a GUI for settings (like the one Cat-a-lot has, perhaps), but I think that should just be a feature request. ← PointyOintment ❬t & c❭23:07, 25 August 2020 (UTC)[reply]
This section is resolved and can be archived. If you disagree, replace this template with your comment. 1989 (talk) 20:54, 25 August 2020 (UTC)
Create namespace alias TEM: for Template: on Commons
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 that 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)[reply]
@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)[reply]
And that's what I said :) I still supportT:. Please note that uppercase and lowercase are the same thing at the beginning of a string. 4nn1l2 (talk) 16:58, 23 July 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 - talk16:46, 20 August 2020 (UTC)[reply]
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 a enormous help to have such a "shortcut". --Jürgen Krause (talk) 17:04, 20 August 2020 (UTC)[reply]
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? SMB99thxOh-kay!!05:59, 25 August 2020 (UTC)[reply]
Add support for uploading AVIF
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)[reply]
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)[reply]
@Koavf: not really needed to propose it here. It will just give a bunch of 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)[reply]
Moral Support, practical 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)[reply]
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.
Only add the template to the categories when they are not instances of Wikimedia category, since it adds no exta information for the user. Every category on Commons is an instance of Wikimedia category. The water is wet. True statements are true. Blue objects are blue. It's a tautology, and only creates extra fud in recent changes.
Automatically add the template to all categories, since they all are Wikimedia categories, and thus apparently deserve an instance on Wikidata.
This proposal should not touch those categories, which are useful on Wikidata. For example if "Economy of Bryanskaya oblast" were a subclass of "Social interaction in Bryanskaya oblast", it would be a good and useful thing to place it here. ℺ Gone Postal (〠✉ • ✍⏿) 03:40, 20 July 2020 (UTC)[reply]
@Ghouston: I think that you didn't read my proposal carefully, Category:London is a great example of a good Wikidata Infobox entry, it is about the subject of the category. On the other hand most of infoboxes that I see being added today are for the Wikidata entries not about the subject of the category, but about the category itself. Think about it, when somebody enters a category Economy of Bryanskaya oblast, are they interested in the economy of a specific oblast in Russia, or are they interested in how Commons manages the specific category page. I am proposing to stop adding (or alternatively add everywhere automatically) those "Instance of Wikimedia category" Wikidata blocks, which add nothing. ℺ Gone Postal (〠✉ • ✍⏿) 05:41, 20 July 2020 (UTC)[reply]
Regarding your second proposal, that goes against the explicit statement in d:Wikidata:Notability that Category items with a sitelink only to Wikimedia Commons are not permitted (with some exceptions). --bjh21 (talk) 10:46, 20 July 2020 (UTC)[reply]
This is a complex issue (and maybe it would have been better to raise it at Template talk:Wikidata Infobox - or at least ping me about it). On the two options:
I think the infoboxes on 'category' items are useful to have for several reasons. First, they are multilingual - they show translated category names and descriptions of the categories (and embed hidden information in the category that makes those categories show up in search for multilingual phrases). Second, they have (or should have) category combines topics (P971) values, which summarise what the category is about - again multilingually. Third, the infobox now tries to use those values to show more context about the category, which is hopefully useful.
I would like to see the infobox used on all categories. We're about half way there (~6-7 million categories, ~3 million infoboxes), and there is still a lot of work to create new items and sync up existing articles/items with categories. There have been various discussions on Wikidata about notability and commons, see d:Wikidata talk:Notability and its archives, and discussions like d:Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion). They haven't (yet?) had consensus to do this, though. In particular there is opposition to the combination categories that are quite Commons-specific. However, there are still a *lot* of categories that are about specific notable things that should be on Wikidata - so there's still plenty of work to do before that becomes a limiting factor.
Note that Pi bot is mostly just adding the infoboxes to categories with new sitelinks now, BTW. I'd rather that we didn't start removing existing uses, and instead focus on building more content. Thanks. Mike Peel (talk) 17:51, 20 July 2020 (UTC)[reply]
---
I withdraw my nomination I think everything has been explained quite well, and since wikidata entries that are "instance of" only will be expanded eventually and are not stuck as such, they should remain and continue being added. ℺ Gone Postal (〠✉ • ✍⏿) 12:30, 10 August 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 1989 (talk) 20:53, 25 August 2020 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 1989 (talk) 20:54, 25 August 2020 (UTC)
RfC: Deprecate XCF file format
An editor has requested comment from other editors for this discussion.
If you have an opinion regarding this issue, feel free to comment below.
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)[reply]
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)
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)[reply]
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)[reply]
Comments (XCF)
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Disallow copyvio speedy tagging for old images
Recently, I came across File:M Yacoub.JPG, which was tagged for speedy deletion because the image can also be found at [2]. 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)[reply]
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)[reply]
Support in theory, 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)[reply]
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)[reply]
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)[reply]
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. Эlcobbolatalk16:36, 18 August 2020 (UTC)[reply]
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)[reply]
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. Эlcobbolatalk17:31, 18 August 2020 (UTC)[reply]
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)[reply]
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. Эlcobbolatalk17:51, 18 August 2020 (UTC)[reply]
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)[reply]
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. Эlcobbolatalk18:10, 18 August 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
"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? Эlcobbolatalk18:19, 18 August 2020 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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? --Krd06:31, 19 August 2020 (UTC)[reply]
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)[reply]
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)[reply]
"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)[reply]
+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)[reply]
This section is resolved and can be archived. If you disagree, replace this template with your comment. --ghouston (talk) 22:59, 26 August 2020 (UTC)
Support as the proposer. -- CptViraj (talk) 06:02, 30 May 2020 (UTC)
Strong support Revoking sysop permissions by bureaucrat here and not by a steward is faster (and I'm 
agreed about it), but how about with revoking bureaucrat permissions by bureaucrat? Nieuwsgierige Gebruiker Overleg • CA 06:46, 30 May 2020 (UTC)
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)
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)
Question@Schlurcher: Really? Then what can you comment about Russavia, who have also been a bureaucrat?廣九直通車 (talk) 08:25, 31 May 2020 (UTC)
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)
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)
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)
Info There is currently a new search system in development using a grid view Special:MediaSearch. --GPSLeo (talk) 14:49, 5 June 2020 (UTC)
Done -- King of ♥ ♦ ♣ ♠ 00:33, 11 July 2020 (UTC)
.jpg){kind=link}
I withdraw my nomination I think everything has been explained quite well, and since wikidata entries that are "instance of" only will be expanded eventually and are not stuck as such, they should remain and continue being added. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 12:30, 10 August 2020 (UTC)
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)
