Commons:Village pump/Proposals

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

Shortcut: COM:VP/P· COM:VPP

  Welcome   Community portal   Help desk
Upload help
  Village pump
copyright • proposals
  Administrators' noticeboard
vandalism • user problems • blocks and protections
Welcome to the Village pump proposals section

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

Commons discussion pages (index)

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


Formatting of image or media descriptions[edit]

There is currently no guideline for the formatting of the descriptions of images (or other media). This includes the formatting of the Description field of the Information template.

Some editors (e.g., User:Look2See1) have been editing image descriptions, adding bold face (to show the main topic), bullet lists (to separate topics), and emdashes. Other editors have objected (see, e.g., User talk:Look2See1/Archive_1), saying that the formatting decreases readability. This controversy has been occurring since at least 2013, resulting in slow edit-warring.

I believe that the community should come to a consensus on a style guideline for image descriptions, to settle this controversy. Let me start with a proposal, then let's discuss and see if it needs modification. If we come to a consensus, Commons can adopt the proposal as a style guideline. — hike395 (talk) 17:58, 18 February 2015 (UTC)


Descriptions of media files should be prose that describes the file, including the contents, location, or historical background of the file. The formatting of the description should be minimal: font styling (e.g., bold face or italics) should be avoided. The description can span multiple paragraphs, but paragraph formatting (such as bullet lists) should be avoided. The description should contain complete sentences, or clauses separated by commas. Informal language or formatting, including the use of em-dashes or ellipses, should be avoided.

The use of internal links to Commons (to galleries or categories) is encouraged, to assist in readers finding relevant media. Internal links to Commons are preferred to links to Wikipedia.

The use of the {{Information}} template to describe media is encouraged for uniformity.


What do other editors think? — hike395 (talk) 17:58, 18 February 2015 (UTC)

  • Symbol oppose vote.svg Oppose the proposal, since each file is different and requires different style formatting, and I do not think there is a single style that works for most works. However in the example image File:Old senate debate.jpg I do Symbol keep vote.svg Agree that user:Look2See1 changes to that file decrease readability. Using proper Infobox templates (in this case {{Artwork}}) often helps avoiding this kind of disputes by decreasing the amount of information in each individual field. --Jarekt (talk) 18:59, 18 February 2015 (UTC)
