Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Community portal
Help desk Village pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

Welcome to the Village pump proposals section

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

Commons discussion pages (index)

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


Restrict Video Uploading[edit]

Wikipedia Zero abusers are uploading hundreds of files per week, hitting 1 terabyte of pirated content. With Embedded Data Bot running, the pirates have switched from JPEG+RAR to blatant copyright violations. I'm hopeful for disabling access to unpatrolled files for WP0 users, but it requires WMF engineering and thus likely only ready in 2018.

The following table shows the abusers are prolific video uploaders compared to normal accounts.

Non-Autoconfirmed Uploads (Last 6 months)
Medium Files Deleted Del% Deleted bytes Not deleted Users Blocked Block%
SVG 8,421 937 11% 0.2 GB 1 GB 1,637 51 3%
Images 498,895 127,599 26% 376 GB 997 GB 158,969 5,527 3%
PDF 6,927 6,484 94% 106 GB 4 GB 3,724 1,038 28%
AUDIO 3,222 2,089 65% 236 GB 2 GB 1,118 719 64%
VIDEO 3,961 3,611 91% 452 GB 15 GB 1,870 1,406 75%

Without anything in the pipeline for video we need to consider disabling video uploads from new accounts. This would be an edit filter that could take into account: account age, number of edits, autoconfirmed and confirmed (for edit-a-thon events) account groups, if an email address was registered, file size, dimensions of the video (YouTube only outputs muxed 360p.webm), and if added video duration. —Dispenser (talk) 13:52, 14 June 2017 (UTC)

  • Symbol support vote.svg Support--Steinsplitter (talk) 15:31, 14 June 2017 (UTC)
  • Symbol support vote.svg Support --Alaa :)..! 16:57, 14 June 2017 (UTC)
  • Symbol support vote.svg Support, unfortunately. Storkk (talk) 17:00, 14 June 2017 (UTC)
  • Symbol neutral vote.svg Neutral I would prefer to see a more specific proposal that can be tested for impact and has options for gradual roll out and roll back later. For example we could restrict video uploads to 10 edit+ accounts and gradually increase that if there is evidence it's being worked around, with agreement to roll back to a lower number after a planned period. As for Youtube, it's not that hard to take other webm sizes that Youtube makes available (such as 1280x720) and merge in an audio stream, so I'm unsure about technically unusual constraints. Video uploading remains pretty bad on Commons, putting up more barriers to entry, without any planned development to improve our front end or transcoding support, does not look good for the future of Commons. -- (talk) 17:38, 14 June 2017 (UTC)
    • Its worded broadly as the pirates have been evading our efforts to stop them. Finding multiple ways to defeat the bot. We are running this because 5-10% (depending on how its sliced) of legitimate uploads will be blocked. —Dispenser (talk) 19:05, 14 June 2017 (UTC)
      • Sure, I would rather see a limited and specific proposal than giving indefinite carte blanche for a change that will create barriers for newbies, and possibly others, wishing to improve our rather indifferent and meagre collection of educational videos (compared to other hosts). Once introduced, I don't see how this change would ever roll back, making it a serious alteration in how we welcome users. My focus is on contributors rather than pirates, and while we want to ensure pirates do not disrupt this project in any way that starts to affect the wider community, it is a greater imperative to ensure supporting contributors and the experience for reusers remains our joint primary concern when assessing the value of changes. -- (talk) 11:39, 15 June 2017 (UTC)
  • Symbol support vote.svg Support, at least for multipage-PDFs, audio and video. Recent-upload patrolers have enough to do with regular copyvios. --Túrelio (talk) 18:42, 14 June 2017 (UTC)
    • The PDF, XCF, DjVu are high since programming the bot for them was tricky, so the pirates exploit them. For Audio, I have several solutions lined up. —Dispenser (talk) 19:05, 14 June 2017 (UTC)
  • Symbol support vote.svg Support Christian Ferrer (talk) 18:47, 14 June 2017 (UTC)
  • Symbol support vote.svg Support --jdx Re: 19:24, 14 June 2017 (UTC)
  • Symbol support vote.svg Support this is taking up precious time and effort which could be better directed elsewhere. The impact on good faith users will be virtually non existent (out of the hundreds of videos I've reviewed and deleted, I can only recall 2 legitimate videos which would have been prevented). Nick (talk) 21:39, 14 June 2017 (UTC)
  • Symbol support vote.svg Support Personally I would like to turn off uploads from Wikipedia Zero users because they are more of a problem than a benefit. But we can't do that because WMF. And the WMF would obviously not do that too. Those users are given the privilege to upload files when they registered an account, as long as they won't misuse the privilege. And because they abused it, the privilege given to them must be removed. --Poyekhali 11:24, 16 June 2017 (UTC)
    • Range blocking Morocco (11 million IPs) where the abuse is coming from is still an option. —Dispenser (talk) 16:40, 16 June 2017 (UTC)
      • Seriously? -- Tuválkin 12:11, 23 June 2017 (UTC)
        • Yes, this has been discussed in a private discussion in Phabricator (I or someone joined in the discussion can add you to the discussion, if you are interested). See also phab:T167915, which is an alternative solution to range blocking Morocco. Poyekhali 02:30, 24 June 2017 (UTC)
          • I shouldn’t have asked, but it’s a brave new world indeed. I’ll peruse that link now, half fearing to find parallel subthreads about draining the swamp and locking her up. -- Tuválkin 19:57, 26 June 2017 (UTC)
  • Symbol support vote.svg Support --Discasto talk 13:20, 16 June 2017 (UTC)
  • Symbol support vote.svg Support   — Jeff G. ツ 14:07, 16 June 2017 (UTC)
  • Symbol support vote.svg Support — Speravir – 22:08, 16 June 2017 (UTC)
  • Symbol support vote.svg Support For video, audio, and PDF. --Yann (talk) 09:51, 17 June 2017 (UTC)
  • Symbol support vote.svg Support +1 for video, audio & pdf. --Achim (talk) 14:28, 21 June 2017 (UTC)
  • Symbol support vote.svg Support +1 for video, audio, and PDF. -- Tuválkin 12:11, 23 June 2017 (UTC)
  • Symbol support vote.svg Support - noting Fae's reservations - nevertheless the evidence provided by dispenser needs to be acted upon JarrahTree (talk) 01:50, 24 June 2017 (UTC)
  • Symbol support vote.svg Support +1 for non-images where the majority of uploads must be deleted. We have to keep it to levels which can be managed by the community. --AFBorchert (talk) 09:21, 17 August 2017 (UTC)
  • Symbol support vote.svg Support +1 for non-images(video, audio, PDFs). --Talk to Kong of Lasers 03:51, 8 September 2017 (UTC)


Okay, i think we have consensus here. @Dispenser:/@Jdx: can you propose a filter code? Maybe based on 180? --Steinsplitter (talk) 11:15, 24 June 2017 (UTC)

My availability is limited for the foreseeable future. Dispenser (talk) 14:03, 24 June 2017 (UTC)

Message from the Partnerships & Global Reach team about the Wikipedia Zero service[edit]

Hello everyone.

We, the Partnerships and Global Reach team, are responsible for the Wikipedia Zero program. We wanted to let you know that we have following this conversation and have heard the concerns raised by the community here on Commons.

Our team is aware that the Wikipedia Zero service has been subject to abuse. We understand that this situation is frustrating. We are saddened to see this happen and have been working on finding feasible solutions to address this issue over the past year.

When this issue was first flagged to us in early 2016, we worked with the engineering, security and community teams to determine the best course of action to take. As a result of this review, we determined that editors needed to have a way to identify and focus just on content uploaded by Wikipedia Zero users. We then created a filter action for AbuseFilter to do exactly that. But a year later, the core problem has escalated to the point where this tool alone is not enough to deal with it.

It looks like that you have come up with a potential way of addressing the issue here. We have also identified further potential solutions on our end, but unfortunately, none of them are ideal. There are many factors in play here, which makes it hard to find an effective and quick solution this problem. We want to make sure the program is not creating more work for copyright patrollers and editors in general. But, we also want to ensure that people using Wikipedia Zero can have access to the entire Wikimedia experience, which includes the ability to contribute to the projects.

In the next couple of days, we intend to share what these possible options are, and make a decision based on your inputs. In the meantime, rest assured we have heard you and are doing our best to solve the issue.

We are looking forward to opening a discussion on this subject next week. AVrana (WMF) (talk) 19:32, 26 June 2017 (UTC)

Follow-up from the Partnerships & Global Reach team about Wikipedia Zero abuse[edit]

Hi everyone, I’m with the Partnerships & Global reach team, and I am following up with our earlier message to discuss how we might address the Zero abuse situation. Here are the different options being considered. I’ll start with the options that are the furthest along.

  • A Wikipedia Zero partner who is experiencing abuse is experimenting with a method to see if they can discourage very large downloads but still allow normal Wikipedia use. If successful, it could help curtail the overall abuse. But even if it’s effective, the effort required by each partner suggests that this will not be implemented universally.
  • Based on the proposal here to restrict video uploading, we have arranged for engineering to implement a method to disable some types of uploads from specific Zero partners. We’ll need to make sure this is as targeted as possible in order to help avoid penalizing legitimate uses, particularly things like contributing to Wiki loves Monuments, valid images, etc.

Other suggestions we’re investigating right now:

  • Disable serving unpatrolled new files to Wikipedia Zero users. Conceptually, this seems like a good approach, as it would discourage abusive uploads if Wikipedia Zero users could not download unpatrolled / pirated content for free. I’m investigating what kind of engineering commitment this would require to see if this is an option we can move ahead with or not.
  • Enhancing TBayer's tool to detect and report abusive uploads. There may be some improvements we can make to his tool with some engineering work, and we are discussing the enhanced features and possible engineering support to implement them.
  • File removal persistence. Not sure the status of this but will find out more.

Regarding these efforts, I expect to learn and share more details about the options we’re investigating soon.

The abuse issue is not simple, and I appreciate the work and thought that everyone has already put into this. We’d really like to help get the abuse situation under control, and any thoughts you have that might help with that are welcome. DFoy (WMF) (talk) 03:12, 6 July 2017 (UTC)

    • @DFoy (WMF): What does "File removal persistence" mean? Kaldari (talk) 23:31, 6 July 2017 (UTC)
    • @Kaldari: This refers to a comment in here about a webm file still being accessible after deletion. DFoy (WMF) (talk) 00:19, 8 July 2017 (UTC)
@Kaldari: A more detailed description of what appears to be the same issue is at phab:T109331. This appears to be a huge problem currently. E.g. among the files detected by the above mentioned tool that I'm currently running, all of the top 6 files for July 7 have this problem - admins had already found and deleted each file (in that case, on hewiki), but it remained accessible via the direct link for many hours afterwards and saw a lot of downloads. More detail in the internal discussion at [1]. This is likely a major reason why the uploads by that particular piracy site have not stopped on that project despite consistent admin intervention in recent days and weeks. (And obviously a concern not just in case of WP0 abuse.)
According to MaxSem there is a manual workaround: The file is gone once one purges the cache. Regards, Tbayer (WMF) (talk) 01:50, 8 July 2017 (UTC) Edit: Max clarified that this needs to be a server-side purge, which can only be initiated by developers. Regards, Tbayer (WMF) (talk) 02:10, 10 July 2017 (UTC)
@Tbayer (WMF): This purge should happen any time a Commons Admin deletes a file or revdels an instance of a file, and the capability to do such a purge should be incorporated into the Commons Admins' toolsets.   — Jeff G. ツ 04:29, 13 July 2017 (UTC)

Implementation results[edit]

  STR_TO_DATE(DATE_FORMAT(fa_timestamp, "%x%v Monday"), "%x%v %W") AS ByWeek,
  fa_media_type, SUM(fa_size),  COUNT(*)
FROM filearchive_userindex
JOIN page ON fa_user_text=REPLACE(page_title,"_"," ")
JOIN categorylinks ON cl_from=page_id
WHERE page_namespace=2 AND fa_media_type IS NOT NULL
AND cl_to IN ("Users_suspected_of_abusing_Wikipedia_Zero")
GROUP BY ByWeek, fa_media_type;
Weekly uploads from Users suspected of abusing Wikipedia Zero
May 29–
June 4
June 5–11
June 12–18
June 19–25
June 26–
July 2
July 3–9
July 10–16
July 17–23
July 24–30
July 31–
August 6
August 7–13
August 14–20
August 21–27
August 28–
Sept. 3
Sept. 4–10
Sept. 11–17
  •   SVG
  •   Images
  •   PDF
  •   AUDIO
  •   VIDEO

On June 16, pirates started looking for other places to upload, which is why the graph drops in the following weeks. By June 22, User:HaeB began implementing a report to find where they went. On July 17, Abuse Filter 180 was switched to disallow, disabling Audio, Video, and a few other heavily abused types. This caused a 33% decrease from the previous week. Edit: On July 25, the IRC alert bot changed to scan non-Commons wikis too.

We also have a better idea how big these pirate networks actually are beyond the "10,000 Facebook followers". We see Edman and Madezyma "news" pull in 20,000–40,000 requests/day, with a peak of 188,000 requests/day. —Dispenser (talk) 22:16, 24 July 2017 (UTC)

Added another week and make date ranges clearer. —Dispenser (talk) 13:37, 3 August 2017 (UTC)
I've been told that 1 request != 1 download, especially for video as the browser will chunk them by default. See wikitech:Analytics/Data Lake/Traffic/Mediacounts Dispenser (talk) 21:50, 20 August 2017 (UTC)

Partnerships & Global Reach team proposal: Targeted Video upload restriction[edit]

We're interested in your feedback on adding an additional method to restrict video uploads. Although similar in many ways to the recent enhancements made to Abusefilter, the suggestions here would not be done using Abusefilter. The proposed Targeted Video upload restrictions are different than Abusefilter in the following ways:

  • Restrictions will be more selective than the current limitation of 'all Zero traffic'. Since Wikipedia Zero now has over 60 partners, and much of the abuse is coming from just a few of these partners (e.g. in Morocco and Angola), all other Wikipedia Zero users are now inadvertently restricted due to the limitations of Abusefilter. With this method, we can set up restrictions on a partner by partner basis.
  • With this capability built into our code base, we can prevent restricted file types from being uploaded before determining that it is not allowed.
  • We can set whether this restriction is for everyone or non-autoconfirmed users (per-partner).
  • We can specify the file types restricted or set as all files (per partner).

Our goal has always been to make sure that Zero users are not automatically treated as second class citizens. It's important for users who are not coming from an abusive partner to be able to contribute legal material. At the same time, we clearly need to clamp down on the specific places that are abusing our service and creating a lot of extra work. With this feature, we can target the abuser locations, but still allow content from areas where we are not experiencing abuse.

Is this something that we should implement? DFoy (WMF) (talk) 23:40, 2 August 2017 (UTC)

@DFoy (WMF): None of our "disallow"-ing filters has a condition of whether uploader is WP0 or not. The reason is that uploader tend to use VPNs or other proxy services in order to bypass some of our past detection mechanisms, with the side effect of being able to workaround autoblocks. I've noted this in my comment in gerrit:367422. The real issue is the downloaders are from WP0 ranges, who can easily get free pirated media on mobile networks. Restricting uploading, as you have suggsuggested and is in the current implementation, will not resolve the issue, but restricting downloading, which we cannot currently do, will; I'm pretty sure the Zero team should be aware of this. See also phab:T167400 --Zhuyifei1999 (talk) 00:18, 3 August 2017 (UTC)
BTW: I'm pretty sure the Community Liaisons team is looking into this as well. --Zhuyifei1999 (talk) 00:20, 3 August 2017 (UTC)
@Zhuyifei1999: Correct, I'm working with the various teams on this in organizing and coordinating communications and the like. Keegan (WMF) (talk) 03:22, 3 August 2017 (UTC)
"Second class citizen" is lip service otherwise T134135: Bring Wikipedia Zero to the United States would've seen progress. —Dispenser (talk) 13:54, 3 August 2017 (UTC)
I was told Wikipedia Zero was the jewel in the Wikimedia Foundation presentations, a vital part of their image as a non-profit. I figured the explosive growth or the hundreds of files deleted each week or the stunning graphs or the undeletable files would've warrant action from the past 9 months. No, it was 2 ½ work days after my update with the misunderstanding that we turned Wikipedia Zero into a second class citizen that somebody was assigned. The vanity is incredible. —Dispenser (talk) 04:27, 4 August 2017 (UTC)

Detailed table[edit]

/* Video Uploads by non-autoconfirmed accounts - 30 min */
  COUNT(filename) AS Files,          COUNT(fa_name) AS Deleted,                 
  COUNT(fa_name)/COUNT(filename) AS "DEL %",
  SUM(fa_size)   AS "Deleted Bytes", SUM(filesize)-SUM(fa_size)  AS "Not deleted", 
  COUNT(DISTINCT user_id)  AS Users, COUNT(DISTINCT ipb_address) AS Blocked, 
  COUNT(DISTINCT ipb_address)/COUNT(DISTINCT user_id) AS "Block %"
  SELECT CONCAT(fa_media_type, " (", fa_minor_mime, ")") AS "Media",
         fa_name AS filename, fa_name,
         fa_size AS filesize, fa_size,
         user_id, ipb_address
  FROM filearchive 
  JOIN user ON user_id=fa_user
  LEFT JOIN ipblocks_ipindex ON ipb_address=user_name
  WHERE fa_timestamp    > DATE_FORMAT(NOW()        - INTERVAL 12 MONTH, "%Y%m%d%H%i%s")
  AND user_registration > DATE_FORMAT(fa_timestamp - INTERVAL 4 DAY, "%Y%m%d%H%i%s")
  AND fa_media_type NOT IN ("MULTIMEDIA"/*, NULL*/)
  SELECT CONCAT(img_media_type, " (", img_minor_mime, ")") AS "Medium",
         img_name AS filename, NULL AS fa_name,
         img_size AS filesize, 0 AS fa_size,
         user_id, NULL AS ipb_address
  FROM image
  JOIN user ON user_id=img_user
  WHERE img_timestamp   > DATE_FORMAT(NOW()         - INTERVAL 12 MONTH, "%Y%m%d%H%i%s")
  AND user_registration > DATE_FORMAT(img_timestamp - INTERVAL 4 DAY, "%Y%m%d%H%i%s")
) AS combined
Non-Autoconfirmed Uploads (Last 12 months)
Media Files Deleted DEL % Deleted bytes Not deleted Users Blocked Block %
BITMAP (jpeg) 424,542 96,386 23% 209 GB 922 GB 130,013 3,422 3%
DRAWING (svg+xml) 3,747 1,075 29% 299 MB 1 GB 1,672 60 4%
BITMAP (png) 45,399 18,527 41% 70 GB 27 GB 24,688 1,468 6%
BITMAP (gif) 4,779 2,036 43% 54 GB 2 GB 2,932 198 7%
OFFICE (pdf) 6,629 6,287 95% 120 GB 1 GB 3,560 1,098 31%
BITMAP (tiff) 2,344 963 41% 30 GB 23 GB 1,369 438 32%
BITMAP (vnd.djvu) 91 44 48% 5 GB 1 GB 52 24 46%
BITMAP (webp) 258 236 91% 4 GB 1 MB 194 94 48%
VIDEO (ogg) 376 328 87% 30 GB 2 GB 212 116 55%
AUDIO (wav) 523 478 91% 18 GB 210 MB 289 188 65%
AUDIO (ogg) 2,092 1,518 73% 206 GB 1 GB 744 484 65%
VIDEO (webm) 4,070 3,918 96% 456 GB 7 GB 2,083 1,746 84%
AUDIO (midi) 80 79 99% 3 GB 1 KB 55 48 87%
AUDIO (x-flac) 144 136 94% 11 GB 93 MB 115 101 88%
BITMAP (x-xcf) 657 629 96% 12 GB 245 MB 322 300 93%
AUDIO (webm) 7 7 100% 441 MB 0 KB 3 3 100%

