Commons:Village pump/Proposals/Archive/2015/03

Give admins the power to speedy delete without discussion

This section was archived on a request by:    FDMS  4    20:45, 2 April 2015 (UTC)

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

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:

• File:US Navy 110211-N-NK458-047 Culinary Specialist 2nd Class Tad Pooler prepares strawberries flambé

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.

67.100.127.236 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)

Clarify blocking policy?

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

• 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

• 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… –Be..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)

"Paradigm images" proposal

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)

•  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)

•  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)

 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)

•  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)
•  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

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)

Use javascript to make a more suitable advanced search

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 https://commons.wikimedia.org/w/index.php?title=Special:Search&profile=advanced 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. -- 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)

Make Categories more visible on file description pages

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)

•  Support (either gadget). -- Tuválkin ✉ 11:13, 23 March 2015 (UTC)
•  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)
•  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  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)
•  Support I like Place categories above all other content option. --Jarekt (talk) 16:26, 23 March 2015 (UTC)
•  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)

•  Support of course; personally I would prefer above content, but below image. --El Grafo (talk) 10:42, 24 March 2015 (UTC)
•  Support. Can be useful for users in case of lack in the description or file name.-- Geagea (talk) 09:09, 26 March 2015 (UTC)
•  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)
•  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)

Discussion

 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)

•  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)