Pictogram voting question.svg Question Without a simple consensus guideline, how do we get editors to avoid changing description formatting to suit their own taste? The lack of a guideline results in slow-motion edit wars. As you can see from User talk:Look2See1/Archive_1 and User talk:Look2See1#Graphic design questions….ongoing, formatting disputes have been festering for years, without resolution. It's easy enough to say "there can't be a general-enough guideline", but we have to realize the cost of no guidelines is a lack of harmonious editing.
This is not a rhetorical question: I am open to any mechanism to settle the long-running dispute. I just thought a short consensus-based style guideline is the most helpful way of doing it. — hike395 (talk) 19:29, 18 February 2015 (UTC)
Simply respect the uploader's choice … ? I'd Symbol oppose vote.svg oppose any general guidelines that go beyond "use a metadata-compatible info template" (and probably which sections to use).    FDMS  4    19:47, 18 February 2015 (UTC)
I am not a big fan of "uploader's choice" since it is counter to COM:OWN and at least in case of PD files who is the uploader should not matter. Disagreements about format of file pages are not different than disagreements about content or format of wikipedia articles. They should be discussed on the talk page of the file, in order to reach consensus. If there are only 2 voices (the usual state) than you can ask VP or other forum for additional opinions. By the way, the disagreement about File:Old senate debate.jpg seems especially pointless since the file is a scaled down duplicate of a different file and should be deleted. --Jarekt (talk) 18:19, 19 February 2015 (UTC)
Does respecting an uploader's choice mean we should not change an uploader's description? I think adding wikilinks from words in the description to Commons galleries adds value to the project. When adding {{Information}} templates, I often rearrange descriptions added by uploaders. — hike395 (talk) 20:06, 18 February 2015 (UTC)
Only when such changes might be controversial. I don't know all (or rather any of) the details of this Look2See1 case, but if he/she changed descriptions of files he/she didn't upload and there are reasonable objections, this should be revertable without much further discussion in my opinion.    FDMS  4    21:20, 18 February 2015 (UTC)
There was this draft User:Rillke/Technical file description policy by @Rillke: about this. Jean-Fred (talk) 19:55, 18 February 2015 (UTC)
Pictogram voting comment.svg Comment, I like {{information}} and many of its helper templates, e.g., the SVG zoo now mostly down to {{igen}} + {{vva}}, or the date zoo now mostly down to one esoteric scribunto module promising to be complex, or simple stuff like {{extracted from}}, license tags, derivatives, the works. I hate artwork variants, they are far too complex. So in essence dunno, but if you plan to add an "official guideline" tag on COM:MRD count me as "support". –Be..anyone (talk) 21:08, 18 February 2015 (UTC)
  • Symbol neutral vote.svg Neutral on the proposal - one of the reasons I like Wikimedia Commons is our reluctance to bog ourselves down in policies and guidelines, and I have some reluctance to adopt a guideline which might make it more difficult (primarily for novices) to upload media or create categories. Perhaps something much simpler ("Unnecessary formatting and punctuation should be avoided.")? Having said that, I Symbol keep vote.svg Agree that the formatting that user:Look2See1 typically adds to category and file descriptions decrease readability and are unnecessary, esp when (s)he breaks down simple paragraphs into bullets (but there is no need for a bullet list). Or the unecessary emdashes -- such as this recent example when he felt the simple description "Baroque Revival style churches in the United States" at Category:Neo-baroque churches in the United States needed a dash in the middle of that basic sentence ("Baroque Revival style churches — in the United States"). Look2See1 feels that the bullets and dashes are easier on his eyes, but it's a nightmare for everyone else, and on a multilingual project there is no need to be weighing down simple English-language prose with unnecessary formatting and punctuation. Dozens of editors have tried to discuss this issue with Look2See1 over the last 2-3 years, and it's like talking to a wall. (S)he otherwise seems like a pleasant person and a capable editor ((s)he seems to have largely stopped his/her past compulsion to COM:OVERCAT), so this problem is unfortunate. --Skeezix1000 (talk) 22:02, 18 February 2015 (UTC)
  • Pictogram voting comment.svg Comment concerning italics: Please note that italics are compulsory in certain cases such as for binomial names or prefixes in chemical nomenclature. --Leyo 23:05, 18 February 2015 (UTC)
  • Symbol oppose vote.svg Oppose the proposal, although I definitely support its goals; it has good purposes, but its blanket standard would be unhelpful when many of our 24M+ files need different types of descriptions. Bold and italics are occasionally useful (see Leyo's comment), and the bulleted list at File:Jefferson Street in downtown Huntington.jpg is easier to read than prose would be. This is significantly different from turning sentences into bullets. When we have a perennially problematic user who attracts tons of opposition and ignores or attacks those who question his edits, the solution is not to create a guideline for everyone that ignores exceptional needs. The solution is to treat it like disruptive editing on en:wp, warning and then following up with blocks and bans if the warnings are ignored. Nyttend (talk) 01:01, 20 February 2015 (UTC)
  • Pictogram voting comment.svg Comment Nothing against guides and help, but more carrots, fewer sticks please. Having uploaded a lot of files, my position now is that I prefer to avoid customizing templates or text unless I do not know of an alternative.
I am guilty of "deviation", some of my Flickr batch uploads have restricted status and multiple tags as well as album names; I use a custom field to stick these in as no standard template has something that formats them in a sensible way.
By "more carrots" I have in mind:
  • better guidelines for more experience uploaders, well crafted videos would be useful to show best practice
  • more barnstars and ways of thanking those for doing a nice job on upload formatting. FP/QI and so forth is nice, but these rarely get applied to images from old archives
  • just as we have 'grades' of language proficiency, maybe we can consider a ladder of grades for those that demonstrate better application of best practices. Much nicer than threats to block and ban those that deviate from the "norm". I'm actually getting very tired of seeing policing (and criminalization) becoming the first reaction rather than collegiate working
-- (talk) 01:20, 20 February 2015 (UTC)
  • Pictogram voting comment.svg Comment I do not think a complex codification of file descriptions is necessary. I do think however that:
  • File descriptions should be straightforward, informative, well-written, and easy to read
  • They should avoid unnecessary formatting such as bullets and dashes which break up the flow of text
  • The choices made by the original uploader, especially if they are also the author of the image, should be respected
  • Changes should not be made in file descriptions unless they are clearly necessary, for instance, to add pertinent information or correct bad information
Those four statements could serve as a simple guideline if we need one. Beyond My Ken (talk) 18:08, 20 February 2015 (UTC)

It's clear that my proposal has no support and I withdraw it. However, I do like BMK's lighter-touch guidelines, above. Do other editors think his version is acceptable? — hike395 (talk) 07:30, 21 February 2015 (UTC)

, please note that lots of people have spent years attempting to work collegiately with Look2See1, but he simply doesn't care. He's proven that nothing will stop him except for blocks and bans. Meanwhile, I agree with BMK. A file description should explain what we see, noting the significant elements, and especially explaining the reason for every category that isn't necessarily obvious. This is why I'll provide a bulleted list on the occasions when I categorise for buildings' construction years. However, it needs to be useful and easy to read, written in prose unless there's a good reason to do otherwise. And definitely listen to the preferences of the uploader, especially if he asks you to stop. I know one regular user (an admin, if I remember rightly) who uses "own work by USERNAME" instead of {{own}}, and although I started replacing them with {{own}}, I stopped when he encouraged me to stop. Why can't others do likewise? Of course, expanding the description is often helpful — even when an original description is good, uploaders often aren't aware of something in the picture, and someone reusing it can often add more details. For example, when I find a photo of a neighborhood that has a US federal historic designation, I often add a note about the designation. Of course, lots of descriptions need significant improvements; sometime I ought to copy the descriptions from File:Holy Trinity Catholic Church, Beaver Falls.jpg and File:St. Mary's Catholic Church, Beaver Falls.jpg into File:Beaver Falls, Pennsylvania (8480753956).jpg and File:Beaver Falls, Pennsylvania (8480754482).jpg, respectively. Nyttend (talk) 03:19, 22 February 2015 (UTC)
I agree with the spirit, but not the content, of BMK's suggestions. While we should avoid unnecessary formatting, bullets and dashes do occasionally have their place (the problem is users like Look2See1, who scatter dashes, bullets and bold text in every sentence and paragraph like sprinkles on a cupcake). While there are many times where the choices of the uploader should be given some deference, all files uploaded here are freely-licensed, part of the project, and subject to our practices and rules about categorization, etc. This is a collaborative project, nobody "owns" any of the files, and the uploader has no veto over the input of others. This is Wikimedia Commons, not Flickr. And I just think a "clearly necessary" rule for changes to descriptions is, ironically, completely unnecessary given the nature of this project (although, admittedly and to be fair to BMK, very tempting on occasion). Ultimately, changes are decided on the basis of COM:AGF and consensus. In reality and practice, however, most people try hard to work with the uploader. We don't need to translate any of that into rules.

I agree with Nyttend's comments (esp. his examples of proper use of bullets, and his description of trying to work with Look2See1), but am puzzled by his "own work by USERNAME" example. Did he provide a rationale? The benefit of {{own}} on a multilingual project is that it automatically translates to the user's preferred language, while English-language text does not. Maybe a hybrid of "own work by USERNAME"/{{own}} might have worked. --Skeezix1000 (talk) 21:49, 24 February 2015 (UTC)

Of course Skeezix1000 is correct that no one "owns" their uploads or the descriptions written by the uploader, that goes without saying, but there is a strong feeling of stewardship when one takes a photo, or discovers one through research, prepares it for upload, researches the history or circumstances and molds that information into a coherent and cogent description. That's why I suggested that these choices should be "respected", not held sacrosanct or inviolable.

I've used bullet points on my image descriptions at times -- for instance when the image portrays multiple buildings, and I want to provide information on each of them in a separate bullet -- so I would never say that they should be outlawed, just that if there's no distinct improvement to be had by altering the existing form of the description, then there's no real reason to do it.

In the instances that brought this about, the editor making the change simply replaced the uploader's format with his own preferred format, with no particular improvement and, in fact, a degradation of the readability of the description. For me, that's a three-strikes and you're out action: no respect for the uploader's choices, substitution of the altering editor's personal preference without good reason, and a lessening of the description's quality. It would be nice if one could point to a simple rule and say "Don't do that", but I see no need for a complex bureaucratic code. Beyond My Ken (talk) 01:59, 25 February 2015 (UTC)

I would agree that the use of 'localization' templates such as {{own}}, {{size}}, and {{oil on canvas}}, as random examples, is rather different from changing the wording of a description or simply adding formatting such as bullet points. Such edits are quite useful given that this is a multilingual project. Revent (talk) 23:18, 24 February 2015 (UTC)
Again a decisive dunno, if an image has no {{information}} I feel entitled to fix this, and trim unnecessary description essays + copyright considerations in prose to a minimum, as much of it as possible with the i18n templates like {{own}}. But {{own}} is hopeless if there are two or more uploaders. Very extreme example some hours ago, this is not how I ever did it before or plan to do it again soon: old vs. new. –Be..anyone (talk) 19:20, 1 March 2015 (UTC)
@Be..anyone: I think templates that are intentionally designed to make the file's metadata machine readable (like, specifically, {{information}} and it's variants) are a rather different issue. Among other things, everyone's favorite thing (Media Viewer) </sarcasm> is broken by the lack of an information template (or a 'real' license tag, for that matter). As far as that example, nice job (but ouch). Revent (talk) 22:17, 28 March 2015 (UTC)
  • @Hike395: I don't think there was any consensus generally for trying to translate current practices into a guideline, even a loose one, but I think the one consistent message from this discussion is that the Look2See1 formatting which concerned you is inappropriate, and contributors can point to this discussion (I see that you alerted Look2See1 of this discussion at the beginning, but (s)he chose not to participate) when they are removing such extraneous formatting. --Skeezix1000 (talk) 18:05, 3 March 2015 (UTC)