When making an argument we pick data best supporting it. The original graph simplified things by using only media_type instead of media_type+mime_minor as I was expecting a fight to block newbies from uploading videos. —Dispenser (talk) 14:40, 23 August 2017 (UTC)

Thanks. Interesting stats. I would prevent any new account to upload these files when deletion or block is over 50%. Regards, Yann (talk) 14:47, 23 August 2017 (UTC)
The pirates are attacking PDF and not XCF these last few weeks. The high deletion rate for PDF is also just crappy uploads (Vector content as PDF instead of SVG, JPEG in PDF, weird documents, etc.), hence the lower block rate. I've asked for a 500 KB cap for MIDI, but it's <100 download/year. I'm really just trying to document for future archive readers. —Dispenser (talk) 18:29, 23 August 2017 (UTC)
Ok, maybe we shouldn't allow newbies to upload 700 MB PDFs with embedded MP4s... Dispenser (talk) 03:44, 25 August 2017 (UTC)

Enabling Gadget deepcat activation via Special:Preferences#mw-prefsection-gadgets[edit]

Hi all, The gadget deepcat is an extremely useful tool to search entire categories (including up to 15 sub-categories deep). This is available on the German Wikipedia via the preferences page. I would like to propose that it be made available on Commons via Special:Preferences#mw-prefsection-gadgets > Gadgets > Tools for categories, enabling a simpler way to activate it (as for example, with Cat-a-lot). The present approach to activating deepcat is a bit cumbersome (see discussion). I know there is some overlap between the already-available FastCCI and deepcat, but they are not identical in several ways that are very significant for those searching for content on Commons:

  • FastCCI only searches categories (intersections such as incategory:A and incategory:B; or, in A but not B and so on.) Deepcat searches down a category tree plus any other search term that is added. For instance, a FastCCI search on the Category:Fish page for incategory:Fish and incategory:Tuna yields no results, while a deepcat search (deepcat:Fish Tuna) picks a bunch of results including those where the word "Tuna" is in Description or filename (and not necessarily in a category).
  • FastCCI only provides a gallery-type view of images; the results of a deepcat search is like that from a regular search, showing thumbnail, filename, description etc.
  • FastCCI is available to all visitors to a category page, deepcat only to logged-in users (would be great if deepcat can be added as an option on at least 'Advanced' search for all visitors/users--but that perhaps should be a separate proposal?)

To summarise, deepcat is useful to search not just by category, but for a word in caption or filename, down a large category hierarchy and it would be helpful to enable its activation via Special:Preferences#mw-prefsection-gadgets. Thoughts? --Shankar Raman (talk) 02:07, 1 July 2017 (UTC)

Symbol support vote.svg Support I don't see a significant downside --Zhuyifei1999 (talk) 03:10, 1 July 2017 (UTC)
Symbol support vote.svg Support — Speravir – 03:56, 1 July 2017 (UTC)
Symbol support vote.svg Support This will be very useful. Thanks for taking this initiative. --Jegan 06:30, 1 July 2017 (UTC)
Symbol support vote.svg Support Why not? --Poyekhali 11:29, 2 July 2017 (UTC)
Symbol support vote.svg Support Much needed. Prashanthns (talk) 06:31, 24 July 2017 (UTC)
Symbol support vote.svg Support Can't see any downside of this. --El Grafo (talk) 16:02, 24 July 2017 (UTC)

Can someone provide a translation of "Deepcat – Schnittmengensuche für Kategorien" (for MediaWiki:Gadget-DeepCat)? I'll implement this --Zhuyifei1999 (talk) 06:33, 25 July 2017 (UTC)

@Steinsplitter: ping. Poyekhali 01:17, 27 July 2017 (UTC)
There is no real english term for "Schnittmengensuche" (well... also a bit strange in german imho), you can call "Deepcat – Deep category search" or some sort of. :) --Steinsplitter (talk) 11:45, 27 July 2017 (UTC)

✓ Done. If you encounter issues feel free to ask. --Zhuyifei1999 (talk) 07:37, 28 July 2017 (UTC)

