Difference between revisions of "Commons:Village pump/Proposals"

From Wikimedia Commons, the free media repository
Jump to: navigation, search
(Explanation: Support)
(One intermediate revision by the same user not shown)
Line 495: Line 495:
:::Hi Adrignola. I want to apologize for not getting back to you. You should not have had to wait this amount of time, and I feel bad about it. I had responded to someone else about a similar issue, and, for some reason, my mind played games on me, making me think I had answered. I promise to get back by next week. [[User:Geoffbrigham|Geoffbrigham]] ([[User talk:Geoffbrigham|<span class="signature-talk">talk</span>]]) 21:46, 3 November 2011 (UTC)
:::Hi Adrignola. I want to apologize for not getting back to you. You should not have had to wait this amount of time, and I feel bad about it. I had responded to someone else about a similar issue, and, for some reason, my mind played games on me, making me think I had answered. I promise to get back by next week. [[User:Geoffbrigham|Geoffbrigham]] ([[User talk:Geoffbrigham|<span class="signature-talk">talk</span>]]) 21:46, 3 November 2011 (UTC)
::::We are always respectful of and impressed by community initiatives. For that reason, it is tough for us to put a barrier in front of folks who are sincerely seeking a solution to a challenge. So our apologies in advance, but, to be honest, it will be difficult for WMF to support the proposed solution in this case.
::::Please allow me to explain in brief. With this proposal, WMF is concerned about possible increased liability for the Foundation and OTRS agents. Sensitive legal matters may be deleted, and, for that reason, increasing the size of the group who can view such deleted material could arguably increase WMF's liability. In addition, OTRS agents could risk personal liability by undeleting content that had been originally deleted for legal reasons (either by the community or WMF). We appreciate the opportunity to be consulted, and we are sorry we cannot support this. [[User:Geoffbrigham|Geoffbrigham]] ([[User talk:Geoffbrigham|<span class="signature-talk">talk</span>]]) 17:30, 6 November 2011 (UTC)
===Additional discussion===
===Additional discussion===

Revision as of 17:31, 6 November 2011

Commons:Village pump/Proposals/Header

Special:MyUploads Part 2