Use javascript to make a more suitable advanced search[edit]

The advanced search feature, isn't very advanced. Have we considered using javascript to add more advanced options specificly suited to commons? Our options are limitted somewhat due to what Cirrus supports (Perhaps this will change. Probably there are many features which would be useful here which aren't much effort. Making OR queries work would be really helpful here, and doesn't sound like that big a thing. Of course the big feature is transitive category search, which is probably not happening in Cirrus anytime soon. Maybe someone could make an extra tab on search specificly for category intersection which runs the query through FastCCI...).

To be concrete, I made a prototype (which may or may not follow commons coding conventions, if commons has coding conventions). To try it out, add importScript( 'User:Bawolff/search.js' ); to Special:MyPage/common.js. It adds fields to so that you can specify to search only in categories, exclude things from certain categories, search by filetype (Sort of, it only checks that the extension is anywhere in the title, might have false positives), and limit to either PD or CC licenses. Obviously this still isn't very flexible, but I think its an improvement over just showing the one box.

Thoughts? Bawolff (talk) 22:17, 3 March 2015 (UTC)

I just added it to my common.js. If it is buggy, I’ll nag you. Face-wink.svg -- Tuválkin 02:28, 4 March 2015 (UTC)
(Pinging Bawolff…) Well, actually, it seems to wipe the search box after a queary, at least when the previous search (from which the search term is expected to be inherited from) is done through the basic interface searchbox (in Monobook), or through a "search this" link in a redlink page. Only happens to me? -- Tuválkin 08:48, 10 March 2015 (UTC)
@Bawolff: Nice. Please let me know when the script is stable, so that i can implement it as a gadget. --Steinsplitter (talk) 08:59, 10 March 2015 (UTC)
@Tuvalkin: That should be fixed now. @Steinsplitter: Its stable now. I don't plan to add anything else unless changes happen in cirrus allowing more specific queries. Bawolff (talk) 20:00, 10 March 2015 (UTC)
This script is now ✓ implented as a gadget. Opt-in here: Special:Preferences#mw-prefsection-gadgets --Steinsplitter (talk) 19:42, 28 March 2015 (UTC)

Clarify blocking policy?[edit]

Recently, a dispute about a block was closed. The particular discussion had two themes, which led to differences in opinions of those participating in the discussion and some drama. I do not think we should discuss the specific case, but it highlight for me some unclear things in our current blocking policy. It think we should consider if a clarification would be relevant.

  1. Is it OK that a blocking admin has had prior controversies with the blocked user. The question of being involved and the threshold for being involved?
    • The current blocking policy does not mention anything about precautions to be taken if the admin is involved. The discussion linked to above indicates that users and admins have different opinions on whether it is OK or not to be involved, and to which extent it is OK to be involved. Some users refer to en:WP:INVOLVED, but that is not really a policy on Commons. I think it would be helpful to settle in the blocking policy, to which extent if any, involvement should be allowed.
  2. Shall a warning be formally issued first on the user talk page, for edits which are deemed disruptive or not?
    • The current policy says "For blocks based on disruptive behaviour, such as vandalism, repeated copyright violations and manual promotional activities, ensure that the user has been appropriately warned, preferably (emphasis mine) using a block warning template."
    • Note the word preferably. This is a loophole and it leads to controversies such as above. As there may be differences in opinion between the user being blocked and the blocking admin as to whether a warning has been issued (in cases where a warning template has not been used) this leads to drama in some cases. Is there a special reason for having the loophole? Why not alwsy require a warning template for these kinds of disruptions to avoid any doubt and misunderstandings that you are close to being blocked?

