Commons:Village pump

From Wikimedia Commons, the free media repository
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


A village pump in Burkina Faso [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)
@DannyH (WMF): I deleted these 2 pages. I hope this closes the issue. Regards, Yann (talk) 06:55, 20 March 2018 (UTC)
Great, thank you. I replaced the two Flow pages with the wikitext export, as an archive. They're at Commons talk:Flow and Commons talk:Flow/tests. Flow has now been removed from Commons. I think that's all we need to do here, but I'm happy to continue discussing this if people want to. -- DannyH (WMF) (talk) 14:56, 20 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)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Speravir 03:33, 22 March 2018 (UTC)

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

Hello, Recently the US patents on MPEG-2 video compression expired. [3] 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. [4]

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. [5]

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)

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]

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)

  • You are fully correct in both accounts, I think. -- Tuválkin 00:15, 20 March 2018 (UTC)
  • I’m trying to undo this mess, but the renaming redirect needs to be deleted by an admin before it can be used. -- Tuválkin 00:27, 20 March 2018 (UTC)
  • Done. - Jmabel ! talk 23:07, 20 March 2018 (UTC)
  • Thank you people very much for assistance! --ssr (talk) 23:08, 20 March 2018 (UTC)
(All 13 uses, I said? No, only in 12 and not in the Arabic Wikipedia. Why so? Because, unlike all other Wikipedias mostly in languages I likewise do not understand but in which I easily replaced one filename with another, Arabic Wikipedia doesn’t seem to have an option to edit the wiki text of its pages and VisualEditor is mandatory in practice. Since I cannot read Arabic, VE’s interface is not something I can use to replace one image with the other. This is one of the many reasons why VE is a bad idea, and not just merely a good idea poorly developed and implemented.)
-- Tuválkin 01:34, 21 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)
That category that you present is a ridiculous. These kind of categories (village ones) should be delete. We should use only "Country photographs taken on date" categories. --Halavar (talk) 21:56, 19 March 2018 (UTC)
There was a proposal to ban the country / date combinations at Commons:Village pump/Proposals/Archive/2017/02, but it failed (thanks to a bunch of sudden oppose votes by accounts that rarely edit on Commons). There's also a silly duplication at Category:Switzerland by day and Category:Photographs of Switzerland by date. --ghouston (talk) 01:14, 20 March 2018 (UTC)
Intersection categories of all kinds are stupid, and reflect a failure of Commons/WMF to offer some decent software/UI. Databases intersect -- it is what they are good at. People, on the other hand, have short lives and should spend them doing something computers can't. -- Colin (talk) 08:12, 20 March 2018 (UTC)
Now: Category:Romania photographs taken on 2014-12-17 -> Category:Photographs of Romania by date -> Category:Photographs of Romania -> Category:Romania -> Category:Countries by name -> Category:Countries -> Category:Nations Category:Places -> Category:Space -> Category:Dimensions -> Category:Geometry -> (loop) Category:Space -> Category:Places -> Category:Geography ->Category:Earth sciences:
To display all parents click on the "▶":
So, "Romania photographs taken on 2014-12-17" is "Earth sciences"? The same for "Photographs of Switzerland by date":
To display all parents click on the "▶":
--Fractaler (talk) 11:23, 20 March 2018 (UTC)
@Fractaler: Category:Countries was put in Category:Nations by a troll 5+ years ago, since blocked. I have just undone that edit.   — Jeff G. ツ please ping or talk to me 13:18, 20 March 2018 (UTC)
@Jeff G.:, thanks, updated statement --Fractaler (talk) 13:30, 20 March 2018 (UTC)
@Fractaler: Ok, Category:Places -> Category:Topics as it should instead of Category:Space now, and I broke the loop by also taking Category:Geometry out of Category:Space.   — Jeff G. ツ please ping or talk to me 13:54, 20 March 2018 (UTC)
@Jeff G.:, ok, updated! --Fractaler (talk) 14:05, 20 March 2018 (UTC)
@Fractaler: For what it's worth, not every parent category is and is-a relationship, so the "Earth Sciences" issue is kind of bogus. - Jmabel ! talk 14:49, 20 March 2018 (UTC)
@Jmabel: Wikidata, for example, said: country is administrative territorial entity, no "Earth Sciences"Fractaler (talk) 16:57, 20 March 2018 (UTC)
And what is "photography"? For example, "Photographs taken with mobile phones"? Category:Photographs taken with mobile phones -> Category:Photographs by camera -> Category:Photographs -> Category:Photography -> Category:Printed objects. "Photographs taken with mobile phones" is "Printed objects".
To display all parents click on the "▶":

Also (where taxonomy is not respected), for example, 1, 2, 3. Fractaler (talk) 11:13, 22 March 2018 (UTC)

