Commons:Village pump/Proposals/Archive/2017/06

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

Symbols-Logo contest: draft proposal

I want to propose for a rapid grant for a Wikimedia Commons Symbols contest. Read the draft proposal below. I kindly ask you for:

  • Discussion whether the symbol contest should be a logo-contest for Wikimedia Commons’ symbols? So that the winner symbol will be used to mark symbols at Wikimedia Commons and also at the Category:Symbols category page and subcategory pages.
  • If you oppose the logo-contest, what other symbol specific content should the winner symbol be used for? What should the symbols specific focus be and how could the symbol be used?
  • Discussion whether the symbol contest should be announced at the Category:Symbols category page aand subcategory pages?
  • Jury participation and organizational help

Draft Proposal:

What content will the contest focus on, and why is it important to your community?

Current situation regarding access to symbols/icons:

  • There is no central repository that allows free access to symbols/icons.
  • There is a high demand for icons.

https://www.quora.com/What-is-the-best-place-online-to-sell-icons “Iconfinder.com has 1.3 million unique monthly visitors. [...] I do know that GraphicRiver boasts several millions. [...] iStockPhoto and Shutterstock have been around for at least 2 decades so they have tens-of-millions of monthly users, if not more.”

  • The demand for icons is met by icon online market places that resell icons with high commission rates (30-70%)
  • Wikimedia Commons has already a lot of icons and contributing designers (over 1 000 registered vector graphics editors).
  • The number of icons on Wikimedia Commons is insuffiecient though. The number of icons is also small compared to icon online market places.
  • Wikimedia Commons already has Category:Symbols.
  • Category:Symbols could be better presented to attract more designers of vector graphics.

The contest will therefore focus on symbols/icons. The symbols/icons-contest is important to the Wikimedia Commons community as it will:

  • increase the number of symbols/icons
  • attract already active designers of vector graphics to contribute
  • attract designers who have not yet contributed to Category:Symbols
  • increase the identification with Category:Symbols

How will you let people know about the contest?

The contest will be announced at the Wikimedia Commons Village Pump, at the Wikimedia Forum, via Wikimedia-I mailing list, on the Category:Symbols category site and subcategory sites.

How will you judge the contest and award prizes?

An international Jury will choose the winners. Rules:

  • Be self created: All entries must be original symbols uploaded by their authors. Symbols uploaded by anyone else than author (even with permission) are not accepted.
  • Be self uploaded during the contest period (1st December 2016 - 28th February 2017): You are also welcome to submit symbols you may have taken in the past. What matters is that the symbols must be uploaded during the contest period.
  • Be under a free license;
  • Contain a logo for Wikimedia Commons symbols.
  • Have the format .svg
  • A participant should have an activated e-mail address via Preferences of his/her account.

For photo contests, what is the strategy to get images used on projects?

The symbol contest is a logo-contest for Wikimedia Commons’ symbols? So that the winner symbol will be used to mark symbols at Wikimedia Commons and also at the Category:Symbols category page and subcategory pages.

Is there anything else you want to tell us about this project?

  1. Prize: 300 $ and the logo being used for Wikimedia Commons symbols
  2. Prize: 150 $
  3. Prize: 75 $
— Preceding unsigned comment was added by 62.47.243.233 (talk) 15:01, 16 September 2016 (UTC)

Edited by GabrielVogel — Preceding unsigned comment added by GabrielVogel (talk • contribs) 15:04, 16 September 2016 (UTC)

This section was archived on a request by: Rudolph Buch (talk) 10:44, 6 June 2017 (UTC)

Allow all users to use Upload Wizard's flickr option

Upload Wizard screen with flickr option

I was recently coaching someone on how to use Upload Wizard's flickr option to speed up his work with uploading flickr images, when we realized that he does not work with the same Upload Wizard I use. Apparently only only administrators and image-reviewers can use Upload Wizard to upload flickr images and the rest of the people has to be using other tools, like Flickr2Commons, Flinfo, F2ComButton to accomplish the same task. The reason would be :

  1. Fairness I see no reason to let all users to use one tool and only some users to use a different tool with the same capabilities.
  2. Avoid confusion and waist of time of figuring out who can use what tool. That way we can simplify or expand the documentation of the tool.
  3. We put a lot of thought into proper handling of many tricky cases related to flickr uploads. Most files should go through the "official" pipeline, which should be most up to date. If we allow everyone to use Upload Wizard than I assume demand for other tools will diminish.

--Jarekt (talk) 04:14, 10 June 2017 (UTC)