I would like to hear the opinion from the community on this matter.

Let me begin by proposing some different view points. Feel free to alter and add, and add you comments underneath. Please do not vote! Let us try to establish consensus.

On being involved[edit]

  • The policy is fine as is. We do not want to be too specific on this in the policy but make case-by-case judgements
    • I think a clarification is needed to avoid future controversies. -- Slaunger (talk) 21:58, 9 March 2015 (UTC)
    • I agree with Slaunger. Case-by-case judgments, for matters that can be covered in policy, invite continued disruption. There is a misunderstanding about policy; policy is merely strong guideline, and guidelines are designed to avoid confusion. That does not change the fact that some situation may require something different from policy and guidelines, and an administrator is not "wrong" because they "violated" a policy. However, at least, we would expect administrators to understand policy and to act with caution when setting it aside. Policy and guidelines are properly written and approved by the community to cover common situations. They should be written in consideration of actual practice, but actual practice may include actions that the community will reject if they are considered, so actual practice is an element in writing policy and guidelines, but not the only consideration. --Abd (talk) 23:08, 19 March 2015 (UTC)
  • It is OK to have had previous controversies as long as the blocking admin finds there is no conflict of interest and emotional strings attached to the block
    • Not OK in my opinion. Even if the blocking admin finds there is no conflict of interest it will likely lead to claims that the block is done in vengeance and because there is a conflict of interest. -- Slaunger (talk) 21:58, 9 March 2015 (UTC)
    • Again, Slaunger is expressing the general wiki opinion on this, with which I agree. It is important for administrators to avoid, not only actual conflict of interest, but also the appearance of COI (conflict of interest). Consider: if you are blocked by an admin you have been arguing with, what does it look like? The dispute can easily become personalized, and personalized disputes can become intractable. --Abd (talk) 23:08, 19 March 2015 (UTC)
  • If there has been or is current controversy between the blocking admin and the blocked user, it is not acceptable to block. An uninvolved admin should always be consulted first. Also if the blocking admin finds the block is uncontroversial and has no grievances towards the user due to past incidents. The objective is to remove any doubt that there could be a conflict of interest.
    • Yes, I think it would be a good idea. -- Slaunger (talk) 22:03, 9 March 2015 (UTC)
    • This can be simple. If an admin issues a warning to a user, being uninvolved, the admin does not have a COI merely because the user then argues with the admin. The admin should not block because the user argues (that would be using tools to "win" an argument). Rather, the admin may block for the offense which was the subject of the warning, if it continues. Admins should avoid arguing with users over warnings. "You've been warned, if you disagree, consult the community. Thanks." However, having blocked a user, the admin should probably avoid blocking the same user again, absent emergency, and emergency blocks should always be short, pending consultation with the community. As well, an admin with a COI, seeing an emergency -- actual harm arising that requires immediate action -- may short-block and immediately consult the community on a noticeboard. Again, this is all common sense. It is better, if possible, to be very careful about declaring an emergency. The real point is to avoid the appearance that a problem a user is having is about the "abusive administrator" and not a problem with the community. So the responsibility should be spread out, with independent decisions being made. Once involved, an admin should request admin attention the same as any other user (and, my opinion, it should not be done privately, that then comes to be or to look like back-scratching.)
  • We should adopt en:WP:INVOLVED as a Commons policy to remove the current ambiguitiy in the blocking policy.
    • It looks pretty well-developed and adequate for me. It sets for me a reasonable threshold for being involved. As a minimum I think it would be a good starting point for an adoption of a similarly spirited policy on Commons. -- Slaunger (talk) 22:03, 9 March 2015 (UTC)
    • Not bad, adding one statement in this direction to the otherwise okay COM:BP could be useful. –Be..anyone (talk) 02:46, 10 March 2015 (UTC)
    • It's a reasonable starting point. There are two sides to this issue to consider: the practical needs of administrators, and protecting the community from administration that is either abusive in some way or which can appear so, thus creating long term disruption. Where I would disagree with the Wikipedia policy is that it seems to approve of COI blocking if "any reasonable administrator would have probably come to the same conclusion." As a result of lack of sensitivity to the effect that this has on users, many long-term conflicts have been created on Wikipedia where the user is convinced that the problem is due to the bias of Administrator X. And, then, his cronies. The WP policy suggests that it would be "better" to take a matter to a "relevant noticeboard." Wikipedia can be very inconsistent on this. --Abd (talk) 23:08, 19 March 2015 (UTC)
  • Being involved should be considered more generally in an admin policy. The blocking policy is just a special case, where it is particularly important not to be involved.
    • Maybe yes. Is it correct, that being involved is not mentioned anywhere in admin policies today? -- Slaunger (talk) 22:03, 9 March 2015 (UTC)
    • Deletions can also involve an admin POV and possible bias. An admin arguing in a DR and then closing it for his argued position would be an example. If the admin closes contrary to his argument, based on consensus and arguments presented, that's fine.
    • I have never seen an administrator sanctioned for failure to act. When it happens, it is always for some action that was perceived as involved or somehow seriously wrong. And the admin often didn't see that, they believed they were right, and continued to argue they were right. So they needed better guidance. This is not about "bad administrators." --Abd (talk) 23:08, 19 March 2015 (UTC)