Thanks much. I enabled Deepcat in preferences and tried searching. Didnt work for me. Tried to look for documentation/help. Is it correct that there's none of that in English? Prashanthns (talk) 15:01, 29 July 2017 (UTC)
I just fixed a bug in its loading (the documentation is bad :( ), but as far as I can see nothing is different when I search. What should it look like? --Zhuyifei1999 (talk) 16:19, 29 July 2017 (UTC)
Didn't work for me, either. What it should look like after I activate the gadget? If I enter deepcat:"Search Category" searchterm it should search down the Search Category and give me a bunch of results with the searchterm. Right now it gives a "results not found". Am I doing something wrong?--Shankar Raman (talk) 16:43, 29 July 2017 (UTC)
Came here to second (third?) this—seems like a great gadget, but I can't seem to get any results out of it. Do I need to clear my browser cache? Dragfyre (talk) 02:12, 30 July 2017 (UTC)
I just renamed 'DeepCat' to 'DeepCatExt' so we don't get a collision with their weird loading mechanics. It seems to work for me now. Can you try again? --Zhuyifei1999 (talk) 04:40, 30 July 2017 (UTC)
It's... weird. The gadget is clearly loading, because I see the Deepcat pop-up talking about max search depth etc. The results don't look right, though. For instance, this search (search terms: Baha'i -deepcat:"Bahá'í Faith") is turning up plenty of results that are within the hierarchy of Category:Bahá'í Faith, which, if my understanding is correct, should all be excluded. Dragfyre (talk) 14:18, 30 July 2017 (UTC)
Thank you Zhuyifei1999, this is very useful. Although I did not quite understand what you meant by 'DeepCatExt' rename (in my user preferences the gadget is still called 'Deepcat'), the gadget seems to be working fine from the regular search box for me now. However, the deepcat search does not appear to work from Inputbox search as implemented in this category page for example. Is there something different that happens in inputbox search?--Shankar Raman (talk) 05:53, 4 August 2017 (UTC)
I'm not sure if they use the same mechanics. Does it work on dewiki? --Zhuyifei1999 (talk) 12:39, 4 August 2017 (UTC)
From what I could try out on dewiki (don't know the language), a similar problem persists--i.e., regular deepcat search works, deepcat-via-inputbox-search does not. Thanks,--Shankar Raman (talk) 01:35, 5 August 2017 (UTC)
Hey Zhuyifei1999 and Shankar Raman The gadget only 'listens' to the 'normal' search input boxes. If there's a need to extend that and listen to more fields, we could do that in the future. Thanks for your feedback. Christoph Jauera (WMDE) (talk) 12:28, 22 August 2017 (UTC)
Hey Dragfyre! I just looked at your case and it seems, that the underlying CatGraph interface does not return the correct subcategories. I filed a ticket on Phabricator. We will look into it and hopefully will be able fix it :-). Christoph Jauera (WMDE) (talk) 12:30, 22 August 2017 (UTC)
Oh cool! Thanks a lot for that. I have to get myself an account on Phabricator... Dragfyre (talk) 20:19, 23 August 2017 (UTC)

@Zhuyifei1999, Steinsplitter, Shankar Raman, Dragfyre: Some reaction to notes of you above. Further discussion should, though, be continued e.g. in MediaWiki talk:Gadget-DeepCatExt.js:

— Speravir – 23:12, 17 August 2017 (UTC)

Ping also @Prashanthns. — Speravir – 23:23, 17 August 2017 (UTC)
Thanks for the wrap-up here. Yes, it would be really helpful to continue the further discussion on a separate page. Feel free to ping me there if you run into issues. Or best, file a ticket on Phabricator. Christoph Jauera (WMDE) (talk) 12:34, 22 August 2017 (UTC)
Thanks for the resources and for pointing to the appropriate talk page. :) Dragfyre (talk) 20:19, 23 August 2017 (UTC)

Use of deep learning and AI on Wikimedia Commons[edit]

Deep learning says there is a fountain on this image with possibility of 98.8%!

I've developed a service for detecting tags and examining ratio of being NSFW of an image with deep learning (a new machine learning trend) open source tools and models and had interesting results with it I believe. For example it tags today's featured picture as lycaenid: 63.7% and thinks of this image as being 90% possible NSFW.

Currently I've made a gadget that can be enabled from gadget tab of preferences, called "DeepLearningServices" and am listing new uploaded images with NSFW rate more than 0.5 with a bot that follows Wikimedia Commons recent changes on User:Ebrambot/deep-learning report.

I was thinking about extending the just added gadget and services to suggest category for images without any categories or even intelligently suggest categories for images being uploaded. What do you think about the mentioned proposals and what else can be done with these capabilities? −ebrahimtalk 13:23, 3 August 2017 (UTC)

@Ebrahim: It would help to flesh out the descriptions of what the links are and what they do at MediaWiki talk:Gadget-DeepLearningServices.js.   — Jeff G. ツ 17:02, 3 August 2017 (UTC)
Jeff Done, is it now more clear what the tool is doing? −ebrahimtalk 17:39, 3 August 2017 (UTC)
@Ebrahim: Yes, but that page does not mention that the gadget is just an AI tool for advising the user of the probabilities of the presence of attributes like NSFW, not for actually adding file description page tags or categories (possibly in the future?), nor does it mention that the user has to click to activate the tool (possibly automatic in the future?). To be clear, it only recognizes porn as NSFW, and does not address violent or pro-hate types of images as NSFW, right?   — Jeff G. ツ 18:03, 3 August 2017 (UTC)
Yes, I followed the original terminology on NSFW of Yahoo project but that's better to be more cleared. Please apply these as it definitely helps the describing current functionality of the tool. Thanks :) −ebrahimtalk 18:24, 3 August 2017 (UTC)
Can we drop the NSFW title in exchange for a "nudity" title? What's not safe for work depends on location and context; a lot of workplaces would consider that Adam & Eve painting acceptable.--Prosfilaes (talk) 21:07, 4 August 2017 (UTC)
I'd say lets stick with the original terminology of the project, Adam and Eve case is somehow false alarm as I guess they've tried to train the model to not rate it even more. −ebrahimtalk 23:39, 5 August 2017 (UTC)
I don't see why; they didn't invent the word NSFW, nor is their use so dominant. We shouldn't use misleading, inaccurate descriptions instead of neutral clearer descriptions, even if the tools we're using do. That Adam & Eve painting may be NSFW in many places, as well as levels of nudity generally considered okay in the West.--Prosfilaes (talk) 01:43, 8 August 2017 (UTC)
The term NSFW is controversial and will remain so as it is highly subjective. No, a painting with a biblical depiction of Adam and Eve should never be labelled as NSFW. -- (talk) 08:57, 8 August 2017 (UTC)
No actual labelling is going to happen, this is just a patrolling tool and the listed images will be removed from the NSFW page each week. −ebrahimtalk 10:16, 8 August 2017 (UTC)
The results look meaningless. In this case the images were examined for 'fleshiness', which is a very poor indicator of much on Commons, especially if photographs of bats or parts of ships are going to be labelled as NSFW. If more interesting features, such as images with no categories that are highly likely to be simple passages of text, or almost featureless apart from borders, then the results would have much more likely value for maintenance. Experiments like this were done during the summer of code last year, I suggest those past experiments are reviewed as they could save a lot of volunteer time, before trying more. -- (talk) 08:51, 8 August 2017 (UTC)
: No automatic labeling is going to happen and images listed on the page will just be removed after a while, a good ratio of images that archived here are now deleted and this can be helpful for patrolling new images I believe. −ebrahimtalk 10:06, 8 August 2017 (UTC)
Sure, however this is effectively a maintenance category and so the quality of the results should be kept under review. Marking, say, 19th century paintings and drawings in a way that even implies they are NSFW is inappropriate. Regardless of the background off-wiki, I support renaming the report. Oh, BTW, don't get me wrong, I strongly encourage further experiments, and even WMF funded projects, that will result in automated categorization, even if this is just along the lines of "appears blank", or "looks like text". Thanks -- (talk) 10:17, 8 August 2017 (UTC)
: Great, I liked also to get some feedback from community and go for even better experiments. So what about "Possible NSFW report" or something like that? −ebrahimtalk 11:40, 8 August 2017 (UTC)
Sorry, I think the NSFW focus of the report is actually bad for these experiments as it's the wrong starting point. For Wikimedia Commons, a generic NSFW report simply fuels the sort of misplaced porn panic that is a priority for other sites and communities. The priority for Commons should be copyright violations, useless selfies, duplicates and generic out of scope material. For these reasons identifying simple modern text documents and images with several indicators that they have been ripped off from other websites and likely to be copyvios is much more useful as a starting point. Frankly identifying porn happens pretty easily without bots, just give a patroller a screen with 500 tiny thumbnails per page, and they'll spot any real nudity straight away, and be able to do much better than a bot at deciding when photographs with nudity or lots of skin in them are still likely to be within project scope.
Think about retuning and drop the word NSFW altogether. -- (talk) 11:54, 8 August 2017 (UTC)
No problem, do you suggest stopping the current report or using some other wording, maybe "images to keep an eye on"? −ebrahimtalk 12:11, 8 August 2017 (UTC)
@Ebrahim: Since the detection appears to be of skin, how about instead of "NSFW" using the word "Skin"? Also, a supplemental gallery format would ease patrolling.   — Jeff G. ツ 12:37, 8 August 2017 (UTC)
Jeff: You are right about the current state of the report :) moved the page to a less attention making title. Feel free to move that to any other place you feel more right. −ebrahimtalk 13:08, 8 August 2017 (UTC)
@Ebrahim: Thanks. You have some images there that scored 0.01, I thought your cutoff was 0.50. Also, could you reformat such numbers as 1% and 50%?
Fixed the formatting and removed the low ranked ones that was added for some testing. Thanks :) −ebrahimtalk 14:01, 8 August 2017 (UTC)
There are some other ready to use models here, for example flower classifier available there can be helpful for identifying unidentified flower maybe available on Commons. What else can be done with the models there do you think? −ebrahimtalk 14:09, 8 August 2017 (UTC)
The flower classifier was created for flowers commonly occuring in the United Kingdom - 102 of them. Applying that as is on a global data set would probably do more harm than good even if it's just for suggesting names. Also, while some plants are easily determined down to species level from a single photograph of a flower, in most cases that's just not enough information even for experts. --El Grafo (talk) 12:38, 17 August 2017 (UTC)
El Grafo: Thanks for checking out its detail.
There are some open trained models here in addition to ones here, I guess some of them can serve some use for Commons community as a helper or service, like "Image Colorization" (for adding artificial colors to the images), "Image Captioning", "Image Denoising" (it tries upscales images) and "Image Inpainting" (for watermark removal or such). What do you guys think? −ebrahimtalk 18:50, 24 August 2017 (UTC)

I think the NSFW/nudity issue is small compared to the fact we have over two million media needing categories. A more valuable use of this technology would be to create a "Commons game" similar to Wikidata: The Game. The software would propose categories for these backlogged files, and human reviewers would choose yes/no. It also could identify likely copyvios from these images, and their sources, allowing semi-automated deletion nominations. Guanaco (talk) 20:47, 24 August 2017 (UTC)

Great! That makes whole lot of sense! −ebrahimtalk 11:53, 25 August 2017 (UTC)
Guanaco: Just started to work on it here: MediaWiki:CommonsGame.js, is in very initial state but soon some tangible results can be seen :) −ebrahimtalk 12:43, 25 August 2017 (UTC)
Guanaco, Yann, Jeff, : Very initial, but worth to check I guess: CommonsGame, the "Add" button is not implemented yet (now it is but as the inaccuracy of the suggestions shouldn't be used anyway) and other than image deep-learning tags some other sources like the file title, file description and usage can/should be used but I think it is a proof-of-concept of some sort at least. There are also some other models available maybe with a better quality and possibly the file name itself is more reliable (as far as I see) but I believe it is better than nothing at this point at least. −ebrahimtalk 19:40, 25 August 2017 (UTC)
@Ebrahim: Good proof of concept. Unfortunately it seems not to identify anything correctly and has a very dark sense of humor, suggesting punching bag Category:Punching bags for File:面內抱 vs 面內前揹法.png! I think this will need a better model for matching, possibly using the file name as you say. This only solves the first half of the problem. It also has a hard time translating matches to relevant categories. For File:Chuck kosak.jpg (suit: 70%, Windsor_tie: 20%, bolo_tie: 1%, groom: 1%, Loafer: 0%) it suggests Category:Suita, Osaka, Category:Suiten, and Category:Suite Noa Noa. I expect this will need development on a much larger scale, with awareness of the category tree and learning based on typed user input. Guanaco (talk) 20:24, 25 August 2017 (UTC)
Guanaco: Thanks for the feedback! Well, on "suit" case, blame goes to Wikimedia's search as it uses its API, search result (of course I don't expect much more given data available on Commons, just wanted to indicate how the script works currently). As a workaround, Wikidata or English Wikipedia search can be used alternatively and then finding related Commons category on the search result pages. −ebrahimtalk 20:36, 25 August 2017 (UTC)
And of course this is just a started work, others can also participate also if interested, if someone could write a python script with an image as input (using whatever logic preferred, even pywikibot + current deep learning result if sees suitable) I can turn that script into a webservice and use it with this work as doing more of such logic would be easier on a powerful backend available tools I guess. −ebrahimtalk 20:47, 25 August 2017 (UTC)

Limit GIF to 100 MB[edit]

SELECT CONCAT("* [[:File:", REPLACE(img_name, "_", " "), 
       "]] (", ROUND(img_size/1024/1024)," MB)") AS Files
FROM image
JOIN page ON page_namespace=6 AND page_title=img_name
WHERE img_media_type="BITMAP"
AND img_major_mime="image" AND img_minor_mime="gif"
AND img_size >= 10e7
ORDER BY img_size DESC;

I propose capping GIF uploads to 100 MB. Animations at these sizes will not animate (see $wgMaxAnimatedGifArea and noc) as the server usage is too great. A proper video codec should be used for animations and archival TIFF/PNG for still images. The abuse filter should direct users to a WebM converter. We should somehow exempt weather maps (video GIFs seem to be uploaded by newbies).