It is proposed to add a link to Special:MyUploads at the top right, next to "My contributions". Special:MyUploads is a new function, which redirects to Special:ListFiles/username. Earlier discussion above (Commons:Village_pump/Proposals#Adding_Special:MyUploads_.22my_uploads.22_link_next_to_.22my_contributions.22) led to the development of various elements of what's needed for this, namely the Javascript and a Gadget for users to turn the new link off in their preferences. To see the script in action, add importScript('User:Rd232/myuploads.js'); to your custom Javascript page, at Special:MyPage/common.js.

  1. The new link is aimed primarily at newcomers. As the blog entry which reported the creation of the Special:MyUploads function said [1], "During our interviews & testing, most people were wondering where their uploads had gone once the upload was completed." The link is currently available as a tiny link at the top of "my contributions" (I only noticed that after re-reading the blog entry! it's tiny, and mixed in with other tiny links!) which might be OK for other wikis, but uploading being so core to Commons it really should be more prominent than that.
  2. There is a Toolserver Gallery tool, but for many users MyUploads is enough, and sending them to the Gallery is confusing and wasteful of scarce toolserver resources. Also the Gallery tool is not always available.
  3. The Toolserver Gallery link can be added at MediaWiki:Listfiles-summary (shown at the top of Special:ListFiles). That way it's accessible (and allows for some description of how it differs from ListFiles, in a relevant context), whilst users get initially pointed at ListFiles.
  4. There will be an easy way to turn off the new link (via a Gadget in their preferences), for those who don't want it.
  5. Bugzilla30522 has been filed asking for improvements to Special:ListFiles. Those improvements will be nice to have, but MyUploads is already useful enough without those improvements.

Rd232 (talk) 22:38, 24 August 2011 (UTC)

  • Comment: I wonder if uploads via bots such as flickr2commons could be creditd to the actual uploader -- rather than to the bot, which IB is now the case? TIA, Tillman (talk) 21:20, 1 September 2011 (UTC)


Support - much easier

  1. As proposer. Rd232 (talk) 22:38, 24 August 2011 (UTC)
  2. Sure thing. I do not think it is necessary to provide a gadget to remove the future link, such a change is consensual enough I think. Jean-Fred (talk) 22:48, 24 August 2011 (UTC)
    Thanks, but I think it best to provide a gadget; for example for people with small screens the extra text may be an issue. If the gadget isn't much used, it could (like any underused gadget) be removed at some point, and those using it use the gadget's CSS in their Special:MyPage/skin.css to hide the link instead. I expect the gadget would be used enough for that not to happen though. Rd232 (talk) 23:04, 24 August 2011 (UTC)
  3. Support, I think it's a great idea. Kelly (talk) 23:18, 24 August 2011 (UTC)
  4. Yes please, integrate that feature right into the UI. Can it have a field for categories as well? Ingolfson (talk) 23:23, 24 August 2011 (UTC)
  5. Symbol support vote.svg  Support Support, with or without gadget. Good idea.--Jebulon (talk) 23:25, 24 August 2011 (UTC)
  6. Symbol support vote.svg  Support InverseHypercube (talk) 23:25, 24 August 2011 (UTC)
  7. Symbol support vote.svg  Support I only discovered that galleries and lists existed after some months and uploading tens of images, so I agree that link should be as easy-to-find as possible.--Pere prlpz (talk) 23:28, 24 August 2011 (UTC)
  8. Symbol support vote.svg  Support Great idea for newbies Rastrojo (DES) 00:59, 25 August 2011 (UTC)
  9. Symbol support vote.svg  Support I very much love this feature; I often find myself needing to find files I've uploaded (among hundreds of edits) and this would be very useful to have up top. Pi.1415926535 (talk) 01:12, 25 August 2011 (UTC)
  10. Symbol support vote.svg  Support Good and useful idea.   ■ MMXX  talk  01:26, 25 August 2011 (UTC)
  11. Symbol support vote.svg  Support --Forwhomthebelltolls (talk) 14:33, 30 August 2011 (UTC)
  12. Symbol support vote.svg  Support useful link with good visibility. --Jovian Eye storm 01:58, 25 August 2011 (UTC)
  13. Symbol support vote.svg  Support Fantastic idea. Would make things a lot easier. Swarm (talk) 01:59, 25 August 2011 (UTC)
  14. Symbol support vote.svg  Support Awesome idea that will be very useful. King Curtis Gooden (talk) 02:24, 25 August 2011 (UTC)
  15. Symbol support vote.svg  Support Themfromspace (talk) 02:55, 25 August 2011 (UTC)
  16. Symbol support vote.svg  Support Definitely a good idea. Michael Barera (talk) 03:09, 25 August 2011 (UTC)
  17. Symbol support vote.svg  Support With this feature all categories "Uploads by User XXX" become unnecessary! -- Simisa (talk) 06:19, 25 August 2011 (UTC)
  18. Symbol support vote.svg  Support -- penubag  (talk) 06:24, 25 August 2011 (UTC)
  19. Symbol support vote.svg  Support A great idea. Novice7 (talk) 07:26, 25 August 2011 (UTC)
  20. Symbol support vote.svg  Support Petritap (talk) 08:08, 25 August 2011 (UTC)
  21. Symbol support vote.svg  Support Looks useful and easy to use for newbies. Better than sending people to the tool server. --Enric Naval (talk) 08:18, 25 August 2011 (UTC)
  22. Symbol support vote.svg  Support --Marco dimmi! 09:05, 25 August 2011 (UTC)
  23. Symbol support vote.svg  Support It is necessary for commons. --Vssun (talk) 09:10, 25 August 2011 (UTC)
  24. Symbol support vote.svg  Support Support -- Raghith 09:20, 25 August 2011 (UTC)
  25. Symbol support vote.svg  Support So useful --Elitre (talk) 09:22, 25 August 2011 (UTC)
  26. Symbol support vote.svg  Support It's very useful to be able to see your uploads without going through your contributions one-by-one; and the Toolserver Gallery is down or malfunctioning half of the time. --Kimsə (talk) 09:26, 25 August 2011 (UTC)
  27. Symbol support vote.svg  Support This would be a very useful tool not only for beginners! --OhWeh (talk) 10:05, 25 August 2011 (UTC)
  28. Symbol support vote.svg  Support Very usefull --Haneburger (talk) 10:14, 25 August 2011 (UTC)
  29. Symbol support vote.svg  Support --Great idea. Vibhijain (talk) 10:50, 25 August 2011 (UTC)
  30. Symbol support vote.svg  Support --Stryn (talk) 13:01, 25 August 2011 (UTC)
  31. Symbol support vote.svg  Support --Mike1979 Russia (talk) 13:07, 25 August 2011 (UTC)
  32. Symbol support vote.svg  Support --Gareth (talk) 13:15, 25 August 2011 (UTC)
  33. Symbol support vote.svg  Support Would be very useful for me. Léna (talk) 14:03, 25 August 2011 (UTC)
  34. Symbol support vote.svg  Support Great idea! AnaJur (talk) 14:17, 25 August 2011 (UTC)
  35. Symbol support vote.svg  Support It's very good idea. Electroguv (talk) 14:50, 25 August 2011 (UTC)
  36. Symbol support vote.svg  Support Great idea! --Dtarazona (talk) 15:01, 25 August 2011 (UTC)
  37. Symbol support vote.svg  Support especially as the toolserver gallery fails often. Shyamal (talk) 15:07, 25 August 2011 (UTC)
  38. Symbol support vote.svg  Support why not? -- ianusius ✆ Disk. 15:12, 25 August 2011 (UTC)
  39. Symbol support vote.svg  Support What a great idea!
    — Preceding unsigned comment added by Jay8g (talk • contribs) 15:14 (UTC)
  40. Symbol support vote.svg  Support useful tool. Should get an easy access --High Contrast (talk) 15:17, 25 August 2011 (UTC)
  41. Symbol support vote.svg  Support Good Estratocastro (talk) 15:18, 25 August 2011 (UTC)
  42. Symbol support vote.svg  Support , Though I'm not sure if I am qualified to vote. --YusuF 15:44, 25 August 2011 (UTC)
  43. Symbol support vote.svg  Support That makes sense. Bouchecl (talk) 15:45, 25 August 2011 (UTC)
  44. Symbol support vote.svg  Support --Jusjih (talk) 16:16, 25 August 2011 (UTC)
  45. Symbol support vote.svg  Support This is a great idea. I wholeheartedly support it. SSG Cornelius Seon (US Army, Retired) (talk) 16:39, 25 August 2011 (UTC)
  46. Symbol support vote.svg  Support Love it! --Ebyabe (talk) 17:13, 25 August 2011 (UTC)
  47. Symbol support vote.svg  Support , I find this even more useful than "My contributions". --Pierre Rudloff (talk) 17:41, 25 August 2011 (UTC)
  48. Symbol support vote.svg  Support yes --IIVeaa (talk) 17:42, 25 August 2011 (UTC)
  49. Symbol support vote.svg  Support Great idea --Beaucouplusneutre (talk) 17:57, 25 August 2011 (UTC)
  50. Symbol support vote.svg  Support Good idea! Georgez (talk) 18:08, 25 August 2011 (UTC)
  51. Symbol support vote.svg  Support --Losch (talk) 18:10, 25 August 2011 (UTC)
  52. Symbol support vote.svg  Support Telperion (talk) 20:25, 25 August 2011 (UTC)
  53. Pile-on Symbol support vote.svg  Support --Philosopher Let us reason together. 21:18, 25 August 2011 (UTC)
  54. Symbol support vote.svg  Support Yeaph, why not! --Jwh (talk) 21:21, 25 August 2011 (UTC)
  55. Symbol support vote.svg  Support For the reasons above. Editor5807speak 21:22, 25 August 2011 (UTC)
  56. Symbol support vote.svg  Support strongly. I hadn't even realised it was there myself and I've uploaded hundreds of images to the Commons. — OwenBlacker | Discussion 22:43, 25 August 2011 (UTC)
  57. Symbol support vote.svg  Support , but expecting that this integrates watchlist-features would be technically obscure. –Be..anyone (talk) 23:20, 25 August 2011 (UTC)
  58. Symbol support vote.svg  Support strongly. Excellent idea. By the way, it would be great to have a column showing how many wikipedia pages are using each specific photo. This way I will sort my uploaded photos, to see the more popular ones.--Jordiferrer (talk) 23:23, 25 August 2011 (UTC)
  59. Symbol support vote.svg  Support idem... Vitor Mazuco Msg 23:25, 25 August 2011 (UTC)
  60. Symbol support vote.svg  Support Great idea! - PKM (talk) 23:53, 25 August 2011 (UTC)
  61. Symbol support vote.svg  Support only if a gadget to disable is provided. fetchcomms 00:30, 26 August 2011
  62. Symbol support vote.svg  Support I didn't even know this page existed. Very useful, thanks! Ephemeronium (talk) 01:16, 26 August 2011 (UTC)
  63. Symbol support vote.svg  Support Agree, it's a fantastic idea! Would be very useful not to layaway through all these sites! Smartcom5 (Any thoughts ?) 02:09, 26 August 2011 (UTC)
  64. Symbol support vote.svg  Support Intresting stuff to add to Wikipedia Commons. Dhe Zerohander (talk) 02:11, 26 August 2011 (UTC)
  65. Symbol support vote.svg  Support } Clearly an improvement. SchuminWeb (Talk) 03:10, 26 August 2011 (UTC)
  66. Symbol support vote.svg  Aye . Makes sense for Commons. — Tanvir | Talk ] 03:43, 26 August 2011 (UTC)
  67. Symbol support vote.svg  Support Very useful tool, and not just for newbies. Tabercil (talk) 03:45, 26 August 2011 (UTC)
  68. Symbol support vote.svg  Support Usefull. Palamède (talk) 08:27, 26 August 2011 (UTC)
  69. Symbol support vote.svg  Support Sure --Hoangquan hientrang (talk) 09:43, 26 August 2011 (UTC)
  70. Symbol support vote.svg  Support Sounds like a useful addition. ZanderZ (talk) 10:10, 26 August 2011 (UTC)
  71. Symbol support vote.svg  Support Support, sounds good. --kuvaly|t|c| 11:07, 26 August 2011 (UTC)
  72. Symbol support vote.svg  Support Sounds really great and encouraging to regular uploaders like me. Hindustanilanguage (talk) 11:44, 26 August 2011 (UTC)
  73. Symbol support vote.svg  Support --Purodha Blissenbach (talk) 12:06, 26 August 2011 (UTC)
  74. Symbol support vote.svg  Support --Vassil (talk) 13:14, 26 August 2011 (UTC)
  75. Symbol support vote.svg  Support Is much more useful and also faster find it at the top. With or without a gadget for me is irrelevant. Is a very-good-idea :) --raul (talk) 13:36, 26 August 2011 (UTC)
  76. Symbol support vote.svg  Support Fantastic idea ! Trizek here or on fr:wp 13:54, 26 August 2011 (UTC)
  77. Symbol support vote.svg  Support Jirka Daněk (talk) 14:26, 26 August 2011 (UTC)
  78. Symbol support vote.svg  Support A time-saving and useful improvement. JuventiniFan (talk) 14:39, 26 August 2011 (UTC)
  79. Symbol support vote.svg  Support --Wmeinhart (talk) 15:15, 26 August 2011 (UTC)
  80. Symbol support vote.svg  Support Would make finding your own uploads much easier! Jacsam2 (talk) 15:46, 26 August 2011 (UTC)
  81. Symbol support vote.svg  Support Lotje ʘ‿ʘ (talk) 15:56, 26 August 2011 (UTC)
  82. Symbol support vote.svg  Support This would be a very useful addition. Harrison49 (talk) 16:34, 26 August 2011 (UTC)
  83. Symbol support vote.svg  Support Good idea. --LinuxCLP (talk) 16:55, 26 August 2011 (UTC)
  84. --Antemister (talk) 17:29, 26 August 2011 (UTC)
  85. Symbol support vote.svg  Support Nice idea, would definitely be useful. Fallschirmjäger  18:18, 26 August 2011 (UTC)
  86. -- Hardcoreraveman (talk) 18:21, 26 August 2011 (UTC)
  87. Symbol support vote.svg  Support Prima. Very good.--PjotrMahh1 (talk) 19:25, 26 August 2011 (UTC)
  88. Symbol support vote.svg  Support It would be very useful. --Boukeas
  89. Symbol support vote.svg  Support Musthave feature. B7elijah (talk) 20:58, 26 August 2011 (UTC)
  90. Symbol support vote.svg  Support Would be useful. Haaninjo (talk) 21:20, 26 August 2011 (UTC)
  91. Symbol support vote.svg  Support Much more convenient than the current system. Delaywaves talk contribs 22:31, 26 August 2011 (UTC)
  92. Symbol support vote.svg  Support fully support.--Gordonrox24 | Talk 04:17, 27 August 2011 (UTC)
  93. Symbol support vote.svg  Support It's a good idea. --Leiem (talk) 05:02, 27 August 2011 (UTC)
  94. Symbol support vote.svg  Support Yes. I can't find stuff either! Agong1 27 August 2011(UTC)
  95. Symbol support vote.svg  Support --Citron (talk) 10:08, 27 August 2011 (UTC)
  96. Symbol support vote.svg  Support Finally. Regards, PETER WEIS TALK 10:33, 27 August 2011 (UTC)
  97. Symbol support vote.svg  Support Nice and helpful. Dysmorodrepanis (talk) 10:53, 27 August 2011 (UTC)
  98. Symbol support vote.svg  Support This has been long overdue. Branko Radovanović (talk) 11:08, 27 August 2011 (UTC)
  99. Symbol support vote.svg  Support Yann (talk) 12:17, 27 August 2011 (UTC)
  100. Symbol support vote.svg  Support Jmalo (talk) 14:16, 27 August 2011 (UTC)
  101. Symbol support vote.svg  Support --Winiar 14:49, 27 August 2011 (UTC)
  102. Symbol support vote.svg  Support Dcoetzee (talk) 15:34, 27 August 2011 (UTC)
  103. Symbol support vote.svg  Support B25es (talk) 15:43, 27 August 2011 (UTC)
  104. Symbol support vote.svg  Support --LasseG (talk) 16:08, 27 August 2011 (UTC)
  105. Symbol support vote.svg  Support Nice.--Morphypnos (talk) 16:16, 27 August 2011 (UTC)
  106. Symbol support vote.svg  Support Good feature! CZmarlin (talk) 18:39, 27 August 2011 (UTC)
  107. Symbol support vote.svg  Support Do it! Williamborg (talk) 19:04, 27 August 2011 (UTC)
  108. Symbol support vote.svg  Support Kennyannydenny (talk) 19:07, 27 August 2011 (UTC)
  109. Symbol support vote.svg  Support - very good idea! Romaine (talk) 20:10, 27 August 2011 (UTC)
  110. Symbol support vote.svg  Support -- M 93 (talk) 21:16, 27 August 2011 (UTC)
  111. Symbol support vote.svg  Support - A very concise way to show just the uploads Benrr101 (talk)
  112. Symbol support vote.svg  Support Logan Talk Contributions 22:12, 27 August 2011 (UTC)
  113. Symbol support vote.svg  Support It's a nice idea --Sammy pompon (talk) 22:27, 27 August 2011 (UTC)
  114. Symbol support vote.svg  Support Great idea! --Yetisyny (talk) 23:45, 27 August 2011 (UTC)
  115. Symbol support vote.svg  Support Seems very sensible Nick-D (talk) 00:28, 28 August 2011 (UTC)
  116. Symbol support vote.svg  Support Nice idea, and it seems not to change "contributions" special page then it would be perfect then. Jeriby (talk) 01:04, 28 August 2011 (UTC)
  117. Symbol support vote.svg  Support As opposed to other projects, uploading is a major part of what almost everyone does here. Being able to quickly look back at what we've uploaded helps us do our tasks better. Daniel Case (talk) 01:44, 28 August 2011 (UTC)
  118. Symbol support vote.svg  Supportstay (sic)! 01:59, 28 August 2011 (UTC)
  119. Symbol support vote.svg  Support Bring it on. That said... I wish it looked more like the currently broken tool from daniel ( http://toolserver.org/~daniel/WikiSense/Gallery.php ). Nephron  T|C 02:34, 28 August 2011 (UTC)
  120. Symbol support vote.svg  Support Would save time. --Thompson.matthew (talk) 04:08, 28 August 2011 (UTC)
  121. GfoleyFour 04:25, 28 August 2011 (UTC)
  122. Symbol support vote.svg  Support Good and useful idea. --Thomy3k (talk) 06:47, 28 August 2011 (UTC)
  123. Symbol support vote.svg  Support --Karelj (talk) 07:18, 28 August 2011 (UTC)
  124. Symbol support vote.svg  Support --ST 08:07, 28 August 2011 (UTC)
  125. Symbol support vote.svg  Support Lymantria (talk) 08:50, 28 August 2011 (UTC)
  126. Symbol support vote.svg  Support - Good move..--...Captain......Tälk tö me.. 09:51, 28 August 2011 (UTC)
  127. Symbol support vote.svg  Support as proposed. –Tommy Kronkvist (talk), 10:43, 28 August 2011 (UTC).
  128. Symbol support vote.svg  Support Excellent idea. --Captain-tucker (talk) 10:57, 28 August 2011 (UTC)
  129. Symbol support vote.svg  Support Seems like a great idea. -Joltex (talk) 11:03, 28 August 2011 (UTC)
  130. Symbol support vote.svg  Support This can replace the "gallery" Richardprins (talk) 11:34, 28 August 2011 (UTC)
  131. Symbol support vote.svg  Support I'm surprised it took so long for someone to think of this ;) . It'd be very useful. MikeLynch (talk) 12:28, 28 August 2011 (UTC)
  132. Symbol support vote.svg  Support Good idea! Cindamuse (talk) 12:29, 28 August 2011 (UTC)
  133. Symbol support vote.svg  Support Good Idea! Subin.a.mathew (talk) 15:42, 28 August 2011 (UTC)
  134. Symbol support vote.svg  Support Long awaited. --Ainali (talk) 15:49, 28 August 2011 (UTC)
  135. Symbol support vote.svg  Support It would be helpful and its a great idea! --Vaishak Kallore | വൈശാഖ്‌ കല്ലൂര്‍ (talk) 16:38, 28 August 2011 (UTC)
  136. Symbol support vote.svg  Support +1 --Kippelboy (talk) 18:15, 28 August 2011 (UTC)
  137. Symbol support vote.svg  Support A very good idea indeed. - Presidentman (talk · contribs) Wikipedia Random Picture of the Day 18:28, 28 August 2011 (UTC)
  138. Symbol support vote.svg  Support Spares me from having this essentially replicated on my user page. -- Mcstrother (talk) 19:17, 28 August 2011 (UTC)
  139. Symbol support vote.svg  Support The most important contributions to commons are usually uploaded images, hence they should be easily accessible. Puchiko (talk) 20:38, 28 August 2011 (UTC)
  140. Symbol support vote.svg  Support -- πϵρήλιο 21:07, 28 August 2011 (UTC)
  141. Symbol support vote.svg  Support Gzzz (talk) 21:13, 28 August 2011 (UTC)
  142. Symbol support vote.svg  Support Good idea! Biólogo32 21:36, 28 August 2011 (UTC)
  143. Symbol support vote.svg  Support --Davidpar (disc.) 21:49, 28 August 2011 (UTC)
  144. Symbol support vote.svg  Support Starus (talk) 22:08, 28 August 2011 (UTC)
  145. Symbol support vote.svg  Support Addresses core activity of Commons. Steven Walling • talk 23:53, 28 August 2011 (UTC)
  146. Symbol support vote.svg  Support - Quite similar to Upload log by user, with a larger picture. Yuval Y § Chat § 09:29, 29 August 2011 (UTC)
  147. Symbol support vote.svg  Support Good and useful idea! --Dirk Van Esbroeck (talk) 10:19, 29 August 2011 (UTC)
  148. Very strong support. It's a good feature. Scrawler (talk) 10:37, 29 August 2011 (UTC)
  149. Symbol support vote.svg  Support , I'm always looking for this link when I need it, I think it is of very different use than the contributions, even if the first one include the second.Indeed, if someone can tell me how to filter out the imports from the contributions, when I'm looking for comment maintenance, I would be glad. --Cqui (talk) 10:54, 29 August 2011 (UTC)
  150. Symbol support vote.svg  Support It's a very good idea. --Rave (talk) 11:02, 29 August 2011 (UTC)
  151. Symbol support vote.svg  Support Handy! Smile4ever (talk) 12:29, 29 August 2011 (UTC)
  152. Symbol support vote.svg  Support Useful -- Kakashi-Madara (talk) 13:39, 29 August 2011 (UTC)
  153. Symbol support vote.svg  Support I litke it --Wilfredor (talk) 17:53, 29 August 2011 (UTC)
  154. Symbol support vote.svg  Support . Yes. Maybe even add it to the toolbox on user pages next to "User contributions". Drilnoth (talk) 18:54, 29 August 2011 (UTC)
  155. Symbol support vote.svg  Support Cool idea. --Anoopan (talk) 20:22, 29 August 2011 (UTC)
  156. Symbol support vote.svg  Support A handy link. --George2001hi (Discussion) 20:56, 29 August 2011 (UTC)
  157. Symbol support vote.svg  Support --RanZag (talk) 22:13, 29 August 2011 (UTC)
  158. Symbol support vote.svg  Support -- Neithsabes (talk) 23:07, 29 August 2011 (UTC)
  159. Symbol support vote.svg  Support . And I like Drilnoths idea. --ᛏᛟᚱᚨᚾᚨ (talk) 23:45, 29 August 2011 (UTC)
  160. Symbol support vote.svg  Support — Excellent idea, given the purpose of the wiki.  Hazard-SJ  ±  00:02, 30 August 2011 (UTC)
  161. Symbol support vote.svg  Support – Excellent idea, especially since the main purpose of this wiki is to host images. mc10 (t/c) 03:08, 30 August 2011 (UTC)
  162. Symbol support vote.svg  Support The Commons is all about uploads, so it makes sense to split those out and make them easier to find. Will Beback (talk) 04:04, 30 August 2011 (UTC)
  163. Symbol support vote.svg  Support --MaryankoD (talk) 10:42, 30 August 2011 (UTC)
  164. Symbol support vote.svg  Support Obvious good idea S a g a C i t y (talk) 10:56, 30 August 2011 (UTC)
  165. Symbol support vote.svg  Support Ziga (talk) 11:07, 30 August 2011 (UTC)
  166. Symbol support vote.svg  Support --Anatoliy (talk) 12:07, 30 August 2011 (UTC)
  167. Symbol support vote.svg  Support Useful tool. --Shibo77 13:46, 30 August 2011 (UTC)
  168. Symbol support vote.svg  Support It's nice.--Jan Polák (talk) 14:29, 30 August 2011 (UTC)
  169. Symbol support vote.svg  Support Super! mr. Анатолий (talk) 17:25, 30 August 2011 (UTC)
  170. Symbol support vote.svg  Support Angelus (talk) 18:07, 30 August 2011 (UTC)
  171. Symbol support vote.svg  Support Dorieo (talk) 18:10, 30 August 2011 (UTC)
  172. Symbol support vote.svg  Support das Beste seit Langem, Danke --Böhringer (talk) 19:19, 30 August 2011 (UTC)
  173. Symbol support vote.svg  Support --Keithonearth (talk) 19:25, 30 August 2011 (UTC)
  174. Symbol support vote.svg  Support --ReijiYamashina (talk) 02:06, 31 August 2011 (UTC)
  175. Symbol support vote.svg  Support This is an important feature, should be done as a one click option. Beta M (talk) 02:27, 31 August 2011 (UTC)
  176. Symbol support vote.svg  Support A great shortcut. Jsayre64 (talk) 02:37, 31 August 2011 (UTC)
  177. Symbol support vote.svg  Support yes very good suggestion --Olli (talk) 06:09, 31 August 2011 (UTC)
  178. Symbol support vote.svg  Support Une super bonne idée, je vais déjà rajouter ce lien Special:MyUploads sur ma page perso Wikisoft* @@@-fr 07:11, 31 August 2011 (UTC)
  179. Symbol support vote.svg  Support Very good idea--Trex2001 (talk) 08:23, 31 August 2011 (UTC)
  180. Symbol support vote.svg  Support It would be nice to have it handle files where we uploaded new versions as well. Right now I handle that with my watchlist. But yes, support. --Quintucket (talk) 08:50, 31 August 2011 (UTC)
  181. Symbol support vote.svg  Support Simple and obvious improvement. Andy Dingley (talk) 09:48, 31 August 2011 (UTC)
  182. Symbol support vote.svg  Support Great idea!--ChristianSW (talk) 12:30, 31 August 2011 (UTC)
  183. Symbol support vote.svg  Support --Paolo77 ru (talk) 12:48, 31 August 2011 (UTC)
  184. Symbol support vote.svg  Support It would be good if it could help newbies come back to their uploads and become aware of speedy or requested deletions when that happens. Teofilo (talk) 13:09, 31 August 2011 (UTC)
  185. Symbol support vote.svg  Support Very good idea. I'm waiting for this tool for a long time. - Bzh-99 (talk) 13:23, 31 August 2011 (UTC)
  186. Symbol support vote.svg  Support --Nevit Dilmen (talk) 13:31, 31 August 2011 (UTC)
  187. Symbol support vote.svg  Support It would be a very useful tool. Sealle (talk) 15:20, 31 August 2011 (UTC)
  188. Symbol support vote.svg  Support Makes a great deal of sense to me... it would be a useful and visible tool. — Gbms86—talk 17:06, 31 August 2011 (UTC)
  189. Symbol support vote.svg  Support --CristianNX 17:29, 31 August 2011 (UTC)
  190. Symbol support vote.svg  Support --Geoff Who, me? 17:46, 31 August 2011
  191. Symbol support vote.svg  Support --Nick Michael (talk) 20:19, 31 August 2011 (UTC)
  192. Symbol support vote.svg  Support Very good idea! --— Habib M'HENNI [¿tell me?] 20:29, 31 August 2011 (UTC)
  193. Symbol support vote.svg  Support Yes FrankyLeRoutier (talk) 23:05, 31 August 2011 (UTC)
  194. Symbol support vote.svg  Support Useful for multiple purposes.   — C M B J   04:30, 1 September 2011 (UTC)
  195. Symbol support vote.svg  Support I would like it.--Salino01 (talk) 04:46, 1 September 2011 (UTC)
  196. Symbol support vote.svg  Support -- Ariadacapo (talk) 07:13, 1 September 2011 (UTC)
  197. Symbol support vote.svg  Support . Can't see why not. Jafeluv (talk) 07:17, 1 September 2011 (UTC)
  198. Symbol support vote.svg  Support Good idea! PAULOGARCIA2005 (talk) 07:21, 1 September 2011 (UTC)
  199. Symbol support vote.svg  Support Yes, please. Wiki-uk (talk) 10:15, 1 September 2011 (UTC)
  200. Symbol support vote.svg  Support --Avenue (talk) 14:23, 1 September 2011 (UTC)
  201. Symbol support vote.svg  Support --Lucien (es·m·com) 15:54, 1 September 2011 (UTC)
  202. Symbol support vote.svg  Support Useful addition. --Geraki TLG 17:54, 1 September 2011 (UTC)
  203. Symbol support vote.svg  Support Galandil (talk) 19:07, 1 September 2011 (UTC)
  204. Symbol support vote.svg  Support Great idea.--Pesare amol (talk) 19:22, 1 September 2011 (UTC)
  205. Symbol support vote.svg  Support Exellent idea! Achird (talk) 21:13, 1 September 2011 (UTC)
  206. Symbol support vote.svg  Supportputnik? 23:02, 1 September 2011 (UTC)
  207. Symbol support vote.svg  Support useful Ggia (talk) 06:12, 2 September 2011 (UTC)
  208. Symbol support vote.svg  Support It would be very useful. Fandecaisses (talk) 10:21, 2 September 2011 (UTC)
  209. Symbol support vote.svg  Support I would appreciate that. Saulus (talk) 10:28, 2 September 2011 (UTC)
  210. Symbol support vote.svg  Support Very useful addition. Owain.davies (talk) 10:58, 2 September 2011 (UTC)
  211. Symbol support vote.svg  Support Useful addition.--Josef Moser (talk) 13:26, 2 September 2011 (UTC)
  212. Symbol support vote.svg  Support Nice! ...Kenrick95 14:35, 2 September 2011 (UTC)
  213. Symbol support vote.svg  Support --Pethrus (talk) 16:25, 2 September 2011 (UTC)
  214. Symbol support vote.svg  Support kallerna 18:26, 2 September 2011 (UTC)
  215. Symbol support vote.svg  Support Gamaliel (talk) 18:48, 2 September 2011 (UTC)
  216. --Aschmidt (talk) 21:48, 2 September 2011 (UTC)
  217. Symbol support vote.svg  Support It would be much useful, easier and quicker to reach, specially for newbies -- Massic80 Contattami 23:35, 2 September 2011 (UTC)
  218. Symbol support vote.svg  Support Good idea. Saves a step. Nonenmac (talk) 00:53, 3 September 2011 (UTC)
  219. Symbol support vote.svg  Support - snow? Bulwersator (talk) 09:09, 3 September 2011 (UTC)
  220. Symbol support vote.svg  Support - very helpful! --KuK (talk) 09:23, 3 September 2011 (UTC)
  221. Symbol support vote.svg  Support --Jakubhal (talk) 11:42, 3 September 2011 (UTC)
  222. Symbol support vote.svg  Support Jerzystrzelecki (talk) 12:58, 3 September 2011 (UTC)
  223. Symbol support vote.svg  Support strongly For some people, their main contribution to Wikimedia projects is uploading new pictures or creating needed graphics. Their support is appreciated and this way it can be better noticed. Ldorfman (talk) 15:22, 3 September 2011 (UTC)
  224. Symbol support vote.svg  Support It's a good a idea, and I think it will have a some kind of benefit for easier use. So, I agree with this. --MrEskola (talk) 16:14, 3 September 2011 (UTC)
  225. Symbol support vote.svg  Support Very helpfull.-- Bertrand GRONDIN  → (Talk) 17:45, 3 September 2011 (UTC)
  226. Symbol support vote.svg  Support That's genius! --Honza chodec (talk) 20:31, 3 September 2011 (UTC)
  227. Symbol support vote.svg  Support Froztbyte (talk) 21:07, 3 September 2011 (UTC)
  228. Symbol support vote.svg  Support Anything that makes it easier to *get to* information/data is a good thing, in my book. —Safety Cap (talk) 00:35, 4 September 2011 (UTC)
  229. Symbol support vote.svg  Support Very useful, as the majority don't upload as-much-as editing... ~ AdvertAdam talk 03:20, 4 September 2011 (UTC)
  230. Symbol support vote.svg  Support --Metalhead 08:19, 4 September 2011 (UTC)
  231. Symbol support vote.svg  Support --Ex13 (talk) 10:11, 4 September 2011 (UTC)
  232. Symbol support vote.svg  Support STRONG Support - It would help me review my own contributions, for updating info, data, etc. --Rsrikanth05 (talk) 12:47, 4 September 2011 (UTC)
  233. Symbol support vote.svg  Support Good idea! "The new link is aimed primarily at newcomers." - badly needed for them indeed. {Reo On (talk) 14:22, 4 September 2011 (UTC)
  234. Symbol support vote.svg  Support --MartinThoma (talk) 14:52, 4 September 2011 (UTC)
  235. Symbol support vote.svg  Support Definitely. I didn't even realize that Special:MyUploads exists! Rdrozd (talk) 15:06, 4 September 2011 (UTC)
  236. Symbol support vote.svg  Support Yes. Saves me the detour. Manxruler (talk) 16:35, 4 September 2011 (UTC)
  237. Symbol support vote.svg  Support --Aushulz (talk) 23:09, 4 September 2011 (UTC)
  238. Symbol support vote.svg  Support That's a great idea! --Mlorer (talk) 23:23, 4 September 2011 (UTC)
  239. Symbol support vote.svg  Support This is great idea, and may encourage people to make more contributions. ···日本穣Talk to Nihonjoe 04:06, 5 September 2011 (UTC)
  240. Symbol support vote.svg  Support That's a great idea! lonio17 (talk) 07:22, 5 September 2011 (UTC)
  241. Symbol support vote.svg  Support Not very important, but useful--Packa (talk) 08:26, 5 September 2011 (UTC)
  242. Symbol support vote.svg  Support Good idea, it will be helpful. Prioryman (talk) 08:54, 5 September 2011 (UTC)
  243. Symbol support vote.svg  Support C'est tout de même bienpratique ce lien direct. Je suis totalement pour ! --Ctruongngoc (talk) 08:58, 5 September 2011 (UTC)
  244. Symbol support vote.svg  Support Good idea, it's what I do with my user page at the moment! Miyagawa (talk) 10:54, 5 September 2011 (UTC)
  245. Symbol support vote.svg  Support Good idea, I would like to use it in the future. --Midi7 (talk) 11:22, 5 September 2011 (UTC)
  246. Symbol support vote.svg  Support Excellent idea ---Peterdownunder (talk) 12:36, 5 September 2011 (UTC)
  247. Symbol support vote.svg  Support Makes sense Jebus989 (talk) 12:46, 5 September 2011 (UTC)
  248. Symbol support vote.svg  Support Of course!? -- Michael F. Schönitzer 17:44, 5 September 2011 (UTC)
  249. Symbol support vote.svg  Support Yes please. Lionel Allorge (talk) 19:24, 5 September 2011 (UTC)
  250. Symbol support vote.svg  Support Alwayse wondered why it's not there. Lysy (talk) 19:58, 5 September 2011 (UTC)
  251. Symbol support vote.svg  Support YES, it is easy to see the images instead of finding them through your watchlist. -- Spesh531 (talk) 22:19, 5 September 2011 (UTC)
  252. Symbol support vote.svg  Support Make it so! --Mav (talk) 23:54, 5 September 2011 (UTC)
  253. Symbol support vote.svg  Support YES ! --MadriCR (talk) 00:23, 6 September 2011 (UTC)
  254. Symbol support vote.svg  Support Yanguas (talk) 02:12, 6 September 2011 (UTC) Excellent idea, but better with gadget. There is a lot of users who don't have any upload.
  255. Symbol support vote.svg  Support --Helios13 (talk) 06:08, 6 September 2011 (UTC)
  256. Symbol support vote.svg  Support Support, I have often wished for something similar and could not find it. Phil Konstantin Philkon (talk) 06:54, 6 September 2011 (UTC)
  257. Symbol support vote.svg  Support Kiltpin (talk) 13:46, 6 September 2011 (UTC)
  258. Symbol support vote.svg  Support Seems very useful. -- sarang사랑.svg사랑 08:58, 6 September 2011 (UTC) But:
    • The column "User" has no use and is redundant
    • The suffix "(file)" in column "Name" is redundant
    • More helpful seems something like "File 151 to 200", or "Page 3", at the top of each page
  259. Symbol support vote.svg  Support Great idea.--Edgars2007 (talk) 14:01, 6 September 2011 (UTC)
  260. Symbol support vote.svg  Support strongly. Very good idea! Eduarda7 (talk) 14:04, 6 September 2011 (UTC)
  261. Symbol support vote.svg  Support A very good idea, it seems useful. Surt Fafnir (talk) 14:42, 6 September 2011 (UTC)
  262. Symbol support vote.svg  Support Good Idea. Usefull. --Willi Wallroth (talk) 18:23, 6 September 2011 (UTC)
  263. Symbol support vote.svg  Support Great idea. --S nova (talk) 20:04, 6 September 2011 (UTC)
  264. Symbol support vote.svg  Support Looks to be a good feature. Matthewrbowker (talk) 23:03, 6 September 2011 (UTC)
  265. Symbol support vote.svg  Support SarahStierch (talk) 23:48, 6 September 2011 (UTC)
  266. Symbol support vote.svg  Support Banfield - Amenazas aquí 02:04, 7 September 2011 (UTC)
  267. Symbol support vote.svg  Support Useful link. --Petrus Adamus (talk) 05:48, 7 September 2011 (UTC)
  268. Symbol support vote.svg  Support Please! --Schorle (talk) 05:52, 7 September 2011 (UTC)
  269. Symbol support vote.svg  Support Seems like a very good, usefull idea. Inks.LWC (talk) 06:12, 7 September 2011 (UTC)
  270. Symbol support vote.svg  Support , could be useful. Cdlt, Pymouss Let’s talk - 11:42, 7 September 2011 (UTC)
  271. Symbol support vote.svg  Support OK/--Torin (talk) 11:46, 7 September 2011 (UTC)
  272. Symbol support vote.svg  Support --патриот8790Say whatever you want 15:23, 7 September 2011 (UTC)
  273. Symbol support vote.svg  Support . Good idea. Marcos talk 18:20, 7 September 2011 (UTC)
  274. Symbol support vote.svg  Support Fantastic! This makes it so much easier to see my media content. Indispensable! Thanks BDS2006 (talk)
  275. Symbol support vote.svg  Support Patrick Edwin Moran (talk) 06:09, 8 September 2011 (UTC)
  276. Symbol support vote.svg  Support Madeline 7 (talk) 07:46, 8 September 2011 (UTC)
  277. Symbol support vote.svg  Support Sure! (for Commons) AndreyA (talk) 11:06, 8 September 2011 (UTC)
  278. Symbol support vote.svg  Support Very good idea. Please with the indication of the category. Dinkum (talk) 11:11, 8 September 2011 (UTC)
  279. Symbol support vote.svg  Support --Lucas Nunes 14:27, 8 September 2011 (UTC)
  280. Symbol support vote.svg  Support --kaʁstn Disk/Cat 14:28, 8 September 2011 (UTC)
  281. Symbol support vote.svg  Support a×pdeHello! 19:51, 8 September 2011 (UTC)
  282. Symbol support vote.svg  Support Tacci2023 Great Idea 19:52, 8 September 2011 (UTC)
  283. Symbol support vote.svg  Support Sounds like a great idea EdwinHJ (talk) 19:52, 8 September 2011 (UTC)
  284. Symbol support vote.svg  Support Definitely helpful! Samar (Talk . Contributions) 20:16, 8 September 2011 (UTC)
  285. Symbol support vote.svg  Support Rainer Halama That is what I am looking for when I want to see my contributions to Commons 23:39, 8 September 2011 (UTC)
  286. Symbol support vote.svg  Support Lauro Chieza de Carvalho (talk) 00:42, 9 September 2011 (UTC)
  287. Symbol support vote.svg  Support Freebiekr (talk) 03:53, 9 September 2011 (UTC)
  288. Symbol support vote.svg  Support Amol.Gaitonde (talk) 11:08, 9 September 2011 (UTC)
  289. Symbol support vote.svg  Support Sounds very convenient. --Soppakanuuna (talk) 12:43, 9 September 2011 (UTC)
  290. Symbol support vote.svg  Support Olsi (talk) 14:38, 9 September 2011 (UTC)
  291. Symbol support vote.svg  Support Ruben JC (Zeorymer) (talk) 16:00, 9 September 2011 (UTC)
  292. Symbol support vote.svg  Support It sounds like a very good idea. -- Marek69 (talk) 17:18, 9 September 2011 (UTC)
  293. Symbol support vote.svg  Support Bonaber (talk) Great idea! 18:12, 9 September 2011 (UTC)
  294. Symbol support vote.svg  Support Yes kekistar (Discusión) 15:58, 9 September 2011 (UTC)
  295. Symbol support vote.svg  Support -- OperRu32TALK -- 21:22, 9 September 2011 (UTC)
  296. Symbol support vote.svg  Support -- I think it would be helpful. Warfieldian (talk) 22:10, 9 September 2011 (UTC)
  297. Symbol support vote.svg  Support . Good idea. Rehman 03:25, 10 September 2011 (UTC)
  298. Symbol support vote.svg  Support -- CristianCantoro (talk) 07:41, 10 September 2011 (UTC)
  299. Symbol support vote.svg  Support Already on the English Wikipedia, it would be very useful here. Hurricanefan25 (talk) 18:00, 10 September 2011 (UTC)
  300. Symbol support vote.svg  Support Chuck Carroll (talk) 20:15, 10 September 2011 (UTC)
  301. Symbol support vote.svg  Support --Gelpgim - disc 20:38, 10 September 2011 (UTC)
  302. Symbol support vote.svg  Support Excellent idea. Beyond My Ken (talk) 22:30, 10 September 2011 (UTC)
  303. Symbol support vote.svg  Support . Good idea. --Dezidor (talk) 10:38, 11 September 2011 (UTC)
  304. Symbol support vote.svg  Support Very usefull. --Claude villetaneuse (talk) 13:54, 11 September 2011 (UTC)
  305. Symbol support vote.svg  Support This could be of some use to some people, hey? WHY NOT!!! (can't others just not check the gadget box if they no like?) — --Benzband (talk) 15:02, 11 September 2011 (UTC)
  306. Symbol support vote.svg  Support Let's do this already, we seem to have a consensus. Feedback (talk) 17:37, 11 September 2011 (UTC)
  307. Symbol support vote.svg  Support GerFes (talk) 19:21, 11 September 2011 (UTC)
  308. Symbol support vote.svg  Support Might as well pile on; it's sensible enough and should save a little clicking around. Not like adding it's apt to hurt anything, either. Isarra (talk) 20:29, 11 September 2011 (UTC)
  309. Symbol support vote.svg  Support Bravo, bravo! Excellent! --WhiteWriter speaks 21:11, 11 September 2011 (UTC)
  310. Symbol support vote.svg  Support Sounds like a good idea to me, I'd also like to see it on all Wikis. --Hibernian (talk) 01:39, 12 September 2011 (UTC)
  311. Symbol support vote.svg  Support Bonne idée Mat.webmiss
  312. Symbol support vote.svg  Support It will be very useful. PRENN (talk) 04:56, 12 September 2011 (UTC)
  313. Symbol support vote.svg  Support --Wladyslaw (talk) 08:29, 12 September 2011 (UTC)
  314. Symbol support vote.svg  Support Since I'm one of those people who had to go through hell tracing the uploaded files, I'm all for it. Great for newbies, or even those who've been around a while, but are yet to master wikipedia's dynamics. --Compendium wmc
  315. Symbol support vote.svg  Support jep! --RoB (talk) 11:42, 12 September 2011 (UTC)
  316. Symbol support vote.svg  Support Been through it, so not much bothered any more, but I too have suffered, so I support it.JonRichfield (talk) 12:06, 12 September 2011 (UTC)
  317. Symbol support vote.svg  Support Ease of use. Nuff said. Maikel (talk) 13:38, 12 September 2011 (UTC)
  318. Symbol support vote.svg  Support (didn't we already vote for that ?). VIGNERON (talk) 19:18, 20 October 2011 (UTC)


  1. No, no, no! This would be equivalent to splitting the "My Contributions" page on all the other Wikimedia projects (Wikipedia, Wikibooks, etc.) into a "Contributions" one and a "My New Pages" (or "My Pages Created") one. Whoop whoop pull up Bitching Betty | Averted crashes 22:35, 27 August 2011 (UTC)
    Well I can't speak to the other projects but I reckon that idea would find some supporters on Wikipedia :) But basically, it's a false analogy, because "my new pages" are textual contributions (which is what Special:Contributions is designed for) and "my uploads" are (largely) images. Whilst Special:Contributions could in theory be merged with Special:ListFiles (which, crucially, shows previews of the files), that wouldn't happen for years even if it was thought a good idea. Even merging Special:NewFiles with Special:ListFiles, which seems pretty obvious, would probably not happen in much less than a year. And, bottom line, if it's useful here (particularly for newcomers, as some WMF research shows them having trouble finding their uploads), who cares what use analogous things might be elsewhere? Rd232 (talk) 00:27, 28 August 2011 (UTC)
  2. Oppose: Increasing the prominence of Special:ListFiles sounds like a good idea, but I don't think a link to 'My uploads' (Special:ListFiles) should be put next to the 'My contributions' link. There are already two easily-accessible links to the feature, available in two clicks from any page. Both links are in 'My contributions' -- 1) right at the top of the page, labeled 'uploads', and 2) at the bottom of the page, labeled 'User uploads'. Link (1) in 'My contributions' could probably be better placed, i.e. immediately to the right of the 'talk' link, instead of having the 'block log' link there. 'My uploads' are a subset of 'My contributions', so it makes sense to put a link to Special:ListFiles within the 'My contributions' page -- and not next to the 'My contributions' link. Emw (talk) 21:11, 28 August 2011 (UTC)


Does this really have to be a script? Of course it's easier to activate, but a native mediawiki implementation wouldn't be that difficult to develop. The opt-out gadget works with css (I had expected a js variable, but Ok), so that wouldn't be a problem. But internationalisation would be easier in translatewiki, and not using js would make the page more accessible (and also a bit faster). -- Bergi 11:10, 6 September 2011 (UTC)
We would appreciate if you develop this extension. A simple link, that sounds really easy. Upload wizard without heavy js would better, too because it could be used by more people. ;-) Unfortunately, I never worked with php. -- RE rillke questions? 11:54, 6 September 2011 (UTC)
Is it possible to make the page tell you how many uploads you have made? --Årvasbåo (talk) 14:14, 7 September 2011 (UTC)
No, I asked the devs but they said the number is stored nowhere. It's a pity. -- RE rillke questions? 18:42, 7 September 2011 (UTC)
Could try filing a bug to ask for it to be stored somewhere... Rd232 (talk) 22:11, 7 September 2011 (UTC)
This would be nice. a) total uploads count (log) b) number of images created by user x and alive c) live count of a) -- RE rillke questions? 18:21, 10 September 2011 (UTC)
MediaWiki implementation (development of Special:ListFiles, probably) would be great, but (a) MediaWiki development is an even more specialised skill and (b) Javascript development allows much easier and quicker feedback from users into improvements. Bugzilla30522 requested improvements to ListFiles; if we get those, that'll be a start. Maybe one day all of Rillke's script will make it into MediaWiki, but it's more likely to be 5 years away than 5 months. And having the Javascript also gives a basis for that possible MediaWiki development, because it's much easier to copy/adapt an existing structure (design/code) than start completely from scratch. Rd232 (talk) 22:11, 7 September 2011 (UTC)
Bergi's comment is just about adding the link, not creating a gallery-tool. Replacing the target of the link to a JavaScript-tool is easily possible. -- RE rillke questions? 23:55, 7 September 2011 (UTC)
I don't think Bergi's comment was about that (?) but I was actually going to suggest that it might be worth filing a bug to have a new MediaWiki option to display the "my uploads" link, pointed at Special:ListFiles, and then your script would divert that link to your script page, for those with Javascript. This would help those users with Javascript turned off. My concern was that the Javascript diverting of the link away from Special:ListFiles might be slightly delayed, and people might often click on it before it happens, and end up not seeing the script. A note/link at the top of ListFiles would help with that though, and also tell people with Javascript off what they're missing out on. This would be a pretty simple bug to implement, so there's some chance it might happen soonish, especially if we can bend the ear of a developer. Rd232 (talk) 07:34, 9 September 2011 (UTC)
File a bug, to display this link, target file-list. If a user is too fast, we can even display a note on the file-list if JavaScript is active. -- RE rillke questions? 18:21, 10 September 2011 (UTC)
There is clearly an overwhelming support for this. Can we just close it and get it out of the sitenotice? :) Personally I don't see why this was so important to put it up for a vote in the first place - even more why it had to be advertized in the sitenotice. But maybe I'm missing something. Effeietsanders (talk) 05:45, 12 September 2011 (UTC)
Agree, this has been running for two weeks and a half, with landslide support. The proposal clearly has support for the community. I thus removed the enquiry from the SiteNotice. Jean-Fred (talk) 14:08, 12 September 2011 (UTC)