How to issue warnings[edit]

  • The current wording of preferably a warning template prior to a block for disruptive editing is just fine. There are exceptions to any rule, and we do not want to make things more specific than what is needed. Users for sure know if they have been warned, elsewhere or on their talk page.
    • No, preferably is too ambiguous. Leads to too many cases of controversy and drama. -- Slaunger (talk) 22:04, 9 March 2015 (UTC)
      IBTD, "ensure that the user has been appropriately warned" is perfectly clear in COM:BP. –Be..anyone (talk) 02:49, 10 March 2015 (UTC)
      Be..anyone: Sorry, what does IBTD mean? On second thought, I do not think it is preferably which is the problem, but the ambiguity in how to interprete what 'appropriately warned' means. In the closed thread referred to above the blocking admin was of the opinion that since more or less direct warnings had been given already on other pages than the users talk page that was enough. Whereas the blocked user had the expectation of being warned first on his user talk page. Actually, I would expect the latter too, and I guess a better clarification would be "ensure that the user has been appropriately warned on the users talk page". -- Slaunger (talk) 20:03, 10 March 2015 (UTC)
      IBTD: Disagree or differ, I have a thing with old FidoNet or Usenet jargon…Classic smiley.svgBe..anyone (talk) 04:02, 15 March 2015 (UTC)
  • preferably should be deleted. A user facing a block due to disruptive editing shall always be warned first with a proper warning template on his user page to avoid any ambiguitiy in the users understanding of whether he has been properly warned or not. It may also stop the disruption in a more constructive manner than actually blocking them.
    • Yes, I believe this would be the most civil thing to do. -- Slaunger (talk) 22:05, 9 March 2015 (UTC)
      • Striked my comment above, because as pointed out by King of Hearts and Jmabel it is not important if a template has been used or not to warn the user. -- Slaunger (talk) 20:09, 10 March 2015 (UTC)
  • We should loosen more up, and change the wording to optionally. We do not always have time to first issue a warning, wait for more disruption to be reverted and then block.
    • I think this would make things worse as compared to now. -- Slaunger (talk) 22:05, 9 March 2015 (UTC) -- Slaunger (talk) 21:56, 9 March 2015 (UTC)
  • I think that a warning that indicates the user will be blocked if the behavior continues should be required. Let's keep the "preferably" in there, since it refers specifically to block warning templates which may not be the best tool for every situation, but emphasize the fact that the warning must contain a reminder that a block is imminent. -- King of ♠ 05:11, 10 March 2015 (UTC)
  • I think it is necessary that the user has been warned about a possible block, but not that a template has been used. - Jmabel ! talk 16:51, 10 March 2015 (UTC)
  • I could give countless reasons why, as a guideline to be generally followed, and before blocking, (1) a warning should be issued by a neutral party, preferably an administrator, and (2) the warning should be on the user's talk page. Briefly, though, warnings issued by someone involved in a conflict with the user are often rejected as biased and incorrect (even when they aren't), and users may not see what is placed elsewhere; further, anyone reviewing the block won't necessarily see a warning somewhere else. If a neutral warning by an admin doesn't do the trick, it's quick to block (and needs no further explanation beyond "ignored warning.")! An alternative is a short block with the explanation, if there is serious ongoing disruption, so this is why it is not *always.* An indef block of a possibly good faith account without warning is offensive, but, again, there can be reasons, such as blatant spamming, gross vandalism, etc. Templates are not required but may be used, if the application is clear.
  • On Wikiversity, we often don't warn disruptive IP users, if the disruption is blatant and any rational person would know this. We are now working on a MediaWiki block message that explains, in detail, how to handle being blocked, for IP users. --Abd (talk) 17:13, 10 March 2015 (UTC)
  • After considering the comments above. How about clarifying that the warning shall be done on the user's talk page. That is:
Current forumation
For blocks based on disruptive behaviour, such as vandalism, repeated copyright violations and manual promotional activities, ensure that the user has been appropriately warned, preferably using a block warning template.
Proposed new formulation
For blocks based on disruptive behaviour, such as vandalism, repeated copyright violations and manual promotional activities, ensure that the user has been appropriately warned on the user's talk page, preferably using a block warning template.

-- Slaunger (talk) 20:17, 10 March 2015 (UTC)

    • I'd have no problem with that. - Jmabel ! talk 20:35, 10 March 2015 (UTC)

Add one (or two) optional parameters to Template:Duplicate[edit]

These files are duplicates:

  1. File:US Navy 110211-N-NK458-047 ulinary Specialist 2nd Class Tad Pooler prepares strawberries flambe as his dessert entry during the Best of the Mess Ch.jpg
  2. File:Flickr - Official U.S. Navy Imagery - Navy chef takes part in culinary competition..jpg

I chose to mark #1 (File:US Navy) as the duplicate that should be deleted, since the Flickr version has extra metadata ("Image title"):

110211-N-NK458-047 VIRGINIA BEACH, Va. (Feb. 11, 2011) Culinary Specialist 2nd Class Tad Pooler, assigned to Commander, Submarine Forces, prepares strawberries flambe as his dessert entry during the Best of the Mess Challenge competition at the Virginia Beach Sheraton Oceanfront hotel. The Commander, Submarine Force Atlantic culinary team competed against four other commands showcasing their culinary specialties. (U.S. Navy photo by Mass Communication Specialist 1st Class Todd A. Schaffer/Released)

But what I wanted to recommend was that the surviving file be renamed to:

I suggest an optional parameter to make this possible. You could add one new optional parameter, which could used to add a comment to cover this w:use case, or you could add a new optional parameter that would contain only the new target file name.

Or you could add two new optional parameters, covering both comments and new target file name. 01:27, 11 March 2015 (UTC)

Just pick which problem you want to solve first, and decide the second step depending on the outcome of your first step. Combining two not necessarily related steps into one new combined procedure could be messy, if one of your two suggestions is contested. This sounds like "non-admin close as delete", a brilliant idea unless it fails. –Be..anyone (talk) 03:57, 15 March 2015 (UTC)

Give admins the power to speedy delete without discussion[edit]