Other services such as Imgur limits files to 200 MB, but transcodes to MP4 on upload (previously 50 MB and 5 MB for untranscoded). —Dispenser (talk) 22:58, 16 August 2017 (UTC)

  • Symbol support vote.svg Support The sensible thing to do. The first one mentioned above is probably a copyvio. Yann (talk) 23:18, 16 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose High resolution Photographs are encouraged and get prompted, but high resolution GIFs should be banned? Considering that GIFs are really only a minimal percentage of the files on this server I really do not see the logic behind this. Do we want high resolution or not? If storage is the problem limiting JPGs to 20MB would help a thousand times more. --Jahobr (talk) 23:59, 16 August 2017 (UTC)
    High filesize is not always high resolution. If really needed, WebM (for animations) or PNG (for still) can be used, which compresses more efficiently. Poyekhali 12:33, 17 August 2017 (UTC)
  • I have to Symbol oppose vote.svg Oppose at the moment if for no other reason than the fact that I am loading these and they are in fact animated. —Justin (koavf)TCM 00:07, 17 August 2017 (UTC)
    @Koavf, Jahobr: I am not sure where to put the limit, but the issue is that on 99% of computers, these files won't play. I have a recent PC with ADSL and 8 GB RAM, and the first 2 files do not play for me. Regards, Yann (talk) 00:16, 17 August 2017 (UTC)
    @Yann: I don't think we need one in principle: it's fine for Commons to host files that are maybe impossible to play on any system as long as they are free and educational. —Justin (koavf)TCM 00:29, 17 August 2017 (UTC)
    IMHO "impossible to play" is not compatible with "educational". Regards, Yann (talk) 00:33, 17 August 2017 (UTC)
    @Yann: But that is only temporary. Someone can and will make a player. Remember how inaccessible .ogg was in 2002? The solution wasn't to avoid all audio/video nor to use a non-free format but to wait and make the tools to play it. What is impossible to render or play now will not necessarily be in the near future but if we prohibit an upload because of a file type restriction that is impractical in 2017, we could stop many from having access to it in the future. This is why I am entirely in favor of 3-D models, fonts, etc. being uploaded to Commons ASAP, even if we don't have in-browser support (yet). —Justin (koavf)TCM 00:55, 17 August 2017 (UTC)
    No. Nobody will make a player for an outdated format. See Zhuyifei's message below. Regards, Yann (talk) 00:57, 17 August 2017 (UTC)
    3-D models and fonts aren't outdated tho. Nor are GIFs. And even if something can't play in-browser, it's still worthwhile for us to serve it up here (assuming that it fits our scope, obviously). —Justin (koavf)TCM 01:05, 17 August 2017 (UTC)
    (Edit conflict)Well, you can play GIFs with a proper player like ffplay or possibly VLC, but that is not what GIFs are designed for, simple animations, not videos. You are forced to have low fps, resolution, and/or duration, and a super bad 256 colour space. --Zhuyifei1999 (talk) 01:09, 17 August 2017 (UTC)
    @Zhuyifei1999: Certainly, there are a lot of limitations which can and have been overcome but they are also not widely adopted. Your argument is just as sensible for refusing GIFs carte blanche. —Justin (koavf)TCM 01:17, 17 August 2017 (UTC)
    @Koavf: Well, you can certainly create a motion picture film for a video, and try to scan the film itself into an image; everyone who wish to watch the video would have to reconstruct the video from the movie tape scan frame by frame. Can it work? Yes. Can automated support to reconstruct the video be added? Yes. Does it exist already? Yes, movie projectors. Then why do we not adopt it? Because an image container format, including GIF, that simply store many images, only to recreate some sense of an actual video, is horribly inefficient. Yes, it may work for smaller animations, in which playback support is usually not needed; but for large (in size) videos with large fps (anywhere above a dozen frames per second), duration (anywhere above a dozen seconds), and/or resolution (anywhere above 240p), GIF will not suffice, not will support ever be added. Developers would better spend time to work on a "next-gen open codec", rather than hacking into the browser and adding playback support to GIFs. --Zhuyifei1999 (talk) 03:39, 17 August 2017 (UTC)
    BTW, I have no idea what you mean by "Your argument is just as sensible for refusing GIFs carte blanche". Please explain it in plain English. --Zhuyifei1999 (talk) 03:41, 17 August 2017 (UTC)
    Clarification: technically, on how GIF works (stores animations), it is just as worse as a scan of a motion picture film. --Zhuyifei1999 (talk) 03:47, 17 August 2017 (UTC)
    @Zhuyifei1999: Sorry if I was unclear: Do you think we should get rid of all GIFs then? If not, why just the ones below a certain arbitrary number? —Justin (koavf)TCM 04:01, 17 August 2017 (UTC)
    @Koavf: Small animations are okay, where playback controls are not necessary. GIFs larger than 100MB are definitely not animations. BTW: 100MB is not an "arbitrary" number; it's the threshold before chunked uploading is required to upload the file. --Zhuyifei1999 (talk) 05:25, 17 August 2017 (UTC)
    I'm not sure if the on "99% of computers, these files won't play" estimate is accurate. The full size "original file" version of all of these files load and play on my two year old phone (it has 2 GB RAM), so I suspect many computers will play them just fine. —RP88 (talk) 05:11, 17 August 2017 (UTC)
  • Symbol strong support vote.svg Strong support IMO GIF is a super bad format. It can't even do 24-bit RGB, but limit you to 256 colours. What's the point of such lossy-ness when you have other formats (eg. VPx) where is quality loss is barely visible? Yes, GIFs are easier to play (automatically) on browsers, but browsers do not usually offer seeking/pausing/resuming/rewinding on GIFs. Even if these large GIFs were possible to play, for a large animation, proper video files with proper playback support are more suitable. --Zhuyifei1999 (talk) 00:44, 17 August 2017 (UTC)
    256 colors is more than sufficient for many animations, animations where GIF will reproduce perfectly the sharp lines and edges that VPx will mangle. There are many old games (some of which have been released freely, like w:Flight of the Amazon Queen) for which GIF would be the only common format that can losslessly reproduce a playthrough.--Prosfilaes (talk) 04:58, 17 August 2017 (UTC)
    Lossless = the format produce no quality loss whatsoever when being transcoded from raw video. GIF will be lossy in colour when transcoded from raw video.
    The question is not whether the format is lossy or lossless (yes, VPx can be much more lossy), but whether the loss is visible. VPx is able to produce a much less lossy video in a much smaller file size. --Zhuyifei1999 (talk) 05:25, 17 August 2017 (UTC)
    That's not what lossless means; it means without loss. In processing certain sources of video, that is video producing by playing old-school games or animations produced with the constraints of GIFs in mind, GIFs will reproduce the original video without loss, whereas VP9 won't. GIFs are not a good tool for video of real life, but many things aren't video of real life or simulation thereof.--Prosfilaes (talk) 06:18, 17 August 2017 (UTC)
    Old video game replays may be watchable in log FPS / resolution, but real life recordings? Certainly not. Face it: none if the GIFs in the list of over 100MB are old video games. If they are "produced with the constraints of GIFs in mind", the recordings are unlikely to exceed 100MB, as it takes around 20 GIFs at 99% mark (5MiB per Dispenser) to produce such a large 100MB. This proposal does not concern those GIFs under 100MB, which video game replays should be.
    Also, colour loss is loss. It is approximation of the original colour. If you transcode a colourful PNG into GIF and back it will be different, just as if you transcode a FLAC into OGG then back. Similarly, just because you can use jpegtran to losslessly crop a JPEG using chunk/block mechanisms does not mean JPEG the format itself is lossless. --Zhuyifei1999 (talk) 06:42, 17 August 2017 (UTC)
    I don't know what you mean by 20 GIFs at 99% mark. 30 FPS for an hour is 108,000 frames, which aren't going to be under 1k per frame, so one hour of old-school game footage is going to be over 100 MB. Yes, color loss is loss. But if you transcode old-school graphics into GIF, you can reproduce them exactly. That's not true for VPx.
    Nothing is lossless; all image and video formats have limits on the range of colors they reproduce. It's all about reproducing the source data correctly, and GIF does that for certain datasets.--Prosfilaes (talk) 10:12, 17 August 2017 (UTC)
    I don't think it's worth to consider a hypothetical "30 FPS for an hour" ... "old-school graphics"/"certain datasets" case. The list of currently known violations does not contain any such datasets, at all. If someone really knowledgeable wants to override this, of course we may consider giving 'autopatrolled' a possibility; but for newbies, no, they are almost never using the appropriate technology for their not-suitable-for-GIF dataset.
    Regarding 20 GIFs at 99% mark, see Dispenser's comment at 02:09, 17 August 2017 below. --Zhuyifei1999 (talk) 10:32, 17 August 2017 (UTC)
    BTW: does footage of old games really need 30 FPS? My experience on old games are almost always low FPS due to slow processing speeds at the time --Zhuyifei1999 (talk) 10:38, 17 August 2017 (UTC)
    The current list of large GIFs is nine files; that doesn't justify an "at all". My statistics is a little weak, but our sample is entirely consistent with 10% of the large GIFs uploaded being old-school playthroughs. Putting up blocks to the rare uploader who uploads large GIFs seems unnecessary.
    Download an old speed run from Youtube and step through it. They're clearly at 25 or 30 FPS. Even the ones that aren't consistently at that rate have elements that update every frame change. Many games, no matter what the system, hit a stable 25/30 FPS; it's a requirement to look half-decent and if you're using a TV as a monitor, you have to match screen refresh rate.--Prosfilaes (talk) 11:18, 17 August 2017 (UTC)
    Well, maybe 10% of large GIFs are indeed a playthrough, and the chance of sampling 9 consecutive non-playthroughs from an infinite population of 10% playthrough and 90% non-playthrough is around 38.7%, which isn't too bad. But what do you think the chance of the newbie-uploaded GIF not being immediately speedied / tagged no-* / filed DR as suspected copyvio, given #Restrict_Video_Uploading? About none, sorry. And no, a newbie is much more likely to upload in a proper video format due to the massive size reduction. --Zhuyifei1999 (talk) 11:57, 17 August 2017 (UTC)
  • Pictogram voting comment.svg Comment
    GIF: 78 MB, framerate judder (only 25 or 33.3 fps timings), color dithering or banding, autoplay, no browser playback controls (T85838)
    Ogg Theora: 19 MB, 30 fps, supports audio, no autoplay (T116501)
    99.0% of GIFs on commons are under 5 MiB (see table). I've included an example on the side with a 100 megapixel GIF and its video version (please enable Media Viewer [use incognito mode]). So another possibility is to only warn users on large GIF uploads that we have video tools and video tools work better than GIF for certain things. —Dispenser (talk) 02:09, 17 August 2017 (UTC)
  • Symbol support vote.svg Support Even the largest animated GIF from the list above runs without problems in full resolution on my notebook (macbook with 16 GB memory). But I agree that GIFs are not the appropriate format for such movies. They should be converted to one of our supported video formats, i.e. Ogg Theora or WebM, which compress much better than GIFs. The autoplay feature is also a nuisance in case of these monster GIFs. --AFBorchert (talk) 06:49, 17 August 2017 (UTC)
  • Neutral, but... among the European Space Agency uploads there have been several GIFs. These are especially useful to animate a series of large satellite images (or digitally enhanced images) that show sequences of weather or other long timescale events. Fortunately they have been of modest size so far (~10 MB), however were I forced to transcode desirable files like this, I probably would not bother. Providing in-built transcoding facilities for video files should remain a high priority if Commons is ever going be a serious host for multi-media, rather than just a poor cousin to Flickr. -- (talk) 06:52, 17 August 2017 (UTC)
  • Symbol support vote.svg Support Large GIFs are huge pains for old computers and phones. By allowing them to be used on sister wikis like Wikipedia, we are not making Wikimedia an all device-friendly website. Also, those with data plans would be surprised to see that they have to pay 10x more than normal just because a large GIF has been loaded. If really needed, WebM VP9 or VP8 only can be used instead for animations, or PNGs for still (and also JPEG, which would be used in sister wikis). GIF has long been superseded by PNG, not only in bit depth but also in compression and animation (although APNGs are not yet supported by most browsers). --Poyekhali 12:27, 17 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose It's a free format with some potential uses; like I mentioned above, 256 color games can be losslessly filmed in GIF, whereas we support no format that can losslessly store it. It's suboptimal for many of the files above, but because someone has uploaded a handful of files in a suboptimal format is not worth hardcoding a ban on the format. It would have taken a lot less time to delete those files then have this discussion, and banning the format is not going to magically make those files get uploaded in a useful format.--Prosfilaes (talk) 00:25, 19 August 2017 (UTC)
    Considering that an abuse filter warning message can, in fact, link to a help page, yes, banning the format is able to magically make those files get uploaded in a useful format. --Zhuyifei1999 (talk) 22:54, 19 August 2017 (UTC)
  • Comment/question: is this about GIFs in general or strictly about animated GIFs? Most GIFs are not animated, but some of the discussion above seems to presume animattion. - Jmabel ! talk 15:32, 19 August 2017 (UTC)
    The edit filter can only target GIF as a whole, but people here seem have forgotten what a Megabyte can hold. For reference: w:VLC media player with every codec compiled in — 31 MB, w:Mozilla Firefox with a codebase that broken the VS compiler — 43 MB, w:Blender 3D full fledged 3D modeling, animation, and game engine — 86 MB, MacOS 8 Operating system (about 160 MB, release 1997), Audio CD or CD-ROM 650 MB. Also, Animated PNG are generally more efficient. Dispenser (talk) 16:35, 19 August 2017 (UTC)
    A megabyte can't hold anything worth talking about. Code is much more concise than pictures or video. That CD-ROM, in VCD format, can hold 80 minutes of video, approaching the lousiest quality of any standard home video format. Animated PNG may be more efficient, but it's not standard.--Prosfilaes (talk) 16:47, 19 August 2017 (UTC)
    10,000 by 10,000 pixels @ one byte per pixel would hit the 100MB limit, provided the GIF is uncompressed. Maybe there's some 30,000 x 30,000 pixel GIF that proper LZW compression doesn't bring under the 100MB limit, but it would be an incredibly unusual beast, and almost certainly better in PNG.--Prosfilaes (talk) 16:47, 19 August 2017 (UTC)
    Exactly. Why would anyone store a gigantic still image in GIF instead of PNG? --Zhuyifei1999 (talk) 22:56, 19 August 2017 (UTC)
  • Symbol support vote.svg Support per Zhuyifei1999. --Steinsplitter (talk) 17:04, 19 August 2017 (UTC)

Only warn uploaders[edit]

GIFs size distribution
Filesize  % of GIF files
<  0.3 MB 84.1%
<  2.6 MB 97.7%
<  4.9 MB 99.0%
< 23.0 MB 99.9%
< 32.2 MB 99.95%

