Commons:Village pump/Proposals

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

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.

Notes
  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. Bugzilla: 30522 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)[reply]

Support

Support - much easier

  1. As proposer. Rd232 (talk) 22:38, 24 August 2011 (UTC)[reply]
  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)[reply]
    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)[reply]
  3. Support, I think it's a great idea. Kelly (talk) 23:18, 24 August 2011 (UTC)[reply]
  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)[reply]
  5.  Support Support, with or without gadget. Good idea.--Jebulon (talk) 23:25, 24 August 2011 (UTC)[reply]
  6.  Support InverseHypercube (talk) 23:25, 24 August 2011 (UTC)[reply]
  7.  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)[reply]
  8.  Support Great idea for newbies Rastrojo (D•ES) 00:59, 25 August 2011 (UTC)[reply]
  9.  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)[reply]
  10.  Support Good and useful idea.   ■ MMXX  talk  01:26, 25 August 2011 (UTC)[reply]
  11.  Support --Forwhomthebelltolls (talk) 14:33, 30 August 2011 (UTC)[reply]
  12.  Support useful link with good visibility. --Jovian Eye storm 01:58, 25 August 2011 (UTC)[reply]
  13.  Support Fantastic idea. Would make things a lot easier. Swarm (talk) 01:59, 25 August 2011 (UTC)[reply]
  14.  Support Awesome idea that will be very useful. King Curtis Gooden (talk) 02:24, 25 August 2011 (UTC)[reply]
  15.  Support Themfromspace (talk) 02:55, 25 August 2011 (UTC)[reply]
  16.  Support Definitely a good idea. Michael Barera (talk) 03:09, 25 August 2011 (UTC)[reply]
  17.  Support With this feature all categories "Uploads by User XXX" become unnecessary! -- Simisa (talk) 06:19, 25 August 2011 (UTC)[reply]
  18.  Support -- penubag  (talk) 06:24, 25 August 2011 (UTC)[reply]
  19.  Support A great idea. Novice7 (talk) 07:26, 25 August 2011 (UTC)[reply]
  20.  Support Petritap (talk) 08:08, 25 August 2011 (UTC)[reply]
  21.  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)[reply]
  22.  Support --Marco dimmi! 09:05, 25 August 2011 (UTC)[reply]
  23.  Support It is necessary for commons. --Vssun (talk) 09:10, 25 August 2011 (UTC)[reply]
  24.  Support Support -- Raghith 09:20, 25 August 2011 (UTC)[reply]
  25.  Support So useful --Elitre (talk) 09:22, 25 August 2011 (UTC)[reply]
  26.  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)[reply]
  27.  Support This would be a very useful tool not only for beginners! --OhWeh (talk) 10:05, 25 August 2011 (UTC)[reply]
  28.  Support Very usefull --Haneburger (talk) 10:14, 25 August 2011 (UTC)[reply]
  29.  Support--Great idea. Vibhijain (talk) 10:50, 25 August 2011 (UTC)[reply]
  30.  Support --Stryn (talk) 13:01, 25 August 2011 (UTC)[reply]
  31.  Support--Mike1979 Russia (talk) 13:07, 25 August 2011 (UTC)[reply]
  32.  Support--Gareth (talk) 13:15, 25 August 2011 (UTC)[reply]
  33.  Support Would be very useful for me. Léna (talk) 14:03, 25 August 2011 (UTC)[reply]
  34.  Support Great idea! AnaJur (talk) 14:17, 25 August 2011 (UTC)[reply]
  35.  Support It's very good idea. Electroguv (talk) 14:50, 25 August 2011 (UTC)[reply]
  36.  Support Great idea! --Dtarazona (talk) 15:01, 25 August 2011 (UTC)[reply]
  37.  Support especially as the toolserver gallery fails often. Shyamal (talk) 15:07, 25 August 2011 (UTC)[reply]
  38.  Support why not? -- ianusius ✆ Disk. 15:12, 25 August 2011 (UTC)[reply]
  39.  Support What a great idea! — Preceding unsigned comment added by Jay8g (talk • contribs) 15:14 (UTC)
  40.  Support useful tool. Should get an easy access --High Contrast (talk) 15:17, 25 August 2011 (UTC)[reply]
  41.  Support Good Estratocastro (talk) 15:18, 25 August 2011 (UTC)[reply]
  42.  Support, Though I'm not sure if I am qualified to vote. --YusuF 15:44, 25 August 2011 (UTC)[reply]
  43.  Support That makes sense. Bouchecl (talk) 15:45, 25 August 2011 (UTC)[reply]
  44.  Support--Jusjih (talk) 16:16, 25 August 2011 (UTC)[reply]
  45.  Support This is a great idea. I wholeheartedly support it. SSG Cornelius Seon (US Army, Retired) (talk) 16:39, 25 August 2011 (UTC)[reply]
  46.  Support Love it! --Ebyabe (talk) 17:13, 25 August 2011 (UTC)[reply]
  47.  Support, I find this even more useful than "My contributions". --Pierre Rudloff (talk) 17:41, 25 August 2011 (UTC)[reply]
  48.  Support yes --IIVeaa (talk) 17:42, 25 August 2011 (UTC)[reply]
  49.  Support Great idea --Beaucouplusneutre (talk) 17:57, 25 August 2011 (UTC)[reply]
  50.  Support Good idea! Georgez (talk) 18:08, 25 August 2011 (UTC)[reply]
  51.  Support --Losch (talk) 18:10, 25 August 2011 (UTC)[reply]
  52.  Support Telperion (talk) 20:25, 25 August 2011 (UTC)[reply]
  53. Pile-on  Support --Philosopher Let us reason together. 21:18, 25 August 2011 (UTC)[reply]
  54.  Support Yeaph, why not! --Jwh (talk) 21:21, 25 August 2011 (UTC)[reply]
  55.  Support For the reasons above. Editor5807speak 21:22, 25 August 2011 (UTC)[reply]
  56.  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)[reply]
  57.  Support, but expecting that this integrates watchlist-features would be technically obscure. –Be..anyone (talk) 23:20, 25 August 2011 (UTC)[reply]
  58.  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)[reply]
  59.  Support idem... Vitor Mazuco Msg 23:25, 25 August 2011 (UTC)[reply]
  60.  Support Great idea! - PKM (talk) 23:53, 25 August 2011 (UTC)[reply]
  61.  Support only if a gadget to disable is provided. ←fetchcomms 00:30, 26 August 2011
  62.  Support I didn't even know this page existed. Very useful, thanks! Ephemeronium (talk) 01:16, 26 August 2011 (UTC)[reply]
  63.  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)[reply]
  64.  Support Intresting stuff to add to Wikipedia Commons. Dhe Zerohander (talk) 02:11, 26 August 2011 (UTC)[reply]
  65.  Support} Clearly an improvement. SchuminWeb (Talk) 03:10, 26 August 2011 (UTC)[reply]
  66.  Aye. Makes sense for Commons. — [ Tanvir | Talk ] 03:43, 26 August 2011 (UTC)[reply]
  67.  Support Very useful tool, and not just for newbies. Tabercil (talk) 03:45, 26 August 2011 (UTC)[reply]
  68.  Support Usefull. Palamède (talk) 08:27, 26 August 2011 (UTC)[reply]
  69.  Support Sure --Hoangquan hientrang (talk) 09:43, 26 August 2011 (UTC)[reply]
  70.  Support Sounds like a useful addition. ZanderZ (talk) 10:10, 26 August 2011 (UTC)[reply]
  71.  Support Support, sounds good. --kuvaly|t|c| 11:07, 26 August 2011 (UTC)[reply]
  72.  Support Sounds really great and encouraging to regular uploaders like me. Hindustanilanguage (talk) 11:44, 26 August 2011 (UTC)[reply]
  73.  Support --Purodha Blissenbach (talk) 12:06, 26 August 2011 (UTC)[reply]
  74.  Support--Vassil (talk) 13:14, 26 August 2011 (UTC)[reply]
  75.  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)[reply]
  76.  Support Fantastic idea ! Trizek here or on fr:wp 13:54, 26 August 2011 (UTC)[reply]
  77.  Support Jirka Daněk (talk) 14:26, 26 August 2011 (UTC)[reply]
  78.  Support A time-saving and useful improvement. JuventiniFan (talk) 14:39, 26 August 2011 (UTC)[reply]
  79.  Support --Wmeinhart (talk) 15:15, 26 August 2011 (UTC)[reply]
  80.  Support Would make finding your own uploads much easier! Jacsam2 (talk) 15:46, 26 August 2011 (UTC)[reply]
  81.  Support Lotje ʘ‿ʘ (talk) 15:56, 26 August 2011 (UTC)[reply]
  82.  Support This would be a very useful addition. Harrison49 (talk) 16:34, 26 August 2011 (UTC)[reply]
  83.  Support Good idea. --LinuxCLP (talk) 16:55, 26 August 2011 (UTC)[reply]
  84. --Antemister (talk) 17:29, 26 August 2011 (UTC)[reply]
  85.  Support Nice idea, would definitely be useful. Fallschirmjäger ✉ 18:18, 26 August 2011 (UTC)[reply]
  86. -- Hardcoreraveman (talk) 18:21, 26 August 2011 (UTC)[reply]
  87.  Support Prima. Very good.--PjotrMahh1 (talk) 19:25, 26 August 2011 (UTC)[reply]
  88.  Support It would be very useful. --Boukeas
  89.  Support Musthave feature. B7elijah (talk) 20:58, 26 August 2011 (UTC)[reply]
  90.  Support Would be useful. Haaninjo (talk) 21:20, 26 August 2011 (UTC)[reply]
  91.  Support Much more convenient than the current system. Delaywaves talk • contribs 22:31, 26 August 2011 (UTC)[reply]
  92.  Support fully support.--Gordonrox24 | Talk 04:17, 27 August 2011 (UTC)[reply]
  93.  Support It's a good idea. --Leiem (talk) 05:02, 27 August 2011 (UTC)[reply]
  94.  Support Yes. I can't find stuff either! Agong1 27 August 2011(UTC)
  95.  Support--Citron (talk) 10:08, 27 August 2011 (UTC)[reply]
  96.  Support Finally. Regards, PETER WEIS TALK 10:33, 27 August 2011 (UTC)[reply]
  97.  Support Nice and helpful. Dysmorodrepanis (talk) 10:53, 27 August 2011 (UTC)[reply]
  98.  Support This has been long overdue. Branko Radovanović (talk) 11:08, 27 August 2011 (UTC)[reply]
  99.  Support Yann (talk) 12:17, 27 August 2011 (UTC)[reply]
  100.  Support Jmalo (talk) 14:16, 27 August 2011 (UTC)[reply]
  101.  Support --Winiar✉ 14:49, 27 August 2011 (UTC)[reply]
  102.  Support Dcoetzee (talk) 15:34, 27 August 2011 (UTC)[reply]
  103.  Support B25es (talk) 15:43, 27 August 2011 (UTC)[reply]
  104.  Support --LasseG (talk) 16:08, 27 August 2011 (UTC)[reply]
  105.  Support Nice.--Morphypnos (talk) 16:16, 27 August 2011 (UTC)[reply]
  106.  Support Good feature! CZmarlin (talk) 18:39, 27 August 2011 (UTC)[reply]
  107.  Support Do it! Williamborg (talk) 19:04, 27 August 2011 (UTC)[reply]
  108.  Support Kennyannydenny (talk) 19:07, 27 August 2011 (UTC)[reply]
  109.  Support - very good idea! Romaine (talk) 20:10, 27 August 2011 (UTC)[reply]
  110.  Support -- M 93 (talk) 21:16, 27 August 2011 (UTC)[reply]
  111.  Support - A very concise way to show just the uploads Benrr101 (talk)
  112.  Support Logan Talk Contributions 22:12, 27 August 2011 (UTC)[reply]
  113.  Support It's a nice idea --Sammy pompon (talk) 22:27, 27 August 2011 (UTC)[reply]
  114.  Support Great idea! --Yetisyny (talk) 23:45, 27 August 2011 (UTC)[reply]
  115.  Support Seems very sensible Nick-D (talk) 00:28, 28 August 2011 (UTC)[reply]
  116.  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)[reply]
  117.  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)[reply]
  118.  Support —stay (sic)! 01:59, 28 August 2011 (UTC)[reply]
  119.  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)[reply]
  120.  Support Would save time. --Thompson.matthew (talk) 04:08, 28 August 2011 (UTC)[reply]
  121. GfoleyFour 04:25, 28 August 2011 (UTC)[reply]
  122.  Support Good and useful idea. --Thomy3k (talk) 06:47, 28 August 2011 (UTC)[reply]
  123.  Support --Karelj (talk) 07:18, 28 August 2011 (UTC)[reply]
  124.  Support --ST ○ 08:07, 28 August 2011 (UTC)[reply]
  125.  Support Lymantria (talk) 08:50, 28 August 2011 (UTC)[reply]
  126.  Support - Good move..--...Captain......Tälk tö me.. 09:51, 28 August 2011 (UTC)[reply]
  127.  Support as proposed. –Tommy Kronkvist (talk), 10:43, 28 August 2011 (UTC).[reply]
  128.  Support Excellent idea. --Captain-tucker (talk) 10:57, 28 August 2011 (UTC)[reply]
  129.  Support Seems like a great idea. -Joltex (talk) 11:03, 28 August 2011 (UTC)[reply]
  130.  Support This can replace the "gallery" Richardprins (talk) 11:34, 28 August 2011 (UTC)[reply]
  131.  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)[reply]
  132.  Support Good idea! Cindamuse (talk) 12:29, 28 August 2011 (UTC)[reply]
  133.  Support Good Idea! Subin.a.mathew (talk) 15:42, 28 August 2011 (UTC)[reply]
  134.  Support Long awaited. --Ainali (talk) 15:49, 28 August 2011 (UTC)[reply]
  135.  Support It would be helpful and its a great idea! --Vaishak Kallore | വൈശാഖ്‌ കല്ലൂര്‍ (talk) 16:38, 28 August 2011 (UTC)[reply]
  136.  Support +1 --Kippelboy (talk) 18:15, 28 August 2011 (UTC)[reply]
  137.  Support A very good idea indeed. - Presidentman (talk · contribs) Wikipedia Random Picture of the Day 18:28, 28 August 2011 (UTC)[reply]
  138.  Support Spares me from having this essentially replicated on my user page. -- Mcstrother (talk) 19:17, 28 August 2011 (UTC)[reply]
  139.  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)[reply]
  140.  Support -- πϵρήλιο ℗ 21:07, 28 August 2011 (UTC)[reply]
  141.  Support Gzzz (talk) 21:13, 28 August 2011 (UTC)[reply]
  142.  Support Good idea! Biólogo32 21:36, 28 August 2011 (UTC)[reply]
  143.  Support --Davidpar (disc.) 21:49, 28 August 2011 (UTC)[reply]
  144.  Support Starus (talk) 22:08, 28 August 2011 (UTC)[reply]
  145.  Support Addresses core activity of Commons. Steven Walling • talk 23:53, 28 August 2011 (UTC)[reply]
  146.  Support - Quite similar to Upload log by user, with a larger picture. Yuval Y § Chat § 09:29, 29 August 2011 (UTC)[reply]
  147.  Support Good and useful idea! --Dirk Van Esbroeck (talk) 10:19, 29 August 2011 (UTC)[reply]
  148. Very strong support. It's a good feature. Scrawler (talk) 10:37, 29 August 2011 (UTC)[reply]
  149.  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)[reply]
  150.  Support It's a very good idea. --Rave (talk) 11:02, 29 August 2011 (UTC)[reply]
  151.  Support Handy! Smile4ever (talk) 12:29, 29 August 2011 (UTC)[reply]
  152.  Support Useful -- Kakashi-Madara (talk) 13:39, 29 August 2011 (UTC)[reply]
  153.  Support I litke it --Wilfredor (talk) 17:53, 29 August 2011 (UTC)[reply]
  154.  Support. Yes. Maybe even add it to the toolbox on user pages next to "User contributions". Drilnoth (talk) 18:54, 29 August 2011 (UTC)[reply]
  155.  Support Cool idea. --Anoopan (talk) 20:22, 29 August 2011 (UTC)[reply]
  156.  Support A handy link. --George2001hi (Discussion) 20:56, 29 August 2011 (UTC)[reply]
  157.  Support --RanZag (talk) 22:13, 29 August 2011 (UTC)[reply]
  158.  Support -- Neithsabes (talk) 23:07, 29 August 2011 (UTC)[reply]
  159.  Support. And I like Drilnoths idea. --ᛏᛟᚱᚨᚾᚨ (talk) 23:45, 29 August 2011 (UTC)[reply]
  160.  Support — Excellent idea, given the purpose of the wiki.  Hazard-SJ  ±  00:02, 30 August 2011 (UTC)[reply]
  161.  Support – Excellent idea, especially since the main purpose of this wiki is to host images. —mc10 (t/c) 03:08, 30 August 2011 (UTC)[reply]
  162.  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)[reply]
  163.  Support --MaryankoD (talk) 10:42, 30 August 2011 (UTC)[reply]
  164.  Support Obvious good idea S a g a C i t y (talk) 10:56, 30 August 2011 (UTC)[reply]
  165.  Support Ziga (talk) 11:07, 30 August 2011 (UTC)[reply]
  166.  Support --Anatoliy (talk) 12:07, 30 August 2011 (UTC)[reply]
  167.  Support Useful tool. --Shibo77 13:46, 30 August 2011 (UTC)[reply]
  168.  Support It's nice.--Jan Polák (talk) 14:29, 30 August 2011 (UTC)[reply]
  169.  Support Super! mr. Анатолий (talk) 17:25, 30 August 2011 (UTC)[reply]
  170.  Support Angelus (talk) 18:07, 30 August 2011 (UTC)[reply]
  171.  Support Dorieo (talk) 18:10, 30 August 2011 (UTC)[reply]
  172.  Support das Beste seit Langem, Danke --Böhringer (talk) 19:19, 30 August 2011 (UTC)[reply]
  173.  Support --Keithonearth (talk) 19:25, 30 August 2011 (UTC)[reply]
  174.  Support--ReijiYamashina (talk) 02:06, 31 August 2011 (UTC)[reply]
  175.  Support This is an important feature, should be done as a one click option. Beta M (talk) 02:27, 31 August 2011 (UTC)[reply]
  176.  Support A great shortcut. Jsayre64 (talk) 02:37, 31 August 2011 (UTC)[reply]
  177.  Support yes very good suggestion --Olli (talk) 06:09, 31 August 2011 (UTC)[reply]
  178.  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)[reply]
  179.  Support Very good idea--Trex2001 (talk) 08:23, 31 August 2011 (UTC)[reply]
  180.  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)[reply]
  181.  Support Simple and obvious improvement. Andy Dingley (talk) 09:48, 31 August 2011 (UTC)[reply]
  182.  Support Great idea!--ChristianSW (talk) 12:30, 31 August 2011 (UTC)[reply]
  183.  Support --Paolo77 ru (talk) 12:48, 31 August 2011 (UTC)[reply]
  184.  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)[reply]
  185.  Support Very good idea. I'm waiting for this tool for a long time. - Bzh-99 (talk) 13:23, 31 August 2011 (UTC)[reply]
  186.  Support --Nevit Dilmen (talk) 13:31, 31 August 2011 (UTC)[reply]
  187.  Support It would be a very useful tool. Sealle (talk) 15:20, 31 August 2011 (UTC)[reply]
  188.  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)[reply]
  189.  Support --CristianNX 17:29, 31 August 2011 (UTC)[reply]
  190.  Support --Geoff Who, me? 17:46, 31 August 2011
  191.  Support --Nick Michael (talk) 20:19, 31 August 2011 (UTC)[reply]
  192.  Support Very good idea! --— Habib M'HENNI [¿tell me?] 20:29, 31 August 2011 (UTC)[reply]
  193.  Support Yes FrankyLeRoutier (talk) 23:05, 31 August 2011 (UTC)[reply]
  194.  Support Useful for multiple purposes.   — C M B J   04:30, 1 September 2011 (UTC)[reply]
  195.  Support I would like it.--Salino01 (talk) 04:46, 1 September 2011 (UTC)[reply]
  196.  Support -- Ariadacapo (talk) 07:13, 1 September 2011 (UTC)[reply]
  197.  Support. Can't see why not. Jafeluv (talk) 07:17, 1 September 2011 (UTC)[reply]
  198.  Support Good idea! PAULOGARCIA2005 (talk) 07:21, 1 September 2011 (UTC)[reply]
  199.  Support Yes, please. Wiki-uk (talk) 10:15, 1 September 2011 (UTC)[reply]
  200.  Support --Avenue (talk) 14:23, 1 September 2011 (UTC)[reply]
  201.  Support --Lucien (es·m·com) 15:54, 1 September 2011 (UTC)[reply]
  202.  Support Useful addition. --Geraki TLG 17:54, 1 September 2011 (UTC)[reply]
  203.  Support Galandil (talk) 19:07, 1 September 2011 (UTC)[reply]
  204.  Support Great idea.--Pesare amol (talk) 19:22, 1 September 2011 (UTC)[reply]
  205.  Support Exellent idea! Achird (talk) 21:13, 1 September 2011 (UTC)[reply]
  206.  Support — putnik? 23:02, 1 September 2011 (UTC)[reply]
  207.  Support useful Ggia (talk) 06:12, 2 September 2011 (UTC)[reply]
  208.  Support It would be very useful. Fandecaisses (talk) 10:21, 2 September 2011 (UTC)[reply]
  209.  Support I would appreciate that. Saulus (talk) 10:28, 2 September 2011 (UTC)[reply]
  210.  Support Very useful addition. Owain.davies (talk) 10:58, 2 September 2011 (UTC)[reply]
  211.  Support Useful addition.--Josef Moser (talk) 13:26, 2 September 2011 (UTC)[reply]
  212.  Support Nice! ...Kenrick95 14:35, 2 September 2011 (UTC)[reply]
  213.  Support --Pethrus (talk) 16:25, 2 September 2011 (UTC)[reply]
  214.  Support —kallerna™ 18:26, 2 September 2011 (UTC)[reply]
  215.  Support Gamaliel (talk) 18:48, 2 September 2011 (UTC)[reply]
  216. --Aschmidt (talk) 21:48, 2 September 2011 (UTC)[reply]
  217.  Support It would be much useful, easier and quicker to reach, specially for newbies -- Massic80 Contattami 23:35, 2 September 2011 (UTC)[reply]
  218.  Support Good idea. Saves a step. Nonenmac (talk) 00:53, 3 September 2011 (UTC)[reply]
  219.  Support - snow? Bulwersator (talk) 09:09, 3 September 2011 (UTC)[reply]
  220.  Support - very helpful! --KuK (talk) 09:23, 3 September 2011 (UTC)[reply]
  221.  Support --Jakubhal (talk) 11:42, 3 September 2011 (UTC)[reply]
  222.  SupportJerzystrzelecki (talk) 12:58, 3 September 2011 (UTC)[reply]
  223.  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)[reply]
  224.  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)[reply]
  225.  Support Very helpfull.-- Bertrand GRONDIN  → (Talk) 17:45, 3 September 2011 (UTC)
  226.  Support That's genius! --Honza chodec (talk) 20:31, 3 September 2011 (UTC)[reply]
  227.  Support Froztbyte (talk) 21:07, 3 September 2011 (UTC)[reply]
  228.  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)[reply]
  229.  Support Very useful, as the majority don't upload as-much-as editing... ~ AdvertAdam talk 03:20, 4 September 2011 (UTC)[reply]
  230.  Support --Metalhead ✉ 08:19, 4 September 2011 (UTC)[reply]
  231.  Support --Ex13 (talk) 10:11, 4 September 2011 (UTC)[reply]
  232.  Support STRONG Support - It would help me review my own contributions, for updating info, data, etc. --Rsrikanth05 (talk) 12:47, 4 September 2011 (UTC)[reply]
  233.  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)[reply]
  234.  Support --MartinThoma (talk) 14:52, 4 September 2011 (UTC)[reply]
  235.  Support Definitely. I didn't even realize that Special:MyUploads exists! Rdrozd (talk) 15:06, 4 September 2011 (UTC)[reply]
  236.  Support Yes. Saves me the detour. Manxruler (talk) 16:35, 4 September 2011 (UTC)[reply]
  237.  Support --Aushulz (talk) 23:09, 4 September 2011 (UTC)[reply]
  238.  Support That's a great idea! --Mlorer (talk) 23:23, 4 September 2011 (UTC)[reply]
  239.  Support This is great idea, and may encourage people to make more contributions. ···日本穣Talk to Nihonjoe 04:06, 5 September 2011 (UTC)[reply]
  240.  Support That's a great idea! lonio17 (talk) 07:22, 5 September 2011 (UTC)[reply]
  241.  Support Not very important, but useful--Packa (talk) 08:26, 5 September 2011 (UTC)[reply]
  242.  Support Good idea, it will be helpful. Prioryman (talk) 08:54, 5 September 2011 (UTC)[reply]
  243.  Support C'est tout de même bienpratique ce lien direct. Je suis totalement pour ! --Ctruongngoc (talk) 08:58, 5 September 2011 (UTC)[reply]
  244.  Support Good idea, it's what I do with my user page at the moment! Miyagawa (talk) 10:54, 5 September 2011 (UTC)[reply]
  245.  Support Good idea, I would like to use it in the future. --Midi7 (talk) 11:22, 5 September 2011 (UTC)[reply]
  246.  Support Excellent idea ---Peterdownunder (talk) 12:36, 5 September 2011 (UTC)[reply]
  247.  Support Makes sense Jebus989 (talk) 12:46, 5 September 2011 (UTC)[reply]
  248.  Support Of course!? -- Michael F. Schönitzer 17:44, 5 September 2011 (UTC)[reply]
  249.  Support Yes please. Lionel Allorge (talk) 19:24, 5 September 2011 (UTC)[reply]
  250.  Support Alwayse wondered why it's not there. Lysy (talk) 19:58, 5 September 2011 (UTC)[reply]
  251.  Support YES, it is easy to see the images instead of finding them through your watchlist. -- Spesh531 (talk) 22:19, 5 September 2011 (UTC)[reply]
  252.  Support Make it so! --Mav (talk) 23:54, 5 September 2011 (UTC)[reply]
  253.  Support YES ! --MadriCR (talk) 00:23, 6 September 2011 (UTC)[reply]
  254.  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.[reply]
  255.  Support --Helios13 (talk) 06:08, 6 September 2011 (UTC)[reply]
  256.  Support Support, I have often wished for something similar and could not find it. Phil Konstantin Philkon (talk) 06:54, 6 September 2011 (UTC)[reply]
  257.  Support Kiltpin (talk) 13:46, 6 September 2011 (UTC)[reply]
  258.  Support Seems very useful. -- sarang사랑 08:58, 6 September 2011 (UTC) But:[reply]
    • 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.  Support Great idea.--Edgars2007 (talk) 14:01, 6 September 2011 (UTC)[reply]
  260.  Support strongly. Very good idea! Eduarda7 (talk) 14:04, 6 September 2011 (UTC)[reply]
  261.  Support A very good idea, it seems useful. Surt Fafnir (talk) 14:42, 6 September 2011 (UTC)[reply]
  262.  Support Good Idea. Usefull. --Willi Wallroth (talk) 18:23, 6 September 2011 (UTC)[reply]
  263.  Support Great idea. --S nova (talk) 20:04, 6 September 2011 (UTC)[reply]
  264.  Support Looks to be a good feature. Matthewrbowker (talk) 23:03, 6 September 2011 (UTC)[reply]
  265.  Support SarahStierch (talk) 23:48, 6 September 2011 (UTC)[reply]
  266.  Support Banfield - Amenazas aquí 02:04, 7 September 2011 (UTC)[reply]
  267.  Support Useful link. --Petrus Adamus (talk) 05:48, 7 September 2011 (UTC)[reply]
  268.  Support Please! --Schorle (talk) 05:52, 7 September 2011 (UTC)[reply]
  269.  Support Seems like a very good, usefull idea. Inks.LWC (talk) 06:12, 7 September 2011 (UTC)[reply]
  270.  Support, could be useful. Cdlt, Pymouss Let’s talk - 11:42, 7 September 2011 (UTC)[reply]
  271.  Support OK/--Torin (talk) 11:46, 7 September 2011 (UTC)[reply]
  272.  Support --патриот8790Say whatever you want 15:23, 7 September 2011 (UTC)[reply]
  273.  Support. Good idea. Marcos talk 18:20, 7 September 2011 (UTC)[reply]
  274.  Support Fantastic! This makes it so much easier to see my media content. Indispensable! Thanks BDS2006 (talk)
  275.  Support Patrick Edwin Moran (talk) 06:09, 8 September 2011 (UTC)[reply]
  276.  Support Madeline 7 (talk) 07:46, 8 September 2011 (UTC)[reply]
  277.  Support Sure! (for Commons) AndreyA (talk) 11:06, 8 September 2011 (UTC)[reply]
  278.  Support Very good idea. Please with the indication of the category. Dinkum (talk) 11:11, 8 September 2011 (UTC)[reply]
  279.  Support --Lucas Nunes 14:27, 8 September 2011 (UTC)[reply]
  280.  Support --kaʁstn Disk/Cat 14:28, 8 September 2011 (UTC)[reply]
  281.  Support a×pdeHello! 19:51, 8 September 2011 (UTC)[reply]
  282.  Support Tacci2023 Great Idea 19:52, 8 September 2011 (UTC)[reply]
  283.  Support Sounds like a great idea EdwinHJ (talk) 19:52, 8 September 2011 (UTC)[reply]
  284.  Support Definitely helpful! Samar (Talk . Contributions) 20:16, 8 September 2011 (UTC)[reply]
  285.  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)[reply]
  286.  Support Lauro Chieza de Carvalho (talk) 00:42, 9 September 2011 (UTC)[reply]
  287.  Support Freebiekr (talk) 03:53, 9 September 2011 (UTC)[reply]
  288.  Support Amol.Gaitonde (talk) 11:08, 9 September 2011 (UTC)[reply]
  289.  Support Sounds very convenient. --Soppakanuuna (talk) 12:43, 9 September 2011 (UTC)[reply]
  290.  Support Olsi (talk) 14:38, 9 September 2011 (UTC)[reply]
  291.  Support Ruben JC (Zeorymer) (talk) 16:00, 9 September 2011 (UTC)[reply]
  292.  Support It sounds like a very good idea. -- Marek69 (talk) 17:18, 9 September 2011 (UTC)[reply]
  293.  Support Bonaber (talk) Great idea! 18:12, 9 September 2011 (UTC)[reply]
  294.  Support Yes kekistar (Discusión) 15:58, 9 September 2011 (UTC)[reply]
  295.  Support -- OperRu32TALK -- 21:22, 9 September 2011 (UTC)[reply]
  296.  Support -- I think it would be helpful. Warfieldian (talk) 22:10, 9 September 2011 (UTC)[reply]
  297.  Support. Good idea. Rehman 03:25, 10 September 2011 (UTC)[reply]
  298.  Support -- CristianCantoro (talk) 07:41, 10 September 2011 (UTC)[reply]
  299.  Support Already on the English Wikipedia, it would be very useful here. Hurricanefan25 (talk) 18:00, 10 September 2011 (UTC)[reply]
  300.  Support Chuck Carroll (talk) 20:15, 10 September 2011 (UTC)[reply]
  301.  Support --Gelpgim - disc 20:38, 10 September 2011 (UTC)[reply]
  302.  Support Excellent idea. Beyond My Ken (talk) 22:30, 10 September 2011 (UTC)[reply]
  303.  Support. Good idea. --Dezidor (talk) 10:38, 11 September 2011 (UTC)[reply]
  304.  Support Very usefull. --Claude villetaneuse (talk) 13:54, 11 September 2011 (UTC)[reply]
  305.  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)[reply]
  306.  Support Let's do this already, we seem to have a consensus. Feedback (talk) 17:37, 11 September 2011 (UTC)[reply]
  307.  Support GerFes (talk) 19:21, 11 September 2011 (UTC)[reply]
  308.  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)[reply]
  309.  Support Bravo, bravo! Excellent! --WhiteWriter speaks 21:11, 11 September 2011 (UTC)[reply]
  310.  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)[reply]
  311.  Support Bonne idée Mat.webmiss
  312.  Support It will be very useful. PRENN (talk) 04:56, 12 September 2011 (UTC)[reply]
  313.  Support --Wladyslaw (talk) 08:29, 12 September 2011 (UTC)[reply]
  314.  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.  Support jep! --RoB (talk) 11:42, 12 September 2011 (UTC)[reply]
  316.  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)[reply]
  317.  Support Ease of use. Nuff said. Maikel (talk) 13:38, 12 September 2011 (UTC)[reply]
  318.  Support (didn't we already vote for that ?). VIGNERON (talk) 19:18, 20 October 2011 (UTC)[reply]

Oppose

  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)[reply]
    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)[reply]
  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)[reply]