@Fractaler: Not every category child-parent relationship is a direct subset-set relationship. The traditional end product of photography has been printed photographic objects, commonly referred to today as photographs, photos, fotos, prints, pics, and pix, but if you disagree, you are welcome to address the categorization of Category:Photography at Category talk:Photography.   — Jeff G. ツ please ping or talk to me 11:53, 22 March 2018 (UTC)
@Jeff G.:, thanks, I asked there who thinks that "Photographs taken with mobile phones" is "Printed objects". --Fractaler (talk) 12:37, 22 March 2018 (UTC)
Things only have to relate directly to the immediate parent category, not all the way to the source category, in reality things don't always work out so neatly for example File:Land Rover brand bicycle hired in Wexford - - 1294248.jpg shows a Land Rover Branded bicycle, it relates to Category:Land Rover vehicles even though it is not a Category:4×4 automobiles Oxyman (talk) 14:20, 22 March 2018 (UTC)

March 20[edit]

Information about the Wikimedia Foundation global survey starting soon[edit]

14:05, 20 March 2018 (UTC)

What single instructional video would best serve Commons?[edit]

My fellow volunteers,

I am thinking about investing some funds in some professionally-produced short (3 to 10 minutes) training videos. I am very keen on making sure that if I go ahead with it at all, it is to be a useful video, answering a real need in an effective and accurate way. Ideally, the video would be maximally useful across languages, i.e. could be easily dubbed or subtitled without significant changes to content. Also, I'd want the video to teach one thing well, rather than to try to cover multiple topics or techniques.

So I am interested in your thoughts on possible topics for such a video. If you think no such video should be invested in, that's also valuable feedback, and please say so! Asaf (WMF) (talk) 14:05, 20 March 2018 (UTC)

Hi, Nice idea! By far, the single point misunderstood on Commons is copyright. However making a video about that seems quite a challenge... Regards, Yann (talk) 16:30, 20 March 2018 (UTC)

I'll start with one idea I've had:

Option #1: "How to contribute a photo to Wikipedia?"[edit]

Target audience
general public (i.e. non-Wikimedians, copyright newbies)
Describe the process of granting permission for photos via OTRS, but/thereby encourage direct uploads to Commons
Scenario of use
1. someone asks a Wikimedian "how can I contribute a photo without too much effort?"; Wikipedian refers someone to this video. 2. Someone writes to OTRS naively just attaching a photo; OTRS volunteer responds including a link to the video.
Sketch of content
1. rudiments of copyright, including the surprising idea that your physically owning the photo doesn't mean you own the copyright. 2. easiest way if you do own the copyright is to directly upload to Commons. 3. explain granting permission via OTRS e-mail.

Option #2: "How to use Commons content without violating someone's copyright"[edit]