Since the animation size restriction is broken ($wgMaxAnimatedGifArea), the 100 MB limit (which guaranteed no animation when downscaled) only made sense with that context. Since we don't have a transcode on upload facility like Imgur; I suggest creating an edit filter to warn/remind uploaders that video content is better compressed/transmitted/viewed in WebM. I think a good trigger for it would be 5 MB (Imgur's old limit) or 25 MB (< 0.1% of GIF uploads). —Dispenser (talk) 23:17, 23 August 2017 (UTC)

The Phabricator task been resolved, all thumbnails of GIFs > 100 animated megapixels are frozen now. Dispenser (talk) 16:08, 12 September 2017 (UTC)

Add Copyright owner and Uploaders info on Mainpage under MOTD and POTD sections.[edit]

Wikimedia Commons Mainpage has an daily average page view of 75,000+ and the MOTD as well as POTD are of main importance on it. I would like to propose/request that the Copyright owner name as well as the Uploaders name be added below the images which will give a clear view of the people who has contributed to the image. As Commons follows Attribution-ShareAlike 3.0 Unported {{CC BY-SA 3.0}} License the term of ATTRIBUTION too will satisfy by this step. This POTD AND MOTD acts as an Featured to wikimedia Commons this step can encourage many others to contribute more to the freely-licensed educational media content to all.

  • Why Copyright owner be featured?
The copyright owner has submitted it's creation for the sake of Creative Commons License use rather than maintaining it's copyright status which should be respected.
  • Why Uploders?
Uploaders are the one who have given their efforts to make the media available to Commons. They get more inspiration by such features on Mainpage. (Am sure they would like it).
  • What if Uploders and Copyright owner are the same?
No issues they can be featured in a single title.

--✝iѵɛɳ२२४०†ลℓк †๏ мэ 07:00, 23 August 2017 (UTC)

  • Symbol support vote.svg Support Excellent idea!   — Jeff G. ツ 20:45, 25 August 2017 (UTC)
  • Symbol support vote.svg Weak support Yeah, okay. --Talk to Kong of Lasers 16:23, 11 September 2017 (UTC)

Finalize Commons:Creator and approve as policy[edit]

I would like to finalize Commons:Creator and approve as policy. One of the controversies around Creator templates is the scope of the template, "clearly yes" and "clearly no" sections were never controversial, but many of the following "gray area" cases still cause conflicts, like here or here. I would like to clarify what would be consensus about each type of use, so I do not have to have discussions like this. --Jarekt (talk) 04:21, 28 August 2017 (UTC)

Commons users[edit]

Few dozen Commons users created vanity creator templates for themselves. Since we have no policy against it, such templates are usually not deleted, however they are usually tagged with "type=commons user" so they do not clog maintenance categories. There are at least 36 of them and can be seen in Category:User creator templates.

  • I Symbol oppose vote.svg Oppose creator templates created by the subjects who are not notable enough to meet Wikidata or Wikipedia notability criteria. This follows the reasoning of this Wikipedia FAQ. However I would not penalize otherwise notable people for also contributing to Commons. --Jarekt (talk) 04:21, 28 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose: same opinion. Nomen ad hoc (talk) 15:21, 28 August 2017 (UTC).
  • Wikidata criteria are not very clear, and quite a number of Commons contributors seem to meet them. Regards, Yann (talk) 18:22, 28 August 2017 (UTC)
If they meet them, they'd be eligible for a creator templates, just not only for them being Commons contributors – as stated above. (Same for the Flickr photographers.)
What clarity specifically do you miss from the Wikidata notability criteria? (They are very permissive of course.) --Marsupium (talk) 21:16, 28 August 2017 (UTC)
Yes, they are very permissive. I mean that many Commons contributors are eligible for an entry there, and that's not what most people expect here. Regards, Yann (talk) 22:27, 28 August 2017 (UTC)
Marsupium, I think what Yann is saying is that Wikidata Notability criteria are broad and can be hard to interpret in this context. For example person is notable if the item has a sitelink to Commons (or other projects), so if you create a one-image gallery on Commons you can create an item on Wikidata which allows you to have creator template. That creates kind of circular dependency. Maybe we should limit Notability to Wikipedia and Wikisource. Or maybe the we should just accept that there is no simple policy that works for 100% of cases and deal with edge cases on page by page cases. --Jarekt (talk) 00:33, 29 August 2017 (UTC)
OK, I see. I think you're both right. So IMHO:
  • Creator templates should only be used for the author of (so to say primary) media that are itself in the project scope, not of those media just depicting/describing/illustrating something else that is in the project scope. If there is no media that should get a creator template also the template shouldn't get created.
Thus, Category:User creator templates should (as of a spot check I just did) get at least almost emptied. --Marsupium (talk) 08:15, 29 August 2017 (UTC)
To be clearer, I wasn't talking about circular dependency. To be eligible for an entry in Wikidata, you only need an external reference. Anyone who is acting somewhere in an official capacity, and anyone who publishes something somewhere may get one. That's quite large... (I meet the criteria ;oD). Regards, Yann (talk) 08:42, 29 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose: same opinion. --Marsupium (talk) 21:16, 28 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose. User templates as creators should be in user namespace. So they cannot have notability in wikidata. -- Geagea (talk) 08:41, 29 August 2017 (UTC)
  • Symbol strong support vote.svg Strong support I would like to one day see creator templates for most of our content. If a file is in scope, then we want complete information about it. Creator data is part of this. Also, this is an inexpensive way of providing recognition to our contributors, encouraging them to upload more original content. Guanaco (talk) 08:51, 29 August 2017 (UTC)
  • Comment Category:User creator templates is used on templates about people (including me) who also meet the Wikipedia or Wikidata notability criteria. Also, this whole debate may be rendered moot by the coming of structured data - we will need some way of holding data about every creator. Hence @SandraF (WMF): for info. And please don't accuse good-faith contributors of acting out of "vanity". Andy Mabbett (talk) 11:53, 29 August 2017 (UTC)
    • P.S. The template's documentation says that |type=commons user is for "For people directly contributing to Commons, aka Commons users." It says nothing about such use being for people who are only Commons users - there are many Commons users who are also known more widely. Andy Mabbett (talk) 12:26, 29 August 2017 (UTC)
Andy I crossed word "vanity" used above, even if many templates in Category:User creator templates seem to meet that label. I totally agree with you that structured data should rendered this discussion moot. As I said in the opening paragraph I do not want to penalize otherwise notable people for also contributing to Commons, so this discussion does not apply to otherwise notable individuals. --Jarekt (talk) 16:59, 29 August 2017 (UTC)
  • Pictogram voting comment.svg Comment Wherever creators of media here are stored, at least I don't see a point in maintaining the (not sourced) date of birth of Creator:Alain Meier (sorry, he simply is the first one in the category) here or at Wikidata. (There should to be drawn a line somewhere between Leonardo da Vinci and IPs perhaps.) --Marsupium (talk) 12:51, 29 August 2017 (UTC)
  • Symbol support vote.svg Support I stand with Guanaco here; it's somewhat useful, and it's a cheap way of supporting our contributors. As for Marsupium's comment, I see good reason for maintaining the date of death of Creator:William Starner; he has a couple photos on Commons, and it's possible I may find many other Commons-worthy shots as I go through his photos; and at some point, 48 years in the future, his photos will be out of copyright in Canada and other places and his date of death will let people know that.--Prosfilaes (talk) 16:40, 29 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose only for creators notable enough to have an article in Wikipedia Christian Ferrer (talk) 18:35, 29 August 2017 (UTC)

Flickr photographers[edit]

Some of Flickr photographers have many thousands of images on Commons, some of them have creator templates.

  • Symbol oppose vote.svg Oppose As with Commons users I think the only contemporary people with creator templates should be meeting Wikidata/Wikipedia notability criteria --Jarekt (talk) 04:21, 28 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose: same opinion. Nomen ad hoc (talk) 15:23, 28 August 2017 (UTC).
  • Wikidata criteria are not very clear, and quite a number of Flickr contributors seem to meet them. Regards, Yann (talk) 18:22, 28 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose: same opinion. --Marsupium (talk) 21:16, 28 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose. But we should make new template for those photographers and we can open discussion in wikidata regarding to notability. -- Geagea (talk) 08:41, 29 August 2017 (UTC)
  • Symbol support vote.svg Support Information in file descriptions is beneficial. Templates and Wikidata entries are cheap. Guanaco (talk) 08:53, 29 August 2017 (UTC)
For most Flickr photographers all we know is on their author flickr page. A link to that page should be sufficient. Templates and Wikidata entries are cheap but data about most flickr authors can not be sourced properly. --Jarekt (talk) 16:41, 29 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose only for creators notable enough to have an article in Wikipedia. Though an alternative solution (a different template) should maybe found for Commons and/or Flickr photographer, with optional parameters... Christian Ferrer (talk) 18:35, 29 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose Agreed with User:Jarekt. --Talk to Kong of Lasers 03:52, 8 September 2017 (UTC)

Non-individual Creators[edit]

We have many creator templates for institutions, projects, factories, manufacturers, multi-generation photo studios, newspapers, corporations, etc. Some of them are in Category:Group creator templates or Category:Corporate creator templates categories. Many fields of creator templates, which were created with people in mind, are not relevant for them.

  • I BA candidate.svg Weak oppose such templates, especially new ones. I do not mind creating other templates for them, like Institution templates, but creator templates are a bad fit. --Jarekt (talk) 04:21, 28 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose: unfit for groups. Nomen ad hoc (talk) 15:25, 28 August 2017 (UTC).
    • And yet the template's documentation includes |type=group. Andy Mabbett (talk) 12:24, 29 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose Better to use Institution templates for these. Regards, Yann (talk) 18:23, 28 August 2017 (UTC)
    • GA candidate.svg Weak support Dunno. Some of those are for two brothers, where it's impossible to tell which one took it -- or a father / son combination, etc. Those seem to be within the spirit. Some of those may be a group of authors, whose members are anonymous, which also seems like it fits. If something fits better as an institution template, by all means use that instead, but there are likely some oddball situations which are not individuals, but where an institution template is not appropriate. That template does not have fields for work period, etc., but are more designed as a marker of where a work of art is located today, which is not the same thing as a creator template. It is going to be hard in some situations to define a line where a creator template goes outside the lines, but there will definitely be cases where non-individual templates make some sense. The idea is to collect information about the creators to aid identification, etc. If there is nowhere else for that information to go, then barring them on creator templates is only hurting. Carl Lindberg (talk) 19:33, 28 August 2017 (UTC)
      • Creator templates are expected to be for individuals. So we either expend that, or we create another template for organisation and groups. This needs a major change anyway. Regards, Yann (talk) 22:31, 28 August 2017 (UTC)
        • Given that the template's documentation includes |type=corporation and |type=group, this claim would appear to be false. Andy Mabbett (talk) 12:23, 29 August 2017 (UTC)
          • Early on we identified that non-individual Creator templates cause issues in our maintenance categories and |type= is used to keep track of non-individual creators and exclude them from most maintenance categories. Since template writers were asked not to add categories to the pages, we use |type= to add pages to Category:Creator templates by type subcategories. --Jarekt (talk) 16:28, 29 August 2017 (UTC)
    • Pictogram voting comment.svg Comment I don't mind whether to store them in one template or another. One could improve the support by {{Creator}} for them or spin them off to a new template. As to institution templates I'm sceptical if they are suitable currently, they are for institutions collecting objects, not creating them, currently used 'work location' and 'work period' make more or less sense for these, not for the others. I think the decision about those non-individuals needs some more investigation on the alternatives. The information should be stored somewhere, thus the most practical way might be the best whatever that is. --Marsupium (talk) 21:16, 28 August 2017 (UTC)
      • Pictogram voting comment.svg Comment Marsupium, template:Creator is becoming too complicated to add proper support for Non-individual Creators, but I think spinning them off to a new template would be a good idea. We could store such templates in the creator namespace or keep them in the template namespace. --Jarekt (talk) 16:28, 29 August 2017 (UTC)
  • Pictogram voting comment.svg Comment. As Yann suggested, Institution templates are the proper template for them (which should be improved as well). They are not creators. Only photography companies can be considered as creators.-- Geagea (talk) 08:41, 29 August 2017 (UTC)
    • Of course we have corporate and collaborative creators. Consider musical ensembles, for example. These are not "institutions". Andy Mabbett (talk) 11:56, 29 August 2017 (UTC)
      • For many templates in {{Institution}} has more relevant fields than {{Creator}}, but it is also not a perfect fit. I like Marsupium idea of spinning such pages off to use a different template. --Jarekt (talk) 16:36, 29 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose Christian Ferrer (talk) 18:35, 29 August 2017 (UTC)

New idea about Non-individual Creators[edit]

@Marsupium, Pigsonthewing, Yann, Clindberg, Geagea: Maybe the best solution would be for pages in Creator namespace to come in 2 flavors:

  1. one for people - served by current Creator template
  2. one for non-person Creators - served by some new template in order to simplify code and documentation. I do not have a good idea for a name, maybe template:Non-individual Creator, template:Non-person Creator, template:maker, template:Creator entity? Other ideas would be appreciated. It would have following fields:
  • Name - also provided by {{label}} if there is a q-code
  • Authority control for items with q-code
  • Description - not filled based on Wikidata
  • "Work period", "activity period" or "active during" - Possibly filled through work period (start) (P2031), work period (end) (P2032) and floruit (P1317) (although the past one is restricted to humans only)
  • "Work location", "activity location" or "active in" - Possibly filled through work location (P937) but possibly not linked to Wikidata