Not sure if it is related to this section here.. but the "Gallery" link (tab) is wrong (on my contribs page). It points to http://commons.wikimedia.org/w/index.php?title=Special:Special:ListFiles/Saibo which has a "Special:" duplicate. --Saibo (Δ) 22:23, 3 October 2011 (UTC) 04:13, 4 October 2011 (UTC)

thanks for fixing, Adrignola! --Saibo (Δ) 04:28, 4 October 2011 (UTC)


  1. Add more localizations in User:Rd232/myuploads.js.
  2. Localizations of the disabling Gadget, in the format MediaWiki:Gadget-NoMyUploadsLink/de, MediaWiki:Gadget-NoMyUploadsLink/fr etc
  3. Add a clarification to MediaWiki:Listfiles-summary (possibly in MediaWiki's default for this message, via Translatewiki) When filtered by user (Special:ListFiles/username), only files where that user uploaded the most recent version of the file are shown. ✓  Done
  4. Add a link to the Toolserver Gallery in Commons' copy of MediaWiki:Listfiles-summary
  5. Put the contents of User:Rd232/myuploads.js somewhere in MediaWiki:Common.js
  6. Move User:Rd232/Gadget-NoMyUploadsLink.css to MediaWiki:Gadget-NoMyUploadsLink.css
  7. Move User:Rd232/Gadget-NoMyUploadsLink to MediaWiki:Gadget-NoMyUploadsLink
  8. Add to MediaWiki:Gadgets-definition, under Interface, NoMyUploadsLink|NoMyUploadsLink.css Rd232 (talk) 22:38, 24 August 2011 (UTC)

Improvements to Special:ListFiles itself are covered by Bugzilla30522 (though it may be possible to do some things in Javascript, this is not easy)

  1. Please also have it show all categories the image is sorted under. Thanks! Ingolfson (talk) 23:23, 24 August 2011 (UTC)
  2. It does not show when someone else uploaded a new version (like for example Rotatebot). /Pieter Kuiper (talk) 16:42, 25 August 2011 (UTC)
  3. Option to show all files that were originally uploaded by user xyz. Hi there, you made these suggestions to help new contributors. I experienced a problem yesterday (before knowing about this discussion) with a new user. He had uploaded several files, some of them not rotated. I helped him and set the rotatebot to heal the pictures. Afterwards this new contributor would not see those files anymore, since this list only shows those files of which he is the latest version contributor (sorry for my English). You are thinking of an extra possibility to sort the list for those files which the user has uploaded. More experienced users may understand about cropped/rotated versions and may choose the option to show only originally uploaded files, but newbies will just try to find “their” files. So I believe the standard option must be “list all files that have been uploaded by user xyz, even if somebody else overwrote that file with a newer version”. --Schwäbin (talk) 08:52, 25 August 2011 (UTC)
    Agree, by default the list should show all files a user has uploaded, regardless of what happened to the files later (with maybe some extra annotation where a file has been overwritten by someone else). That's the behaviour most users will expect, and I'm surprised it doesn't do that. Hopefully this will be done soon under Bug 30522 (but "soon" in bug terms is months...). Rd232 (talk) 01:29, 26 August 2011 (UTC)
I tend to agree. The old gallery tab (running on toolserver) showed ever image you'd uploaded, I believe. Pi.1415926535 (talk) 02:17, 26 August 2011 (UTC)
I, too, have always found it strange that the currently generated list doesn't show files that were later overwritten by another user. It would be a welcome improvement to show all files uploaded by a given user, but I agree with Rd232's suggestion that (ideally) it ought to include a notation to indicate when a given file is no longer the current version. Steve Morgan (talk) 13:19, 28 August 2011 (UTC)

The feature is very good, but I have found faults:

  • When a file has originally been uploaded at e.g. the german wikipedia and is transferred from there by a bot, the file is missing in the list. An example would be Funktionsprinzip akustisches Mikroskop.svg. Such images have to be added in the future.--Salino01 (Salino01) 05:02, 1 September 2011 (UTC)
  • There is a small bug in the program: If you have e.g. about 220 images in your list and you are displaying 50 images per side, one can switch to the next image side by clicking on the button 'next side'. If the last 20 images are displayed, the button is still highlited and switches to the first list again.--Salino01 (talk) 05:02, 1 September 2011 (UTC)

Implementation II

Behind the scenes, User:Rillke has been developing a Javascript version of ListFiles which is absolutely brilliant. This script will be used in the new top-right "my uploads" link instead of ListFiles. It's still a work in progress but already amazing. To use it now, add

if (-1 != mw.config.get("wgPageName").indexOf(mw.user.name())) importScript("User:Rillke/JSONListUploads.js");

into Special:MyPage/common.js - it gives you a link to "my uploads" in the toolbox. Comments welcome (bearing in mind it's not finished). Rd232 (talk) 10:44, 6 September 2011 (UTC)

JSONListUploads.js Discussion

Currently there is a link to JSONListUploads.js at Special:MyUploads (in the English interface only). To get this great tool to all languages translations of MediaWiki:Listfiles-summary would be needed. But this needs a translation for every language → The Link should be in the default translation. And if we include the link in the translation directly we should templateify the Tool's URL. Otherwise we have to change masses of translations if the link changes in the future.

Another option would be: We inject (directly below the headline) a link via JavaScript if the page's "wgCanonicalSpecialPageName" = "Listfiles" and delete the link from the interface message (doesn't need to be localized locally as this is done via translatewiki). Users without JS are no worse off since they cannot use the JSONListUploads.js anyway. The only question is: how to internationalize the link-accompanying text ("More options are available in the Gallery tool")? Probably in the .js directly (with fallback to English). Cheers --Saibo (Δ) 22:56, 4 October 2011 (UTC)

OTRS member permissions

Right now if we look at the user rights for the OTRS member group we see that they only get autopatrol, which has led to comments justifiably asking what the point of the group is. Certainly it provides verification of membership for the OTRS userbox and prevents tags by the edit filter for non-OTRS members adding tags to files. However, it's been brought up on the OTRS-permissions mailing list, where OTRS agents who work at both Commons and Wikipedia on getting validation for media content at either location have to deal with the difficulties imposed by deleted content referenced in emails. If a file is deleted the OTRS agent cannot check to see whether conflicting information was placed on the description page for comparison to the email that has come in regarding the file. And for files that have been deleted, OTRS volunteers must continually pester admins or make a request at Commons:Undeletion requests/Current requests‎, remember which files were requested, keep coming back to check for a restoration, then finally add the proper tags before emailing that the restoration was performed. OTRS agents working with permissions do so for both en.wiki and Commons but in many cases are an admin on one but not the other, despite the fact that files can be uploaded to either.

In order to expedite the process, reduce the workload on the limited number of admins, and acknowledge the trust already placed in individuals considered knowledgeable enough with the projects already to answer emails to our readers, it is proposed that the following rights are to be associated with the group to facilitate the operations that OTRS agents would need to perform as part of their duties and which are hindered when content has already been deleted:

  • Undelete a page (undelete)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)