Given the rubbish and the out of scope stuff that is continually flooding Commons I would like admins to have the ability to speedily delete files on sight. At present a situation often arises[citation needed] where admins (or plain old editors) put files up for deletion, there is no discussion, and another admin then closes the DR and deletes the file.

File uploading is increasing, the number of active editors is flattening off, we cannot assume good faith, and the backlog is not going away. Lets save ourselve some wiki-time here and put our trust in admins to delete files straight away. I think admins can check up on others admins deleted files, and the uploader can kick up a stink if their files are summarily deleted. Alan Liefting (talk) 18:53, 14 March 2015 (UTC)

Symbol oppose vote.svg Oppose BTW, some of your DRs are abusive. Regards, Yann (talk) 19:00, 14 March 2015 (UTC)
Why do you oppose the idea? And why do you say some of my DRs are abusive? Alan Liefting (talk) 19:02, 14 March 2015 (UTC)
Do you read your talk page? Yann (talk) 19:16, 14 March 2015 (UTC)
Yes of course I read my talk page. I sorry, am I missing something here? You will have to spell it out to me. Alan Liefting (talk) 19:21, 14 March 2015 (UTC)
I have just had a look at some a my DRs and I see nothing wrong with the wording. Either I cannot see my own abuse or you and I have a different concept of what abuse actually is. Can you give any examples of this abuse in my DRs? Alan Liefting (talk) 19:10, 14 March 2015 (UTC)
Symbol oppose vote.svg Oppose we have COM:CSD, no need for a extra policy. --Steinsplitter (talk) 19:15, 14 March 2015 (UTC)
Symbol oppose vote.svg Oppose One of the concepts behind structuring rights is to ensure that systems of governance are conceptually valid against the aim of maximizing transparency and confidence by the community in the outcome. Deletions need to have two pairs of eyes as a default. Of course some stuff does get quietly removed, but this should be minimized and done for extremely good reason which should itself be able to survive scrutiny. -- (talk) 19:29, 14 March 2015 (UTC)
Symbol oppose vote.svg Oppose, per Steinsplitter and . -- Tuválkin 20:55, 14 March 2015 (UTC)
Symbol oppose vote.svg Oppose Fæ is correct. This is basic wiki process. I've seen what happens on small wikis where admins delete on sight. It can get ugly; the community can have great difficulty supervising the process. "Cleanup" becomes the goal, and one person's important contribution is another's ugly mess. Hence a basic and simple and efficient process: one person tags for speedy deletion, any user may remove the tag (rules vary on this) and an administrator approves -- or removes the tag. In my view, absent emergencies, any user in good standing should be able to protest a speedy deletion, and the file should then be undeleted and if anyone still wants to delete, then there is a deletion discussion. A "user in good standing" who frivolously and frequently protests deletions won't be "in good standing" long. On en.Wikiversity, administrators do not unilaterally delete except sometimes for obvious spam and vandal pages; rather, they tag like anyone else, and another administrator does the deed. Users are encouraged to help by tagging files, for it is finding and identifying the material to delete that is the hard part of the job, and the second hardest part is notifying the user. Pushing the delete button is quick. It takes a community. --Abd (talk) 00:41, 15 March 2015 (UTC)
The suggestion here seems to come from a misunderstanding. If something is obviously speedy-deletable, filing a Deletion Request is inappropriate. The page should be tagged for speedy. Only if there is protest should the page go to DR. --Abd (talk) 00:41, 15 March 2015 (UTC)
Symbol oppose vote.svg Oppose, the general idea is to always have four eyes, e.g., reviewers can review as they like, but not their own uploads. There might be reasons to ignore all rules, but typically admins can't pull IAR when they use elevated rights outside of SNOW, or in other words, that suggestion tries to solve a non-existing problem. –Be..anyone (talk) 03:45, 15 March 2015 (UTC)
Symbol oppose vote.svg Oppose: The current system, by having a en:two pass verification, offers safeguards against unilateral action that may be against policy. If the nominator can also delete a file, how can non-admins know that the reason for nominating was correct in the first place? At least now we have diffused responsibility across two editors (one being an admin), which increases accountability and reduces the margin of error for files being wrongly deleted. ColonialGrid (talk) 04:18, 15 March 2015 (UTC)
Symbol oppose vote.svg Oppose Per Fae and Abd. --Discasto talk | contr. | analysis 10:23, 16 March 2015 (UTC)

"Paradigm images" proposal[edit]

The community has recently reiterated that ambiguous or generic names for images are problematic. Any editor can upload a file to any available name, and generic file names therefore tend to be either unoccupied (see "File:Cat.jpg", "File:Dog.jpg", "File:Person.jpg"), or occupied by images that are poor-quality or not particularly representative for the term in question (see "File:Drum.jpg", and "File:River.jpg"; having recently had this image moved to its current title from "File:Guitar.jpg", I realize that as soon as I post this, some editors will want to move the images for the currently-occupied titles; if so please note that here). Files may also be technically accurate, but still surprising to the reader (see, e.g., File:Human.jpg, which was surprising to me). Furthermore, when a file with a generic name is moved, the file name then becomes available for the next editor who wants to upload any image they want under that name, unless the file name itself is somehow salted or protected against re-use.

I therefore propose the creation of a process to have the community nominate high-quality images that editors believe represent the paradigm case of the generic term. For example, rather than having File:Cat.jpg point to a placeholder, and have the current dull content at File:River.jpg, editors would comb through our thousands and thousands of pictures of cats and rivers, respectively and nominate the images that they felt would be the single best picture of a cat to have at File:Cat.jpg, and the best picture of a river to have at File:River.jpg. A community selection process would then take place in a manner much like the selections for our monthly Commons:Photo challenge contests, except that the goal would be to select the most paradigmatic high-quality image for each term, to be the image to be hosted at that basic title. This selection would then be moved to that title and memorialized with a template indicating its status as the community consensus selection for "Cat" or "River". An option would also exist for there to be a consensus that there is no paradigmatic image in Commons for a particular topic, in which case the image would remain blank, but not for lack of trying.

