Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from Village Pump)
Jump to: navigation, search

Shortcut: COM:VP

Community portal
Help desk Village pump
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{section resolved|1=--~~~~}} may be archived; for old discussions, see the archives.

Please note

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page

Search archives


It can only be speculated that, like the modern office water cooler, the village pump must have been a gathering place where dwellers discussed ideas for the improvement of their locale. [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch

January 29[edit]

WMF response to proposal to uninstall Flow[edit]

Hi everyone, I'm posting the WMF's response to the Proposal to uninstall Flow RfC from January. I'm sorry that it took us so long to respond; it was a busy month for us. Sorry that we left you hanging for so long.

The RfC is asking for Flow to be removed from Commons. There are currently two Flow pages on Commons -- Commons talk:Flow and Commons talk:Flow/tests -- and they're essentially inactive. There are some conversations on those pages which will be lost, but (in my opinion) they're not that important, and if folks on this wiki want them gone, that's okay with us.

What we propose to do: Delete all of the Flow pages and conversations on Commons, and then make it impossible for anyone to create any more Flow pages or conversations. The Collaboration team is finishing up this ticket -- phab:T188577 -- which is essentially a "kill switch" for Flow on this wiki. Once the kill switch is finished and turned on for Commons, nobody will be able to create a Flow page or post, regardless of user rights or global user membership. Flow pages will be deleted from Commons and deactivated.

There was some discussion in the RfC about whether it's better on the back end to completely uninstall the extension, and a desire to confer with the tech staff on the impact of that. We talked with the Collaboration team about it. They say that uninstalling Flow would make things less stable than leaving it "installed" but completely disabled, as described above. There are log entries for the existing Flow posts in people's contributions, and other logs. With the pages deleted and disabled with the kill switch, those entries will be red links, and if you click on one of those links, you'll get a message saying that it's been deleted. If the extension was completely uninstalled, then there's no software that recognizes what those links are, so clicking on them would cause a fatal exception error, and attempting to undelete them could cause a serious error. It's more stable to delete and use the kill switch.

So that's what we think is the best way to remove Flow from Commons. We expect that the "kill switch" will be deployed next week, or the week after, and we'll be able to take care of it then.

As I said above, this will delete some existing content, but we agree with the community assessment that it's not particularly important content. For the wikis where people have been actively using Flow on talk and user talk pages, we wouldn't want to handle things in this way, but for these two pages, it's okay with us. What do you all think? -- DannyH (WMF) (talk) 02:28, 3 March 2018 (UTC)

@DannyH (WMF): Symbol oppose vote.svg Oppose 'leaving it "installed" but completely disabled'. Which part of "uninstall" do you not understand? Perhaps those two pages or their individual topics and responses could be deleted normally, or a shim could be developed that could handle those pesky red links. If those pages and their individual topics and responses could not be deleted normally, that is another reason Flow shouldn't have been here in the first place. Perfect reversibility of end-user actions is necessary on all Mediawiki wikis, or the vandals will win. I have nominated them, Commons:Structured Discussions, and redirect Commons:Flow to the latter for deletion.   — Jeff G. ツ please ping or talk to me 14:48, 3 March 2018 (UTC)

Ping to supporters of the RFC: Jeff_G., MarcoAurelio, , Krd, Steinsplitter, Storkk, Tuválkin, Rschen7754, Gestumblindi, Train2104, Nemo_bis, Wikimandia, Davey2010, Jc86035, Nyttend, Begoon, DarwIn, no ping to IP contributor 2001:2003:54FA:2751:0:0:0:1, and no ping to me. Also ping DannyH (WMF). Alsee (talk) 04:21, 3 March 2018 (UTC)

  • OPPOSE. No. Consensus was Uninstall Flow, as was done on English Wikipedia and Meta wiki.[1]. Alsee (talk) 04:11, 3 March 2018 (UTC)
    Note: A volunteer developer has already done the work of writing and submitting the patch uninstall Flow. (See Phabricator task T186463.) The WMF is actively blocking deployment of the work that has already been done. Alsee (talk) 04:28, 3 March 2018 (UTC)
    I am having trouble seeing the patch on the page you linked. Please show me where it is. --Gryllida (talk) 05:07, 3 March 2018 (UTC)
    Gryllida the patch itself is here at Gerrit. Alsee (talk) 05:29, 3 March 2018 (UTC)
  • Created - create a Flow uninstall script --Gryllida (talk) 05:05, 3 March 2018 (UTC)
  • Note: The WMF has opened a Phab task to build a superprotect level for Flow. Alsee (talk) 06:12, 3 March 2018 (UTC)
    • Alsee: Stop spreading fake news. That won't fly anywhere. Yann (talk) 06:54, 3 March 2018 (UTC)
    • Alsee: That ticket is the "kill switch" that will make it impossible for anyone to create new Flow pages or posts. See my longer reply a little further down for more details. -- DannyH (WMF) (talk) 20:45, 3 March 2018 (UTC)
  • Pictogram voting comment.svg Comment I oppose removing Flow from Commons. This RFC was a tentative to play politics and dividing the community because of past grievances against the WMF. The WMF should simply close the request as irrelevant. Regards, Yann (talk) 06:35, 3 March 2018 (UTC)
    Yann there are reasonable arguments on both sides of the issue, and I respect your position is to keep Flow. You well expressed your position in the RFC. I merely ask you to consider what advice you would give to anyone else who disliked any other consensus result, after participating in an RFC. Alsee (talk) 07:24, 3 March 2018 (UTC)
  • If this needs to be done on Commons, this should also be done on enwiki and other wikis where ‘flow’ is gone. Why Commons is treated differently from other wikis? (enwiki is even bigger than Commons in size, so...) — regards, Revi 06:39, 3 March 2018 (UTC)
  • Danny's response is technically incorrect and will not stand. That said, the users have never asked for Flow's leftovers to be kept pretty. Wikimedia Commons is perfectly fine with losing a dozen topics and related logs. --Nemo 06:51, 3 March 2018 (UTC)
  • I fail to see any reason not to remove this weak forum impersonation completely, it's just useless clutter that should be removed. The "technical reasons" are just straw-men by the collaboration team, that doesn't want to loose one of it's favourite pets completely on one more big project, there is no valid technical reason not to uninstall this unwanted intrusion. Sänger (talk) 08:57, 3 March 2018 (UTC)
  • DannyH (WMF) With all due respect, the WMF response is against community consensus as enacted in the RfC so I reject your proposal and ask Collab to implement the results of the RfC as closed; which is the same as was done on enwiki and metawiki; both of them happily working without Flow and nothing broken. It bugs me that each and every time a community has asked for this problematic software to be removed from one site, the WMF Collab team has always been putting spooks in the wheels and raising a different argument each time not to do this. Sorry, but I'm not buying that. If Flow is so problematic that once enabled cannot be removed without causing havoc it shouldn't have been installed at all, less thrown upon wikis without asking for community consensus in the first time. Flow is not a core wiki function, it is not CentralAuth, SpamBlacklist or other critical MediaWiki extensions. Flow can be removed and should be removed as requested by this community. —MarcoAurelio 11:38, 3 March 2018 (UTC)
  • The WMF Dev's objective of "break everything" (yes, this was stated in writing) seems broken as well as being a fundamental misreading of Agile best practice. This was installed as a trial, now that trial has finished, it gets uninstalled. As was said above, no competent programmer installs software that cannot be uninstalled; that's something unethical hackers do. -- (talk) 11:45, 3 March 2018 (UTC)

DannyH (WMF) I'd like to draw attention to a communication problem:

  • Feb 5th the WMF effectively halted the uninstall patch at Gerrit with a -2 code review. The text was "Under discussion by the team. Do not merge at this time."
  • For weeks the WMF refused explain what was being discussed, despite multiple requests from multiple people.[2] It's clear that there was an active decision to keep the discussions secret.
  • After excluding the community from discussions for weeks, the WMF spent the last five days (Feb 28 - Mar 2) deliberately building code in secret. (The superprotection for Flow.)

Do I even need to say that we shouldn't be working like this? The WMF actively locks us out of the conversation for weeks, builds code in secret, disregards consensus, and you thought this was going to get a positive reception? If this were a good-faith proposal you would have talked to us before building the code. Whoever wrote the code, or whoever ordered it to be written, clearly expected that it was going to be deployed in disregard of consensus. Alsee (talk) 12:22, 3 March 2018 (UTC)

hey, it's all good - send your ultimatum to WMF again. maybe you could send a check as well, since you seem to want to micro-manage code development. "we shouldn't be working like this?" who is working? why do you imagine that direction by temper tantrum will work? why don't you change you method of giving feedback to WMF, and expectations? Slowking4 § Sander.v.Ginkel's revenge 15:08, 3 March 2018 (UTC)
Alsee, re: the communication problem. I do apologize for taking so long to respond, it was rude on my part. The explanation (not a good excuse) is that there was a change in leadership in the Product team in late January, and then we jumped into annual planning and budgets, which took my eye off this response. But, yeah, that was rude of me, and not your problem. Sorry again.
However -- that ticket is not "superprotect for Flow". That is the ticket -- phab:T188577 --which I referred to in my response above as the "kill switch", which will completely disable Flow on this wiki. Our proposal is to delete the existing Flow pages, and then use that "kill switch" config change to make sure that nobody can create a new Flow page or post. We're not stopping you from deleting Flow pages, we're stopping anyone from re-creating the pages after they're deleted.
The reason why Roan started working on that ticket before I posted the response is that we decided how we wanted to respond on Monday, and then I went on vacation for a few days. I didn't want to post here on Monday, and then not be around to read everybody's replies for three days. So I posted on your Phabricator ticket that we'd have an answer by the end of the week, and when I got back to work yesterday, I posted my answer. Meanwhile, Roan got started on that ticket, because not starting on it would just create more unnecessary delays later, after we'd all talked about it here. Yes, that means we assumed that we'll need it, because we think it's a practical solution to the problem here.
Now, I know all this personal behind-the-scenes stuff doesn't matter to you -- the important thing is that it took me a month to get back to you in the first place, which I know was frustrating for everyone here. I'm only bringing up the backstory of this week to say that there wasn't a secret plot to keep you in the dark, just the normal ups and downs of daily life. -- DannyH (WMF) (talk) 20:45, 3 March 2018 (UTC)
DannyH (WMF) I'm not sure if you thought my "communication problem" was directed at you, or if you're trying to take the heat for others. However the communication issue was primarily before you showed up, and I definitely didn't consider you to be rude. The task was halted because of "discussions", however the discussions were nonpublic and there was a systematic refusal to even say what the issue was. It was frustrating that you also wouldn't say what the issue was, but at least you made it clear that there would be an answer in a concrete and reasonable time frame. That was a big improvement. If anyone had simply said the issue was logs we could have avoided drama. We could have avoided jumping to build an undiscussed superprotect_for_flow/kill_switch. We could have started sooner on looking at solving the log issue. Alsee (talk) 23:12, 3 March 2018 (UTC)
Alsee: No, I'm just taking responsibility for the stuff that I was responsible for. :) I recently (mid-January) became the Director of Product Management for the Contributors team, so I'm responsible for the Collaboration team, which is part of Contributors. I think the opaque "team discussions" reason that you're referring to was early February, so under my watch. Those discussions took a long time because the team was waiting for me to actually focus on this problem and figure out a response, and I just had too many things to learn about and catch up on to properly focus on this specific issue. That's not a good excuse at all -- you're correctly saying that I didn't take responding to this RfC seriously enough to put other stuff aside and deal with this earlier. I'm just saying that's what happened. So I'm taking responsibility for that, sorry again, and that's why I'm here talking about it. -- DannyH (WMF) (talk) 02:40, 6 March 2018 (UTC)
  • While it’s a very good thing that Flow will be gone and its ground will be salted, it is also true that «losing history is bad», as said in phab:T188577. -- Tuválkin 15:25, 3 March 2018 (UTC)
  • Tempest in a teapot. If it's effectively gone and unavailable, the technical means for that does not concern me. - Jmabel ! talk 17:09, 3 March 2018 (UTC)
  • I don't see what causes the big fuzz. Danny & team think along, come up with an alternative and more efficient solution to achieve the same end as what you request (or rather, demand). With this kind of attitude, you make it harder for the WMF to grant your requests in the long run. Please show some flexibility, and focus on the big picture :) Effeietsanders (talk) 18:18, 3 March 2018 (UTC)
    @Effeietsanders: It's not the same end for this wiki that enwiki and meta got.   — Jeff G. ツ please ping or talk to me 19:12, 3 March 2018 (UTC)

Hi everyone, general response to all the comments: Folks are asking why the plan for Commons is different from enwiki and Meta. I'll talk to the team some more, and I'll let you know what I find out. -- DannyH (WMF) (talk) 20:57, 3 March 2018 (UTC)

DannyH (WMF) a volunteer was working on the original uninstall task, and now it appears that Nemo bis is willing to work on the log issue in T188806. The question now is whether the WMF is going to actively prevent the log issue from being addressed? (And subsequent uninstall.)
If the WMF were willing to discuss the issue in public, it might have avoided the perception that logs were just an excuse. Alsee (talk) 22:16, 3 March 2018 (UTC)
  • OPPOSE - Sorry I'm late to the party haven't been on Commons all that much, In short I expect the exact same treatment as what EN and Meta got (IE remove the whole fucking thing), None of this "It will be installed but disabled" bullshit ..... We as a community don't want it so you WMF should honour the consensus here and remove it WHOLE from this site. –Davey2010Talk 21:15, 3 March 2018 (UTC)
  • Meh - +1 to Jmabel basically. What we're seeing here is people objecting at the fact of WMF noncompliance with the community, and not to the substance of the matter. I.e. I'm not seeing any compelling technical reason that Flow, completely disabled/deleted but not uninstalled, will have any negative impact on Commons or its users apart from exacerbated pre-existing WMF-related resentment. If someone can provide a concrete reason why uninstalling provides a benefit that you can articulate apart from "because we said so" or abstract appeals to best practices, that would be another thing. But otherwise: meh. — Rhododendrites talk |  01:48, 4 March 2018 (UTC)
  • Symbol keep vote.svg Keep "As I said above, this will delete some existing content, but we agree with the community assessment that it's not particularly important content. " deleting content is always bad, why not just disable flow and add {{historic}} to the pages? What is the WMF's obsession with making sure that future generations forget about what happened in the past on Wikimedia projects? To document and not to serve, and to archive and not to destroy. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:17, 5 March 2018 (UTC)
  • Don't care about the issue, do care about Alsee using polemic language to stir the pot. —TheDJ (talkcontribs) 10:17, 5 March 2018 (UTC)
  • I must say the I find the helpful and collaborative attitude off DannyH very refreshing. Therefor it’s regretful that the first response in this conversation is a direct attack at him. This said, I also find it regretful that there is chosen for a course of action that contradicts the communities wishes. Whilst I can’t say much about the technical aspect I do believe that this is a poor choice. When you have a continues relationship trust is one of the most important factors to keep this relationship healthy. It’s no secret that the relationship between Commons and the WMF is still fragile and doing something that harms this relationship is a pretty bad move in my opinion. (The same applies to the persons making harsh and flaming comments.) Hopefully the WMF will reconsider. The social aspect is in the end much more important than the technical aspect. Natuur12 (talk) 13:18, 5 March 2018 (UTC)
    • +1 to all that. Storkk (talk) 15:38, 6 March 2018 (UTC)

Okay, I talked to Roan from the Collaboration team, to get more info on the question: why can't you just do what you did on Meta and Enwiki? The answer is that doing the uninstall on Meta and Enwiki showed the team what a bad idea it is. On Meta, there was only one active Flow page -- a Research talk page that had conversations the Research team wanted to keep -- so the team ported that page and history to, and then uninstalled from Meta with no history links to worry about. On English, there were lots of Flow pages, and uninstalling created a lot of errors that we had to fix -- broken history, lost history and fatal exception errors. The team made it work okay, but in a "duct tape and bubble gum" way -- a lot of hacks built on hacks, to keep it from causing errors that would negatively impact site stability. That's why the team doesn't want to do that again.

From the end-user point of view, the two options -- "uninstall Flow" vs "delete and disable Flow" -- are essentially the same thing. All Flow content will be gone from Commons. It won't be possible for anyone to create any more Flow content. The Commons community has made it clear that Flow isn't welcome on this wiki, and Flow is not going to be on this wiki.

But the history of Flow development at the Foundation includes quite a few mistakes and empty promises, and as folks have said here, there's a lot of mistrust around the way that the Foundation tested and deployed the feature that goes back to 2013. The people who are saying that Flow must be uninstalled want to draw a line in the sand. I understand that point of view. It doesn't make me want to do something that could risk site stability, so we're still planning on doing the "delete and disable" version, but I understand the frustration and mistrust, and we can keep talking about it if you want to. -- DannyH (WMF) (talk) 02:24, 6 March 2018 (UTC)

DannyH (WMF) perhaps this is the first time you are you having this discussion, however this is the THIRD time the WMF re-arguing 'delete and disable'. We went through it on EnWiki, and the result was yes we really wanted it uninstalled. We went through it with Meta, the result was yes we really wanted it uninstalled. One of the reasons for distrust and animosity is that we keep having to have the same arguments over and over and over again. If Flow is a threat to site stability then it needs to be uninstalled. Leaving it installed and continuing development only increases the technical debt and increases the threat.
You also did not answer my question. The question is no longer whether the WMF is willing to uninstall. A volunteer was working on the original uninstall task, and now it appears that Nemo bis is willing to work on the log issue in T188806. The question now is whether the WMF is going to actively prevent the log issue from being solved? (And subsequent uninstall.)
I try really hard to assume good faith. I try to remember that the WMF is made of individuals, and they shouldn't all be automatically distrusted because of actions in the past by others at the WMF. However if there's no answer to the question, or if the answer is that the WMF is going to actively obstruct fixing the log issue & uninstall, then I can see no good faith explanation. It would pretty well establish that the log issue is a bad faith smokescreen. Is the WMF drawing a battle line in the sand, fighting a fix to the logs & uninstall? Alsee (talk) 07:27, 6 March 2018 (UTC)
Re "showed the team what a bad idea it is", I'll note that the "bad idea" was largely the team's own making. For instance, nobody had asked for the test discussions under Flow to be preserved, but the team insisted that they absolutely had to be converted to wikitext. The community has consistently asked for the simplest solution, for years. --Nemo 12:48, 6 March 2018 (UTC)
Nicely put. Do not expect to get a hero firefighter award if you started the fire - old Agile developer's motto. :-) -- (talk) 12:59, 6 March 2018 (UTC)
Alsee, I understand that you want Flow uninstalled, and that there is a community consensus that says that. However, if your interpretation of my response is that Flow is a threat to site stability, then there must be a misunderstanding, because that's not what I said. What I said was that the most stable and least risky course of action is "delete and disable", and it provides the same result as uninstalling. On technical matters, like questions about site stability and code quality, I rely on the judgment of the senior developers that I work with -- in this case, Roan. He says that uninstalling Flow on English caused problems that he doesn't want to repeat.
But I've also been talking about Nemo's patches with Roan and with Ryan Kaldari (Sr Eng Manager), including both T188806 (create a Flow uninstall script) and T188812 (uninstall Flow from wikis that don't have any Flow content). So far, Ryan says that there's no particular reason to block the second ticket, but we need to talk about it with Roan and the rest of the team some more. We're planning to get together and talk about it tomorrow, and I'll be able to report back here on Thursday. -- DannyH (WMF) (talk) 01:39, 7 March 2018 (UTC)
DannyH (WMF):
  • T188812 uninstall Flow from wikis that don't have any Flow content: That would be excellent. I hope to hear a positive result on that.
  • T188806 create a Flow uninstall script: Specifically in regards to fixing the log issue to allow uninstall, your post was unclear. I will assume you meant it will be part of the internal discussions you mentioned. When you return, please answer the question I asked.
  • T188577 Add a config setting making all Flow boards read-only: That would be worse than doing nothing. It's bad enough that the WMF yet again built undiscussed&unwanted software, please do not take the next step of trying to force out undiscussed&unwanted software. Exactly no one raised the issue of somebody creating a Flow page. In past discussions community members have told the WMF we're not worried about that. If that were the concern, and if it did happen, we would trivially resolve it with a speedy-delete tag and Admin tapping the delete button within minutes or hours. Whoever at the WMF cooked up that plotline is off in imaginary-land. The WMF spun off into imaginary-land because you insisted on non-public discussions. If the discussions were on-Wiki or on Phab, someone could killed that misunderstanding before you wasted time and money building this useless code. And trying to force out the code as a supposed answer to the community would make it worse than useless... it would be received as insulting and malicious. Alsee (talk) 05:14, 7 March 2018 (UTC)

Okay, I talked to my senior engineers (Roan and Kaldari) about the Phabricator tickets. Here's what we think:

  • T188812: Uninstall Flow on all wikis where it has zero topics. Nemo has written the code for this. This won't have any visible impact, but Nemo's already written the patch, and there's no reason to block it. We'll do code review, and assuming that goes well, we'll deploy it.
  • T188577: Add a config setting making all Flow boards read-only. This is the kill switch that will allow us to follow the "delete and disable" plan -- we'll delete all of the existing Flow pages and posts, and then keep anyone from creating any more Flow content here, even if they have advanced rights. This will accomplish the goal of the RfC, which is to take Flow off of Commons.
  • T188806: Create a Flow uninstall script. This would deal with all of the log issues, and any technical challenges that came up when we uninstalled Flow from English WP. We are not going to work on this. It would be very complicated and expensive to write and test, and it would have no visible impact. It involves modifying the database, and you need to be very careful when you do that, because an error can cause problems in a lot of places. Working on this ticket would derail the project that the Collaboration team is currently working on, which is improvements to the Maps extension. If there's a volunteer developer who wants to work on this, we have no objections to that, but the team is not going to spend time working on this ticket, when the same goal can be achieved using the ticket described above.

Now, I understand that that plan is not what many people on this page are asking us to do. To explain why we think this is the correct course of action, there are two parts of the community consensus:

  • Goal: Remove Flow from Commons so that it can't be and won't be used here.
  • Implementation: Uninstall Extension:Flow, using the script proposed in phab:T188806.

The goal established in the RfC is a completely reasonable request, and that's what we're going to do. Nobody working on Commons will need to see or interact with Flow in any way. We're happy to follow consensus on that.

However, the specific technical implementation of how the Collaboration team achieves that goal is not up for community consensus. Choosing the best technical solution for a problem is a job for the experienced developers on the team. I look to them for information and judgment on how to implement a solution; that's what they're for.

So that's what's going on for us. I'm happy to talk more with folks about what you think. -- DannyH (WMF) (talk) 19:23, 8 March 2018 (UTC)

DannyH (WMF) {{citation needed}} on your fictional goal. I trust the WMF not to create new Flow pages, and if one is inadvertently created it can be Speedy Deleted per existing consensus. Do I need to start a new proposal explicitly to block deployment of the undiscussed, unwanted, unrequested, utterly useless T188577? Alsee (talk) 12:43, 9 March 2018 (UTC)
Hi Alsee: As I said above, the backend technical implementation isn't up for community consensus, so I don't think an RfC to stop a developer from creating a new config setting is going to do much good. But I'm interested in the "citation needed" on the goal. Leaving aside the specific backend implementation, I think "Remove Flow from Commons so that it can't be and won't be used here" is the goal. If that's not the goal of this discussion, then what is the goal? -- DannyH (WMF) (talk) 21:28, 9 March 2018 (UTC)
You just want to insert a line of code or two, to make it harder to create a Flow page. Yes, there is some mumbo-jumbo about completely disabled, but that's just the surface, not the real thing. To get it back all that has to be done by those who want Flow is to change a line of code or two, not to re-install the whole extension. And especially with projects like Flow, VE and MV (and superprotect as the always looming companion) there is not that much trust left towards those, who push such stuff down the throats of unwilling communities. Getting completely rid of that unwanted and never asked for piece of software would make it at least much harder for the anti-community guys to re-enable it. It should not be here ar all, it should be a very hard task for those who want it back against the community wishes to do their anti-community work. Sänger (talk) 22:02, 9 March 2018 (UTC)
DannyH (WMF) I definitely did not say I was going to run "an RfC to stop a developer from creating a new config setting". The RFC would be whether Commons should change to the new mode. The WMF may have started work on the new mode with good intentions, and based upon misunderstanding. If an RFC result is against applying the new mode, it would no longer be an issue of good faith or misunderstanding. A bad-faith forcible deployment of the new mode here would be a pointless assault. It would be worse than doing nothing.
As for "goals", you are attempting to discuss the goals of a collective-community-voice. That consensus is the result of many people with varied concerns and rationales. An RFC provides an answer on the question being debated. Sometimes reviewing that discussion can provide an uncontested implicit consensus on surrounding questions. Sometimes post-RFC discussion provides uncontested implicit consensus on surrounding questions. Enough supporters of the RFC have explicitly rejected your interpretation to sink it as a viable interpretation that consensus. Whether to set Commons to T188577 read-only-Flow would require an RFC actually addressing that new question. If the new mode is unwanted, and the WMF is unwilling to uninstall Flow, then that leaves us with a consensus to uninstall Flow and the WMF unwilling to do anything constructive. Alsee (talk) 10:14, 10 March 2018 (UTC)

Folks: it is clear that several years ago, when Flow was added here, WMF was a mess from the top down (especially at the top) and was acting in a very imperious manner. I don't see a good reason to hold that against those who are trying to clear up the mess now. There isn't even a snowball's chance in hell that Commons will have consensus to re-enable Flow, and there is about a snowball's chance in hell that WMF will again be run by people who care that little about community consensus. I understand what people are angry about, but I don't understand why they are nursing that anger and directing it at people who are basically solving the actual functional problem. - Jmabel ! talk 22:12, 9 March 2018 (UTC)

The above echoes my thoughts; there seems to be a lot of ABF in some of the previous comments. It’s the devs who are charged with keeping the project running, so I agree with Danny that we should respect their judgment as to the most workable solution, as long as the outcome is that no user need use Flow to communicate anywhere on the site. The harder the machinery is to maintain, the less likely improvements can be made: we don’t want a situation where nobody wants to touch the program for fear of breaking something. Sure, on general principle the idea of leaving disabled code in the system may seem questionable, but if its removal will make the site’s codebase problematic to work with going forward, this practical consideration should trump the theory.—Odysseus1479 (talk) 23:00, 9 March 2018 (UTC)

I just opened Commons:Village_pump/Proposals#Flow_-_WMF's_proposal asking Is there a desire to convert Commons-Flow to the new mode? Ping for DannyH (WMF). Alsee (talk) 14:38, 11 March 2018 (UTC)

Hi everyone, we're going to deploy the Flow "kill switch" and the "uninstall Flow from wikis that aren't using it" patches early next week; these are two of the tickets discussed above. There are deletion requests for the two existing Flow pages -- Commons:Deletion requests/Commons talk:Flow and Commons:Deletion requests/Commons:Flow -- were resolved as Keep, so I'm not sure if the proposed deletion of those pages is going to happen. I've posted wikitext archives of both pages as subpages of my user page, if they're useful: User:DannyH (WMF)/Commons Flow export and User:DannyH (WMF)/Flow tests export. -- DannyH (WMF) (talk) 00:00, 17 March 2018 (UTC)
Hi everyone, the two tickets that I mentioned above are now live -- the Flow "kill switch" and "uninstall Flow from wikis that aren't using it". The kill switch is part of the plan to remove Flow from Commons; the other part is deleting the two existing Flow pages -- Commons talk:Flow and Commons talk:Flow/tests. The deletion requests were resolved as Keep, so I'm not sure what to do. Pinging Jeff G., who opened those deletion nominations, and Yann, who closed them. Do we need to renominate those, or can we just delete them and replace them with the wikitext archives? -- DannyH (WMF) (talk) 18:49, 19 March 2018 (UTC)
@DannyH (WMF): They should be terminated with extreme prejudice (kill -15).   — Jeff G. ツ please ping or talk to me 18:58, 19 March 2018 (UTC)
@Jeff G.: How would that not constitute a deletion against explicit consensus? (I happen to agree with you as to what is desirable, but don't we at least have to got through another DR?) - Jmabel ! talk 19:36, 19 March 2018 (UTC)

What are the rules concerning non-photographic medias to become QIs ?[edit]


Reading the Image guidelines, there's nothing concerning SVGs, PNGs or animated Gifs. It's all about resolution, JPG compression, noise, exposure, focus, lighting, distorsions, and so on. Although we can find several QIs in this category Commons:Quality_images/Subject/Non_photographic_media. I wondered what are the valid criteria on which we can legitimately support or oppose a QIC. For example why is this logo a QI, and this hieroglyph too ? What kind of materials have great chances of success ? Which ones less ? What should we accept / reject / discuss ? -- Basile Morin (talk) 11:09, 4 March 2018 (UTC)

One thing you might want to check for SVG files is that the code is valid. E.g., after checking with this tool or other means, {{Valid SVG}} should have been added to the file before it gets reviewed for QI. This is just my 2 cents though. De728631 (talk) 17:48, 6 March 2018 (UTC)
Thanks @De728631: But then, I don't understand why some SVGs like File:GDP_PPP_2017_Selection_EN.svg and File:GDP_PPP_2017_Selection_DE.svg (now nominated as Quality Images) are marked as valid on commons, whereas they contain errors with -- Basile Morin (talk) 01:19, 13 March 2018 (UTC)
@Basile Morin: Apparently this happened because the {{Igen}} template had been used on these files without checking the actual number of errors. I have now adjusted the two file descriptions. De728631 (talk) 01:31, 13 March 2018 (UTC)

Public domain for an author of unknown date of decease?[edit]

Good evening,

I ran accross this map of en:Cuevas del Drach, which could be a great addition to the article. The map has been drawn by a certain José Ygnacio Moragues in 1880, but I can’t find more information about him. Imagining the case where he plotted the map at the early age of 20 and died at the late age of 100, the map will be in the public domain in many juridictions in twelve years. But if he worked on it at 30 and died at 90, the map is already available since 2010. Is there a generally accepted practice in these cases where no precise information is available about the author?

Simulateously, the digital archive where the map is placed releases the file under the non-free CC by-nc-nd. So unless they acquired the rights for it from a donation or other, could it mean that it is already in the public domain and that either they license their scan of it (can they do this?), or they mislabelled the file?

~ nicolas (talk) 19:34, 4 March 2018 (UTC)

1880 is over 120 years ago, so is within the scope of {{PD-old-assumed}}. If it was published before 1923 then {{PD-1923}} can also be added. The digital archive doesn't seem to be revealing its grounds for claiming copyright over the work, but there's also {{PD-Art}} in case it's just for digitizing it. --ghouston (talk) 21:57, 4 March 2018 (UTC)
If it's from Spain, please use {{PD-old-assumed|duration=80}}, because Spain has a PMA+80 term. Jcb (talk) 22:08, 4 March 2018 (UTC)
Actually it was not drawn by Moragues himself but by a German named F. Will. There is a note printed on the map in the lower right corner: "Fecit F. Will de München (Alemanna) Mayo 1880" (F. Will from Munich, Germany, made it, May 1880). I can't find anything about this Will person, but we're still good in terms of {{PD-old-assumed}} without additional duration. De728631 (talk) 02:40, 5 March 2018 (UTC)
PD-old-assumed is not an agreed template as a RFC is still needed along with supporting policy and guidelines for usage, nor is it supported by any copyright law, specifically the 1879 Act. The file may be subject to deletion under Spanish copyright law. -- (talk) 10:29, 5 March 2018 (UTC)
Actually it is supported by copyright law; works by authors of unknown death date that were created 120 years ago and not published in 1923-2002 are PD in the US. Which, funny enough, is exactly the copyright law that is binding on the WMF. PD-old-assumed was created based on discussion on VP/C and general consensus, so feel free to use it.--Prosfilaes (talk) 23:32, 5 March 2018 (UTC)
You are implicitly claiming that Spanish copyright law does not apply or can be ignored. Why?
As for the template, please actually read how the discussion closed, a RFC and changes to policy and guidelines are required before the template is used. -- (talk) 23:35, 5 March 2018 (UTC)
Spanish law does not apply to the WMF. Commons policy requires us to use Spanish law in certain cases, and tells us we can ignore it in others--cf. PD-Art. In this case, we're asserting that 120 years is long enough for us to reasonably assume that Spanish law is satisfied.
As for the template, it's being used. There's always been lines where a file has been old enough to not be deleted; this is merely clarifying the exact line based on consensus. If you want further bureaucracy, then go ahead, but I think the rule is clearly in effect in practice.--Prosfilaes (talk) 00:05, 6 March 2018 (UTC)
No, with respect to the draft template it is used on just 200 files (out of our 43+ million) mistakenly. A RFC is required as was stated at the time of closing by a Bureaucrat. Despite Jcb's campaign about their template and their original proposal, the use of the draft template is not supported by law or policy or a credible consensus. It is wrong and misleading to use this template on files which are going to be reused by members of the public as the details of when and how it should apply have yet to be worked out.
With regard to ignoring non-US law, that is not what Commons:Licensing requires. According to that policy to be public domain this image must be "in the public domain in at least the United States and in the source country of the work." Please do not mislead this uploader by confusing policy with your personal views about copyright law, they will be disappointed when it has to go through a DR process after upload. Thanks -- (talk) 00:14, 6 March 2018 (UTC)
while i salute the thumbing nose at spanish copyright law, a consensus would be helpful, but some will not budge from 130, so not much hope of achieving that. noting the impasse, and warning about spanish law would be forthright. (especially given the german case with gutenburg [3]). Slowking4 § Sander.v.Ginkel's revenge 01:52, 6 March 2018 (UTC)
Since Commons begin, we've been uploading files without secure death dates; the theory that the Greek gods authored part of the Homeric Hymns seems not to have stopped anyone from uploading them. At some point in the 19th century, it stops being okay to just assume the creators have been dead long enough. The general consensus is 120 years ago; if you don't want to use the template, feel free to take a guess and use the appropriate PD-Old template. Fæ is not DRing those 200 files, and they probably won't DR your file, because likely as not, all it will do is establish that the consensus went against them.--Prosfilaes (talk) 03:33, 6 March 2018 (UTC)
*Cough*, your evidence of being "right" is that I am not DR-ing 200 old files? That's because I'm not a dick, rather than because there is a credible consensus or policy or copyright law that supports hosting these files on Commons. Plus, of course, on reasonable investigation many of these can be kept because proper license releases can be used, such as those that were published without any named artist or photographer.
The previous discussion was closed with the action that policies had to be written explaining detail, and a RFC should be run once the detailed guidelines were ready. If you want to start enforcing the 120 years "rule", get your finger out and write some usable guidelines and redesign the template to avoid misleading reusers, get them agreed and then run a full RFC.
Until then, there is no credible consensus to use the "120 years" template instead of having deletion requests, the associated images are effectively being hosted without a proper license and volunteers are being badly advised by encouraging them to use the template. -- (talk) 12:00, 7 March 2018 (UTC)
I'm not sure what you think should be done with the map that's at issue here. Do you want it deleted, or is there some other template that can be used? --ghouston (talk) 21:12, 7 March 2018 (UTC)
Well, not deleted, since it hasn't been uploaded, but not uploaded at least? --ghouston (talk) 21:14, 7 March 2018 (UTC)
There's enough to do with files we host, thanks. -- (talk) 21:15, 7 March 2018 (UTC)
If there's not copyright law that supports hosting these files on Commons, then they should be DRed. So should all the works we have on Commons that have a named author and no death date, like the Iliad. We assume all the time that the authors of works have been dead long enough; all this does is draw a line in the sand and mark those with a template besides PD-old. I've seen enough of these go to DR to know that this wouldn't get deleted, given its age, even before discussion.--Prosfilaes (talk) 21:04, 8 March 2018 (UTC)
The legally meaningful answer varies by country, pretending otherwise is to have your head in the sand. In all cases, volunteers should be able to point to evidence of "reasonable" efforts to determine copyright, in practice this is a very low bar. -- (talk) 11:15, 11 March 2018 (UTC)
And in this case, Spanish law is effectively ten years longer than the life+70 120 years was mostly based on, and conveniently the file under question was published over 130 years ago.--Prosfilaes (talk) 17:41, 12 March 2018 (UTC)
@Nclm: Some days ago I wrote Commons:Assuming worst case copyright while in a funny mood. Didn't put it up yet and forgot about it. Your question reminded me, you may or may not find it useful. - Alexis Jazz 07:51, 9 March 2018 (UTC)

March 05[edit]

Stained glass windows[edit]

Ester and Artaxerxes
Rose window

If we regard photographic reproductions of out-of-copyright two-dimensional artworks as public domain, why not do the same for images which are reproductions of ooc stained glass windows? By which I mean images like the 'Ester and Artaxerxes' one above, rather than those showing the window in a setting, like the rose window picture. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:10, 8 March 2018 (UTC)

I would think modern stained-glass windows are covered by Freedom of Panorama as "works of artistic craftsmanship"; older windows, e.g. by William Morris must be out of copyright. I think the presence of absence or context is irrelevant. Rodhullandemu (talk) 16:22, 8 March 2018 (UTC)
Indeed, but that's not the question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 8 March 2018 (UTC)
You can photograph a traditional painting today or tomorrow, it can be illuminated from above or left or right or below – the photograph will be practically the same. But a stained glass can be illuminated by direct sun (in morning or afternoon), or by sky, or by reflected sun, or by luminescent lamp, or by LEDs, and you will obtain different pictures. Too many uncertainties. Incnis Mrsi (talk) 16:37, 8 March 2018 (UTC)

Consider, for example the images at - why is the paint-on-glass less freely useable than, say, paint-on-canvass or paint-on-paper (the artist's death date notwithstanding)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:44, 8 March 2018 (UTC)

Why is it? Rodhullandemu (talk) 18:07, 8 March 2018 (UTC)
Never thought about this before. If the window is ooc then it dosen't matter if the photographer had to wait for a time when s/he thought the sun was at the right angle or whether s/he used fill-in flash. It is still a slavish copy that does not add one iota to the creativity of the original subject. --P.g.champion (talk) 18:58, 8 March 2018 (UTC)
I agree with P.g.champion, however that "Pauline Boty" stained glass is very definitely not OOC. Panorama depends on the country; stating the obvious most stained glass photos are taken (indoors) from within buildings. BeckenhamBear (talk) 16:34, 9 March 2018 (UTC)
Hence "the artist's death date notwithstanding". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:21, 12 March 2018 (UTC)
@Pigsonthewing: For reference, here's the policy on photos of "old" stained glass windows. - PKM (talk) 02:51, 12 March 2018 (UTC)
That says nothing about using others' images, as we do for paintings. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:21, 12 March 2018 (UTC)
well, the section heading is “Photograph of an old stained glass window or tapestry found on the Internet or in a book”. - PKM (talk) 04:17, 13 March 2018 (UTC)
So it does - I only read the body text. Apologies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 14 March 2018 (UTC)


Hello, can it be that these magic words are disabled for Commons? Therefore, they can be removed without any hurt? --Arnd (talk) 17:50, 8 March 2018 (UTC)

@Aschroet: TOC is working fine for me at the bottom of User:Jeff G.#Introduction and I've never seen a good explanation for use of NOTOC. Do you have examples or statements that indicate they are disabled for Commons?   — Jeff G. ツ please ping or talk to me 18:40, 8 March 2018 (UTC)

See Commons:Photo challenge/2018 - January - Blue/Voting. A TOC would be a pest on that page. -- Colin (talk) 18:58, 8 March 2018 (UTC)

I see no TOC here: CenaF-U.jpg. --Arnd (talk) 19:10, 8 March 2018 (UTC)
Shouldn't this discussion run for a while before bot removing them? Thanks. Mike Peel (talk) 21:51, 8 March 2018 (UTC)
__NOTOC__ is the default for the file namespace. So it can be removed from all files with no effect. They still work for the Gallery namespace. So to come back to Arnd's question, I would not touch them outside the file namespace. Some users use __NOTOC__ for galleries with many headings and only a couple of pictures. --Schlurcher (talk) 22:22, 8 March 2018 (UTC)
BTW: OgreBot 2 does remove this while doing some cleanup on imported files for years now - 2 examples from images where I prompted the import: Special:Diff/289323650/289663727 and Special:Diff/289324840/289663802. — Speravir – 00:55, 9 March 2018 (UTC)
BTW 2: It seems there are not that much files containing it – search links: search for __NOTOC__ and search for __notoc__ (update: fixed all 12 appearances of the latter). — Speravir – 00:55, 9 March 2018 (UTC)
Arnd, is everything clear and could the thread thwerefore be closed? — Speravir – 23:21, 15 March 2018 (UTC)
It is. Thanks, --Arnd (talk) 06:18, 16 March 2018 (UTC)

Creator templates for Commons contributors[edit]

Sich ein eigenes Wikidata-Objekt kreieren und eine Creator-Vorlage?

Ein Commons-Benutzer+A hat sich einen Wikidata-Datensatz sowie eine Creator-Vorlage gebastelt. Ist so etwas gern gesehen oder überhaupt zulässig?

Diego Delso  (1974–) Blue pencil.svg wikidata:Q28147777
Diego Delso
Alternative names Poco a poco
Description Spanish photographer
Free-license photographer
Date of birth 19 May 1974
Location of birth Alicante, Spain
Authority control

--Mattes (talk) 20:34, 11 March 2018 (UTC)

Can a Commons user create their own Wikidata item and creator template? I suppose anybody can create their own creator template on Commons, I'm not really sure. On the Wikidata side, they should follow d:Wikidata:Notability. At present it seems that creating a non-Category Wikidata item with a sitelink to a Commons category is permitted, but the wording on Commons has changed recently and may change again. --ghouston (talk) 22:37, 11 March 2018 (UTC)
For the creator template, see Commons:Creator, section "Who should have creator page". --ghouston (talk) 22:50, 11 March 2018 (UTC)
Mattes, die Vorlage ist schon gerechtfertigt, das Datenobjekt kann ich nicht einschätzen, aber ghouston hat ja auf die die Wikidata-Relevanzkriterien hingewiesen. Diego/Poco a poco hat über 18 000 Fotografien auf Commons hochgeladen, siehe auch die Kat. Images by User:Poco a poco. (Die Village Pump ist eigentlich der Treffpunkt der Englisch Plappernden. Deutschsprachige unterhalten sich ganz klassisch auf dem Forum). — Speravir – 03:02, 12 March 2018 (UTC)
So does this mean that with nearly 3 times that number of photos on Commons (but not having bothered to create a category for them), I should have a Creator template? - Jmabel ! talk 05:24, 12 March 2018 (UTC)
I don't see why not. According to Commons:Creator, you can have one if you meet the notability requirement for categories, among other things. But there isn't any notability requirement for categories, according to Commons:Requests for comment/User categories. --ghouston (talk) 05:48, 12 March 2018 (UTC)
About the original question "Can a Commons user create their own Wikidata item and creator template?", I would argue yes if the Commons user is a prominent creator enough to deserve one. It shouldn't be a problem unless it is made to be one. -- Sixflashphoto (talk) 15:40, 12 March 2018 (UTC)
Hi, I haven't created that template as you can see in the file history, but rather User:Sergkarman, whom I didn't know before that. He contacted me after he created the entry because he thought it should be fine with the project policies, and I improved the data entered. At the same time I discussed the topic in a Telegram group with members of Wikimedia Spain as some of them know Wikidata better than me, as I was actually unsured about the requirements in terms of notability. I entered 2 or 3 references and they considered it good to go (I just recovered one of those references, that was removed for some reason I cannot understand). I've made quite a bunch of achievements within the movement, most FPs, most QIs, placing 2 images among the top 12 in the Picture of the Year contest, or placing images among those highlighted (top 10 or top 25 depending on the year) in the last 4 editions of Wiki Loves Monuments (in WLE I was also second worldwide in 2016). I agree that only items over a threshold of notability should be accepted. I don't know if I pass the bar, and therefore I've no problem if the item is deleted, no hurt feelings there, your call. Poco2 19:08, 12 March 2018 (UTC)
Pictogram voting comment.svg Comment Poco's template is fine for me, but I foresee major disagreements about who meet the notability criteria. I have mentioned that in the Structured Data discussion, but it doesn't seem to have gathered attention. See Commons talk:Structured data/Get involved/Feedback requests/Ontology#Notability of Commons creators. Regards, Yann (talk) 08:58, 13 March 2018 (UTC)
Following up on my comment above: I'd be glad to have one of these for my contributions, but at least up to now have presumed it would be considered inappropriate. It's certainly not something I want a fight over, so I still hesitate to do it. - 19:40, 16 March 2018 (UTC)

March 12[edit]

Microsoft Sketchfab models[edit]

Okay, so we have 3D models support on Commons. Now, by all means I don't expect these models to be ridiculously detailed (though some are); the format for them originates in 3D printing after all. However, the files sourced from Microsoft on Sketchfab have major issues with fidelity in my opinion. For example, the Empire State Building looks quite different from its model, with more prominent setbacks and a tapered spire. The Space Needle is supposed to have gaps inside as well as an antenna. The proportions for the White House are all wrong. While these models are fine for a representation or interpretation of these structures, by no means do they accurately represent them, which does not align with Wikimedia's goal of education (see also, Template:Factual accuracy). What's more, they're actually being used in articles and added as items in Wikidata. If these models are to stay, there must be clear identification that they're oversimplified and inaccurate models. Again, let me make it clear that it's not the level of detail that I'm taking issue with here. Opencooper (talk) 08:24, 12 March 2018 (UTC)

(Tangentially: this prompted me to make {{Sketchfab}}. More often than not the indication of provenance of STL files could be better. :/ Jean-Fred (talk) 08:02, 13 March 2018 (UTC))

Discussion on supporting the upload of MPEG-2 videos[edit]

Hello, Recently the US patents on MPEG-2 video compression expired. [4] A few weeks ago Lead Software Architect Brion Vibber put forth a discussion on the multimedia-l mailing list regarding the merits and concerns of supporting MPEG-2 uploads on Commons. [5]

Quoting Brion, "I expect this to be most useful for importing old videos from scientific papers and web sites (small files), and for archival footage from GLAM institutions such as digitizations of old SD broadcasts and tips of modern HD broadcasts (large files) -- importing the original files would avoid recompression artifacts and save time and effort re-encoding."

Wikimedia legal has discussed this support with the Multimedia team and it is OK from their perspective. It is worth noting that there are still patents open in the Philippines and Malaysia. [6]

Given that supporting new file formats is a community decision, I wanted to broach the subject with you all here. So, what do folks think about supporting this file format for uploads here on Commons? As Brion notes, most browsers don't display MPEG-1 or MPEG-2 natively, so playback will rely on the WebM transcodes. Comments, questions, and feedback are welcome. CKoerner (WMF) (talk) 17:33, 12 March 2018 (UTC)

EU only? or for everyone? Not sure, but anyway in general I think it is fine to have it. — regards, Revi 13:13, 17 March 2018 (UTC)
You may wish to have a nicely written Phab ticket and then raise the yay nay vote at Commons:Village pump/Proposals. It appears entirely non-controversial. -- (talk) 13:26, 17 March 2018 (UTC)

Tech News: 2018-11[edit]

19:44, 12 March 2018 (UTC)

User custom license tags forbidden?[edit]

Not on the user’s talk page, but here, because I think this is of fundamental importance.

Are user custom license tags forbidden on Commons? If so, why is there an own category User custom license tags with over 400 of these license tags in it? Also, I know for sure that there are even more of these. (I admit that’s slightly provocative.)

User Code wanted to relicense his photos who he had originally published in Flickr after uploading to Commons: In Flickr only CC-by-2.0 is possible, however, he intended to relicense to CC-by-4.0 (it shouldn’t matter, but believe me he knows why). He started to add both {{Cc-by-2.0}} and {{Cc-by-4.0}} (cf. Special:Diff/288918945/288920522), but didn’t like the appearance. So he asked in (German) Commons:Forum for an individual license template (now archived in Commons:Forum/Archiv/2018/February#Lizenz-Template erstellen. Note that the question is not for a user license, but I knowing about the existence of custom user license tags suggested to create another one while De728631 pointed to {{Cc-by-all}}, but this includes cc-by-1.0 which is inacceptable for Code. I made a first suggestion in this thread before we moved to Code’s talk page (User talk:Code#Individueller Lizenzbaustein). My proposition I presented there was then copied by Code to User:Code/FlickrCommonsLicenseBY and used for the same file, cf. Special:Diff/288920522/289843174. But then came Jcb along and reverted Code’s license update claiming “file must have at least one official license” (Special:Diff/289843174/291947045).

Though I think Jcb is totally in error here – I do not see his claim in Commons:Licensing, and especially the file is for me properly licensed to both cc license versions – I’m interested in other opinions about the general topic behind this. Following Jcb we had to change the license tags of lots and lots of files now using an apparently illegal custom license alone. — Speravir – 23:44, 12 March 2018 (UTC)
PS: For technical advices regarding the license in question perhaps better answer on the user talk page.

Oh, some special kind of edit conflict: While I wrote this here, what took sooome time Jcb answered on Code’s talk page (Special:Diff/291956222/291984200). — Speravir – 23:54, 12 March 2018 (UTC)
Some remark for this: We also have lots of files without a machine readable license. Should all of these be edited? — Speravir – 00:12, 13 March 2018 (UTC)

@Speravir: The official answer here is yes, transcluded userspace custom license tags are forbidden per guideline COM:USER, a part of policy COM:PSP. The goal is to ensure that any change to actual licensing of a file will show up in the history of the file. On the other hand, transcluded templatespace custom license tags seem to be allowed if they meet the project's needs, have a good reason to exist, and contain COM:L standard licenses (for instance, if they refer to OTRS tickets and thus reduce future OTRS member workload). The latter tags tend to attract more watchers than the former, and the referred OTRS tickets can also be watched.   — Jeff G. ツ please ping or talk to me 01:48, 13 March 2018 (UTC)
Sorry, Jeff, could you, please, exactly cite the part of COM:USER, because I do not see such a prohibition there, too. Otherwise I wonder why all the other custom user licenses have not been an issue for years. In regards to machine readability I know that the template has an issue, and I will deal with it later. — Speravir – 02:05, 13 March 2018 (UTC)
Jeff. — Speravir – 02:06, 13 March 2018 (UTC)
@Speravir: COM:USER#Regarding licenses and its subsection COM:USER#Examples. Also, I have for many years relied on this edit.   — Jeff G. ツ please ping or talk to me 02:19, 13 March 2018 (UTC)
No, Jeff, I’ve already read this part and I still do not get it. Instead I read explicitly “If the user-specific template does not incorporate a standard license template, then it can be subst:ed or not as the user prefers.” Or is it for you the next sentence “Templates such as "CC-BY-SA-UserExample" (which combines the standard license template with file author information) should not be used. Use of such custom templates reduces machine readability about file licenses. (It becomes impossible to tell by parsing the wikitext which license applies, if there are potentially as many license templates as there are users.)”? I see a should not be used, not a must not be used. (About the lacking of machine readability I already wrote myself above.) — Speravir – 02:50, 13 March 2018 (UTC)
@Speravir: I tried to harden "should"s to "must"s over 10 years ago in these edits, but I was rebuffed.   — Jeff G. ツ please ping or talk to me 03:13, 13 March 2018 (UTC)
(edit conflict) I agree with user:Jcb, User custom license tags are not forbidden as long as there is at least one official license tag present in the image. We do not want to evaluate user written license texts in order to find if they do or do not meet commons requirements. So at the moment the practice is that each official license template gets machine-readable marking and only licenses discussed at the Commons:Village pump/Copyright which got consensus. Images without machine-readable marking can be detected and placed in problem categories. --Jarekt (talk) 02:09, 13 March 2018 (UTC)
Speravir yes we still have many custom user templates which seem to cross, in my opinion the line into counter productive self promotion. I agree we should clean them up. --Jarekt (talk) 02:26, 13 March 2018 (UTC)

(I will be out for hours after this.) Jcb, Jarekt, according to which policy do you act? I cannot see any prohibition on the pages linked as of now, though I have to admit that I understand the reasons. (In case of Code I presume the fears are not justified, because a template change introducing inappropriate licenses would endanger his profession.) — Speravir – 02:50, 13 March 2018 (UTC)

Com:Lic says "The license that applies to an image or media file must be indicated clearly on the file description page using a [[<tvar|tags>Special:MyLanguage/Commons:Copyright tags</>|copyright tag]]." For years all allowed copyright licenses were explicitly listed on Commons:Copyright tags, but at some point whoever was maintaining that must have retired or list got too big, so now we use machine readable marking. --Jarekt (talk) 03:00, 13 March 2018 (UTC)

Even if Jcb was right (I'm still not convinced about that) he could and should have a) talked to me before just reverting my own edit on my own file b) helped Speravir and me to find a solution for the problem. Everybody can see that I just want to license my file under two licenses which are perfectly acceptable on Commons. It's nothing but upsetting to just revert my edit under these conditions. --Code (talk) 05:06, 13 March 2018 (UTC)

Pictogram voting comment.svg Comment That's typically an issue which should disappear with Structured Data. Then we will simply have "license 1" + "license 2" + "credit". The display can be customized at will, but the information would be machine readable. Regards, Yann (talk) 08:47, 13 March 2018 (UTC)
Pictogram voting comment.svg Comment Seconding Jarekt and Jeff. Custom license/attribution templates on Commons are an interesting story ; but the main reason user-space licence-templates are not allowed is to avoid non-transparent relicensing − in the same way that Source templates should generally not include/transclude licence templates − examples of issues with that approach are {{PLOS}} or {{Agência Brasil}} (source changes its licensing, templates is updated in good faith, previously uploaded files are mistagged).
License templates should be somehow-vetted by a community process, and indef-protected. A licence in user-space typically is not watched but by a few users (for example, User:Code/FlickrCommonsLicenseBY is on the watchlist of exactly one user) − vandalism on that template could go easily go unnoticed, all the files would have their licensing implicitly changed. If that happens after the photographer had moved on from Commons, it’s not likely anyone would notice (or at the very least not rapidly).
Also, the sheer count pagecount of Category:User custom license tags is a bit misleading because many of these tags are more custom attribution templates − I have started to move some to Category:User custom attribution tags‎ accordingly. Jean-Fred (talk) 09:57, 13 March 2018 (UTC)
With respect to should be somehow-vetted, the topic is wooly in policies and guidelines. The process for creating a new license, or significantly adapting an existing one, could be made usefully clearer. The current process means that someone could create a new license and a discussion on the talk page might be sufficient to tick a box for "consensus".
Credit and attribution templates are at the don't care level, and should remain easy to create and apply. In the past these have rarely become an issue, so informal seems a good place for these to stay though guidelines could improve if anyone recalls past problem cases to learn from. -- (talk) 10:44, 13 March 2018 (UTC)
I have no idea what is going on here (as in what the user is trying to achieve) and I don't particularly care, but we have templates for a reason, and if people start copy pasting stuff around etc, then it all becomes terribly hard to maintain (translate, detect with software, style, etc etc). We should be presenting a consistent and UNIFORM experience, whenever possible, now and into the future, so everyone can make the right assumptions. That's why we have license templates, and that's why you shouldn't fork them. And note the respect that I saw mentioned somewhere by someone goes both ways. Those who put effort into making and licensing their images, but equally there should be shown respect to those who try to manage all existing content. Uploader, curator, developer, downloader. All require respect, it's not a one way street. There is a place for user custom licenses perhaps (adding categories is a good one as far as I'm concerned), but you can reuse an existing template FROM your user template, instead of copy pasting one. That is SO MUCH MORE future proof. I hope that with commons data, we can soon leave some of this behind... —TheDJ (talkcontribs) 17:36, 15 March 2018 (UTC)

March 13[edit]

Non existing file[edit]

In the Category:Ciriè train station there is a non-existing file. What has happened?Smiley.toerist (talk) 09:54, 13 March 2018 (UTC)

It looks like it got moved to File:Ciriè station 2016.jpg, and then an anon tried to hand-revert the redirect. Bawolff (talk) 12:12, 13 March 2018 (UTC)
I fixed it to the proper redirect. Pi.1415926535 (talk) 15:29, 13 March 2018 (UTC)

Removal of invalid PD templates[edit]

File:Guantanamo disposition - Final Dispositions as of January 22, 2010.pdf was tagged with the PD-USGov-Military-Navy template. Since this is the work of the ODNI and not the US Navy, I removed the template. I noted the problem in my edit summary. As expected, a bot soon came along and tagged it as needing a license. For some reason, User:Jcb restored the original incorrect license template and left me a message on my talk page telling me not to remove licenses. When questioned, Jcb intimated that they would block me if I continued to remove invalid license templates (or maybe just for questioning them, it's not clear).

Is it ok to remove a demonstrably invalid license template? It seems like this would be beneficial rather than harmful. Jcb's suggestion that a deletion discussion for such files is less work for volunteers seems questionable. World's Lamest Critic (talk) 17:14, 13 March 2018 (UTC)

I have given you clear instructions and I have also provided the correct license at your user talk page in my first respons. Don't remove licenses, or you will get blocked. If you disagree with a license, fix it or nominate the file for deletion. Jcb (talk) 17:18, 13 March 2018 (UTC)
I don't want to be blocked, but I don't want files here to have invalid templates either. You seem to know what the correct template for that file is, but it still has an incorrect PD claim. It seems like you are more interested in blocking users than fixing file problems. World's Lamest Critic (talk) 17:24, 13 March 2018 (UTC)
Jcb is known to wage wars over it, alongside other possible pretexts. It is his personal preference, not community consensus. Recommended actions: avoid edit wars in the File: space but do what you deem necessary. Incnis Mrsi (talk) 17:20, 13 March 2018 (UTC)
Do what you deem necessary? That's dangerous advice. Be bold isn't always a common Commons practice as with other wiki's. World's Lamest Critic You were wrong. Jcb was technicially correct. You many have changed the author (correct or not is immaterial) but removed the permission template. Jcb also linked on your user page a general {{PD-USGov}} template. Jcb wasn't wrong, this isn't a big deal, and Incnis Mrsi you don't need to look for a fight with Jcb over this. -- Sixflashphoto (talk) 19:28, 13 March 2018 (UTC)
Oops… now I see this diff – it is not a good thing to remove a PD template from a public-domain work. Incnis Mrsi (talk) 20:35, 13 March 2018 (UTC)
That's what this discussion is about. The options are leave an invalid PD license or remove it so it gets tagged by the bot and someone can investigate the correct license. Why does it make sense to leave an incorrect PD template? World's Lamest Critic (talk) 03:40, 14 March 2018 (UTC)
  • I hadn’t yet seen this discussion when I reverted another one of these removals; sorry if that seemed un-mellow to anyone. If anything in my comment at this DR is overly procedure-focused or otherwise out of line with practice, I’m open to being trouted for it, but it struck me at the time that removing the disputed permission template amounted to an end-run around the DR.—Odysseus1479 (talk) 00:18, 14 March 2018 (UTC)
    @Odysseus1479: could you clarify with diffs which removals do you deem objectionable? Quibbles over specific choice of a licensing template where the file has evidences to lie in public domain anyway – I agree, are disruptive. But I now wary that this discussion may be seen as encouragement for disparagement and harassment of volunteers who alert the community about files with completely forged licenses. Incnis Mrsi (talk) 07:33, 14 March 2018 (UTC)
@Incnis Mrsi: the whole story is in the brief history of File:U. S. Coast Guard- Small Cutters and Patrol Boats 1915 - 2012.pdf. If nothing else, the licence‘s removal would be inconvenient to participants in the DR, making them look over the history to see what was originally claimed. Or likewise to whichever admin processes the speedy tag, if taking that route; it just obfuscates the question in either case.—Odysseus1479 (talk) 07:56, 15 March 2018 (UTC)
apparently, there is not a PD-USGov template for the w:Director of National Intelligence. this is not a military command. why don't you all fix the licenses instead of edit warring like a child? Slowking4 § Sander.v.Ginkel's revenge 01:24, 14 March 2018 (UTC)
If I had known the right template, I would simply have replaced it. For the record, there is no edit war going on. I don't know why Jcb would knowing replace an invalid PD claim or why they did not fix it after we had discussed it. World's Lamest Critic (talk) 03:40, 14 March 2018 (UTC)

This discussion hasn't answered the question of what do I do the next time I find a file with an incorrect PD license? Is there a template to flag that? Nominating a file that is probably PD for deletion because it has the wrong template seems like a very poor solution. At least removing the template gets the file noticed by a bot which will get someone to fix the missing license correctly. World's Lamest Critic (talk) 14:22, 14 March 2018 (UTC)

@World's Lamest Critic: You would have the following valid options:
  1. Investigate and fix it yourself.
  2. Discuss it on the talk page.
  3. Discuss it with the user who tagged it as such or the uploader.
  4. Discuss it on COM:VPC.
  5. Ignore it.
Making a mess by removing the tag entirely is not a valid option.   — Jeff G. ツ please ping or talk to me 14:58, 14 March 2018 (UTC)
If I had known the correct template (and apparently there is no ODNI PD template) of course I would have just fixed it myself, but what "mess" did I create? A template saying that there's no license? If we are trying to reduce the waste of "precious time" surely it is more efficient to deal with a missing license than have a multi-party discussion? World's Lamest Critic (talk) 19:40, 14 March 2018 (UTC)
World's Lamest Critic do not remove license templates, doing so only alerts the original uploader who might no longer be active. Without license template image might get deleted, often without further investigation. If you can not fix the license, than a better way is to nominate file for deletion and state your reasons. --Jarekt (talk) 19:51, 14 March 2018 (UTC)
Ok, from now on I will nominate such files for deletion. It might be helpful if this subject was addressed in a guideline. World's Lamest Critic (talk) 19:54, 14 March 2018 (UTC)
FWIW, I got chewed out by a fellow admin a few weeks back for dealing with a licensing mess by nominating for deletion. It was a supposedly PD assemblage that didn't credit any of its sources, and which included a photo of mine that was not PD. I still think that if you can't readily fix it, nominating for deletion is a perfectly appropriate step. - Jmabel ! talk 20:23, 14 March 2018 (UTC)
please do not nominate for deletion, just use the generic "PD-USGov" all the custom ones by agency are purely decorative. and stop warning the good faith editor, sofixit. Slowking4 § Sander.v.Ginkel's revenge 01:37, 16 March 2018 (UTC)

Categorization of louvered windows[edit]

Discuss here.--Carnby (talk) 19:37, 13 March 2018 (UTC)

March 14[edit]

Uploading new version of file.[edit]

Most of the images I upload to Wikimedia are images of emblems of United States Air Force units. On occasion, I will upload an improved (for resolution, accuracy, etc.) version of an image already on Wikimedia. This most commonly occurs when I replace an image of a patch displaying the emblem with the official emblem itself. An example is 13 Military Airlift Squadron.

Sometimes the change on the pages where the image displays occur quickly, but sometimes there is a long delay in the change showing up on pages where it is used. I presume the delays are due to some review process to prevent vandalism. Is that accurate? If it is, is there a permission/right that I can apply for that would avoid the delay?

Hi, I think the delay is simply due to cache issues. Regards, Yann (talk) 13:53, 14 March 2018 (UTC)

Encouraging payment for photos[edit]

Not really sure how to raise this. I was looking for a photo to illustrate a Wikipedia article, and the one I found (File:London March 2018. See profile for image use.IMG 0655.jpg) urged me to check the user's profile in its name and description. Checking it, User:Øyvind Holmstad's profile says I appreciate very much a payment of 250 N.Kr for my images for volunteer organizations and 500 N.Kr for commercial use., and perhaps I'm reading a level of intent that isn't there, but this made me feel like it would be rude for me to use their image on Wikipedia without paying the 250 Kroner. So I didn't use it. But that's not what CC-Attribution and Wikimedia Commons should be about, is it? --Lord Belbury (talk) 15:09, 14 March 2018 (UTC)

  • Seems awfully commercial to me (and also potentially confusing). At the very least, it should make clear that any such payment would be entirely voluntary, and that the images are free-licensed. - Jmabel ! talk 15:48, 14 March 2018 (UTC)

Wow! Sorry my encouragement for Wikipedia, students and bloggers to feel free to use my images for some reason disappeared when I edited my profile last time. I added it again:

"Wikipedia, students and bloggers are encouraged to use my images for free!"

Anyway I sold two images to an advertising company recently, and I think they felt happy to pay a little for the images.

By the way, that was my best image for our short visit to Borough Market. Very happy if you can use it in an Wikipedia-article!

Øyvind Holmstad

— Preceding unsigned comment added by Øyvind Holmstad (talk • contribs)

I don't know how to sign, but as I made the change to my profile it's obvious it's me.

I will anyway continue to add full resolution images until I get my new camera. But if I can't continue commercial businesses and organizations to pay a little, if they feel for it, I must add small resolution images, probably 1024 pixel only, when I get my new camera, and encourage to contact me personally for a larger resolution if needed. I see some contributors do it this way.

I though prefer to contribute with full resolution images for Wikimedia, stressing that the content can be used for free for Wikipedia articles, students and personal bloggers. While encouraging a volunteer payment from businesses and organizations. My next camera will cost me a lot, and the quality with full resolution should be very valuable for Wikimedia and Wikipedia-articles. So I hope you can let me contribute my images the way I suggest?

Øyvind Holmstad

Pictogram voting comment.svg Comment No problem for me as long as it is clear that the payment is only voluntary. Free software developers do this a lot, so I don't see an issue for photographers. Regards, Yann (talk) 07:49, 15 March 2018 (UTC)

Hybrid PDF/ODF[edit]

Some time ago, I uploaded successfully hybrid PDF/ODF files, it was useful for example for templates of various documents. Now it is not possible, the upload form doesn't allow such files, it writes the file is a wrong ZIP format. What can I do? --Petrus Adamus (talk) 16:54, 14 March 2018 (UTC)

See Commons:Village_pump/Archive/2013/09#PDF-ODF_files_cannot_be_uploaded. Ruslik (talk) 17:34, 15 March 2018 (UTC)

Layout of file pages[edit]

Where might I go within the project to suggest structural changes in the way file pages are laid out ? I believe there are certain ways to be more user-friendly for the chance-by and non-registered visitor, while improving the possibility of our Wikimedia files being searched and thereby used when within the project. Acabashi (talk) 21:32, 14 March 2018 (UTC)

  • Commons:Village pump/Proposals, but you might do best to draft a page in "Commons" space describing your proposal and link it from there. - Jmabel ! talk 22:11, 14 March 2018 (UTC)
    • Many thanks. What do you mean by 'draft a page in "Commons" space' ? Acabashi (talk) 22:39, 14 March 2018 (UTC)

March 15[edit]

Structured licensing and copyright discussion[edit]

Hi all,

I've posted the first discussion around structured licensing and copyright on Commons. If you get some time, please head over to the page to learn more and participate in the discussion. I'll be spreading the word to some mailing lists shortly. Thanks, happy editing. Keegan (WMF) (talk) 16:07, 15 March 2018 (UTC)

onlyinclude in categories etc.[edit]

Good evening, i have a question: What sense it makes to use onlyinclude in categories, galleries, files? [18] Can we remove at least some of them? --Arnd (talk) 18:25, 15 March 2018 (UTC)

That's the {{Category definition: Object}} setup. Someone thought it would be a good idea to transclude categories as templates on files. Technically possible, but utterly confusing. Fits into the Commons technical history of trying to build things with tools that weren't intended to be used like that. Should be gracefully deprecated and replaced with Wikidata. Work is being done by Jarek on {{Artwork}} so it can be switched to LUA and grab data from Wikidata. When that's all up and running, data can be migrated and template usage replaced. Multichill (talk) 19:47, 15 March 2018 (UTC)

March 16[edit]

About F2C[edit]

Hello, why in Flickr2Commons auto-detecting category tool isn't working?--√Jæ√ 11:19, 16 March 2018 (UTC)

You have to check cats always by hand, there is no way to automatically detect all cats. Probably F2C should be restricted to extended uploader, we had multiple issues with this mass import tool in the past. --Steinsplitter (talk) 12:13, 16 March 2018 (UTC)
The Flickr2Commons tool never detected categories for me, other than for importing images I don't think that It's usable, but restricting it to certain "trusted users" would be a major disservice as there are many great images of archeological sites and museums on Verizon's Flickr that need importing that can't simply be imported with another tool in the current repertoire. It needs more users, not less. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:00, 17 March 2018 (UTC)

It would be useful for all users experiencing problems with F2C, or other tools, to log into Phabricator and raise a ticket. You can find related existing tickets with an easy search like this. Though volunteer tool tickets are less likely to gain attention from WMF development, long term issues described on Phabricator are ideal to help prioritize a development related grant or for one of the hackathon/summer of code type projects and events. Even if that does not happen, it's great to have a ticket and be able to quote it and add to it, rather than having circular discussion and complaints that evaporate without action. -- (talk) 13:08, 17 March 2018 (UTC)

+1 - we need some tool migration for WMF to onboard the best ones in mediawiki functionality; but in the meantime, we will have to give feedback at phabricator. User:Magnus Manske is pretty responsive, maybe drop him a line also at quality of category import is dependent on metadata at flickr, which is not good in my experience. Slowking4 § Sander.v.Ginkel's revenge 00:42, 18 March 2018 (UTC)

March 17[edit]

Picture that uploaded first on Facebook[edit]

Hello. A picture have uploaded first on Facebook page. I communicate with the administrator of the page and said it is ok to use the picture on commons (it is his/her picture). I used to be an OTRS member some years ago but never faced a Facebook picture situation. I know that if they add ticket number in picture decription on Facebook they OTRS member can confirm it. But what must happen before that? Should they send an email to create the ticket? If they don't have an email as a page? Can I send the email to create the ticket? But then, how OTRS member can really know that the creator really know all the informations of the email? Xaris333 (talk) 14:06, 17 March 2018 (UTC)

  • The simplest way would be for them to (1) make the picture public on Facebook. (2) Assert the license there, and that they are the copyright holder of the photo. Then you can link that as a source & use the same license. - Jmabel ! talk 16:58, 17 March 2018 (UTC)
Ok. For (1) the picture is already public on Facebook. For (2) what exactly they must write? And if they remove it after a period how someone will know if they had approved publication under the terms mentioned? Xaris333 (talk) 17:13, 17 March 2018 (UTC)
I suggest that they write that the image is released under Creative Commons Attribution-Share Alike 4.0 International license, link so it is clear they know what that means, and indicate how they want it attributed.
If you are really concerned about them later taking it down, then I suggest screenshotting the facebook page and sending that screenshot to to - Jmabel ! talk 01:04, 18 March 2018 (UTC)

March 18[edit]

Linkrot on Wikimedia Commons[edit]

On Wikipedia if sources are online the ArchiverBot will automatically add links from the last access date to the Internet Archive and will add an archived version of the link, since here on Wikimedia Commons many images are imported public domain or otherwise free images from a variety of sources such as Verizon's Flickr and museum websites, wouldn't it be wise to let an ArchiverBot run on Wikimedia Commons and use the upload date as the "access-date"? --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:30, 18 March 2018 (UTC)

Yes. If you need examples, take a look at Uploads by Fæ with linkrot. -- (talk) 13:34, 18 March 2018 (UTC)
So are there any plans to deploy the ArchiverBot on Wikimedia Commons? If not, then why not? --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:49, 18 March 2018 (UTC)

It is a minor problem, compared to rampant deletion of redirects (especially in the File space) on Commons itself. With current deletionist practices, Commons does not serve a reliable storage of media which could permit to see images when browsing some two-years-old histories of, say, Wikipedia articles. Incnis Mrsi (talk) 18:55, 18 March 2018 (UTC)

March 19[edit]

User replacing image instead of posting[edit]

The File:Nizhny Novgorod ISS view.jpg was replaced with totally another image by user:AlexTref871, and it was afterwards renamed. I feel this is wrong, he should create new file instead. I have asked him to fix this, and asked the renaming user for assistance. No fix was made since, so I write here. Am I correct? --ssr (talk) 13:32, 19 March 2018 (UTC)

Tech News: 2018-12[edit]

15:03, 19 March 2018 (UTC)

Intersection categories[edit]

@Halavar: Didn't we have an explicit consensus against "intersection categories" as narrow as a geographic location on a single day? Or has this changed? I ask because of the recent re-ccategorization of a bunch of my photos into Category:Romania photographs taken on 2014-12-17. At the risk of absurdity, are we headed toward explicitly intersecting all categories, to the point where will have things like Category:Black and white photographs of black Chevrolet automobiles taken in Winesburg, Ohio on the afternoon of 2014-12-17? Isn't there a point in having multiple, independent categories? And isn't multiple, independent categories exactly the direction we are more likely to go when we switch over to WikiBase? - Jmabel ! talk 19:44, 19 March 2018 (UTC)

I do not see a problem. "Country photographs taken on date" categories are widely used by lots of Commons users, since about a year even more widely. --Halavar (talk) 19:55, 19 March 2018 (UTC)
I don't see a problem with "Country photographs taken on date" as a countries usually cover large areas and so could generate reasonable amounts of files, I can accept "County photographs taken on date" for similar reasons. But there are "Village photographs taken on date" categories. No reason to pick on this particular category but people will be wanting an example Category:Worlaby photographs taken on 2006-05-13. Oxyman (talk) 20:41, 19 March 2018 (UTC)