Discussion

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)[reply]
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)[reply]
Is it possible to make the page tell you how many uploads you have made? --Årvasbåo (talk) 14:14, 7 September 2011 (UTC)[reply]
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)[reply]
Could try filing a bug to ask for it to be stored somewhere... Rd232 (talk) 22:11, 7 September 2011 (UTC)[reply]
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)[reply]
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. Bugzilla: 30522 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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

Implementation

  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)[reply]
Other

Improvements to Special:ListFiles itself are covered by Bugzilla: 30522 (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)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

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)[reply]

OTRS member permissions

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This proposal, despite community support here, cannot succeed because it is opposed by the Wikimedia Foundation on legal grounds. (The comment, towards the bottom of this lengthy section, is quoted here in full.) We should look to alternatives for improving OTRS. Rd232 (talk) 01:18, 10 November 2011 (UTC)[reply]
“ 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:31, 6 November 2011 (UTC)[reply] 		”

—17:31, 6 November 2011 (UTC) Geoff Brigham, general counsel for the Wikimedia Foundation



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)[reply]

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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]

Votes

  • (Edit conflict)  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)[reply]
  •  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)[reply]
  •  Support as per Adrignola. Yann (talk) 17:15, 3 September 2011 (UTC)[reply]
  •  Support tool needed for the job, should be part of job's rights.--Havang(nl) (talk) 19:35, 3 September 2011 (UTC)[reply]
  •  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)[reply]
  •  Support--Anatoliy (talk) 20:42, 3 September 2011 (UTC)[reply]
  •  Support per Adrignola MorganKevinJ(talk) 21:13, 3 September 2011 (UTC)[reply]
  •  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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  •  Support granting deletedhistory and deletedtext;  Oppose granting undelete. John Vandenberg (chat) 03:26, 4 September 2011 (UTC)[reply]
  •  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)[reply]
  • 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)[reply]
  •  Support OTRS voluteers are trustworthy and should have the tools they need to do the job, in my humble opinion. - Hydroxonium (T•C•V) 07:06, 4 September 2011 (UTC)[reply]
  •  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)[reply]
  •  Support Weak support for "undelete" right, strong support for the other two rights. SV1XV (talk) 07:54, 4 September 2011 (UTC)[reply]
  •  Oppose Unneeded. Ask an sysop without details. Ebe123 (talk) 17:00, 4 September 2011 (UTC)[reply]
  •  Support including undelete. Kropotkine 113 (talk) 16:40, 5 September 2011 (UTC)[reply]
  •  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)[reply]
  •  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)[reply]
  •  Support for viewing deleted content, personally I also have no issues with undelete, but I can understand other people's concern, so  Neutral on undelete --Ben.MQ (talk) 19:31, 5 September 2011 (UTC)[reply]
  •  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)[reply]
  •  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)[reply]
  •  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)[reply]
    • 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)[reply]
    • @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)[reply]
      • 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)[reply]
        • 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)[reply]
  •  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)[reply]
  • 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)[reply]
  • Support - A very helpful feature indeed for OTRS volunteers. --Sreejith K (talk) 11:46, 24 October 2011 (UTC)[reply]
  • an otrs volunteer myself, i  Support "deletedhistory" and "deletedtext", but  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)[reply]
  • As another OTRS volunteer, I feel the same as Pill above:  Support deletedhistory and deletedtext,  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)[reply]