I realize that there are potential pitfalls with, for example, false friends from different languages, like "cat" in French being "chat" (see File:Chat.jpg and File:Chat.JPG), but I think that overall this would nonetheless be the best solution to an otherwise unsolvable situation. Cheers! BD2412 T 19:41, 19 March 2015 (UTC)

  • Symbol neutral vote.svg very weak oppose I´m fascinated by the idea because it would lead to a visual dictionary as a by-product and because it would be fun for the community to search for the "ideal picture". But (perhaps contrary to the community consensus you mentioned) I prefer file renaming being kept to a minimum for workload and technical reasons. And I fear there is potential for unnecessary conflict because there seem to be very few concepts that are really generic if it comes to visuals. River and dog might work but with cow you already run into cultural issues: For me, "the" cow has brown chequers, for my girlfriend it has black chequers (we come from different parts of Germany and farmers are very traditional about regional cow color). Or think about farm houses. Would Farmhouse.jpg rather belong to this, this or that image? So: If you decide to make a gallery of one or several paradigmatic images, I´ll be happy to contribute. But I wouldn´t mix this with file renamings. --Rudolph Buch (talk) 21:59, 19 March 2015 (UTC)
    That is an interesting objection. Perhaps it could be mooted by first having a community process to determine which common nouns are the best candidates for having a paradigm image at all. If "cow" and "farmhouse" are problematic, then they will be pushed down the list in favor of topics for which everyone can agree that a single paradigm image can be used. BD2412 T 22:09, 19 March 2015 (UTC)
  • I think you are trying to reinvent the Valued images project. ;oD Regards, Yann (talk) 22:23, 19 March 2015 (UTC)
    Thanks, that is an interesting comparison. Looking at that project, it's about the images, not their titles. For example, the "valued images" example for a tidepool is File:Porto Covo February 2009-2.jpg, which in my opinion is quite frankly a much better illustration of a tidepool than either File:Tidepool.jpg or File:Tidepool.JPG. Another option would be to move the existing tidepool pictures at those titles to more location-descriptive titles, and then redirect their current titles to the better image (so that the reader would find it at the simpler search term without sacrificing the descriptiveness of the current title). BD2412 T 22:51, 19 March 2015 (UTC)
There is a generic problem with file renaming, it can mess with incoming links. Suppose someone has used an image, and credits Commons for it, with a link. Where does that link go? Suppose the image is in use on a project. This one can and should be checked before moving any page. As long as the link is not positively misleading, it should probably stay the same. It is categorization that helps users find images, much more than the filename, which is often obscure. On Commons, filenames are not important, usually. --Abd (talk) 23:13, 19 March 2015 (UTC)
  • I would say that this is a problem with all renaming situations. That could also be addressed by redirecting the existing generic titles to the existing paradigm image title, since we are going to be moving poor-quality images away from generic titles whether this proposal goes through or not. BD2412 T 00:43, 20 March 2015 (UTC)
  • Pictogram voting comment.svg Comment In my opinion, no images should be at those common names. Instead, put a placeholder and point the reader to the appropriate category where they can find hundreds of great images. So I would suggest drawing up a list of images with generic names, renaming them, and implementing the placeholder I've described. -- King of ♠ 03:47, 20 March 2015 (UTC)
    • That would certainly be an improvement over using File:Name.jpg as the redirect target for those pages. BD2412 T 03:53, 20 March 2015 (UTC)
Symbol oppose vote.svg Oppose We never delete redirects of files created more than 7 days ago (unless they are offensive or there are legally relevant issues with them), as reusers may rely on links to filedesc pages to fulfil attribution requirements, which CC explicitly allows.    FDMS  4    14:14, 20 March 2015 (UTC)
  • Can attribution requirements be fulfilled by a note on the page? BD2412 T 14:23, 20 March 2015 (UTC)
Probably, but I guess that would be messy. The exact CC BY 4.0 license text is […] it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information […].    FDMS  4    15:34, 20 March 2015 (UTC)
  • Pictogram voting comment.svg Comment I'd rather see it done by a redirect than a move, but I think the basic idea is good. (That is, something like File:River.jpg would always be a redirect if it existed at all.) - Jmabel ! talk 16:11, 20 March 2015 (UTC)
  • Symbol oppose vote.svg Oppose see FDMS comment above and other projects, including those using InstantCommons, might be using the file even though they don't show up in the global usage. Deleting the redirects would break their file references. --Steinsplitter (talk) 16:52, 20 March 2015 (UTC)
    I am guessing that is why File:Fish.jpg and File:Fish.JPG, respectively, point to the targets to which they now point. BD2412 T 19:09, 20 March 2015 (UTC)

License templates for the Mozilla rebranded software by Debian[edit]

I just created the template {{User:Amitie_10g/Templates/Mozilla-Debian_MTL}}, that is a modified version of the {{MTL}} template, that indicates that is for the Mozilla software rebranded by Debian (Iceweasel, Icedove and Iceape) and indicates that these software is still licensed under the MPL/GPL/LGPL tri-license.

Is this template useful? Do I move this to the Template: namespace?

Thanks for your comments. --Amitie 10g (talk) 16:47, 20 March 2015 (UTC)

Confusing, so Iceweasel would be {{MTL}}, and your thingy is for what else? And what exactly is the difference, at the moment I see MPL 1.1 == MPL 1.1, GPL == GPL, and LGPL == LGPL, the only difference is that you mention and wikilink Debian. If that's not only promotional, how about a parameter debian=yes or similar in {{MTL}}? –Be..anyone (talk) 04:18, 26 March 2015 (UTC)

Make Categories more visible on file description pages[edit]