Please note that the above does not include the ability to delete in the first place. – Adrignola talk 15:21, 3 September 2011 (UTC)

Sounds reasonable. Could you write or link something about how the users became OTRS members? How we can be sure they do not abuse their new rights? -- RE rillke questions? 15:29, 3 September 2011 (UTC)
What about a new usergroup like "advanced OTRS agent" which can be elected without such a high barrier like admins? -- RE rillke questions? 15:45, 3 September 2011 (UTC)
To the first, m:OTRS/volunteering is where it is requested, and that page also provides information on what the requirements are. Note that the OTRS admins are "especially interested in users who are entrusted with any special tools on local projects". As to the second, if people think it would be a good idea. I thought I'd try to reduce complexity. – Adrignola talk 15:59, 3 September 2011 (UTC)
@Adrignola, would this new permission be granted to all OTRS volunteers or only to Commons-OTRS volunteers, provided they are at all a "separate" group? --Túrelio (talk) 15:16, 8 September 2011 (UTC)
Just as when most people hear "OTRS volunteer" they're thinking of the people working on permissions for text/images and placing those tags with that orange logo on pages, that's also what I had in mind and probably didn't make very explicit. You only see the OTRS volunteers here with access to the permissions queues anyway. Since we have an OTRS-members group at Commons already and this is just adjusting their rights, it should be hopefully clearer than the parallel proposal at en.wiki as to who this would affect and include. But to answer your question very specifically, Commons-OTRS volunteers accessing the permissions queues (they are a separate group within the OTRS system itself and you can see that some people have publicly listed which queues they have access to at m:OTRS/personnel; the official list is on the private wiki). – Adrignola talk 20:34, 8 September 2011 (UTC)


  • (Edit conflict) Symbol oppose vote.svg  Oppose - I may weakly support 'deletedhistory' and 'deletedtext' tho I think only administrators should be able to review such revisions (OTRS agents already have access to private material so it's not that I'm really concerned with that). But 'undelete'? No, that's too much. If undeletions are needed COM:UNDEL is there. Use it. --Marco Aurelio (disputatio) 15:35, 3 September 2011 (UTC)
    • Pictogram voting comment.svg  Comment Undel is that slow that Users like me gave up to request something there -- RE rillke questions? 15:45, 3 September 2011 (UTC)
    • I don't see an OTRS agent restoring a file as being any worse than an admin without OTRS access blindly restoring a file based on some random number. – Adrignola talk 15:59, 3 September 2011 (UTC)
  • Symbol support vote.svg  Support : I never encountered a problem with an OTRS member regarding to the abuse of those rights. They have a hard job and need these rights. Furthermore they are "checked" while becoming a member. -- RE rillke questions? 16:53, 3 September 2011 (UTC)
  • Symbol support vote.svg  Support as per Adrignola. Yann (talk) 17:15, 3 September 2011 (UTC)
  • Symbol support vote.svg  Support tool needed for the job, should be part of job's rights.--Havang(nl) (talk) 19:35, 3 September 2011 (UTC)
  • Symbol support vote.svg  Support at least the assignment of deletedhistory and deletedtext as tools obviously needed for the job. For me, giving OTRS members undelete too is fine, but I could conceive that others may have objections like hinted by Marco Aurelio above, so not assigning undelete while getting the two other rights could be a kind of compromise. Regards, Grand-Duc (talk) 20:32, 3 September 2011 (UTC)
  • Symbol support vote.svg  Support --Anatoliy (talk) 20:42, 3 September 2011 (UTC)
  • Symbol support vote.svg  Support per Adrignola MorganKevinJ(talk) 21:13, 3 September 2011 (UTC)
  • Symbol neutral vote.svg  Neutral - I think deletedhistory and deletedtext are OK, but I'm concerned about undelete. There could have been reasons for deletion apart from permission, reasons for which even admins need to use COM:UDR instead of just undeleting - Jcb (talk) 01:42, 4 September 2011 (UTC)
  • I've suggested over at the parallel discussion on en.wiki that if such a user group were given the ability to view deleted revisions, holders of the right should need to submit the relevant ticket number to a log when viewing deleted revisions. I'm not sure if such a thing would be desired here, but I thought I would mention it. (Note that such a suggestion is dependent on changes to the software) –xeno 03:21, 4 September 2011 (UTC)
    That'd be easy to cheat, since looking at deleted revisions isn't logged (and probably there's no need I think). You can simply have a look at a deleted page or file and noone will notice that. And given the fact that until recently images could not be oversighted that's an aditional reason for me to restrict the ability to view deleted materials to few people. Elected people if possible. Of course OTRS agents (I'm one despite not being flagged as such here) work with confidential information and thus, in one hand I'm not very concerned with deletedhistory and deletedtext but on the other hand increasing in a large number (see NVO below) the access to deleted content concerns me for basic privacy reasons. Best regards. --Marco Aurelio (disputatio) 15:49, 4 September 2011 (UTC)
    My suggestion would require the software being updated to have a separate permission for logged viewing of deleted entries. –xeno 17:39, 6 September 2011 (UTC)
    Designing a log for recording views would be very difficult, since views are not logged by the software in the same manner as edits or deletes. If it was possible, though, then that would be a good idea. Ajraddatz (talk) 18:59, 17 October 2011 (UTC)
  • Symbol support vote.svg  Support granting deletedhistory and deletedtext; Symbol oppose vote.svg  Oppose granting undelete. John Vandenberg (chat) 03:26, 4 September 2011 (UTC)
  • Symbol support vote.svg  Support including undelete. I personally ignore tickets regarding deleted material on Commons because it's annoying to have to continually post undeletion requests. fetchcomms 04:00, 4 September 2011 (UTC)
  • There are 200 OTRS members who are not administrators. Just make all active OTRS folks ex officio administrators, sort of a mass coronation ;). I mean, one hundred sysops more or one hundred less - no big deal. NVO (talk) 06:29, 4 September 2011 (UTC)
  • Symbol support vote.svg  Support OTRS voluteers are trustworthy and should have the tools they need to do the job, in my humble opinion. - Hydroxonium (TCV) 07:06, 4 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose unless the Foundation agrees it's OK, and the process of OTRS access granting is clarified. There are legal implications, potentially, to substantially broadening the base of users with access to deleted material - see WMF comments at en:Wikipedia:Viewing deleted articles. Perhaps more likely than just given everyone access would be an OTRS Advanced User usergroup, given to OTRS users with current rights to view deleted material on other WMF wikis, relying on at least that process of screening. Rd232 (talk) 07:46, 4 September 2011 (UTC)
  • Symbol support vote.svg  Support Weak support for "undelete" right, strong support for the other two rights. SV1XV (talk) 07:54, 4 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose Unneeded. Ask an sysop without details. Ebe123 (talk) 17:00, 4 September 2011 (UTC)
  • Symbol support vote.svg  Support including undelete. Kropotkine 113 (talk) 16:40, 5 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose I do oppose the "undelete"-rights, but I support the other two rights. There are over 250 admins that can help with undeletions. --High Contrast (talk) 17:14, 5 September 2011 (UTC)
  • Symbol support vote.svg  Support This comes up very frequently in the OTRS permissions queues. There are a few dozen OTRS agents, many of whom are admins either here but not on the English Wikipedia (as in Adrignola's case) or on the English Wikipedia but not on Commons, and it's a royal pain in the arse trying to deal with tickets relating to deleted content on the project where you can't see it. A lot of people who email OTRS don't realise the distinction between WP and Commons, and there really isn't that much difference and the difference isn't that much—OTRS agents do much the same job on Commons as they do in the enwiki filespace, and allowing them to view and restore deleted images on both just makes everybody's lives easier. The other clear advantage is that OTRS agents take personal responsibility for the undeletions, rather than asking admins to take responsibility on the basis of a ticket the admin can't see. HJ Mitchell | Penny for your thoughts? 19:22, 5 September 2011 (UTC)
  • Symbol support vote.svg  Support for viewing deleted content, personally I also have no issues with undelete, but I can understand other people's concern, so Symbol neutral vote.svg  Neutral on undelete --Ben.MQ (talk) 19:31, 5 September 2011 (UTC)
  • Symbol support vote.svg  Support OTRS members often get requests concerning deleted media. On Commons, those requests might be users whose uploads were deleted due to incomplete information being supplied. I trust the OTRS application process. Dcoetzee (talk) 06:25, 6 September 2011 (UTC)
  • Symbol support vote.svg  Support At least deletedhistory and deletedtext should be granted because they are neccessary for all OTRS actions referring to files that are already deleted. Undelete also appreciated for the OTRS agents to finish their work without needing admin assistance in every case. --Krd (talk) 12:31, 6 September 2011 (UTC)
  • Pictogram voting comment.svg  Comment I'm afraid that this is likely to be a problem. :/ Since I'm both an OTRS agent (who is not an admin on Commons) and currently under contract by the WMF, I was hesitant whether I should say anything, but I've been told that it's okay for me to speak up. (I'm still allowed to be a volunteer. :)) I've been involved in some (limited) conversations about this, and I think it's likely that the legal department won't approve this change from the status quo. Given that, I wanted to check on an alternative. What about if we created something like a cross-wiki board for OTRS agents, maybe at the OTRS wiki, where admins on specific projects can be asked to assist in tickets by OTRS agents who are not admins there? That might diminish (if not solve) the problem without risking running afoul of legal concerns. --Moonriddengirl (talk) 19:47, 8 September 2011 (UTC)
    • That might help, but I'm not sure how practical it would be, given OTRS volume of tickets. Knowing nothing about how OTRS works, I'm slightly wondering if the system could be adapted so that a person handling a ticket could flag it as needing input/action from someone with particular permissions. Then people with those permissions can focus on those tickets. Rd232 (talk) 07:39, 9 September 2011 (UTC)
    • @Moonriddengirl, do these concerns affect all three permissions proposed by Adrignola or only the real undeletion? --Túrelio (talk) 07:58, 9 September 2011 (UTC)
      • Their concerns are for deletedtext. I've also been involved in direct discussions with the legal department in seeking to address their concerns. I don't share the concerns given that administrators are community elected while OTRS agents are privately screened and selected. Admins' actions are subject to public oversight; OTRS members' responses to emails are not. So one could say that on a certain level even more trust is placed in an OTRS volunteer than an admin. So I don't buy the argument that there'd be any higher level of legal liability should anyone but admins have access to deleted revisions, given the group of people we're talking about here. I find it offensive to imply that OTRS agents who deal with confidential information on a daily basis would not be able to keep information that has been deleted private. – Adrignola talk 12:59, 9 September 2011 (UTC)
        • Adrignola, you may know more about this than I do, as I have not been involved in direct discussions with the legal department, only overheard conversation between other staff, but I don't believe that there is any implication intended that OTRS agents are not trustworthy. :) Per conversation on the en OTRS mailing list, it seems to me that the idea is simply clearly defining a specific and limited group that has access to deleted content. (By "limited" I do not mean in terms of numbers, but specifically "this group" as opposed to "this group" and "that group" and "that group".) I'll see if I can get specifics. Another idea I tossed on the en mailing list, if this should not be permitted, is that we might create subqueues into which we could put material that needs specifically admin attention? --Moonriddengirl (talk) 17:58, 9 September 2011 (UTC)
          • Ardignola, no one is suggesting that the users aren't trustworthy. Only that the legal department, as risk managers, have identified a risk that this permission may expose us to greater liability. That's not saying people aren't trustworthy, it's lawyers trying to keep us all out of hot water.  :) Don't take it personally, it's their job. Further, this isn't them changing their mind: legal has been very clear through two general counsels that this wouldn't happen. We don't give deleted revs to people who aren't admins. Philippe (WMF) (talk) 19:30, 9 September 2011 (UTC)
            • And there is no chance to create a new user-group, which is elected like admins but get the 3 mentioned rights only? -- RE rillke questions? 20:01, 9 September 2011 (UTC)
              • I can check with legal. Generally speaking, if someone is elected like admins, is there a reason to not just elect them AS admins, though? I honestly dunno how legal will feel about it, but my gut says they'll be holding the line on this one. Philippe (WMF) (talk) 22:07, 9 September 2011 (UTC)
                • See also en:Wikipedia:Village pump (proposals)/Persistent proposals/Straw poll for view-deleted in which then-General Counsel Mike Godwin "vetoed" a previous proposal (though it was much broader than the one here). The current General Counsel, Geoff Brigham, endorsed Godwin's statement. The statements from each are at the top of the linked page. --Philosopher Let us reason together. 08:07, 18 September 2011 (UTC)
                • A lot of voters on RfA expect a large amount of contributions in the Commons-namespace or on deletion-requests. OTRS members are more active on file-pages. That's why they may fail as admins (like recently one) while nobody mistrusts them (e.g. because known from homewiki, good contribs in file-namespace, ...) -- RE rillke questions? 10:03, 28 September 2011 (UTC)
  • Symbol support vote.svg  Support OTRS members are trusted not to misuse their rights, also why not give them the tools needed for their job? —stay (sic)! 01:05, 9 September 2011 (UTC)
  • Due to several recurring concerns raised by other users, I've somewhat modified my comments above. —stay (sic)! 09:57, 13 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose 'undelete' but I support deletedhistory and deletedtext.  ■ MMXX  talk 13:53, 9 September 2011 (UTC)
  • Symbol support vote.svg  Support for these permissions for the "Commons-OTRS volunteers". --Túrelio (talk) 15:36, 9 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose without Foundation approval. Ironholds (talk) 19:38, 9 September 2011 (UTC)
  • Symbol support vote.svg  Support . Sounds sensible to me. Users with OTRS access can be trusted with these features. WJBscribe (talk) 21:46, 10 September 2011 (UTC)
  • outright Symbol oppose vote.svg  Oppose undelete function....though kinda ok with review functions as I understand the need but I still have reservations. I have previously had OTRS access including commons.permissions (resigned because I didnt/dont have the time) but in that time I deleted many copyright violations but cant recall any action I performed that was an undeletion. While OTRS are identity verified there isnt any review of a person gaining rights by this community I believe that such actions should only be performed by the people Commons Community have themselves chosen to review. Gnangarra 06:39, 12 September 2011 (UTC)
    • updated a serious review of the users within the OTRS reveals too many that arent even remotely active on commons, including one that has made one edit in 2 years. Gnangarra 14:39, 30 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose all. Creating new categories of users who have access to deleted information is always a bad idea. If a non-admin OTRS volunteer finds that they regularly need admin access, there's no reason they can't request to be made an administrator. (See also my comment in the legal discussion, above.)--Philosopher Let us reason together. 08:07, 18 September 2011 (UTC)
  • Comment. From this discussion it is clear that 'deletedhistory' may be added without any problem - it has a community support and encounters no legal objections. Ruslik (talk) 08:54, 18 September 2011 (UTC)
    • I have not heard from the legal counsel to revise comments made previously on stonewalling any viewing of deleted material even by those with access to non-public data already. The addition of deletedhistory alone would not show the file's content or the initial upload summary for any file uploaded with the Upload Wizard. So you can tell who uploaded a file? Big deal; usually they tell you they did in the email they sent. In short, this proposal is going nowhere and the relevant comments by the legal team should have been on Meta to avoid this complete waste of time. – Adrignola talk 17:18, 18 September 2011 (UTC)
  • Symbol support vote.svg  Support as per rationale on en.wiki, this should reduce bureaucracy which has to be a good thing. Eraserhead1 (talk) 11:59, 19 September 2011 (UTC)
  • Symbol oppose vote.svg  Oppose per Philosopher. Creating a new category of quasi-administrator rights would be a dispensation from the process of having to apply for an administrator status in order to use them. Horses for courses. --Gavin Collins (talk) 11:49, 21 September 2011 (UTC)
  • Symbol support vote.svg  Support for viewing richts, Symbol neutral vote.svg  Neutral on undelete. OTRS-volunteers are already given a big amount of trust, so this seems like a reasonable proposal to reduce bureaucracy. --Terfili (talk) 14:43, 29 September 2011 (UTC)
  • Support viewing rights so that OTRS volunteers are better able to answer requests, but oppose undelete. Local admins were invented for a reason, and I really don't see a pressing need for OTRS volunteers to be able to undelete pages themselves. Ajraddatz (talk) 18:56, 17 October 2011 (UTC)
  • Support - A very helpful feature indeed for OTRS volunteers. --Sreejith K (talk) 11:46, 24 October 2011 (UTC)
  • an otrs volunteer myself, i Symbol support vote.svg  Support "deletedhistory" and "deletedtext", but Symbol oppose vote.svg  Oppose giving volunteers the right to restore files/pages etc. the possibility to view deleted versions of files would be terribly helpful for everyday handling of requests. i cannot accept permission emails if i don't know the underlying picture, so i'd have to ask an administrator to somehow send me the image or describe it to me and even then i'm never quite certain about it. this is both time-consuming and, if you ask me, unnecessary. the viewing rights are a matter of trust, but given that otrs volunteers have access to information much more sensitive than that on commons, i do not possibly see a problem here. as to the right to restore content, however, i think this is not a good idea. for one, deleting (and undeleting) content is a particularly community-specific thing. commons has its own policies, practices etc. users who restore previously-deleted content should be familiar with those, as well (i actually agree with jcb on that -- scary). this, however, cannot be guaranteed for otrs volunteers. the selection process for otrs does not include a check for the user's capability to handle undeletions on commons. second, i fear that the "undelete" right is potentially a weak point for the proposed extension of otrs volunteers' privileges. the legitimacy of such a privilege is based on the community's approval for it. if wrong decisions are made by otrs volunteers, this could be critical to public support of the extension of rights for otrs volunteers as a whole. —Pill (talk) 19:11, 30 October 2011 (UTC)
  • As another OTRS volunteer, I feel the same as Pill above: Symbol support vote.svg  Support deletedhistory and deletedtext, Symbol oppose vote.svg  Oppose undelete rights. There's just no need for such rights. Undeletion should be reserved for admins elected individually by the community here at Commons. Huntster (t @ c) 01:48, 31 October 2011 (UTC)


This has been open for nearly two months, so I think it's about time for a summary.

  1. All rights
    1. Pro: 20: Rillke, Yann, Havang(nl), Grand-Duc, Anatoliy, MorganKevinJ, Fetchcomms, NVO [implicitly - make all OTRS admins], Hydroxonium, SV1XV [weak support for undelete], Kropotkine123, HJ Mitchell, Ben MQ, Dcoetzee, Krd, stay (sic), Turelio, WJBScribe, Eraserhead1, Sreejith K
  2. 'deletedhistory' and 'deletedtext': 29 pro, 6 against = 83%
    1. Pro (all rights): 20
    2. Pro (specifically): 9: Marco Aurelio, Jcb, John Vandenberg, High Contrast, MMXX, Terfili, Ajraddatz, Pill, Huntster
    3. Against: 4: Ebe123, Gnangarra, Philosopher, Gavin Collins
    4. Against unless WMF agrees: 2: Rd232, Ironholds
  3. 'undelete': 20 pro, 13 against = 61%
    1. Pro (all rights): 20
    2. Pro (specifically): 0
    3. Against: 13: Marco Aurelio, Jcb, John Vandenberg, Rd232, Ebe123, High Contrast, MMXX, Gnangarra, Philosopher, Gavin Collins, Ajraddatz, Pill, Huntster

In conclusion, there is a high enough support for asking WMF whether they can support 'deletedhistory' and 'deletedtext' (the indications are no). Support for 'undelete' is perhaps not quite high enough, but it could be included in the request, and if WMF is OK with it, it could be discussed further. Now, any suggestions on getting a definitive answer from WMF? Rd232 (talk) 22:39, 31 October 2011 (UTC)

I had been in discussion with Geoff who asked for additional information to understand the issue better. This was provided on September 4. I have not heard back. The only thing definitive at this point is that I've been told the ultimate decision rests with the Foundation. – Adrignola talk 23:55, 31 October 2011 (UTC)
Thanks for pushing this to Geoff, hopefully something will come of this in the near future. Huntster (t @ c) 05:55, 1 November 2011 (UTC)
Hi Adrignola. I want to apologize for not getting back to you. You should not have had to wait this amount of time, and I feel bad about it. I had responded to someone else about a similar issue, and, for some reason, my mind played games on me, making me think I had answered. I promise to get back by next week. Geoffbrigham (talk) 21:46, 3 November 2011 (UTC)
We are always respectful of and impressed by community initiatives. For that reason, it is tough for us to put a barrier in front of folks who are sincerely seeking a solution to a challenge. So our apologies in advance, but, to be honest, it will be difficult for WMF to support the proposed solution in this case.
Please allow me to explain in brief. With this proposal, WMF is concerned about possible increased liability for the Foundation and OTRS agents. Sensitive legal matters may be deleted, and, for that reason, increasing the size of the group who can view such deleted material could arguably increase WMF's liability. In addition, OTRS agents could risk personal liability by undeleting content that had been originally deleted for legal reasons (either by the community or WMF). We appreciate the opportunity to be consulted, and we are sorry we cannot support this. Geoffbrigham (talk) 17:30, 6 November 2011 (UTC)

Additional discussion

I didn't know where else to put this, so I was bold and created a sub-header!

I'm wondering if people might feel less concerned about this if it were only to be granted to OTRS agents who are already admins on the English Wikipedia (or other "big" WMF wikis, but most OTRS tickets seem to relate to enwiki content)? HJ Mitchell | Penny for your thoughts? 22:18, 5 September 2011 (UTC)

Well, there seems to be pretty good support for the current proposal here without any qualifications added to it. This might be something to suggest at the parallel proposal at en.wiki. Can't quite agree with your last statement, as most tickets sent to permissions-en would be en.wiki content, most sent to permissions-commons would be Commons content (and OTRS people with access to one have access to the other). Then there's tickets linking to the en.wiki mirror location of Commons content sent to permissions-en or linking to the place where the mirror used to be. And maybe I keep taking all the Commons tickets, leaving few for you. :) – Adrignola talk 00:59, 6 September 2011 (UTC)

Does all the OTRS members have the same knowledge of Commons' policies?  ■ MMXX  talk 14:03, 9 September 2011 (UTC)

Anyone in the OTRS-members group here (those with access to the permissions-commons queues) would never have gotten access to them in the first place otherwise. Perhaps this concern is why you opposed undeletion? OTRS volunteers would be restoring files marked as lacking permission or violating copyright. So more important than policies is knowledge of copyright. As the guide to adminship says, "Copyright law is not by any means a simple area, and you are not expected to know everything, but admins should have a decent understanding of our current policies and practices". So admins don't have to be copyright experts, but OTRS volunteers practically must be, as nobody else will check a ticket to verify an OTRS agent's claim that everything is good unless the ticket is questioned, input is solicited, or someone is curious. – Adrignola talk 14:50, 9 September 2011 (UTC)
Yes, that's why I opposed, I somehow agree with the HJ Mitchell's comment above, I'm not concern about OTRS members who are already admin on other big projects but I'm not sure about giving this right just to anyone, on the other hand, I agree that it's easier and faster that OTRS members could be able to handle undeletion requests by their own.  ■ MMXX  talk 16:43, 9 September 2011 (UTC)
  • Are OTRS user trust worthy well my quick checking shows some are doubtful, others clearly dont the experience on Commons to show that they even understand our policies and requirements(see below). Additionally this has the appearance of a backdoor approach to the perennial request for admins on other projects to be given automatic admin rights on Commons something this community has rejected many time before. Gnangarra 01:18, 14 September 2011 (UTC)
  • If a user is trusted and competant enough to be answering OTRS emails, I don't think that there is a need to limit these rights to only users who are admins on some wikis. I'd prefer to have some sort of discussion before assigning the otrs flag to users here. Ajraddatz (talk) 19:09, 17 October 2011 (UTC)
  • As someone who was an OTRS volunteer before being an admin anywhere, there is plenty that a competent and trustworthy volunteer can offer without being an admin. Accessing deleted material is essential for some requests on OTRS, but these are the minority. The OTRS volunteer acceptance process should ensure that volunteers are trustworthy to handle confidential material and we should then be able to trust the volunteer's judgement to only handle OTRS requests that they have sufficient policy knowledge and experience to address competently. This change would make my life slightly easier on Commons, however having never been involved in a case where someone's OTRS access was revoked, I suspect there may be a (theoretical?) issue with granting rights on Commons which have no open process for the Commons community to remove if trust is lost through poor behaviour. -- (talk) 13:54, 31 October 2011 (UTC)

I know that one can watch a file without actually undelte it.

  1. Does the "undelte" right enable this functionality, too?
  2. Is this event logged somewhere to see abuse?

-- RE rillke questions? 09:50, 8 September 2011 (UTC)

Anyone can watch any file, whether it has ever existed or never existed. Undeletions are logged like deletions. In the same log, in fact. – Adrignola talk 03:24, 9 September 2011 (UTC)
Sorry, I expressed myself unclearly. With watch, I meant view. I read this and my question is whether viewing a deleted image is logged. -- RE rillke questions? 07:36, 9 September 2011 (UTC)
The viewing of deleted revisions is not currently logged in the software (for admins or otherwise), but it's been mentioned as something that some people would like to have. – Adrignola talk 13:01, 9 September 2011 (UTC)
There are a few bugs about "undeletion" and "log" on bugzilla but not what I was looking for. Should I file a bug (feature request)? Or did I miss something? Thanks. -- RE rillke questions? 13:48, 9 September 2011 (UTC)
What feature? as Adrignola said, viewing of deleted revisions (page or file history} is not logged and IMO it doesn't need to be logged, but undelete actions are logged.  ■ MMXX  talk 14:35, 9 September 2011 (UTC)
You may call me a control-freak. But I would appreciate logging viewing deleted content to see abuse if the undelete-right is granted to OTRS-members. But let's see whether other users have the same desire. -- RE rillke questions? 17:03, 9 September 2011 (UTC)
Abuse by viewing or undeleting? because these two are different.  ■ MMXX  talk 18:27, 9 September 2011 (UTC)
I want a log-event being triggered when someone looks at a deleted file or file-revision and when restoring (the latter is implemented, I know). I don't know what terminology MW uses for this. -- RE rillke questions? 18:47, 9 September 2011 (UTC)
Why? deleted contents were once accessible for everyone and IMO there is no risk of misusing, also OTRS members are trusted and they already have access to nonpublic information.  ■ MMXX  talk 19:03, 9 September 2011 (UTC)
If I'm not mistaken, there is no logging of viewing content or logs in MediaWiki at all, on the grounds of fundamental principles of privacy. Logging the views (even of deleted contents) sounds absolutely unacceptable. Logs can only be taken on actions that change content or metadata. --Krd (talk) 19:13, 9 September 2011 (UTC)

Protection of privacy of users who upload the wrong image etc. is much more important than cover up an admin's or OTRS member's action. There is nothing to protect and I can see absolutely no problem with logging it. Whether this log is public or for admins only visible is another question. Logs were always a good method to unveil problems without actually showing the content. Viewing deleted content requires elevated privileges and use of them should be logged. -- RE rillke questions? 19:53, 9 September 2011 (UTC)

Per Krd - I see absolutelly no need to log who looks at deleted revisions. Other "risky" log views are not (at least publicy) logged, either. I recommend reading Commons:Privacy_policy#Reading_projects. Logging publicy what I look or leave to look is unnaceptable for me. --Marco Aurelio (disputatio) 13:58, 12 September 2011 (UTC)
Using admin's button is not "reading". It is viewing deleted content which is not publicly visible. Checkuser is also logged and it is just a "viewing something without changing content", too. And it is good that it is logged. -- RE rillke questions? 10:41, 13 September 2011 (UTC)
By viewing a deleted page I am, in fact, reading it's content deleted or not. Using CheckUser is logged of course (and it's good as you say) but for example viewing the CU log or the OS logs are not logged (not publicy at least, maybe in non-public raw database logs). That's what I intended to say. --Marco Aurelio (disputatio) 10:45, 13 September 2011 (UTC)
I never suggested logging viewing of a log. That really makes no sense. Since the deleted contend is not visible and there is maybe room for abuse, I thought it's better to have a log. When viewing deleted content, one has a specific reason given and reasoned by the function as administrator for doing so, therefore I see no problem with logging it. The undelete feature is not for "private reading". -- RE rillke questions? 14:03, 13 September 2011 (UTC)
From what I know of how the mediawiki software logs views, having a log for views would be very difficult, and would involve some redesigning of the current system of looking at deleted revisions. Actions such as blocks and deletes are easily logged, as a database is being modified. If each page view were recorded in a database in such a manner, then Wikipedia would require thousands of servers and be very, very slow. When viewing deleted versions of files, there is a message "Do you want to view revision blablabla of File:Blablabla.png?" and a button that must be clicked to continue - whether or not that action is added to a database I'm not sure. Ajraddatz (talk) 19:09, 17 October 2011 (UTC)
If such a log were available then I'd support it being enabled. Transparency is rarely a bad thing. Ajraddatz (talk) 19:10, 17 October 2011 (UTC)