Summary

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
Does all the OTRS members have the same knowledge of Commons' policies?  ■ MMXX  talk 14:03, 9 September 2011 (UTC)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. --Fæ (talk) 13:54, 31 October 2011 (UTC)[reply]
Log
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Abuse by viewing or undeleting? because these two are different.  ■ MMXX  talk 18:27, 9 September 2011 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Alternative

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)[reply]

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)[reply]
Just compare Commons:Administratoren and Category:Commons OTRS volunteers. --Túrelio (talk) 12:24, 13 September 2011 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


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)[reply]

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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]

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)[reply]

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.
   Attribution: John Doe
Some rights reserved // linking to the license tag
use this
use this
email
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Explanation

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This appears uncontroversial after a week, so I'm closing and implementing. Rd232 (talk) 00:50, 10 November 2011 (UTC)[reply]

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.  Support as proposer Rd232 (talk) 12:17, 1 November 2011 (UTC)[reply]
  2.  Support Always implied, good to have it set out explicitly. --Skeezix1000 (talk) 12:38, 1 November 2011 (UTC)[reply]
  3.  Support - indeed, the reason for the decision should be clear. /Pieter Kuiper (talk) 12:42, 1 November 2011 (UTC)[reply]
  4.  Support makes sense that admins should explain decisions especially in disputed cases. Warfieldian (talk) 15:50, 1 November 2011 (UTC)[reply]
  5.  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)[reply]
  6.  Support Good to make this explicit. --Avenue (talk) 00:36, 3 November 2011 (UTC)[reply]
  7.  Support Sensible. --Walter Siegmund (talk) 21:50, 5 November 2011 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Discussion