Such fields would provide minimum of information to wide range of groups, studios, manufacturers, newspapers, corporations, etc. that can be refereed to as " authors" of some work. --Jarekt (talk) 13:27, 19 September 2017 (UTC)

A "GroupCreator" template like that could work, sure. Could also have a field of "members" if we do know of related individuals (if the creator is a father/son combination who only used the last name or company name to mark works, etc., things like that). Work period start / end may be enough -- not sure we need a flourished field. A group could have multiple locations of course (as can individuals). Carl Lindberg (talk) 16:05, 19 September 2017 (UTC)
I like the "GroupCreator" term it could be a good template name. Or maybe template:Creators. Clarification about "Work period" on Wikidata there are work period (start) (P2031), work period (end) (P2032) for describing work period in a for of 2 dates and floruit (P1317) to describe it in the form of a single date, like 19th century. --Jarekt (talk) 03:24, 20 September 2017 (UTC)
No, we don't need two, near-identical templates. As noted above, we already have |type=group to distinguish from templates about individuals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 20 September 2017 (UTC)
The big issue with that is it has a rather large dependency on birth date and death date, as those are displayed in the header, and you have to jump through a couple of extra hoops to avoid that. Granted, the template coding could also check type=group to fix that as well. I'm not sure how much complication to the rest of the creator system that a second template would add, or if it's better to have conditional behavior in one template. Carl Lindberg (talk) 22:17, 20 September 2017 (UTC)

"In other projects" section in side bar[edit]

Hello, the side bar has sections such as "Participate", "Tools", "In other projects", and "In Wikipedia". However, the "In other projects" and "In Wikipedia" sections are not next to each other, but "Tools" is between them. Can you switch the position of "In other projects" and "Tools", so the sections appear in the order I first mentioned? -- 14:22, 28 August 2017 (UTC)

Feature request - upload files in the order specified by user[edit]

When I upload a batch of images, they appear in my uploads list in a different order than the order I specified. For example I select Image 1 then Image 2 then Image 3, but they upload in a different order: 2, 3, 1 or another random order. Please give the user the option to upload the images one by one, in the order they specify, even if that means they have to wait longer (for example the first image might be very big so you have to wait until it finishes uploading). Thanks. Fructibus (talk) 08:30, 29 August 2017 (UTC)

@Fructibus: This could be implemented client-side. What upload client(s) do use for batch uploads?   — Jeff G. ツ 10:27, 11 September 2017 (UTC)
@Jeff G.: I am using the only upload clients I know - the Special:UploadWizard - because there is a link for it on the left side of the window, saying "Upload file". Fructibus (talk) 11:35, 11 September 2017 (UTC)
@Fructibus: Did you "Select media files to share" or "Share images from Flickr"?   — Jeff G. ツ 00:38, 12 September 2017 (UTC)
@Jeff G.: I always just click the blue button "Select media files to share". I don't see any Flickr option. Fructibus (talk) 02:12, 12 September 2017 (UTC)

Proposal: Allow 'source' code for "free" 3D modelling and rendering tools software like Povray, Blender and MakeHuman to be uploaded as files..[edit]

Commons currently has some categories related to images rendered or modeled using various "free tools"

Category:Povray Category:Blender_(software) Category:MakeHuman

I am seeking a community consensus and opinion on allowing the source code files for these (providing they are under suitable licenses.), to be uploaded directly, as the relevant mhm, blend, and pov and related files directly (as opposed to being a text inclusion on file information pages), so that :

  • The relevant "free tools" are promoted as is the variety of artwork that can be made with them
  • The 'source code' for renders can be examined and built upon.
  • It's potentially possible to render them directly to a thumbnail them on the Wikimedia back-end at a future date.

ShakespeareFan00 (talk) 15:37, 10 September 2017 (UTC)

There's this, but that does not support those files. I would also like for such files to be able to uploaded, even though actually rendering previews (like the 3D extension) is not feasible. I'd rather have unrendered files than to potentially lose freely-licensed 3D models. Tom-L (talk) 19:39, 10 September 2017 (UTC)
It would also be valuable to be able to upload and link RAW and similar files for the purpose of losslessly and more effectively editing photographs. With each modification to a JPG, the file is degraded. Guanaco (talk) 19:43, 10 September 2017 (UTC)
It's useful to have the POV-Ray files around, but they're not without concerns; points out that a Trojan could in theory be written in the POV-Ray language, and if I wanted to hack the Wikimedia server, a POV-Ray file could open files and export useful information not externally available. Without those IO restrictions that article mentions, which users may not have turned on, a POV-Ray file could be a lot more dangerous.--Prosfilaes (talk) 01:00, 11 September 2017 (UTC)
Indeed, the need for "file sanitisation", possible "sandboxing" etc is an issue that arises with many formats, (I've found articles identifying potential risks with PDF files for example) which Commons already accepts. Another issue would be that I'm not entirely sure how mediawiki would handle dependent files. Whilst it's possible for a povray file to be complete in itself, a large project in it would typically have many files, ( and includes from relevant "standard" libraries (which for POVray are under some form of Creative Commons license, according to header files I've examined.) Commons being Mediawiki based is naturally different from a "web-based repositry manager" whose backend is GIT/SVn etc. Whilst dependencies could be mentioned in an {{information}} block, it's not necessarily an ideal long-term approach for this... Hmm...

ShakespeareFan00 (talk) 08:52, 11 September 2017 (UTC)

Hey all, thanks for sharing the links to the 3D work of the Multimedia team. We're planning on starting with STL files only first, for technical reasons - more formats means more work to support them. You may be interested in this Phabricator task and the discussion around other file formats. CKoerner (WMF) (talk) 22:29, 14 September 2017 (UTC)

Parametric patterns ( for textile design and sewing)[edit]

Recently open source software for drafting 'sewing' patterns for clothing (and other textile) construction became available :-

Would the Wikimedia Community on Commons be interested in seeing sewing patterns included within the scope of "educational resource" materials, Commons provides? Finding freely usable sewing patterns isn't easy, and most of the patterns I've found online are not Creative Commons, (and thus open to modification for sizing tweaks.)

The relevant patterns would at present have to be exported from Valentina to an appropriate vector format (most likely SVG) to be hosted at commons though, as I don't see there being a "Pattern" extension to show them directly for a while.

ShakespeareFan00 (talk) 10:14, 11 September 2017 (UTC)

  • Symbol support vote.svg Support  — Jeff G. ツ 10:24, 11 September 2017 (UTC)
  • Pictogram voting comment.svg Comment I am supportive of this initiative however it seems to me that there is a high chance nobody will ever touch SVG files derived from Valentina file format. Maybe a wikibook about sawing could use such images, but I can not think of other Wikimedia projects that would use them. If others can image other uses please list them. Also projects outside of Wikimedia would more likely use original Valentina files. I would support using Commons as a backup for just in case that website ever disappears. --Jarekt (talk) 20:15, 11 September 2017 (UTC)
The SVG thing was because I didn't think anyone would be interested in writing a viewer for the XML based original files. I would of course back an option to host the Val and companion Vit files directly, but my understanding was that it would require configuration changes to do that, which would need clear community consensus. ShakespeareFan00 (talk) 20:47, 11 September 2017 (UTC)
Hosting files in some new format is also tricky since it would require us to install some viewer while it is unclear if anybody would use it. I think that storing SVG files is within the scope of the project and does not need extensive discussion. However I still have my doubts about who would use such files. --Jarekt (talk) 02:06, 12 September 2017 (UTC)
Someone already wrote a Python implementation of part of the core of the Valentina engine, which may be capable of generating SVG, (Mediawiki already has ways of thumb-nailing from SVG to other formats...). Would still need someone to write a viewer extension though. ShakespeareFan00 (talk) 17:21, 15 September 2017 (UTC)

Increase Special:UploadWizard upload limit[edit]

Currently Special:UploadWizard upload limit is 50 files. I would like to propose to increase that limit to 500 for admins, license reviewers and possibly other trusted users. That capability is already there as discussed here, but it would be more transparent. I found that capability very useful when uploading images from flickr from albums which are bigger than 50 images. --Jarekt (talk) 17:16, 11 September 2017 (UTC)

  • Symbol support vote.svg Support sounds reasonable. --Steinsplitter (talk) 17:50, 11 September 2017 (UTC)
  • Symbol support vote.svg Support The limit of 50 images is small to several types of uploads. Raising the limit to 500 for all users - or at least for now for "admins, license reviewers and possibly other trusted users - is a good move. Tm (talk) 19:49, 12 September 2017 (UTC)
  • Symbol neutral vote.svg Neutral I would like to see this tested using the current Wizard, before having a final consensus. I'm not strongly in favour as the users of the Wizard to do this as an easy way to upload thousands of images, are unlikely to be the sort of technically minded people who would think of neat ways to categorize the images, without having complaints about flooding diffusion categories etc. -- (talk) 20:01, 12 September 2017 (UTC)
I agree with your assessment of this potential issue, that is why I proposed to limit this "super-power" to admins and license reviewers who hopefully are more aware of community standards. I tested this with Category:Photographs by Judy Gallagher, where 100% of files were uploaded using "current Wizard" and most in large batches of up to 500 images. --Jarekt (talk) 17:00, 18 September 2017 (UTC)
  • Symbol support vote.svg Support If there are no technical problems with that many images in the UploadWizzard. -- Michael F. Schönitzer 12:09, 14 September 2017 (UTC)
  • Symbol support vote.svg Support Agreed, if it poses no technical problems. Gestumblindi (talk) 18:34, 17 September 2017 (UTC)
  • Symbol support vote.svg Support. License reviewers and admins are expected to have a basic understanding of categorisation.    FDMS  4    18:48, 17 September 2017 (UTC)

Proposal to uninstall Flow[edit]

Flow is a WikimediaFoundation project intended to replace wikitext talk pages with more conventional forum-style discussion page. It is intended to be more inviting to people unfamiliar with wikitext, and intended to benefit experienced users as well. You can view and test Flow at Commons_talk:Flow/tests.

Many of Flow's intended benefits are quickly apparent. Flow has familiar forum style and features. There is a clear "reply" button, and messages are signed automatically. Other intended benefits of Flow have been well documented on the Flow page. However some technical aspects warrant more detail.

Technical limitations

In addition to providing software-structured discussions, Flow's input and storage mechanism are noteworthy. Flow's primary input method is VisualEditor. The VisualEditor engine is also used for all content rendering. In particular, audio and video files are not fully supported at this time. Audio and video files may not display at all, or they may appear as a generic icon. The WMF currently has a task open to improve media support. At the bottom right of the Flow edit window, a pencil icon may be used to switch to a mode where wikitext may be entered. In some cases Flow may render wikitext differently than expected. When saving wikitext, the VisualEditor engine is used to convert supported wikitext to VisualEditor's native content format (HTML+RDFa). The wikitext is then discarded. Flow does not include a separate preview function for wikitext. The VisualEditor mode is intended to serve as the "preview" for wikitext. When switching to VisualEditor to view a "preview", the VisualEditor engine converts the wikitext to HTML and discards the wikitext. When you return to the mode for editing wikitext, the VisualEditor engine is used to convert the HTML into new wikitext for editing. The newly generated wikitext usually resembles the wikitext you originally entered. However anomalies may appear, due to translation of wikitext->HTML->wikitext. In rare cases, reverting an edit may damage the original content. This is because the original wikitext was never saved, and the translation process may not correctly re-create the original version. The translation process also has the potential to generate "tumors", chunks of corrupt wikitext that expand each time you preview or save.

Current deployment of Flow

The WMF has repeatedly given firm assurance that there are currently no plans to deploy Flow without a local consensus to do so.

Flow is currently available as an opt-in preference on several wikis. This activates Flow as a replacement for an individual's User_Talk page. Most of these are small wikis, activated with consensus as small as 2 or 3 people.

At least one microwiki was fully converted to Flow, based on a consensus of 3.

English Wikipedia: Activity died on all Flow pages, they were deleted and the entire Flow extension was uninstalled by community request. (An RFC was drafted, but the WMF agreed the outcome was obvious and Flow was amicably uninstalled.[2])

Meta Wiki: One Flow page was Two Flow pages were shut down and the extension was uninstalled by an RFC consensus of 26-4.[3]

German Wikipedia: Some individuals are currently discussing running an RFC to uninstall.

Current state of Flow on Commons

Flow is currently installed, and active on two pages: Commons_talk:Flow and Commons_talk:Flow/tests.

An April 2017 RFC to Enable beta function of Flow on own talk page ended Opposed 11-2.

General level of support for Flow

In September 2016, the Wikimedia Foundation ran a Flow Satisfaction survey. A small number of public invitations to the survey were posted, and targeted invitations were sent to almost everyone who had actively opted-in to Flow for their user_talk page. Concerns were raised that this may have severely canvassed participation, however those who ran the survey "insist [] we don’t think this is a canvassed or biased survey" and "It was still open to anyone who wanted to participate".[4]