Instead of giving OTRS users permissions on Commons why cant Commons Admins, Crats(subject to id requirements) be given automatic access to the OTRS commons queues, this would be simpler solution. Gnangarra 07:13, 12 September 2011 (UTC)

Perhaps someone could clarify how common it is for Commons admins not to have OTRS access; that's certainly one area that would make sense to address if it's common. This might also complement my thought above, that the OTRS system could perhaps be adapted so that a person handling a ticket could flag it as needing input/action from someone with particular permissions. Then people with those permissions can focus on those tickets. Rd232 (talk) 12:09, 13 September 2011 (UTC)
Just compare Commons:Administratoren and Category:Commons OTRS volunteers. --Túrelio (talk) 12:24, 13 September 2011 (UTC)
Well a detailed comparison would be some work :) but the headline numbers are 263 admins and 175 OTRS volunteers, so clearly there is some room for improvement. Rd232 (talk) 13:00, 13 September 2011 (UTC)
The manual listing and category may not be accurate since you have to add yourself or add a userbox. Better to look at Special:ListUsers/OTRS-member and note how many do not have admin access. I recently asked for removal of inactive OTRS members at the bureaucrats' noticeboard, so this list also contains only active members to boot. – Adrignola talk 13:36, 13 September 2011 (UTC) – Adrignola talk 13:36, 13 September 2011 (UTC)
That OTRS list isnt all well that maintained, I can readily identify 2 editors who have previously had RFA declined, another editor who has made two edits on commons since May 2010, another who had made 1 edit since Mar 2009. I also can identify a user who left a chapter committee under questionable circumstances. What would be more useful is for that list to show what queues these members have access to and remove the OTRS rights from users who dont have access to the commons queues. Do some much needed house keeping, show us that its being maintained appropriately before asking us extend trust to this user group. Gnangarra 01:15, 14 September 2011 (UTC)
I asked for those who no longer have access to OTRS to be removed from the list. Everyone in that list has access to OTRS regardless of how much or little they do on Commons currently or whether they failed an RFA. I am not an OTRS admin so I have no power to force anyone out of the system if they aren't pulling their weight. Only those with access to the permissions-commons queues should be a member of this group. – Adrignola talk 01:19, 14 September 2011 (UTC)
Then that list needs to be addressed as editors who dont have the experience or the knowledge of Commons policies should not be answering those questions, and they definately should not be given permission to undelete files. Gnangarra 01:31, 14 September 2011 (UTC)