Conclusion

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.
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
OK, the first sentence isn't going to get support, and the second is already on Commons:Deletion requests in the section above the Admin Guidance one. Can we continue discussion about closing requests though? There seems some interest in seeing if this can be improved. Rd232 (talk) 11:44, 2 November 2011 (UTC)[reply]
  1.  Support as proposer Rd232 (talk) 12:17, 1 November 2011 (UTC)[reply]
  2.  Oppose DRs need to be decided, also when there is disagreement. Wrong decisions will be made, there is not much that can be done about that. When a reason is given, it should be easier to accept the decision. Or it could stimulate an appeal (renomination or request for undeletion). /Pieter Kuiper (talk) 12:48, 1 November 2011 (UTC)[reply]
  3.  Oppose first sentence -- instruction creep/a solution in search of a problem.  Support second sentence -- well said. --Skeezix1000 (talk) 12:54, 1 November 2011 (UTC)[reply]
  4.  Oppose first directive would lead to many, many unclosed requests as discussion sometimes does not lead to clear consensus and decision needs to be made.  Support OK with second sentence Warfieldian (talk) 15:49, 1 November 2011 (UTC)[reply]
  5.  Oppose First Sentence: No, we would be sitting on loads of unclosable DR's. Second sentence is redundant. Amada44  talk to me 08:42, 2 November 2011 (UTC)[reply]
  6.  Oppose Per Amada --Herby talk thyme 09:03, 2 November 2011 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Discussion
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
Fair enough. I have no problem repeating it, but others may see that as unnecessary. --Skeezix1000 (talk) 13:06, 1 November 2011 (UTC)[reply]
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)[reply]
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)[reply]