Amongst the various questions about Flow, the survey found 38% of participants prefer Flow over wikitext talk pages. People are encouraged to follow the survey link above, and read the highly positive (glowing) summary of other survey results. The survey report then recommended that the WMF resume Flow development work and pursue expanded deployment. Resumption of Flow development was then added to WMF quarterly schedules.


Uninstall Flow, as was done on English Wikipedia and Meta wiki. Alsee (talk) 22:24, 11 September 2017 (UTC)


  • Symbol support vote.svg Support for two reasons:
    1. Standard Industry Best Practices say that one of the most important ways to improve the security and stability of a system is to uninstall unused software. This is especially true when that software is undergoing active development. Flow is an unusually complex and invasive extension, hooking into many parts of the wiki. The WMF has drafted extremely vast plans for Flow development that would be extremely invasive into all parts of the system. There is absolutely no reason Commons wiki should risk disruption due to inevitable bugs in an extension that it's not using.
    2. If a series of major wikis uninstall Flow, pretty soon the the WMF will be forced to face reality. We are NOT eagerly waiting for Flow to be upgraded and deployed. We really truly want Flow gone. The 38% support in the survey was a Votestacking fabrication, and the glowing Survey Report was somewhere between wishful-self-delusion and propaganda. Alsee (talk) 22:24, 11 September 2017 (UTC)
    @Alsee: There are a lot of allegations without evidence here... Yann (talk) 15:07, 12 September 2017 (UTC)
    Yann, I'm not going to guess what you mean and waste my time digging up cites for random sentences we both agree don't need cites. Would you like to identify your top two concerns? Alsee (talk) 16:02, 12 September 2017 (UTC)
    @Alsee: You can't put up wild allegations without giving evidence. Sorry, but it is to you to back up what you say. Regards, Yann (talk) 16:12, 12 September 2017 (UTC)
    Yann, I am not going to guess what you mean. Would you like to identify your top two concerns? Alsee (talk) 19:25, 12 September 2017 (UTC)
    @Alsee: Copying and pasting the same sentence again doesn't give any more evidence to your allegations... At this point, it is quite clear you have some agenda here... Yann (talk) 20:36, 12 September 2017 (UTC)
  • Strong support At the very heart of this wiki lies the presumption that any edit can be reverted perfectly. Flow does not allow that. For that reason and all the others above, it should be uninstalled posthaste.   — Jeff G. ツ 00:36, 12 September 2017 (UTC)
  • Symbol support vote.svg Support uninstalling. I only had to spend one minute to look. I failed to immediately find out how to edit comments made by others. It is also so invasive I didn't understand immediately if wiki markup is understood at all, or how I would format my posts to be semantic and accessible to any reader.

    Speaking of accessibility, it's still in baby shoes: <article> elements are not used for comments, but instead a <div> soup. I understand it's a work-in-progress, but still. 2001:2003:54FA:2751:0:0:0:1 01:19, 12 September 2017 (UTC)

  • Symbol oppose vote.svg Oppose Flow brings several advantages on talk pages: no need to sign, no need to follow the whole page to get a notification about an answer, etc. These are mostly useful for newbies. Flow should be used on pages where it would be useful (Help desk, COM:UDR, etc.), where most people asking questions do not sign, and do not see the answers because they do not watch the page. Regards, Yann (talk) 10:22, 12 September 2017 (UTC)
  • Symbol support vote.svg Support uninstalling. My experience using Flow on wikis where I am forced to hasn't been positive. —MarcoAurelio 10:24, 12 September 2017 (UTC)
  • Symbol support vote.svg Support Correct rendering of pages, including images and video files, are critical for sensible discussion about Commons content on Commons. If newbies don't want to sign their posts, then for goodness sake, someone write a bot script to do it for them. As for expecting long term contributors to this project to switch to using the Visual Editor, forget it. It's been many many years of pointless discussion, and too many years of the WMF blatantly ignoring valid complaints about the different ways in which it failed to work, to expect us to invest our unpaid volunteer time to just get bitten yet again. -- (talk) 10:41, 12 September 2017 (UTC)
  • Symbol support vote.svg Support --Krd 10:42, 12 September 2017 (UTC)
  • Symbol support vote.svg Support --Steinsplitter (talk) 11:15, 12 September 2017 (UTC)
  • Symbol support vote.svg Support per MarcoAurelio & YannFae. Storkk (talk) 13:05, 12 September 2017 (UTC)
    • @Storkk: If you agree with me, you should oppose this proposal... Regards, Yann (talk) 15:04, 12 September 2017 (UTC)
      • Sorry for the confusion. Typo/braino after reading the substantive responses. Storkk (talk) 16:20, 12 September 2017 (UTC)
  • Symbol oppose vote.svg Oppose I agree with Yann. Flow might not be all the way there but it does have many advantages over traditional talk pages. I would give it a chance and not pull the plug yet. --Jarekt (talk) 13:07, 12 September 2017 (UTC)
    It will brake our talk page notification tools, etc. And handling spam via Flow is a mess, imho. --Steinsplitter (talk) 16:05, 12 September 2017 (UTC)
    @Steinsplitter: Which notification tools are you talking about? Flow completely changes the way notifications are handled, so you can't compare it with the current system. And IMO using {{ping}} and other templates is a poor hack. Regards, Yann (talk) 16:21, 12 September 2017 (UTC)
  • Symbol abstain vote.svg Abstain as long as I don't have to use it. It's disgusting to use it on Wikidata user talk pages, works for simple text and is awful for templates and links, costs perhaps twice the time to input those if they are rendered correctly at all, those using <code> or <syntaxhighlight> don't it seems and needs workarounds not to introduce wrong <nowiki /> tags. --Marsupium (talk) 17:42, 12 September 2017 (UTC)
  • Symbol oppose vote.svg Oppose Per discussion below. Proposal seems politically motivated with no strong argument presented to uninstall (vs choosing not to use). Perhaps Flow is unfinished, buggy and may even be the wrong approach for Commons editing participation, but it can be ignored, just as parts of Commons can be ignored. The wikitext interface is a poor one that attracts a narrow subset of the population (typically male, typically nerdy) and is a barrier to many creatives who would otherwise participate here. That might not bother those who are happy to hoover up images from elsewhere, but it bothers me, who wishes we had more photographers (and other artists) contributing directly to Commons. The solution might not be Flow, but it certainly isn't wikitext. -- Colin (talk) 07:52, 13 September 2017 (UTC)
  • Symbol neutral vote.svg Neutral I tend to oppose mainly as per Colin, however the issue is that even when you don't active it yourself, if a user active it on his talk page, then you have not other choice that to use it. Also the option "source editing" in Flow should at least propose the same taskbar / menu bar (specially with the edittools). And how will this work with our notification system (block, copyvio, nomination for deletion coming from VFC)? the fact that it is a choice "only wikitext" or "only Flow" worried me a bit. I just try to nominate the page for deletion, as a test, and that don't work, therefore likely the VFC notifications will not work too in a "Flow user talk page", hassle to notify the users. Therefore I tend also to support. Christian Ferrer (talk) 11:44, 13 September 2017 (UTC)
    • Symbol oppose vote.svg Oppose Keep it as a test, develop the test to highlight the potential problems with Commons. No to an implementation as long as there is no solutions for potential issues. But I even more opposed to a test end just "for the principle". Christian Ferrer (talk) 18:08, 13 September 2017 (UTC)
  • Symbol support vote.svg Support, obviously. -- Tuválkin 22:05, 13 September 2017 (UTC)
  • Symbol support vote.svg Support If there's no consensus to even leave it as a beta feature, then no point in leaving it installed. --Rschen7754 00:35, 14 September 2017 (UTC)
  • Symbol oppose vote.svg Oppose -- 12:07, 14 September 2017 (UTC) — Preceding unsigned comment added by MichaelSchoenitzer (talk • contribs)
  • Symbol support vote.svg Support Not needed here. --Gestumblindi (talk) 20:21, 15 September 2017 (UTC)
  • Symbol support vote.svg Support Unused. Should the community change their mind in the future, another proposal can always be made. Train2104 (talk) 16:20, 17 September 2017 (UTC)
  • Symbol oppose vote.svg Oppose per Colin and Yann. It may not be a finished product, but removing it simply becuse it is not ready for prime time and only used for testing here, is not any way to imporove anything.It seem as development has started up again, so let's keep it for testing - so Commons does not get forgotten and left behind when other wikis adopt and fit Flow for their needs. --Jonatan Svensson Glad (talk) 04:51, 20 September 2017 (UTC)


  • Pictogram-voting-question.svg Question What's the actual status of Flow right now? Shortly after it was announced as a beta feature in 2015, it was put in "bugfixes only" mode (see the statements by User:Quiddity_(WMF) in Topic:So4juczs8f56jvp5). There were talks about moving on to something called "Workflows" instead but it seems that never took off? mw:Flow#Development_status is pretty vague, but there seems to be some movement over at Phabricator (phab:T167928)? As it is, Flow might be useful for some smaller wikis, but it's currently not in a state where it really could be used broadly on a project like Commons. Might be useful for a few select pages, though. --El Grafo (talk) 13:13, 12 September 2017 (UTC)
    If it were uninstalled today from Commons, there's nothing to stop it continuing to be played around with on the beta cluster. If folks are going to keep using main projects like Commons as a test site, especially for "tests" which carry on for more than 2 years, then I don't see the point of having a beta cluster. -- (talk) 13:39, 12 September 2017 (UTC)
    El Grafo, like you have seen on phab:T167928, the development has restarted. No announcement has been done so far because the developers needed to decide on a few things and update some pages to provide the best information to communities. In a nutshell, the improvements listed (wikitext storage of messages, search on a page, or move messages) narrow Flow's scope to user-to-user discussions. Those improvements will be deployed on all existing Structured Discussions pages. Some wikis, including Wikidata, French Wikipedia or Chinese Wikipedia, have chosen to use Structured Discussions on user talk pages (Beta feature) or Help desks. Trizek (WMF) (talk) 14:08, 12 September 2017 (UTC)
  • Pictogram voting comment.svg Comment I cannot help but notice that Alsee has 118 edits on Commons, of which only a minority is content. What motivates such a drastic proposal from someone with so little stakes in Commons? Rama (talk) 17:04, 12 September 2017 (UTC)
    Hi Rama. I acknowledge my work on this wiki has been very modest. However I am a well established member of the broader community (mainly EnWiki), and I expect I will be returning here for years to come. I also don't think the proposal is "drastic". It would remove two unproductive pages, and the WMF has already worked out a reasonably easy uninstall procedure. As for my motivation: Wiki-community service. (Based on responses so far, it appears most people agree that posting this proposal was a positive service.) In particular, I am very concerned that WMF engagement with the community is too often painfully-poor. I have taken a special interest in bringing EnWiki community-consensus concerns to the WMF, and keeping the EnWiki community informed of significant new developments by the WMF. It is often painfully difficult getting the WMF to listen to EnWiki, and I've seen how hard it is for other wikis to have any effective voice with the WMF. Other wikis get screwed over. In some cases EnWiki can push to get a problem fixed, and the WMF only fixes it for EnWiki. For example the WMF has begun stealth-deployment of VE as the default editor for new users at all wikis. I caught the issue and EnWiki got it fixed - for EnWiki. The WMF plans to silently do the same at every wiki, unless there is a local consensus to define the wiki as "wikitext primary". The WMF isn't telling wikis that choice exists, they're just going to push out what they want unless someone opens a local discussion on it. The WMF has also decided to phase-out our wikitext editor. They're building a wikitext mode inside VisualEditor as a replacement. It has atrocious performance and faulty previews. EnWiki established overwhelming consensus against it. The WMF is moving forwards with the project, planning to eventually deploy it here and everywhere else. We need more cross-wiki community collaboration to give the community more voice with the WMF. We need more cross-wiki communication, to establish multi-wiki consensus on shared interests. I saw Common's overwhelming rejection of Flow in the last RFC, and I decided to take a step towards establishing a stronger multi-wiki consensus on Flow.
    If you like Flow, I hope you will at least respect that I am acting in Good-Faith service of community consensus here (presuming that this proposal continues to get solid support). Alsee (talk) 19:19, 12 September 2017 (UTC)
    Your argument is more about your distrust and dislike of the WMF than about the uninstall of Flow. In fact, I fail to see any argument at all supporting your case in your very own argumentation: your not using Flow is one thing, uninstalling it from projects is quite another. I do not use the Upload Wizard, but you do not see me advocating its removal. Rama (talk) 19:44, 12 September 2017 (UTC)
    Yes, it is quite clear Alsee is not here to improve Commons, but just using this project as a playground for politics... Yann (talk) 20:39, 12 September 2017 (UTC)
    Rama, I gave two clear reasons for uninstall in my !vote. (1) There is no reason the wiki should be affected by development-bugs in an unused extension. If you are going to claim I made no argument at all supporting uninstall, then I'm not sure what productive discussion we can have. And (2) I think there needs to be a reality-check on the future of Flow. If Flow has a long term future, then we should embrace and improve Flow. If Flow is a dead-end, those limited resources may be better allocated elsewhere. Alsee (talk) 22:48, 12 September 2017 (UTC)
    (1) is not an argument for uninstalling Flow, just a statement that Flow is not widely used. "Flow has bugs that open security holes to the rest of the software", for instance, would be an argument for uninstalling (I insist that it is just an example, not an argument that anybody has actually raised). "Flow has bugs, I don't like it an neither do my pals" is an argument for you not using it, for which, well, congratulation (on the day you start contributing extensively to this wiki, I mean).
    (2) is not even remotely an argument for uninstalling Flow, it is a judgement of value. That "there needs to be a reality-check on the future" is a vague, unactionable opinion, and a very fine one, that I would support; but it does not entail that an immediate uninstall of Flow is in order. I would support reality-checking lots of things that I would also find unwise to disrupt. Rama (talk) 06:37, 13 September 2017 (UTC)
    Alsee, please stop saying that "The WMF has also decided to phase-out our wikitext editor". This is not true. We've talked before about this, and you know that this is not true. The Foundation's plan for the 2010 wikitext editor continues to be full, normal support for the foreseeable future. Please do not mislead fellow volunteers by saying otherwise to them.
    For the rest of you, I apologize for this confusion. I am the product manager for Structured Discussions (Flow) now, so the responsibility for this decision lies with me. I have decided not to de-install this software from this or any other wiki without a solid technical reason for doing so. Custom configurations for each wiki slightly slow down the sites for every reader and editor, and complicates Ops' work, which, unlike the assertions above, actually is a security risk.
    If anyone wants to object to the existence of this tool, as used by several communities, then I encourage them to engage in that discussion at the right time and place – which is in the annual plan, not the village pumps for individual wikis. I see the annual plan very much as our "contract with the communities" – we say we will do things, and our communities should expect that we keep to our commitments in that plan. You will find community-requested improvements to this software listed as a priority for this year under Program 5, Goal 3. The talk pages about the annual plan, widely advertised through banners during the process, were the correct places to suggest changes to the Foundation's planned work. Jdforrester (WMF) (talk) 18:13, 13 September 2017 (UTC)
    Jdforrester, you do not get to personally dictate to this community how we run our votes or discussions, and I doubt that anyone wants to be forced to check-in with you every time we have a meaningful vote or discussion. If you have suggestions or advice, that's super, but you are not the boss of me or any other unpaid volunteer contributor. If you want input in the "right" places, then please feel empowered to take our locally established community consensus and put it in those places yourself. Thanks -- (talk) 19:18, 13 September 2017 (UTC)
    Hi Jdforrester (WMF), it's a surprise to hear from you on this subject, given that you have been non responsive for six months[5] on whether you intend to be collaborative or combative regarding the consensus on the new wikitextmode-in-VE editor. For those unfamiliar, there was an overwhelming EnWiki consensus[6] objecting to performance and preview issues with the "NewWikitextEditor". (The last time I tried to use it, clicking preview took over 60 seconds to load, and the rendering was faulty.) As for the "confusion", the plan is for wikitextmode-in-VE to become the default wikitext editor, and for the current wikitext editor to move to opt-in for some unspecified period of time. The WMF's roadmap states: Finally with regards to core work, our intent right from the beginning of our work on the visual editor has been to operate as the core 'platform' for all kinds of editing in MediaWiki, and not just to be another single editor. Depending on how you count them, there are currently six pieces of editor software beyond the visual editor installed on most of our wikis, which gives us six different interfaces by which to confuse users, six different sets of bugs to track down, and six different places where features can interact in unexpected ways and which need to be tested. Our goal is to gradually reduce the number of pieces of software with equivalents based on the single platform.[7] Who wrote that? You did.[8] Maybe I am confused. I don't see how increasing the number of editors will "reduce the number of pieces of software with equivalents" unless you explicitly plan to remove the current wikitext editor. I think most people would consider it a "phase out" to temporarily move the current editor to opt-in, then remove it. Alsee (talk) 19:25, 13 September 2017 (UTC)
  • There are a couple of things I like about FLOW but they do not surpass the things I dislike. For example "history" does not work so I cannot see what has changed from when I last looked. Also I am very concerned with us going from two ways to edit Wikipedia to three ways to edit Wikipedia (VE and the old editor to VE, the old editor, and FLOW). Additionally I like new comments at the bottom rather than the top and I hate the fact that discussions jump around within a page (BTW I hate Facebook which also has many of these features). IMO FLOW is in a early stage of development. Doc James (talk · contribs · email) 21:18, 13 September 2017 (UTC)
    • With respect to new posts occuring at the top rather than the bottom, it is not that much of an issue with the current system. Not sure if I want "infinite scroll". Doc James (talk · contribs · email) 23:24, 13 September 2017 (UTC)
      Doc James, what is your view on removing Flow from communities that don't want it? I am rather concerned that the WMF appears to have reversed position on this. Alsee (talk) 03:44, 14 September 2017 (UTC)
      If as they say it makes the tech work easier and improves performance I am okay with seeing it stay installed. If the community has agreed something is not to be used than one would expect to see blocks handed out by the community for members who breach that agreement. It would be the use of the tool that the majority oppose that is the real issue rather than the existence of the tool. From what I understand some of the small wikis like FLOW and if consensus exists to use it there than okay. Doc James (talk · contribs · email) 14:20, 14 September 2017 (UTC)
      Doc James, I seriously question how having Commons configured the same as the Flagship-EnWiki and Meta could make tech work more difficult or diminish performance. It appears to be an implausible claim.
      On the other hand almost any programmer can confirm industry EN:Best_coding_practices#Deployment #1 Don't install something you're not going to use and #2 uninstall things you aren't using. Bugs are inevitable, especially when software is under active development. Keeping the EN:attack surface as small as possible is a basic security measure, and generic bugs can't affect a system if they aren't installed.
      Is more bad-blood between the WMF&community truly being outweighed here due to priority technical reasons? Or is this about digging in on an agenda to eventually convert Commons and other wikis to Flow? Alsee (talk) 10:22, 15 September 2017 (UTC)
      Hum, as a non tech person I do not know. I think we can all agree that our talk page systems could use improvement. VE was acceptable and in fact supported as it was and is only optional. Those of us who do not like it are not required to give up their prefered method of editing. This is the fundamental problem FLOW faces in that it has difficulty being introduced gradually.
      I am on the other hand happy to see software developed for projects other than EN WP. However I would still like to see significant efforts put into improving the current talk page system. Maybe we need a version of VE that works on talk pages? Regardless we need more community input / involvement in software development. We are NOT like facebook users (these being who FB sells to advertisers) and thus we cannot use software development techniques that FB uses for its users. Doc James (talk · contribs · email) 12:53, 15 September 2017 (UTC)