LX, My previous proposal (about which I already forgot about) was proposed 3 years ago. A lot can change in 3 years. As for phab:T90004 issues, I see
Also if people are not using Upload Wizard, then they are using Flickr2Commons and other tools. Are above issues handled better in those tools? --Jarekt (talk) 14:20, 10 June 2017 (UTC)
Jarekt, the Flickr checking is currently done on the client side, which is not robust at all, because it allows meddling from userscripts and other code that may be in a user's browser. I proposed doing the checks on the server side to increase the likelihood of preventing bad uploads. And while other tools are less robust in this sense, as the primary entry to our upload pipeline, I think UploadWizard needs to be better. If Commons decides that yet more complications to the review pipeline are desirable, then I suppose it is time for a change! --MarkTraceur (talk) 14:45, 10 June 2017 (UTC)
MarkTraceur, So it sounds like a bit like "a chicken and egg problem". phabricator:T100062 is low priority if the only users allowed to use the tool are admins and image-reviewers and at the same time it is blocking enabling it for all users. To me Upload Wizard still seems safer than other tools we are currently forcing regular users to use. --Jarekt (talk) 15:06, 10 June 2017 (UTC)
We can use the flickr reviewer bot until the issue is fixed. I proposed this a while ago (on phab or irc). --Steinsplitter (talk) 15:09, 10 June 2017 (UTC)
I think that is a good solution. --Jarekt (talk) 02:23, 11 June 2017 (UTC)
@Jarekt: What is meant by the review system being client side is that {{FlickrVerifiedByUploadWizard}} is still a trusted tag, and anyone with enough technical knowledge can fake that tag with UW (and one can imagine that the knowledge can spread via black market). --Zhuyifei1999 (talk) 16:24, 10 June 2017 (UTC)
  •  Comment Getting on my soapbox for a moment here. I'm very wary of anything that's going to increase the number of flickr transfers by inexperienced users: flickrwashing issues aside, there is the less-noticed problem of identifying information. All Commons files should have three kinds of identifying information: a descriptive filename to make the contents of the image obvious, a clear and encyclopediac description of the file in the wikitext, and properly considered specific categories. Most flickr files have neither a Commons-style descriptive filename nor an encyclopediac description of the file, and flickr uses non-hierarchical tags rather than hierarchical categories. I have had several tense discussions with very experienced and trusted users (who are overall excellent contributors) because I felt their flickr transfers consistently failed to properly include one or more kinds of this crucial information; less-experienced users are less likely to understand the importance of good filenames and categories.
The existing non-admin tools (including Flickr2Commons, which I use even as an admin) also do not enforce any of these descriptive properties; however, they tend to lend themselves more towards experienced users. Any change to flickr transfers (including this proposal, which I think overall could be very helpful) really needs to guide users towards adding proper information. That should probably include steering them away from problematic information (users should have to input file names rather than using the flickr defaults), maybe some basic filters (minimum filename length, minimum description length, minimum number of categories) and a clear message of why the identifying information is required. Pi.1415926535 (talk) 18:35, 10 June 2017 (UTC)
Pi.1415926535 I share your concerns but we have the same issue with regular uploads, but nobody is proposing prohibiting new users from using it. A lot of problems with bad edits can be solved by allowing only experts to edit but that is not how wiki works. If we worry about bad categorization lets propose to delete unused and uncategorised files uploaded that way, or maybe it is better to have them than than not to have them. --Jarekt (talk) 18:50, 10 June 2017 (UTC)
  •  Support except for non-autoconfirmed accounts. --Yann (talk) 09:54, 17 June 2017 (UTC)
  •  Support with Yann's caveat. If it's a problem (like mobile uploads were), then we can turn it off--no reason to keep a useful feature from a great number of constructive editors without even seeing what happens in the wild. —Justin (koavf)❤T☮C☺M☯ 05:01, 21 June 2017 (UTC)
  •  Support for autoconfirmed users. Regarding Pi.1415926535's objections above, UploadWizard does require a description (and even enforces a minimum description size), and if you don't provide a category, it gives you a warning. Obviously there is never going to be an upload tool that can force the user to write an encyclopedic description and "properly considered specific categories". The idea that we should only allow users to import from Flickr through tools that are hard to use seems counter-productive. If this leads to a flood of Flickr-washing, of course we should turn it off, but let's give it a shot and see what happens. Kaldari (talk) 02:21, 23 June 2017 (UTC)

Restrict Video Uploading

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)

  •  Support--Steinsplitter (talk) 15:31, 14 June 2017 (UTC)
  •  Support --Alaa :)..! 16:57, 14 June 2017 (UTC)
  •  Support, unfortunately. Storkk (talk) 17:00, 14 June 2017 (UTC)
  •  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. --Fæ (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. --Fæ (talk) 11:39, 15 June 2017 (UTC)

Filter

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

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

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)

@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 upload.wikimedia.org 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

SELECT 
  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
250
500
750
1,000
1,250
1,500
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
Sept. 18–24
Sept. 25–Oct 1
  •   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

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

/* Video Uploads by non-autoconfirmed accounts - 30 min */
SELECT Media,
  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 %"
FROM (
  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*/)
UNION ALL
  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
GROUP BY 1
ORDER BY 9 ASC;
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)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2017/06&oldid=262185296"