Ideas to help reduce OTRS backlogs

The proposal above, Commons:Village_pump/Proposals#OTRS_member_permissions, on extending key admin rights to OTRS volunteers (the ability to view and possibly even undelete deleted material) has failed due to WMF opposition on legal grounds. I suggest we should discuss some alternatives to help reduce OTRS backlogs, particularly in relation to OTRS volunteers not having admin rights.

Here are some ideas to kick off discussion:

  1. Encourage all active Commons admins to consider applying for OTRS
  2. Reach out to other Wikimedia projects to ask admins there who are active in licensing/copyright to consider (a) applying for OTRS and (b) becoming active on Commons and (c) applying for adminship here
  3. Create a streamlined "Expedited RFA" process for admins on other Wikimedia projects who are OTRS volunteers. Make it clear in COM:ADMIN that such users don't need to have a deep involvement with Commons in order to gain adminship, since OTRS membership ought to confirm relevant competence (in exchange, they agree to only use admin powers in relation to OTRS tickets, unless they pass a normal RFA).
  4. Alternatively, formalise idea 3. by creating a "limited admin" group specifically for such users (admins on other Wikimedia projects who are OTRS volunteers), with just viewdelete, browsehistory and undelete, and the understanding that these only be used in relation to OTRS tickets.
  5. Create a system to easily identify OTRS tickets which need admin rights to handle, so that admins can focus on these. [This might already exist, I don't know; but reading between the lines, I think not.]

Both 3. and 4. would have to be run past WMF legal, but I think have a fair chance of success. Comments? Other ideas? Rd232 (talk) 01:40, 10 November 2011 (UTC)[reply]

Requests for comment/User conduct

Commons:Administrators' noticeboard/User problems is a free-form forum for discussing user problems. This (parallel to en.wp's en:WP:ANI, for those who know it) doesn't work well for all problems; long-term or complex issues, especially with established contributors, are difficult to resolve in this format. en.wp has "Requests for comment/User conduct" (RFC/U for short), a Request for Comment system for discussing user conduct issues in a calmer, more solution-focussed and evidence-based way. For those unfamiliar with it, here are two current examples: 1 2. I propose importing this system from en.wp (in theory it can be adapted, but that opens the door to much discussion of details, so it's tempting to try to avoid this and consider changes later on, based on experience here).

I know some users are not keen on using en.wp as a model, so let me stress that I think this RFC approach will be more useful here than on en.wp because of the issue of multilingualism. I believe the slower, calmer, more focussed and evidence-based approach will help level the playing field and make it easier for users writing in English whose first language is not English, and also easier for users writing in other languages, with a request for translation. I think it's also one of those things which is relatively non-disruptive and can be tried without much risk; if it isn't used or doesn't really work, Commons won't be any worse off. PS This of course also Commons:Disputes noticeboard, but that is equally free-form in format, and not much used (look at dates of disputes there). Rd232 (talk) 01:57, 10 November 2011 (UTC)[reply]

Proposal: Import en:Wikipedia:Requests for comment/User conduct and test it for 6 months.

  1.  Support as proposer Rd232 (talk) 01:57, 10 November 2011 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=62291808"