Target audience
general public (i.e. non-Wikimedians, copyright newbies)
Describe the process of starting from a photo (probably in Wikipedia), getting to the rights info, and writing an attribution that conforms to the license. Also explain that it is considered good practice to indicate the origin (insofar as it's known) of PD content.
Scenario of use
1. someone asks a Wikimedian "how can I use a photo in Wikipedia/Commons?"; Wikipedian refers someone to this video. 2. Someone is a lot more likely to reuse the image in a conformant manner.
Sketch of content
1. rudiments of copyright, including the surprising idea that not everything on Wikipedia and Commons is in the public domain, and that crediting Wikipedia or Commons is not enough. 2. easiest way to navigate to license information. 3. explain writing a conformant attribution.
  • option 2 added by Jmabel ! talk 14:56, 20 March 2018 (UTC)

Option #3: "What kind of content is it allowed to upload into Wikimedia Commons?"[edit]

Target audience
potential future users and not experienced users
insist on the notion of what is really "own work", and for why all is not uploadable into Wikimedia Commons, or in what conditions
Scenario of use
automatic opening of the video at the first(s) each upload(s) of a new account or of users not yet autopatrolled (possible??). Or it can be linked in our policies, in various help pages. A link can be given by any users to another users who need to understand the topic. And IMO very important a link should be given with speedy deletions notifications for educational purposes.
Sketch of content
1/ to create a file in Commons is not your necessarily "own work" 2/ what can be called an "own work"? usually a photo that you took, yourself, with a camera, and in no way a photo that you found in the web 3/ why is it important to distinguish "own works" and other works? because it is the base of the protection by copyright laws 4/ quick explanation about copyright protection 5/ if it is your own work then you can give the license of your choice, otherwise we need the permission from the copyright holder (link to a legitimate source with a compatible license or an OTRS permission), or the specific reason for why the work is exempted of copyright protection. 6/ quick explanations about allowed license terms, about OTRS, about public domain 7/ introduction of the "derivative work notion : while a photo of a CD cover is indeed your "own work" the CD cover has its own copyright protection, in the same way that you own your photo 7/ if you are not the photographer and if you do not fully understood the video, then better to ask advice into our help forums or to experienced users.

There are of course things in common with the things stated above Christian Ferrer (talk) 18:26, 20 March 2018 (UTC)

  • Remark: If I have a site start automatically opening videos without my requesting it, unless it's something like Youtube where the video is why I go to that site, I stop using that site. - Jmabel ! talk 20:23, 20 March 2018 (UTC)
This was an idea among others. A good/better idea can be a link in the Upload Wizard at the step "This file is my own work", to put a link to the video with a little sentence in the kind "Make you sure that you understood what means own work".
And if the Option #3 has too many notions, IMO it's important to focus on the concept "own work" and on the fact that everything that is not "own work" can be uploaded only under specific conditions (free licenses at sources, OTRS permission, PD...). And to suggest to the uploader, in case the they are not able to determine if the work don't meet the criteria, to read our various guidelines/policies, or/and to ask in various help pages or discussion pages. And also by making the person aware that when he ticks this box "This file is my own work", in case this is not accurate then it will give us maintenance work and/or it will give potential issues for re-users of the images. In summary this choice "own work" is very important in many ways. Christian Ferrer (talk) 12:00, 21 March 2018 (UTC)
  • Pictogram voting comment.svg Comment #1 is very misleading, Wikimedia Commons isn't the only way to upload images to Wikipedia('s) as several (especially large) Wikipedia's have their own native UploadWizards for fair use images (something which isn't allowed on Wikimedia Commons) and might give users free wrong idea that an illustrative image that belongs in an article can't be uploaded anywhere, it might also give people the wrong impression that their images may/can/will only be used for Wikipedia. Personally I would prefer that an instructional video will also note that images that aren't allowed here usually are allowed with a local language Wikipedia's UploadWizard (if applicable) as a very common problem here on Wikimedia Commons is people uploading fair use images. Any video that properly explains Commons:Scope and Commons:Licensing is welcome, but not one that excludes other possibilities for adding images to Wikipedia articles. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 02:10, 21 March 2018 (UTC)
I do not see how #1 is misleading, and I do not think we should be explaining fair use issues. Too confusing and possibly changing too much. I would make option #1 only about OTRS. So if someone, tells you you need to send permit to OTRS you can point to the video to explain the concept. I like options #2 and #3 as well.--Jarekt (talk) 03:02, 21 March 2018 (UTC)
instruction video is a good idea for editathons. now we tend to say "it's complicated, see us for custom help" would need to be customized by jurisdiction, or US / EU + commonwealth. i would not make it for incorporation in upload wizard. tl;dr will not be listened to. the upload process is so arcane and bitey, we need some video explication. funny, i explain fair use all the time, especially for contemporary art articles. and the 4 factor test does not change, merely the "non-free policy" which seems to ratchet up from time to time. but a video for that would be of lesser interest. Slowking4 § Sander.v.Ginkel's revenge 20:05, 21 March 2018 (UTC)

Option #4: ?[edit]

Discolouration correction[edit]

Morez point manoeuvre.png
This is a typical slide where no colour correction was applied. When I scan my own slides I can easily correct this during the scan. However in photoshop I seem to find the rigth tool, for this.Smiley.toerist (talk) 18:14, 20 March 2018 (UTC)
It’s not a trivial task, but I find Photoshop’s Color Balance and Hue/Saturation adjustments the easiest to experiment with. You can apply separate corrections to highlights, midtones, & shadows (which may or may not correspond to the effective ‘break points’ in a given image). Use Adjustment Layers rather than applying corrections directly, so you can go back and tweak the settings without losing any of the original data, and so you can ‘stack’ different kinds of corrections. Where the fading is uneven, as it often is on prints exposed to sunlight or air, the layers can be given graduated or vignetted masks to vary their strength. Successively more powerful, but trickier to use, are the Levels and Curves adjustments.—Odysseus1479 (talk) 18:42, 20 March 2018 (UTC)

A concern about UK Traffic Signs Content, pursuant to a recent news item on the BBC website[edit]

It has been noted in a BBC News item ( that there was a suspect in an ongoing investigation that had defaced a number of actual road signs, Whilst there is absolutely no evidence to suggest they obtained any material from Wikimedia Commons, a "public safety concern" arises about the potential misuse of traffic sign related material on commons, and thus it seems sensible to have a wider discussion about whether Commons should be actively hosting UK traffic sign related material as extensively as it currently does so. (especially the sub-categories of Category:Traffic_Signs_Manual_(UK) and Category:Working_Drawings_for_Traffic_Signs_in_the_United_Kingdom which provide detailed technical data in PDF/SVG format).

Currently some of the UK traffic signs content on Wikimedia Commons includes this disclaimer:- Traffic signs are Crown copyright. You may reproduce traffic signs free of charge and without having to seek permission, but you must reproduce them accurately and not in a misleading context (e.g. not on roadside billboards where they could mislead drivers). (ref [9])

However this may have not been universally applied to all media in Category:Diagrams_of_road_signs_of_the_United_Kingdom and all the various sub-categories. Would it be possible for someone with a suitable tool to apply this or suitably updated disclaimer across all the relevant media, if a decision is reached to retain it?

ShakespeareFan00 (talk) 21:14, 20 March 2018 (UTC)

In the linked article, it's apparently modification of existing signs, and if the perpetrator was prosecuted I doubt that copyright would be a factor. The disclaimer on certain files (like File:UK traffic sign CW701.svg) is consistent with the statement in the Open Government License that you must "ensure that you do not mislead others or misrepresent the Information or its source;" Files on Commons are supposed to be free for all purposes, but does that include misleading others, about aspects not related to attribution? The extra disclaimer specifically about traffic signs presumably doesn't need to be legally included: the OGL license itself should be sufficient. Simple traffic signs may also be considered public domain. --ghouston (talk) 23:13, 20 March 2018 (UTC)
The English Wikipedia contains sufficient information for a number of nefarious activities. One such article is Gunpowder. I personally regard the illegal manufacture of gunpowder as being more serious than some relatively harmless defacing of road signs. I therefore suggest that User:ShakespeareFan00 does not get over-excited about the traffic-sign issue. Martinvl (talk) 22:41, 21 March 2018 (UTC)

Help identifying this newt, please.[edit]

I took Unidentified newt at Hakone Gardens in Saratoga.jpg, a picture of a newt. There appear to be two very similar kinds of newt that live in this area, the en:California newt and the en:Sierra newt. Is there any way for me to tell which kind this was? Thanks in advance! grendel|khan 23:00, 20 March 2018 (UTC)

Try If it can't be identified, you could put it in Category:Taricha and list the possible species in the description. --ghouston (talk) 23:27, 20 March 2018 (UTC)

March 21[edit]

Adding sites to URL-upload whitelist[edit]

Some Ukrainian government sites used now CC-BY-4.0 licenses. I made request to add them to URL-upload whitelist. But developers asked to discuss here.--Anatoliy (talk) 20:56, 21 March 2018 (UTC)

National Portrait Gallery images[edit]

I'd like to use an 1856 image for the article John Doubleday (restorer), which is on the National Portrait Gallery's website (link). Just wanted to make sure that consensus is that such images are out of copyright? Also, does anyone know of a good way to download the full resolution image? --Usernameunique (talk) 22:26, 21 March 2018 (UTC)

Doubleday was born in 1947. Are you sure that figures "1856" are the year and not some code? If you visit this page, you will see that will have to pay to get a copy of this print (except for a 800 x 900 pixel PNG copy non-commercial purposes). Martinvl (talk) 22:52, 21 March 2018 (UTC)
Whoops, Martinvl, wrong link (now corrected). Linked to John Doubleday, when I meant to link to John Doubleday (restorer), who died in 1856. --Usernameunique (talk) 23:01, 21 March 2018 (UTC)
If one looks closely at the signature/date on the drawing, this looks more like 1846 than 1856 to me. In both cases it is unlikely that Henry Corbould (1787–1844) has drawn this image. Did his son Edward Henry Corbould (1815-1905) sign his drawings with HC? In any case the image is in the public domain. Vysotsky (talk) 09:20, 22 March 2018 (UTC)

Notification of DMCA takedown demand - Interno chiesa bedero valcuvia[edit]

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me. The takedown can be read here.

Affected file(s):

To discuss this DMCA takedown, please go to COM:DMCA#Interno chiesa bedero valcuvia Thank you! Joe Sutherland (WMF) (talk) 23:13, 21 March 2018 (UTC)

It was the only internal photo of Category:Sant'Ilario di Poitiers (Bedero Valcuvia) that we had. Looking at the Flickr page, it had all rights reserved, so the deletion seems to be right, but it's a shame that we don't have any other photos of the interior of that church. Maybe an editor in Mexico could go take one? Thanks. Mike Peel (talk) 23:52, 21 March 2018 (UTC)
Mike, it’s pointless to write this here. Go as stated in Joe’s notification to COM:DMCA#Interno chiesa bedero valcuvia. — Speravir – 03:47, 22 March 2018 (UTC)
@Mike Peel, Speravir: The remaining uploads of Davide9191 (talk · contributions · Move log · block log · uploadsblock user are now subjects of DRs.   — Jeff G. ツ please ping or talk to me 08:36, 22 March 2018 (UTC)

March 22[edit]

March 23[edit]