Categories have evolved to be our main tool for organizing our content. However, they are by default placed at the very bottom of the file description page, where hardly anyone who's not looking for them will ever find them. That's probably because that's how it's done at Wikipedia, where they play a minor role compared to Commons. In order to make non-regular users more aware of their importance, I suggest to make categories more visible at file description pages, hoping that this may encourage uploaders to better categorize their images and help to slow down the increase of our already enormous backlog of not or badly categorized files. A simple way to do that would be to move them up on the file page by switching on one of the already existing gadgets Place categories above all other content or Place categories above content, but below image on file description pages by default. What do you think? --El Grafo (talk) 10:33, 23 March 2015 (UTC)

  • Symbol support vote.svg Support (either gadget). -- Tuválkin 11:13, 23 March 2015 (UTC)
  • Symbol support vote.svg Support. Categorization, as part of content curation, is, IMO, the most important thing to do here. José Luiz disc 11:32, 23 March 2015 (UTC)
  • Symbol support vote.svg Support Below the image would be better, I think - the file itself is more important than the categories. It's arguable whether the description or the categories are more important, but the upload log and Exif data are purely technical info. However, splitting them would mean re-designing those sections somehow - is that possible, seeing that they are auto-generated? YLSS (talk) 15:51, 23 March 2015 (UTC)
    I don't know if categories are more important than the description, but they don't take too much space and wouldn't distract from the description if placed above it. You can go to the gadgets settings in you preferences and enable one of the gadgets I mentioned above to try it our for yourself (they are in the Interface: Files and categories section). Putting the categories below the description would probably mean putting them above the file history and below anything directly editable on the file page, which may contain a huge amount of various templates (FPC, WLM, etc.), so I don't think we would gain much visibility. I don't think it would be possible to display the categories between the description and the licensing section, for example. Or at least it would be much more complicated than just setting an existing gadget as default. --El Grafo (talk) 10:55, 24 March 2015 (UTC)
    I know, I know, just throwing in some things to consider as an alternative. I agree with everything you wrote, it's only that the description sometimes can (and ideally should) contain far more information than any categories, including some more precise information. Moreover, the categories are (currently) in English only, so they won't be helpful for those who don't know the language; while the description can (and should) at least include something in the local language WRT photo subject. But the other fields of {{Information}} are less informative, yes. YLSS (talk) 12:09, 24 March 2015 (UTC)
  • Strong Symbol support vote.svg Support. I rely on the categories when using Commons, wouldn't know how to do use it efficiently without them. I have them displayed below the image, which I think is the better option. -- Deadstar (msg) 16:05, 23 March 2015 (UTC)
  • Symbol support vote.svg Support I like Place categories above all other content option. --Jarekt (talk) 16:26, 23 March 2015 (UTC)
  • Symbol support vote.svg Support -- Stephan Kulla (talk) 01:34, 24 March 2015 (UTC) PS: The JavaScript-Code $("#siteSub").after($("#catlinks")); does what you want. You can place this code in the personal or global JavaScript files.
    No need for that, as you can already through the preferences with the two "gadgets" I mentioned above. --El Grafo (talk) 10:40, 24 March 2015 (UTC)
  • Symbol support vote.svg Support of course; personally I would prefer above content, but below image. --El Grafo (talk) 10:42, 24 March 2015 (UTC)
  • Symbol support vote.svg Support. Can be useful for users in case of lack in the description or file name.-- Geagea (talk) 09:09, 26 March 2015 (UTC)
  • Symbol support vote.svg Support below the image. This would also be useful to more prominently alert readers (and uploaders) to the absence of categories, since files needing categories are categorized as such. BD2412 T 15:03, 26 March 2015 (UTC)
  • Symbol support vote.svg Support The actual tool Place categories above all other content enabled per default (only for the file and category namespace). -- Christian Ferrer 07:57, 29 March 2015 (UTC)


Pictogram voting comment.svg Comment I suggest a gadged (enabled per default), only for the file and category namespace. thoughts? --Steinsplitter (talk) 13:23, 24 March 2015 (UTC)

That might indeed be nicer, but I've had the above all content but below images enabled for years now and I don't really mind having categories at the top of other pages like – say – this one or FPC at all. If someone could do this, I would welcome it, but I wouldn't say we can't live without it. --El Grafo (talk) 15:30, 24 March 2015 (UTC)
  • I'd prefer a MediaWiki extension doing that to avoid Jumping Content. Same goes for the user uploads link. -- Rillke(q?) 15:13, 24 March 2015 (UTC)
No idea what you mean by Jumping Content or the user uploads link, but same as above: If someone was willing to do that as a proper extension, I'd welcome it. But if that leads to a "someone should do this, let's file a bug report and wait another 5 years" then I'd rather have the quick&dirty approach. --El Grafo (talk) 15:30, 24 March 2015 (UTC)
The bar containing the categories is moved after first content is displayed. If you have a German interface the link next to your contributions was called Hochgeladene Dateien, now it's Uploads, to - and it tends to appear there after all the other links, at least under certain circumstances. -- Rillke(q?) 08:50, 26 March 2015 (UTC)
A extension sounds reasonable. Agree that JS is not good in this case. --Steinsplitter (talk) 08:08, 29 March 2015 (UTC)
  • Symbol oppose vote.svg Oppose, new users arriving here are already completely confused where they are (no, this is not wikipedia, let alone enwiki), frustrated by never working upload wizards with 1001 better alternatives to pick from which might sometimes work, and thousands of right or wrong licenses triggering deletions or erroneous accusations to be thieves. That's not the month or day where they need to figure out categories. –Be..anyone (talk) 04:26, 26 March 2015 (UTC)
    Of course it is. I always wanted to suggest that both the default form and the UploadWizard do not accept files without some (existing!) categories added, like they do if no license is chosen, — but that's another topic for another discussion. YLSS (talk) 10:15, 26 March 2015 (UTC)