Regarding not being a tech person - there's an entire tech staff that can offer advice on the difficulty and impact of uninstalling Flow. As for improving talk pages, that would obviously be popular. But it's hard to get any progress on talk pages when that department seems to view talk pages as a competitor to Flow. I wholeheartedly agree on more community input on development - most importantly before coding starts. The cheapest and most pain-free time to identify and resolve issues is during the concept&planning stage. The NewEditor project was effectively built in secret. Once the prototype was complete is was too late. The WMF has been completely unwilling to discuss changing the design. For the last year I have been unable to get any meaningful response on how the WMF plans to deal with community concerns. I fear the NewEditor project may be driving towards a crisis. Could you inquire whether they plan to force it out as default, if the community considers it a downgrade? Alsee (talk) 05:09, 16 September 2017 (UTC)

That's a good point by Doc James: "VE was acceptable and in fact supported as it was and is only optional. Those of us who do not like it are not required to give up their prefered method of editing. This is the fundamental problem FLOW faces in that it has difficulty being introduced gradually." In German-language Wikipedia, the community decided in early 2016 to adopt VE as an option for not logged-in and new users. Per default, there are now two edit tabs in German-language WP: "Bearbeiten" (which is using VE) and "Quelltext bearbeiten" ("edit source", using the classic wikitext editor). Logged in users are still able to completely disable VE individually, if they wish to do so. Only through the optional nature and full mutual compatibility (you can always edit the same page in VE or wikitext and switch freely between these modes) VE finally was considered acceptable by the community, I think. As Flow, on the other hand, is not an optional mode for editing discussion pages but something radically different and incompatible with the existing "flow" of editing discussion pages, it's no wonder that the opposition is very strong. Gestumblindi (talk) 18:49, 17 September 2017 (UTC)

Define Wikimedia Commons as "wikitext primary"[edit]

This would prevent the WMF shoving the Visual Editor as default down our collective throats, per User:Alsee in this edit.   — Jeff G. ツ 03:08, 13 September 2017 (UTC)

  • Hey User:Jeff_G., I don't think that you need to worry about this. There are no plans to promote the use of the visual editor at Wikimedia Commons. For this wiki, the main focus for my colleagues at the Foundation and many volunteers is the Structured Data on Commons project. I don't think encouraging people to try to edit file pages with the visual editor is a good use of their time or our resources. Jdforrester (WMF) (talk) 18:54, 13 September 2017 (UTC)
Jdforrester (WMF), thank you for affirming that "There are no plans to promote the use of the visual editor at Wikimedia Commons". However could you please clarify? Does that mean there are no plans to promote VisualEditor's new mode[9] as a new default editor on commons? Or did you mean to say that you do intend to promote VisualEditor as the default editor on commons, but only the new mode of VisualEditor? Alsee (talk) 21:28, 13 September 2017 (UTC)
  • Symbol support vote.svg Support Regardless of Jdforrester's claim that "there are no plans to promote the use of the visual editor", just minutes earlier above they wrote "I have decided not to de-install this software from this or any other wiki without a solid technical reason for doing so", confirming that these decisions are whatever is in their head, rather than by a published plan or any consultation with the community. Establishing a clear consensus by the Commons community will make it a lot harder for Jdforrester to wake up one day and dictate to the Commons community what will happen to us next. -- (talk) 19:13, 13 September 2017 (UTC)
  • , Alsee's proposal is a nasty game, using Commons as a playground for politics, so James Forrester is right to dismiss it right out. I hope you see it clearly. Regards, Yann (talk) 19:21, 13 September 2017 (UTC)
If Alsee is playing games, ignore them, the vote itself is a valid community process regardless of who raised the proposal or their background.
It is Jdforrester's precise words and dictatorial tone that worries me, simply through the process of reading them carefully rather than what anyone else has written. -- (talk) 19:40, 13 September 2017 (UTC)
  • Symbol support vote.svg Support explicitly setting Commons as "wikitext primary". Also there a specific "global default setting" that gets applied to any wiki that has not specified preference. If communities representing a global majority of editors request wikitext primary then I Symbol support vote.svg Support setting the global default to wikitext primary. Any wiki that prefers VisualEditor primary may of course have VisualEditor primary. Alsee (talk) 19:31, 13 September 2017 (UTC)
  • Symbol support vote.svg Support It's good to know there are no plans to make it the default, but a consensus from the community here should cement that (which it sounds like the WMF has no problem with anyways), such that the default editor should not be changed without further (affirmative) community consensus. Carl Lindberg (talk) 20:34, 13 September 2017 (UTC)
  • In a few years we will get structured data anyways (YAY!), and all this will be moot anyways; why swett over this non-issue. --Jonatan Svensson Glad (talk) 20:48, 13 September 2017 (UTC)
  • No, we wont. (Yay!, I guess.) “We” might broke Commons, either technically or sociologically (or, most likely, both), while trying to implement it, tho — and, for that, unyay! (I really hope to be completely wrong about this, but the bad omen tells are all there.) -- Tuválkin 22:00, 13 September 2017 (UTC)
  • Symbol support vote.svg Support: Hell, yes. -- Tuválkin 22:00, 13 September 2017 (UTC)
  • Symbol abstain vote.svg Abstain because there are no plans. Too soon to vote, even though I'd like to. 2001:2003:54FA:2751:0:0:0:1 07:19, 14 September 2017 (UTC)
  • Symbol support vote.svg Support Preventative measure to reduce the probability of this abomination being forced down our throats. Train2104 (talk) 16:19, 17 September 2017 (UTC)
  • Symbol oppose vote.svg Oppose I do not see a need for this proposal, as I do not expect Jdforrester (or anybody else) "to wake up one day and dictate to the Commons community what will happen to us next" or "shove" anything "down our collective throats". I do not share User:Alsee experience with WMF. I also do not agree with the description of work of Jdforrester (WMF) and other WMF staff. In my experience they always seek community feedback on proposals, see for example phabricator:T175601 or work of Structured data team. The above discussion paints them in rather bad light, which I do not think is warranted. If there is a discussion in the future on a specific proposal related to Visual Editor I would vote to always preserve wikitext option, as I try to avoid Visual Editor; however, I would not want to prohibit anybody from using it either. I can not support the proposal in the form it was proposed. --Jarekt (talk) 15:47, 19 September 2017 (UTC)
  • Pictogram voting comment.svg Comment Media files are the primary focus for Commons and whatever markup used around those files are secondary. This proposal is unclear as to what is defined when saying "wikitext primary". Does that mean the editing interface? The way the content is stored in a database? The way it is presented?Ckoerner (talk) 17:15, 19 September 2017 (UTC)
    @Ckoerner: I meant edited and stored. Presentation has always been HTML at its core (with optional js and css addons), and I expect that to continue.   — Jeff G. ツ 03:43, 20 September 2017 (UTC)
  • Symbol oppose vote.svg Oppose I don't see the need, nor do I want to stiffle future innovation from WMF if we limit ourselfs. --Jonatan Svensson Glad (talk) 04:47, 20 September 2017 (UTC)