Clarifying attribution requirements

A recent VP discussion prompted some thoughts on making it clearer how reusers should attribute credit.

Currently we have

  1. Commons:Reusing content outside Wikimedia, which isn't really clear on this
  2. Commons:Credit line which does the job, but isn't easy to find.
  3. a small "use this file" link at the top of the file description page, which is easily overlooked. (It's bigger for logged-out users though.)
  4. {{Credit line}} which works with the {{Information}} and {{Artwork}} templates; it is added into the "other_fields" parameter of {{Information}} and {{Artwork}}. Note that {{Artwork}} has a "credit line" parameter which is used for attributing credit to donors of artworks, and has nothing to do with the image license.
  5. User attribution templates, most of which are not listed in Category:Attribution templates.

We can talk about other licenses too, but I think the biggest problem is with CC-BY-SA (as it's the most common requiring attribution). The license template states You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). But typically the author doesn't specify anything, which can easily be confusing.

There are several things we can do:

  1. Merge Commons:Credit line into Commons:Reusing content outside Wikimedia. I think that would help a lot, since the latter is linked from the Information/Artwork templates under "reusing this file".
  2. Make the "use this file" link much more prominent. Put it next to the "reusing this file" link to Commons:Reusing content outside Wikimedia. (Some way of explaining the difference is needed then.) And/or make the link part of every license template, so that it appears at the bottom of the Licensing section.
  3. Have each license template display the standard way of attributing credit for that license (with a parameter to optionally suppress it, though it should anyway be made clear that any specific author wishes override the standard). Commons:Credit line provides guidance on the standard ways, and the relevant templates can incorporate these.
  4. Create a {{user standard attribution}} template which, given the uploader's user name, displays the contents of the page Username/attribution, if it exists (which is a page in the user's userspace using the {{credit line}} field. This would reduce the proliferation of template-space templates used for this purpose.
  5. Add an "image attribution" field to the {{Information}} and {{Artwork}} templates, so that it's clearer how to add a custom attribution.

Well, those are some thoughts, let's have some discussion. Comments please! Rd232 (talk) 13:12, 17 October 2011 (UTC)

In order to address the problem I made my own permission template. User:Nevit/Not-PD I tried to address the major problem I encounter: Usage without attribution outside commons. I added how to attribute paragraph above license template and a couple of extra words below. --Nevit Dilmen (talk) 16:55, 17 October 2011 (UTC)
Very nice overview ; but you did miss the attribution parameter of the CC templates. See for example File:GLAM WIKI UK 2010 - Tom Morgan - National Portrait Gallery - 3.JPG. I think this is the simplest way to specify a custom attribution. Jean-Fred (talk) 17:13, 17 October 2011 (UTC)
(Which does not address your proposal entirely, only 4 & 5. I should not read too fast.) Jean-Fred (talk) 17:18, 17 October 2011 (UTC)
I created Commons:Credit line and {{Credit line}} after some discussions on VP without any knowledge of Commons:Reusing content outside Wikimedia existence. I agree that they could be merged; however, what I was aiming in Commons:Credit line was to provide look-up tables of examples of minimal attribution for each license without much talk. May be we can copy some examples from it to Commons:Reusing content outside Wikimedia, but keep the Commons:Credit line as page of examples.
I am not sure about adding "image attribution" field to the {{Information}} and {{Artwork}} templates. That was my original proposal but as many other proposals there was no interest in it. That is why I created {{Credit line}} and why others added attribution fields to many license templates. So now we have two competing standards, I am not sure if we need a third one. I actually like attribution parameter in license template; however, I am rather unhappy that requested attributions are usually not valid. For example attribution in File:GLAM WIKI UK 2010 - Tom Morgan - National Portrait Gallery - 3.JPG asks for "© Benjamin Smith / Wikimedia Commons" omitting "GFDL / CC-BY-SA-3.0-2.5-2.0-1.0" part required by the license. That is providing wrong information.
Also lets not forget about "use this file" icon which creates attribute line based on the image data using some gadget (not sure which one). That is the 3rd way to get attribution line, but I do not know where is the documentation of that gadget. I also do not know if it follows author's wishes by reading the other 2 ways. --Jarekt (talk) 18:38, 17 October 2011 (UTC)
This is MediaWiki:Stockphoto.js. It does leverage on {{Credit line}} & attribution parameter.
I think the way the attribution parameter is asked in CC templates is fine and logical : in our example, the author wishes to be attributed as "© Benjamin Smith / Wikimedia Commons". Indeed, this is only one part of the credit line, so maybe the template should render the full credit line. Which is given by the "Use this file" button.
If there is consensus to do so, I think we should consider retiring {{Credit line}} in favor of attribution parameter. I think it makes more sense. Jean-Fred (talk) 19:25, 17 October 2011 (UTC)

Thanks for those initial comments - I'm glad there is some interest in discussing this. However I'm not sure I've kicked off the discussion in the clearest possible way, because several related but separable issues are mixed up. I was trying to survey how things are done (and missed the attribution parameter in some licenses - thanks Jean Fred), but we really need to think about what problems we're trying to address.

  1. Standard attributions. Making it very clear to reusers on a file page (a) that a standard attribution is required (for some licenses). Jarekt pointed out some 2009 discussions on VP where this was raised. (b) make it clear what the nature of that standard attribution is. The information in the "use this file" link (MediaWiki:Stockphoto.js) and in Commons:Credit line needs to be more prominent. On a file page at least the minimum attribution needs to be visible without needing to click (Stockphoto.js can provide more attribution options, and the link to it needs to be more prominent - not necessarily bigger, but more closely linked with attribution requirement).
  2. Custom attributions. Making it easier for uploaders to specify custom attributions, including custom attributions that are reusable across files via a template. It makes sense to store this in the user's userspace in a standard location/format, rather than (as now) use templates in template space. Templates and tools can then access this data more easily. It also makes it easier to develop and display contextual guidance on creating such custom attributions (via editnotice perhaps), so that they make sense and don't conflict with license or other requirements.
  3. Attributions overview. Commons:Reusing content outside Wikimedia needs to contain this information as well; and looking at it again, I think merging Commons:Credit line into makes a lot of sense (eg Credit line is currently in only 2 languages), putting everything reusers need in one place.

The issue of having two competing ways for displaying custom attribution data ({{Credit line}} and the attribution parameter in license templates) for me maps the overlap between the {{Information}} template and the license templates. I don't really see that it's helpful to do it this way. It would make more sense to me if {{Information}} did everything on a typical file page: tell it what licenses apply (none of this "permission: see below" unhelpful confusion) and it displays the relevant license template(s), together with any standard or custom attribution data. It can put the license templates below the summary box, so the aesthetics don't change much (apart from losing the Licensing header). Rd232 (talk) 23:47, 17 October 2011 (UTC)

It seems to me that stockphoto ("use this file") does a fairly good job in showing that there is some attribution to be made and it is very visible for non logged in users (who I guess are the most likely to commit this kind of copyvio). But I think that hurried users will not want to go into the details of help page or even license tags just for using an image. (after all the site advertises itself as "freely resusable" so one might not car about the details). I think that a small license tag near the license would be a good compelement to a lengthy license tag one screen away that many people do not care to read. I would suggest either add another icon on the "use this file"
I would imagine something like this.
Cc.logo.circle.svg    Attribution: John Doe
Some rights reserved // linking to the license tag
Gnome-emblem-web.svg use this
Tango style Wikipedia Icon.svg use this
Gnome-mail-send.svg email
Gnome-document-save.svg download
I would even suggest to replace the remove the "informations" link from this bar because it links to a lengthy -so scary- page while all info should already be in the license. We could have a link to Commons:Reusing content outside Wikimedia in a "learn more" section", for instance at the end of the license tag. I think people we need primarily deal with are those that are unwilling to read long text for the license.--Zolo (talk) 09:23, 21 October 2011 (UTC)

Adding CatDown link for categories

I think will be good idea to add link to CatDown to categories tool box or to tabs. If it'll be implemented as gadget, this gadget could be default one. --EugeneZelenko (talk) 14:49, 25 October 2011 (UTC)

I'm cautious about adding prominent links to Toolserver tools, because the Toolserver is always having capacity issues. Adding as a gadget would be an option, but not on by default. Such a gadget could add a link to CatDown into the Toolbox on category pages (so that clicking the link would prepopulate CatDown's category field with the relevant category). User:Rillke is one who could knock up such a gadget. Alternatively, it could be added to MediaWiki:Gadget-ExtraTabs2.js. Rd232 (talk) 16:18, 31 October 2011 (UTC)

Add more guidance at Commons:Deletion requests

In view of some recent discussions (which we needn't discuss here, hopefully, so I won't link to them), it seems clear that it would be helpful to have a little more guidance to administrators about the community's expectations of how deletion requests are handled. I propose adding to Commons:Deletion_requests#Instructions_for_administrators:

Administrators are encouraged not to close requests where discussion has stopped but unresolved issues remain. Administrators should always be aware that even a strong consensus can never trump copyright law nor override Commons Policy.
Administrators closing deletion requests are expected to provide adequate explanation for their decision. In many cases, where there is little discussion and no disagreement with the request, no details are required. However the more complex a discussion, and the more users have argued for the opposite outcome than the administrator's decision, the more a clear explanation of the decision is required. In any event, administrators are expected to clarify or explain their decisions on request.

The context for this addition can be seen here. I believe my addition is not any new requirement, just a description of what the community expects. It is carefully worded not to create any simplistic requirement admins must remember in closing discussions, just general guidance. The only firm part of the wording is the requirement to explain or clarify on request, which surely cannot be controversial. Note also that Commons:Deletion requests is not formally a policy or guideline, which perhaps limits how controversial it should be to make such additions to it. Rd232 (talk) 17:21, 31 October 2011 (UTC)

OK, this risks getting more complicated than I expected. I'm going to split the proposal into two parts, and I've taken the liberty of moving relevant comments into a subsection. Rd232 (talk) 12:17, 1 November 2011 (UTC)


Proposal: add

Administrators closing deletion requests are expected to provide adequate explanation for their decision. In many cases, where there is little discussion and no disagreement with the request, no details are required. However the more complex a discussion, and the more users have argued for the opposite outcome than the administrator's decision, the more a clear explanation of the decision is required. In any event, administrators are expected to clarify or explain their decisions on request.
  1. Symbol support vote.svg  Support as proposer Rd232 (talk) 12:17, 1 November 2011 (UTC)
  2. Symbol support vote.svg  Support Always implied, good to have it set out explicitly. --Skeezix1000 (talk) 12:38, 1 November 2011 (UTC)
  3. Symbol support vote.svg  Support - indeed, the reason for the decision should be clear. /Pieter Kuiper (talk) 12:42, 1 November 2011 (UTC)
  4. Symbol support vote.svg  Support makes sense that admins should explain decisions especially in disputed cases. Warfieldian (talk) 15:50, 1 November 2011 (UTC)
  5. Symbol support vote.svg  Support Frankly mad when we have to state the utterly obvious but apparently that is now necessary --Herby talk thyme 09:02, 2 November 2011 (UTC)
  6. Symbol support vote.svg  Support Good to make this explicit. --Avenue (talk) 00:36, 3 November 2011 (UTC)
  7. Symbol support vote.svg  Support Sensible. --Walter Siegmund (talk) 21:50, 5 November 2011 (UTC)


Proposal: add

Administrators are encouraged not to close requests where discussion has stopped but unresolved issues remain. Administrators should always be aware that even a strong consensus can never trump copyright law nor override Commons Policy.

Deletion requests must be decided at some time, also when there is no consensus. When discussion has stopped, there is no point in keeping the DR open. I agree with the second part, about giving a rationale for the decision. /Pieter Kuiper (talk) 17:29, 31 October 2011 (UTC)
Discussion can stop without reaching a conclusion. What I'm trying to suggest is that administrators should be encouraged to ensure a conclusion is reached, and not just close a discussion with unresolved issues by counting heads. I didn't want to go into too much detail, but I didn't mean just leaving such situations open indefinitely, but actively trying to move them forward - for example when there are unanswered questions, by trying to get answers to them, either from the people they're addressed to, or from others. Maybe an extra sentence would help explain that. Rd232 (talk) 17:36, 31 October 2011 (UTC)
If we are to accept that rule, though, there would have to be a time limit. At some point it makes sense to acknowledge that there is simply no consensus for something and/or that people aren't interested enough to comment/work towards a consensus. There shouldn't be any long-term deletion requests - it's just unprofessional. --Philosopher Let us reason together. 21:39, 31 October 2011 (UTC)
I wouldn't use the word rule; this is guidance on what is expected of administrators, not rules requiring something. Administrative discretion and judgement is expected. Perhaps you're right though that some guidance on time limits is needed. There could be a two-step time limit combined with some way of bringing extra attention to these particularly difficult DRs. Something like: if there's no conclusion in 1 month, list the DR for extra attention (in a manner to be agreed), and give it a further month. If it's still not resolved then, default to keep if it's a scope issue, and default to delete if it's a copyright/permission/licensing issue. Allow exceptions at administrator discretion if there is a specific reason to give more time. Of course, this is going into different territory than I had in mind, by creating new guidelines, but maybe that's necessary. Rd232 (talk) 22:01, 31 October 2011 (UTC)
There is just the question: "Which way should a DR where is no consensus/ not enough copyright knowledge should be decided?" And I am sure there is no general answer to this question. Should possibly unfree files being kept? Should we delete those files that are, additionally probably highly used? That's why I would not favorize a "time-limit". Those conroversal DRs should be on a more prominent place, maybe — in order to get more people engaging in discussion. -- RE rillke questions? 12:07, 1 November 2011 (UTC)
OK, we could just have a time limit for making the DR more prominent, say 1 month, and then leave it open-ended. How can we get DRs that need it more attention? (How many of these old DRs are typically open?) Rd232 (talk) 12:20, 1 November 2011 (UTC)

Pieter will be shocked to hear that I agree with him. Personally, I think the first sentence is way too vague, open to abuse, and is frankly a solution in search of a problem. In discussions where there is an unresolved issue and it is being meaningfully pursued (someone is chasing down OTRS, someone has volunteered to make inquiries with a source, etc. etc.), discussions are almost always left open. I just find the first sentence to be an unnecessary level of instruction creep. I have always seen admins use common sense when closing such discussions. Automatic arbitrary time extentions seem pointless - strikes me as simply a vehicle to allow copyvios to linger unnecessarily, or properly licensed/public domain images to remain in purgatory. If there are discussions that would benefit from wider participation, perhaps we should have a noticeboard of some kind that would allow either people to solicit more input. If a DR gets listed, then perhaps there is an automatic 7 day extension before it is closed, although these discussions typically last as long as they need to (a mandatory month is just silly). But there should be some sort of proactive step before anything gets triggered (either a participant who would like further input or a closing admin who sees that the issue is not fully resolved). --Skeezix1000 (talk) 12:53, 1 November 2011 (UTC)

The second sentence is redundant. The instructions already say: "The debates are not votes, and the closing admin will apply copyright law and Commons policy to the best of his or her ability in determining whether the file should be deleted or kept. Any expressed consensus will be taken into account so far as possible, but consensus can never trump copyright law nor can it override Commons Policy. " /Pieter Kuiper (talk) 13:00, 1 November 2011 (UTC)
Fair enough. I have no problem repeating it, but others may see that as unnecessary. --Skeezix1000 (talk) 13:06, 1 November 2011 (UTC)
I'm aware of the redundancy; I see the first mention as more directed at participants, the second specifically at admins to emphasise that closure is not by headcount but by substance. Rd232 (talk) 13:27, 1 November 2011 (UTC)
Normally I'd say that making it harder for admins to decide issues is a bad idea. But after reading the de-sysop discussion elsewhere maybe you have a point. –Be..anyone (talk) 11:06, 4 November 2011 (UTC)