This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I'm too tired of Colin still not having gotten over his GFDL proposal being rejected and bashing my proposals as a result to argue this any further. The only sensible point from it was that this proposal should be simplified. While I agree it's too complicated and therefore withdraw this proposal, it can't be simplified without it either no longer achieving its goal of searchable warnings or severely curbing talk page freedom. So we'll have to stick with the status quo. - Alexis Jazzping plz15:10, 2 July 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Warnings on user talk pages are useful to detect trends in problematic behavior. Some users make a habit of erasing such warnings after they have read them. Some of those are experienced, but the same practice is exercised by serial copyviolators to cover their tracks. When directed at experienced users, {{Dont remove warnings}} has been controversial. Regardless, those warnings provide a helpful overview of a user's history.
So I propose:
All warnings and notifications:
May be erased if they originate from a confirmed sockpuppet.
May be erased if they are obviously bogus.
May be erased with permission from an administrator. (note: an admin theoretically could give you permanent permission to remove any and all warnings, if they fully trust you)
May be erased if they are more than 18 months old.
Erasing deletion notifications, copyvio and similar warnings about files:
May be erased if the file(s) in question are kept.
May be erased if the deletion rationale is not policy related. (for example: corrupted upload, a subject requests courtesy deletion or a file that was superseded)
May be erased if you were not the original uploader of the disputed work. (generally happens when you overwrite a file, create a crop or derivative work of an existing image)
May be erased if they are duplicates of another notice. (for example: when a speedy deletion is converted to a DR, keep one notice)
Warnings about behavior and notifications about noticeboard discussions:
May be erased if they don't refer to any specific action or discussion and you haven't done what the warning accuses you of in the past 24 hours.
May be erased if you aren't accused of any policy violation.
All other warnings and notifications can be:
Archived to a subpage, either automatically or by hand. This may be done directly after the message has been read.
Collecting all your warnings separately on a single subpage so they don't "clutter" your regular archives is allowed.
Collapsed, if you just want them out of sight. They may be grouped together so only one collapse bar is needed.
Compacted, as long as the information within is preserved.
Left on the talk page until the page becomes too large to edit. (that'll take a while..)
Any combination of the above.
Hopefully this can strike a balance between user talk page freedom and the ability of the community to keep track of problematic use.
Oppose I support the direction of this proposal, but not its destination. I can see a requirement for an admin (or even a licence reviewer) to somehow store their warnings somewhere, but a regular user should be absolutely free to wipe their talk page every 5 minutes. History of the page is already a log, there is no reason to make a contributor of media to become a master archivist. Of course, I do understand, that this proposal technically states what a user may do, rather than stating what they may not do. So I could be brought on board to support this if we create a warning along the lines of "Immediately stop warning people, who are doing things that are explicitely allowed! (Yes, you may remove this warning)". But I must be honest, I would support that just to make a point and would not use such a template myself in most cases. ℺ Gone Postal (〠✉ • ✍⏿) 06:01, 1 July 2019 (UTC)
strong oppose Some serious instruction creep here and doesn't reflect community consensus, but rather the creation of completely new complex rules. Remember people do not read the manual and we should only vote if you think you have reached a consensus, rather than on some out-of-the-blue 20-point set of regulations. It is interesting that en:Wikipedia:Talk page guidelines#User talk pages is shorter than Commons:Talk page guidelines#User talk pages. The relevant wiki text is at Personal talk page cleanup which is a summary of en:Wikipedia:User pages#Removal of comments, notices, and warnings. I see no reason why we should take a different attitude than on Wikipedia, which is to regard a deletion as simply an acknowledgement the content has been read. This is in keeping with COM:MELLOW. We should adopt the Wikipedia wording, though I would argue that "Declined unblock requests regarding a currently active block" is the only situation where users should be disallowed from removing user talk page content. -- Colin (talk) 12:19, 2 July 2019 (UTC)
"we should only vote if you think you have reached a consensus"
No, you should vote if you have an opinion about what has been proposed. Which you did and have, so thanks for that. - Alexis Jazzping plz12:51, 2 July 2019 (UTC)
m:Polls are evil. This is long established and accepted. But frequently forgotten on Commons, with the negative results we so often see. If you had begun with "I think it would help to clarify in our guidelines when and whether talk page messages, such as warnings, can or should be deleted or archived." And if you had done your research and found that Wikipedia already covers this, and that our user talk pages and their user talk pages are for the same purpose, then you'd perhaps come to the same conclusion I have. Instead you make a ridiculous proposal with 16 separate points, any or all of which may be contentious. This should be snowball closed and stop wasting people's time with ill thought out proposals. -- Colin (talk) 13:58, 2 July 2019 (UTC)
Archiving warnings discussion
It would actually be better if ArchiverBot would automatically archive every discussion older than 365 (three-hundred-and-sixty-five) days of all user talk pages (including IP talk pages), a talk page is both "a personal space" and "a community space" so both purposes often conflict, having many warnings on your talk page might discourage you if you're a new and/or inexperienced user but if you blank them then while it might make perusing "your own" (owned by the WMF) talk page less stressful for you, it might not give the complete information to others.
Personally I would rather have ArchiverBot enabled by default and that users may turn it off or make it faster if they so wish. Though ifㄊ a patroller sees dozens of warnings they might be more inclined to report a user to the sysops then try to engage with them and explain how they should improve (and yes, some users are so daft that they don't read the automated templates but do listen to more personalised conversation which isn't exclusively made up of warning templates by "the regulars"). There should be a balance between trying to suppress our own negative biases and perceptions for when we see warnings and dealing with actual problematic users who clearly cannot understand that Wikimedia Commons can't accept fair use images, but finding this balance will be hard. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:49, 29 June 2019 (UTC)
@Donald Trung: Enabling archiving by default.. I wouldn't be against that. Setting up archiving isn't exactly trivial. It's not like it's a setting in your preferences, new users rarely have archiving set up. But that wouldn't replace this proposal, though it would reduce the need for new users to erase anything from their talk page. - Alexis Jazzping plz16:50, 29 June 2019 (UTC)
Do not continue telling people to stop removing warnings from their talk page!
DO NOT MESS WITH ME.
I AM WATCHING YOU!
Immediately stop warning people, who are doing things that are explicitly allowed! (Yes, you may remove this warning).
Ironically, the person receiving this "warning" would either have to stand by their position that warnings shouldn't be removed or be a hypocrite and remove it. This is exactly why I support sub-page archiving, you don't remove the warnings, you just move them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:35, 2 July 2019 (UTC)
Ahahaha. I love it. Thank you. But I still think that most of the warner brothers would not understand the irony and simply get agressive. Personally I think that archiving is silly on a platform with page history. ℺ Gone Postal (〠✉ • ✍⏿) 10:41, 2 July 2019 (UTC)
@Gone Postal: the page history can't be searched. If a user gets 10 copyvio/DR notices and constantly wipes their user page (and this really happens), I have to look at 10 old page revisions to get a complete picture of the user's history. - Alexis Jazzping plz11:50, 2 July 2019 (UTC)
A fair objection, however, it does not make sense to harrass people and insist that they jump through hoops to recreate a feature that could be present in the software itself. I honestly do not understand what "moving" content even means on a wiki, the content is now in two places: in the history of the original page and in the history of a newly created archive. Is it a move or is it a copy? Why should we force people to copy it only once? Wouldn't it make it easier to find these warnings if we get users to also copy them a few more times? Maybe we can start a new MediaWiki project just to store warnings that people have ever received... And please note, I myself am perfectly happy to keep all the warnings on my talk page, I find them useful, so it is not about the licence to hide information. ℺ Gone Postal (〠✉ • ✍⏿) 12:40, 2 July 2019 (UTC)
We had a related discussion about warning templates back in November, but it doesn't look like it was every formally closed and enacted by an uninvolved contributor. GMGtalk12:17, 2 July 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I am not re-opening this proposal, I just want to note that I actually agree with some of it and disagree with some of it and can understand the instruction creep. As for how this should have been handled I think that an earlier discussion in the regular village pump would have allowed more community input because then more suggestions could have been made and users could have stated which points they disagreed with the most or what should be adapted. If talk pages were perfect then the Wikimedia Foundation (WMF) wouldn't constantly attempt to shove Flow down our throats. Improvements are there to be made and I think that Alexis Jazz did a great job in finding a middle ground between preserving user freedom and making it easier to keep track of user warnings.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Override the title or username blacklist (tboverride)
I know several trusted technical users who regularly make edit requests. They should be able to edit the protected templates themselves, and maybe help with fulfilling edit requests made by their fellow users.
Support great idea, much better than always to molest admins - they have more essential duties than these copy work! -- sarang♥사랑03:44, 12 June 2019 (UTC)
Rudimentary counting of Special:ProtectedPages shows that there are 3,499 fully protected pages in the template namespace. That includes all pages including translations, documentations, etc. that happen to also be fully protected. Some of these would probably need to remain fully protected for one reason or another, being tied to the main page being one of the reasons that pops into my mind, but the vast majority could probably be downgraded to a "template editor" protection level. --Majora (talk) 03:15, 13 June 2019 (UTC)
If there is no exclusions, then they all should be changed. They can be changed back if needed. 1989 (talk) 19:19, 7 July 2019 (UTC)
@1989 and 4nn1l2: Anything used in system messages (ie, the mediawiki space) should not be downgraded in my opinion. System messages are especially sensitive as they are shown not only to editors but to readers as well. As I said previously, anything linked to the main page should also be excluded. Beyond that, downgrading them to "template editor" protection seems prudent. --Majora (talk) 20:11, 7 July 2019 (UTC)
Just as an example, {{@}} is used on MediaWiki:Blockedtext and should not be downgraded. As the mediawiki space is inherently locked to administrators allowing templates that are used in that space to be edited by anyone other than administrators kinda defeats that. --Majora (talk) 20:22, 7 July 2019 (UTC)
I am missing any progress for establishing such a user group - there are just discussions about the icon. I would like to get these few more rights soon! -- sarang♥사랑05:41, 8 July 2019 (UTC)
# Option 1 is easier to read and more accurate in its intention, though the brackets could use a rework to look like the ones in Option 2. I note, however, that the Chinese Wikipedia ended up adopting instead. –LaundryPizza03 (dc̄) 12:01, 13 June 2019 (UTC)
This alternate for option 1 also matches other padlocks featuring characters: ({{). Compare used on enwiki. A variant with bigger symbol was aesthetically unappealing. –LaundryPizza03 (dc̄) 21:49, 13 June 2019 (UTC)
@1989: At that request, I have decided to restore the version with the bigger symbol. Clarity is much more important than aesthetics. –LaundryPizza03 (dc̄) 19:28, 7 July 2019 (UTC)
Option 2 - the brackets are better to distinguish, at option 1 they are too difficult to identify as brackets --sarang♥사랑03:44, 12 June 2019 (UTC)
@Sarang: actually, that's not universally true. At icon size, is more clear than . Option 2 couldn't be used anywhere at icon size. - Alexis Jazzping plz11:30, 12 June 2019 (UTC)
The different protection messages shows it larger; there are at least 3 larger displays. Because always the same icon should flag the same case, I am thinking about creating an icon which combines both advantages. --sarang♥사랑07:24, 13 June 2019 (UTC) - - - It looks like that: - the rough drawn large curlies are better visible?
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 15:33, 9 July 2019 (UTC)
New speedy deletion criterion G11: Blatant text copyright violations
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I think there should be an additional speedy deletion criterion for blatant textual copyright violations, separate from those regarding file copyrights. I first raised this proposal at Commons talk:Criteria for speedy deletion, but after 29 days it has gotten relatively little attention. As such, I am seeking broader consensus. The collapsible below contains a copy of the original discussion. If passed, it would be designated G11. –LaundryPizza03 (dc̄) 09:06, 13 June 2019 (UTC)
Proposal: Blatant copyright violations outside of filespace
I think there should be a speedy deletion criterion for blatant copyright violations outside of filespace (i.e. text copyvios), for although they do not happen often, they can be just as serious as file copyvios, and deletion is likely to be uncontroversial in such cases.
Perhaps clarify that speedy deletion criterion F1 (for copyright violations in filespace) should be used only for "unambiguous" cases, i.e. where a file is an obvious copyright violation. –LaundryPizza03 (dc̄) 02:43, 15 May 2019 (UTC)
Indeed it would be more sensible to separate text copyvio (say, G11) from more ubiquitous F1–F6 (file copyvio). Imagine: someone uploaded a new free file, but stuffed {{Information}} with copy-and-paste from a copyrighted document. Then the copyrighted stuff on the namespace-6 page can be blanked and revision deleted under G11, but the file may remain intact. Incnis Mrsi (talk) 04:24, 15 May 2019 (UTC)
Comment What about text copyright violations included in filepage descriptions, usually as descriptions, esp. when the file itself has no copyright issues? -- Tuválkin✉✇02:10, 15 June 2019 (UTC)
Not a reason to speedy delete the file -- just edit away any problem text. I think that was the reason this proposal is explicitly outside of filespace; there would be a different way to fix those issues which does not involve deletion. Carl Lindberg (talk) 04:13, 15 June 2019 (UTC)
Maybe we should add a note or something (in the template?) that when G11 is used on a file page, the file shouldn't be deleted. - Alexis Jazzping plz16:28, 16 June 2019 (UTC)
While I support the intent of the proposal, I think that it is an error. Let us examine a possibility, somebody uploads a video under CC-BY-SA 4.0 licence, then another individual transcribes a portion of an audio and posts it in the information box. That is a blatant copyright violation (text on Commons is CC-BY-SA 3.0 and GFDL, you cannot take CC-BY-SA 4.0 and make a derivative under either of those two). The fact that this is a copyright violation cannot be questioned if the transcription is long enough. However, I would like a community decision on whether to remove it completely or keep parts that can be considered De Minimis or Fair Use (I am actually unsure if Fair Use is allowed in the description of the file on Commons). As such I Oppose it as a speedy deletion criteria. ℺ Gone Postal (〠✉ • ✍⏿) 10:51, 18 June 2019 (UTC)
Actually I thought about it, and since the text is required to be released as both CC-BY-SA 3.0 and GFDL (not either of these two), then even if we have a video under just one of them, a transcription of a large portion of it would bea blatant copyright violation. I do think that if some admin will begin speedy wiping such things, it would create significantly more harm than to let a normal discussion process run its course. So it should be a deletion, and not a speedy deletion criteria. ℺ Gone Postal (〠✉ • ✍⏿) 09:35, 19 June 2019 (UTC)
I don't think this deletion reason would apply to filespace, per the proposal language. Any textual copyright problems on file pages should be dealt with differently, agreed. I would not support this tag being used in the File: namespace; that should be made clear (as Alexis Jazz mentioned above). Carl Lindberg (talk) 16:40, 21 June 2019 (UTC)
I am sorry, I think that you have misunderstood either what Alexis Jazz has said or what was said by me. Alexis Jazz has pointed out that the file itself should not be speedy deleted simply because there is a copyvio on a file description page. My point was that the file description page itself should not be speedy wiped by admin either, rather a discussion should take place to figure out how best to make the description page copyright compliant. ℺ Gone Postal (〠✉ • ✍⏿) 18:14, 25 June 2019 (UTC)
As long as the text is in history, that should be fine. Unless they delete the revisions, I guess. I thought this proposal was for items not in File: space (i.e. this cannot be used on portions of a file description either). Regular editing should be able to deal with those. This is for where the entire entry needs to be deleted. (BTW, for your example, putting in CC-BY-4.0 text would not be a copyright violation. It's not being mixed with anything, and has a free license. You may argue that it is a technical terms of use violation, but that does not affect licensing, and I would argue it would fall under the "project edition or feature" exemption anyways, as that particular file requires a different license.) Carl Lindberg (talk) 17:51, 29 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 15:34, 9 July 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Oddly, the widely accepted "previously published" rule doesn't seem to be codified in policy anywhere.
If you are a copyright holder and would like to confirm permission, please use the email template to do so.
with
If you want to upload any content that was previously published, for example, because you shared your photos on Facebook or licensed your photo to a newspaper or website, you need to add a free license to the source (instructions for some popular sites), link to the social media account in question from your user page at Commons and link back to your Commons user page from that page/account or contact OTRS using either an email template or the release generator. OTRS can also be used to confirm permission if your content was uploaded by others or if your authorship was called into question.
Comment - That seems extremely complicated (both to implement and to verify). Has anyone actually done all of that before? Emailing OTRS seems much simpler. Kaldari (talk) 19:38, 11 July 2019 (UTC)
Oppose There is nothing odd about the non-inclusion. COM:L is meant to "giv[e] non-lawyers an overview of complicated copyright laws through an example-based tutorial." It is not the proper venue for elaborate detail of tending to our evidentiary requirements, let alone for the specific scenario of previous publication. Эlcobbolatalk20:00, 11 July 2019 (UTC)
Oppose – Don't make it complicated. The lengthy instructions proposed won't help, rather it will confuse most. The way it is written currently gets the basic point across. Senator202903:02, 12 July 2019 (UTC)
@Kaldari: mailing OTRS is part of the text. The first suggestion is adding a free license to the source (where possible), which the OTRS page also suggests. Linking and linking back could be done in a couple of minutes, this is now also a valid method of verifying usernames. Contacting and satisfying OTRS may take days. In more complex cases the linking may not be enough but it would be sufficient, for example, for someone who previously shared their travel photos on Facebook or their blog and now wants to share them with us. - Alexis Jazzping plz20:27, 11 July 2019 (UTC)
@Elcobbola: It is common practice. It should be included on some policy page. It is found on OTRS, but that's not policy. COM:L already has the notice about confirming licenses with OTRS. After some digging, I found a technically more suitable place: Commons:Project scope#Evidence. I didn't expect to find it there. The entire section Commons:Project scope#Must be freely licensed or public domain doesn't belong on COM:SCOPE. It duplicates part of COM:L (which IMHO should be removed or heavily compacted) and uses inclusion for Commons:Project scope/Evidence and Commons:Project scope/Precautionary principle, which would also be a better fit for COM:L. SCOPE should just define the scope. (file formats, what is educational/in scope) Perhaps a new policy page for permissions and non-copyright restrictions would be an option? It's another policy page, but COM:SCOPE would get a bit shorter. COM:L would also get shorter as the trademark section could be moved to the new page, so COM:L could focus purely on licensing and copyright. - Alexis Jazzping plz20:27, 11 July 2019 (UTC)
Why so complicated man... Textual instruction is hard to understand and reproduce. The easiest way to express one's wishes to release the files would only need two placards, a camera and ten minutes.
One placard shows a big-ass username. Another placard could be prepared by us in PDF and downloaded and printed by the user. It lists the logos and names of four licences: CC-BY-4.0, CC-BY-SA-4.0, CC0, PD-self. (Or use an ipad.)
The person would record a video and say the following: I am XYZ. (Holding username placard) This is my wikipedia account. I (or my authorised representative) will upload my works (or in the case of heirs, my dad/mom/whoever's works) to Wikimedia Commons with this account... (Holding licence placard) under free licences such as these four. I understand the implications of these uploads and I give my authorisation.
Upload the video to Youtube (or here) and link it on the user page. Impeccable evidence of authorisation can be given in ten minutes. This is probably the easiest way even for the braindead. Opening a youtube account and uploading a video should be easier than trying to upload stuff on Commons. And we can do step-by-step demo videos to show them: 1. register a wikipedia account 2. record the video 3. upload it and link it on user page.--Roy17 (talk) 21:03, 11 July 2019 (UTC)
@Roy17: if the Commons app supports video (I'm not sure.. not tried it), that would be simple. I have thought about what you're saying. Personally I'd support it, but I think many people would oppose it, believing it to be too complicated. It also doesn't prove the person in question owns some social media account or website where something was previously published. It would mostly be useful for celebrities who want to upload selfies. - Alexis Jazzping plz21:27, 11 July 2019 (UTC)
No it doesnt matter. The copyright holder, be it a photographer or an artist, can relicense his/her own stuff anytime. Copyright is enforced here to prevent random people uploading stuff they find on Internet. When a person identifies him/herself and declares his/her intention to share in a video, there's no point deleting.--Roy17 (talk) 22:24, 11 July 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Some Commons users do a lot of maintenance and other work here, but they may not be interested in becoming an administrator or not deemed suitable by the community.
When it comes to administrators, there are two reasons we can't promote everyone to be an administrator: the community doesn't trust everyone with the mop and for the WMF administrators (to be precise: anyone who can view deleted content) are a legal liability. Being an administrator on a Wikimedia project also carries some legal risk for the administrators themselves because of that.
A general maintainer wouldn't quite be an administrator, but would be given access to various tools. They need to be users who can be trusted not to abuse their tools (similar to, for example, rollbackers), but don't need overly extensive copyright knowledge (like a license reviewer) and the community doesn't need to trust them with sanctioning other users. General maintainer can be a step towards adminship, but doesn't have to be. You also won't have to be a GM to apply for adminship.
A general maintainer could:
Move files
Delete their own files and revisions (very handy for mass-uploaders who spot a bad file after uploading and map makers who need to delete inaccurate old revisions of maps)
Speedy delete abusive uploads (these deletions would always be accompanied by a report on COM:ANB)
Hide abusive page revisions (vandalism)
Handle G7 requests that fully meet the G7 criteria. (original author or uploader requests deletion of recently created (<7 days) unused content)
Not be affected by rate limits for edits, moves, uploads, rollbacks, purges and thumbnail rendering (depending on developer preferences, they may get noratelimit instead, but deletions will be limited to 10 per minute)
Not create redirects from source pages when moving pages (suppressredirect)
Requests to become a general maintainer should be made at Commons:Requests for rights and granting this right to candidates is at the discretion of admins. Obviously, only properly experienced users should be made general maintainers.
To prevent an endless accumulation of GM accounts as people often naturally move on as years pass by, to retain GM status the user should make at least 1 edit per year.
Community approved general maintainer
If a general maintainer also wants to engage in dealing with DRs (including close-deleting them), copyvios, etc (which technically they can), they need a community mandate very much like an RFA. For the community, the bar to support such a request will be lower than the bar to support adminship. One does not have to already be a GM in order to apply for community approved general maintainer.
A general maintainer with community approval could, in addition to everything a GM is capable of:
Delete more than 10 files per minute
Deal with DRs and copyvios
Edit pages protected as "Allow only administrators" (editprotected) and fulfill edit requests
Change protection levels and edit cascade-protected pages (protect)
Both the GM and the community approved GM can be voted on. They don't exclude or require each other. - Alexis Jazzping plz18:31, 11 June 2019 (UTC)
Create user group 'general maintainer': votes
General maintainers, this right can be requested at Commons:Requests for rights and granting this right to candidates is at the discretion of admins.
Oppose Nonsense proposal. If an editor wants to "Delete their own files and revisions," "Speedy delete abusive uploads," "Hide abusive page revisions," etc. they are, by default, "interested in becoming an administrator" (no admin is forced to block, do license reviews, etc.) and if they are "not deemed suitable by the community" to be a "full" admin, they are not trusted enough for this thinly veiled "admin lite." COM:RFA is that way. Эlcobbolatalk19:14, 11 June 2019 (UTC)
Oppose Primarily for the inclusion of revision deletion abilities. Revision deletion should remain in the hands of individuals who have gone through RfA. It is a powerful tool in a movement that should be as open as possible and shouldn't be taken lightly. Also there is nothing in the current system that allows for the selective deletion of "own" files. What if the file was overwritten with a new one? Could you only delete your version or all versions? The delete system also doesn't care what tag is on it. Limiting it to G7 would be pointless from a technical standpoint. If such technical limitations can be surmounted and iff the revision deletion abilities are stricken from this proposal I would be more apt to be neutral on the whole thing. --Majora (talk) 18:18, 15 June 2019 (UTC)
Oppose Unnecessarily complicated, and it appears that from a technical standpoint there is no limit to what they can delete other than a rate limit of 10 per minute. I cannot imagine any candidate I would support to have the delete button but not to be a normal admin. -- King of♥♦♣ ♠ 03:18, 27 June 2019 (UTC)
Create user group 'CA general maintainer': votes
Community approved general maintainers, they are promoted after a successful RfA-like vote.
Oppose Nonsense proposal. If an editor wants to "Delete their own files and revisions," "Speedy delete abusive uploads," "Hide abusive page revisions," etc. they are, by default, "interested in becoming an administrator" (no admin is forced to block, do license reviews, etc.) and if they are "not deemed suitable by the community" to be a "full" admin, they are not trusted enough for this thinly veiled "admin lite." COM:RFA is that way. Эlcobbolatalk19:14, 11 June 2019 (UTC)
Neutral Honestly I don't see how "admin lite" would help otherwise qualified people who are controversial pass this although I could see it helping increase the show of support of candidates that people feel uneasy about giving the ability to block but feel fine about giving them other admin-like abilities. I also don't see current admins supporting this proposal if above votes are any indication. And I'd vote for Patrick Rogel to get the mop. (since Alexis mentioned them in the discussion). Abzeronow (talk) 17:01, 13 June 2019 (UTC)
Neutral leaning Weak oppose This section I'm much more meh on than the above one mostly because it includes a requirement that you would have to go through an RfA like process but like Abzeronow stated I don't really see the point of segregating such things out. If I trust you to delete and protect I trust you to have a full mop. Quite simple in my mind. I'm a little concerned about protection abilities and the sometimes vagueness that is associated with DRs and copyvios (where exactly should the GM draw the line) but obviously if it can be revoked easily in instances of problems whatever. As a side note, I'm guessing this would be grantable, and therefore removable, by admins not just 'crats even though it would have to go through a "RfA-like" process. If people really think that segregating this out would get us more help so be it, I just don't necessarily think it is needed to do so. --Majora (talk) 18:27, 15 June 2019 (UTC)
Support Might help users how don't wish to become admin, but want some admin rights. Serving as an Admin is not an easy task for some users, they should be provided some rights. And their accounts must at-least be 1 year old. -- Eatcha (talk) 10:39, 18 June 2019 (UTC)
Strong support Actually I am quite surprised that there isn't something like this already. At this moment I would not want to even try to become admin, but something like this would be an area where I could help out a project. ℺ Gone Postal (〠✉ • ✍⏿) 18:24, 25 June 2019 (UTC)
We might think of a better user group name for CA general maintainers, but don't let your vote hinge on that. - Alexis Jazzping plz18:31, 11 June 2019 (UTC)
Certainly a well-intentioned proposal, but I'm not convinced by this attempt at defining an "admin light" permission. I see it as problematic to be able to delete, but not to view deleted content. Especially the proposed "general maintainer with community approval" who would be allowed to "deal with DRs and copyvios" - for such cases, viewing deleted content is often helpful or even necessary. Just one recent example: In Commons:Deletion requests/File:Terence Winter.jpg, a file got nominated for deletion as "already deleted". In fact, the deleted one only has the same file name as the newly uploaded image. - I think the WMF would have no problem with giving a few dozen people more full admin permissions (that would still be comparable to admin numbers on other projects), so I would rather encourage more people to be bold and request adminship. Gestumblindi (talk) 18:56, 11 June 2019 (UTC)
@Gestumblindi: Fair point, but this is more about Patrick Rogel than anything else. Patrick does plenty of good work here, but may occasionally cut corners. In this case, Patrick may be right though. Obviously no GM (and no admin, for that matter!) should take a user's word for it when they claim a file was "previously deleted". This is, however, a minority of deletion requests. Asking for people to be bold and request adminship is fairly pointless. Some people have, but the community is picky. And general maintainer may well be a step towards adminship for some. Someone who has already taken on the role of GM can also more easily prove they are admin-worthy before starting their RFA. If you want more admins, allow general maintainers. - Alexis Jazzping plz20:19, 11 June 2019 (UTC)
@Elcobbola: I am living proof you're wrong. I'd be interested in being able to (revision) delete my own mistakes. I'd be interested in getting rid of the ratelimit. I'd be interested in getting DelReqHandler to close-keep DRs. (I leave resolved DRs open now because closing DRs by hand is a pain) But I'm not interested in (full) adminship. Oh, and there's a map maker with a bit who only became admin to be able to (revision) delete their own outdated maps. That person is on the list of admins, but in practice not really an admin. - Alexis Jazzping plz20:19, 11 June 2019 (UTC)
And the nonsense argument if they are "not deemed suitable by the community" to be a "full" admin, they are not trusted enough for this thinly veiled "admin lite." You could say the same about license reviewers, rollbackers and file movers. You could also eliminate those groups. Away with license reviewers: grow some balls and become a real admin. Just ignore all the other privileges you get. If the community doesn't trust you with blocks, you can't be trusted with LR either. Except, no. License reviewers, file movers, etc do their thing, and so could general maintainers. - Alexis Jazzping plz20:27, 11 June 2019 (UTC)
Elcobbola is right in that no admin is forced to do everything an admin can do. For example, my own use of the admin tools was for quite a long period rather low, mainly consisting of deleting duplicates from time to time. Now I have become more active, processing more deletion requests, but I'm still not active in the area of user problems and blocks. Alexis Jazz, I think that you would be a good admin in the area of deletion discussions and don't see why you shouldn't try an RfA. Gestumblindi (talk) 20:37, 11 June 2019 (UTC)
@Gestumblindi: There are several reasons for that. I once made a request to become a license reviewer, which was declined because of a lack of trust. As I am no more or less trustworthy than I was back then, I feel I shouldn't be a license reviewer. By extension, I can't be an admin because the ability to do license reviews is inherently connected to that. The community also likely wouldn't accept it. And Jcb just might lose it if I became an admin, and many fear Commons will fall apart without Jcb. Potentially having more run-ins with Jcb is yet another reason I don't want it. And finally, I don't want to be "one of them", part of what is commonly seen as a kind of elite, only reinforced by Elcobbola. Community doesn't trust you with adminship? Then stick to rollbacking and file moving. No middle ground, no compromise. You're an admin or you're not. And as a result, we have backlogs. Because anyone who isn't trusted with blocks can't help with the DR backlog either. - Alexis Jazzping plz21:37, 11 June 2019 (UTC)
@Alexis Jazz: I beg your pardon, but then your proposal seems to be very much focussed on your personal experience and feelings. Not necessarily a good base for a general proposal. Gestumblindi (talk) 21:53, 11 June 2019 (UTC)
@Gestumblindi: I'm sorry if that would appear to be the case. I probably wouldn't be the first to apply for GM. Jeff G. seems interested, and I wouldn't be surprised if Fæ applied. 4nn1l2 told me a similar concept on fawiki helped greatly to reduce backlogs, but also said not to be very fond of them "because I believe they could be admins themselves". But the matter of fact is, the community doesn't trust a lot of people with adminship. The jump from user to admin may simply be too big, or too intimidating. That's why I came up with GMs. If anyone has a better idea that'll actually work, I'm all ears. - Alexis Jazzping plz22:02, 11 June 2019 (UTC)
By the way, the argument also goes into the opposite direction, "why would we need separate CheckUsers and Bureaucrats? The community trusted them to be admins so they're trusted enough." Same logic, the more split the powers are the less abuse of them will occur. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:35, 11 June 2019 (UTC)
Comment There is some merit in this proposal, but I am not sure how it would technically be implemented. Is it possible to have the delete button, and then only be able to delete one's own files? I would support an intermediate level between license reviewer and adminship, but with different tools (protect, editprotected page, ratelimit, closing uncontroversial DRs as kept, etc., basically, everything except blocking users and deleting files). Regards, Yann (talk) 06:41, 15 June 2019 (UTC)
@Yann: while reupload-own exists (overwrite existing files uploaded by oneself), delete-own does not. But given the existence of overwrite-own, a feature request for delete-own may be feasible. If this proposal doesn't make it (I keep hope it will), I'll draft another proposal in which I'll possible incorporate delete-own. - Alexis Jazzping plz13:00, 18 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Question I am not trying to re-open this discussion or anything, but I noticed that regarding the second proposal that there are 5 (five) oppose "votes" (4 sysops) and 6 (six) support "votes" (no sysops), while I can see that the majority would be too slim to allow for the creation of this user group (at least I am certain that this page has an unwritten rule of maybe 80% (eighty percent) support or something), I also see that some opposes are conditional (such as the ability to delete files/pages) and there are some neutral "votes" so I wonder why this proposal seems to be de facto rejected after there was a slim majority support for one iteration of the user group. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:44, 9 July 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 22:13, 17 July 2019 (UTC)
Use the WebRTC (DNS leak) to expose the true IP address of a sock-puppet.
Not a snowball's chance in hell. Collecting sensitive user data - especially using a security flaw - on the off chance it's useful is antithetical to the spirit of Commons. The community has been clear about that view. Pi.1415926535 (talk) 19:13, 17 July 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hello everyone,
I was browsing through the CU codes when I noticed that we do not collect true IP address of Users using the WebRTC that often compromise the security of VPN/Proxy tunnels. I think by collecting the WebRTC data we can increase the detection rate. Check https://browserleaks.com/webrtchttps://tools.wmflabs.org/fpcstats/bfp/ after starting your VPNs or open proxy , deviceId is also generally useful to track users. We are presently collecting only IP, User agent string and of course comparing edits. WebRTC is enabled in all browsers by default, this need to be manually turned off. We should also collect screen sizes, Available screen, Color depth and Pixel depth (check https://ipleak.net/#webrtcleakhttps://tools.wmflabs.org/fpcstats/bfp/). -- Eatcha (talk) 15:08, 8 July 2019 (UTC)
(edit) This data will be accessible to Check Users and Wikimedia Foundation only. This proposal is not about releasing your data publicly. It only adds some powerful detection elements to the Check-User Extension. -- Eatcha (talk) 14:19, 9 July 2019 (UTC)
Votes supporting/Opposing collecting true IP addresses using WebRTC (DNS leak)
Support As proposer, this should also benefit Wikipedia where sock-puppets are more common compared to commons. Eatcha (talk) 15:08, 8 July 2019 (UTC)
Oppose Unless I misunderstand something, this is basically a proposal to publicly log checkuser data. We already collect similar sets of data, and there is a good reason why we restrict access to this information only to checkusers, and even for checkusers, mandate mutual oversight and only keep logs of this information for a limited period of time. See also m:Access to nonpublic personal data policy and m:Privacy policy. GMGtalk14:02, 9 July 2019 (UTC)
Umm...well then this really needs to be evaluated by some technically competent checkusers before we even try reaching out to legal. I know User:Magog the Ogre is at the very least both a CU and a bot operator. Maybe they can weigh in. GMGtalk14:52, 9 July 2019 (UTC)
Oppose There are reasons for users to stay anonymous. For example users form China or Turkey. At some political topics some people also want to stay anonymous in democratic states. --GPSLeo (talk) 13:00, 10 July 2019 (UTC)
Oppose I consider exploiting these leaks as extremely unethical and don't think Wikimedia should engage in this. I don't think the end justifies the means here. No one should collect data people don't want to be collected and in the majority probably don't even know they expose to websites. I'd be very sad about Wikimedia to set a bad example. --Marsupium (talk) 13:06, 13 July 2019 (UTC)
Oppose Sorry, but this is not something Commons community can decide on unilaterally. You need to start a site-wide RfC on Meta where users from different projects (such as Wikipedia, Wikisource, etc.) and various language communities (en, fa, ar, etc.) can participate in, assuming WMF agrees with your proposal. 4nn1l2 (talk) 20:17, 13 July 2019 (UTC)
Comment, I know that the CheckUser tools are currently limited due to privacy concerns, but if this information wouldn't be able to reveal too much more it would probably be acceptable, but I agree with Alexis Jazz that WikiLegal should first look at this because this could open up lawsuits in countries where collecting such data without consent could be considered "a privacy violation". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:03, 9 July 2019 (UTC)
Another issue is that users who use a VPN due to safety concerns could be outed this way. There's also a technical issue I think: this data would have to be collected from all users and stored on WMF servers. You can't collect this information from just vandals. - Alexis Jazzping plz13:19, 9 July 2019 (UTC)
I meant "collect these things from every-editor", there is no profit in collecting data from blocked vandals only. BTW what is Wiki-Legal ? -- Eatcha (talk) 13:29, 9 July 2019 (UTC)
This should definitely be sent to the WMF Legal Team for consideration as it most likely goes beyond the current PP and DRG. Legal exceptions can be made in certain cases, but collecting various browser fingerprinting data can get murky very quickly. SBassett (WMF) (talk) 15:21, 9 July 2019 (UTC)
Question, Come on!, don't say you never used Google/Facebook/YouTube/Amazon, they fingerprint your device to show relevant ads, WMF don't show ads or share any kind of data to any external government (Excluding NSA, with or without WMF's approval) . We are facing increasing number of trolls, we don't have many active admins to deal with them. Only 5 CU, use a VPN, spoof your User-Agent and boom CU fails!. Fingerprinting is quite new in tracking industry, it doesn't depends on whether you use a VPN/proxy or change you UA or even change your browser! We just need info about the CPUs, GPUs, sound device and mics and a hash generated using these details is really hard for a sock. I don't need you change you vote, but please note that If we don't upgrade our tools we will loose. Thanks for sharing your opinions -- Eatcha (talk) 18:56, 13 July 2019 (UTC)
@Eatcha: "We just need info about the CPUs, GPUs, sound device and mics "
I can fake all that shit in multiple ways. It's an arms race. But still, collecting system info (which may not help much in the long run) is different from collecting true IP addresses. - Alexis Jazzping plz19:45, 13 July 2019 (UTC)
I know that these can be spoofed in many ways like using VM, add-ons etc. But doing all of these together is not an easy task, What I meant by "We just need info about the CPUs, GPUs, sound device and mics " is the Machine FP, we can use java-script, timezone, flash for finger-printing browser. We are collecting visible IP, with RTC vulnerability we can also get the true IP if anyone is behind VPN/proxy. I think if we add all of this in CU-extension it will be really hard for Sock operators. Maybe if we add more data into the system (CU Database ) it can be made automated, which will detect socks automatically. Note: I Know nothing is foolproof, but something is better than nothing IMHO. Warm Regards, -- Eatcha (talk) 20:00, 13 July 2019 (UTC)
@Eatcha: so I disable javascript and I can't remember the last time I had the Flash plugin installed and activated anyway. Collecting true IP using a vulnerability is, I think, never going to fly with legal. Now what? - Alexis Jazzping plz20:31, 13 July 2019 (UTC)
Why do you think intelligence agencies do not get these data? The have the possibility to get an undercover agent a CheckUser or just need to threaten or buy someone with these rights. We are not only talking about US government, many states are much more interested in who is participating here. --GPSLeo (talk) 20:34, 13 July 2019 (UTC)
I will open this on Meta, legal we will see there. Bad users are on rise, I can't think of a better option other that automation of CU by pumping more data into it so that we can set a detection rate above which it should block automatically or inform a CU to take further action. Regards, -- Eatcha (talk) 20:38, 13 July 2019 (UTC)
"We just need info about the CPUs, GPUs, sound device": well, users can go to https://panopticlick.eff.org and tell us whether they're happy with it. (Canvas fingerprinting might be the most powerful one at the moment.) If you want to make such bits of identifying information available to CheckUsers, you have the option to send a patch for the CheckUser extension. Sending private data outside MediaWiki is not an option and any sysop trying to do it is routinely deflagged on sight. Nemo10:55, 15 July 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 22:13, 17 July 2019 (UTC)
Give translation administrators the templateeditor right
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Templates that are commonly used and template protected may need translation and translation administrators should already be trusted enough to have this right. MorganKevinJ(talk)02:46, 15 July 2019 (UTC)
Why shouldn't they just apply for the right if they feel like they need it? Many people are not comfortable editing template syntax. Many more don't know what they are doing and could very easily break templates by editing carelessly. Being able to translate between languages and being able to edit templates effectively are two very very different things. --Majora (talk) 03:05, 15 July 2019 (UTC)
Translation admins are not people "able to translate between languages" but people who know how to use a powerful tool (whose syntax is sometimes confusing to people) and what translators need (e.g. which parts of a template are untranslatable syntax and which are language-dependent). Nemo10:52, 15 July 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 22:13, 17 July 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As suggested by ŠJů in phab:T228317#5346845, I propose doubling the move limit from 8 to 16 per minute. This would help with harmonizing category names.
Oppose per Snaevar's statement on Commons:Village_pump#Increasing the rate limit for page moves. The only known case when the rate limit was hit is a move in violation of Commons' policies. In that case, any change to move rate limits doesn't make sense at all. Dislaimer: I am a volunteer system administrator processing wiki configuration changes, and I am involved with the request that was created by the proposer. This is a vote that was made in my personal capacity, as a Wikimedia contributor. --Martin Urbanec (talk) 23:08, 20 July 2019 (UTC)
Oppose per Snaevar's statement on Commons:Village_pump#Increasing the rate limit for page moves. The only known case when the rate limit was hit is a move in violation of Commons' policies. In that case, any change to move rate limits doesn't make sense at all. Dislaimer: I am a volunteer system administrator processing wiki configuration changes, and I am involved with the request that was created by the proposer. This is a vote that was made in my personal capacity, as a Wikimedia contributor. --Martin Urbanec (talk) 23:08, 20 July 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Is there such a thing as a template, easy to find, to ask that a better version of an image be uploaded, such as here, where the size is so small, hence the writing so blurred, that it's questionable whether or not such an image, of a very interesting subject, is snything more than an irritating distraction?
Thank you for asking! I was thinking more in terms of a template that says something like "This image of a valuable subject should be replaced if possible with a better version". --SergeWoodzing (talk) 20:51, 18 July 2019 (UTC)
Support I think that this is a good change to make now. The Creator template probably doesn't need to be included, though, since it should just duplicate what's shown in the infobox. @Alexis Jazz: They appear at, e.g., [1] - "You are creating a new category description page. To pre-fill it with some basic elements, choose: People, Ships or Museums". That can probably be reduced to just adding the infobox. Thanks. Mike Peel (talk) 19:21, 24 July 2019 (UTC)
The same file with no change but a reduced file size using tools like PNGOUT, pngcrush, jpegoptim, etc.
I occasionally see users doing this, thinking its useful. For any thumbnail (most on-wiki use) it makes no difference so it saves little bandwidth, does cost some storage, browser compatibility (especially for SVG files) can be altered, metadata and color profiles could be lost, compression is not guaranteed to be lossless and because those users do this by hand, they could be introducing all kinds of errors. If we actually wanted it, we'd have a bot for it or even just have MediaWiki do it automatically. No user should do this by hand. - Alexis Jazzping plz01:58, 25 July 2019 (UTC)
Support, how is this not considered a form of vandalism? (just to be clear, I don't support ever blocking someone over this, people often do it in good faith, but if partial blocks will one day be implemented then I would support limiting WARNED repeat offenders from doing this.) Maybe when someone overwrites an existing file there should be a list of rules displayed like we have for renaming an existing file. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:24, 25 July 2019 (UTC)
Support That kind of "optimization" doesn't really seem to help anybody as a) it only increases the storage space used over all and b) the user gets served png thumnails that have been rendered server-side anyway. --El Grafo (talk) 07:27, 26 July 2019 (UTC)
Oppose The proposal is much too general and should more specific to a global restriction. E.q. file-format, SVG, s. below or if the optimized file is 3/4 smaller (or other) -- User: Perhelion00:26, 11 August 2019 (UTC)
Oppose I'm unconvinced this is a problem that needs fixing. If you see someone doing something that you consider to be a waste of time, perhaps let them know... but I struggle to see why this is something for which we need to create a rule. Also, there are situations where a file is perversely huge for no good reason - on the other hand, maybe we should just delete them. Storkk (talk) 09:35, 13 August 2019 (UTC)
Comment altering browser compatibility for SVG can be a good thing if it fixes some of the many commons issues … --El Grafo (talk) 09:40, 25 July 2019 (UTC)
Comment It seems most people here have no real clue about the SVG format. A general restriction is absolute senseless here. Some SVG are full of code garbage (e.q. 4 MB vs 40 KB, which can have huge performance impact and can crash the Mediawiki renderer) and that's one of the main points why SVG is not natively support here (not the compatibly issue). phab:T208578 -- User: Perhelion00:07, 11 August 2019 (UTC)
@Perhelion: You misunderstood the proposal. Some further explaining can be added to COM:OVERWRITE though. If you overwrite some 4 MB SVG file with a 4 KB one to stop the Mediawiki renderer from crashing or browser from locking up, you have overwritten it for those reasons. Not to reduce the file size. If a 4 KB SVG is crashing the Mediawiki renderer, you'd also overwrite it. Not crashing the Mediawiki renderer is a change different from reduced file size, so you can overwrite. Removing junk that makes the file hard to edit, thus making it easier to edit, is also a change different from reduced file size. - Alexis Jazzping plz07:41, 13 August 2019 (UTC)
By that logic, any size reduction of (non-png) files would make them easier to edit. And that change may not be trivial if the edits are being done in bulk (for raster) or by hand (for SVG). Some common sense is always going to be necessary, no matter how many rules we create. Some people are always going to occupy themselves in ways that others think are trivial, and while it may be OK to point out to them why you think that work is trivial or useless, I can't fathom why you'd want to enshrine a prohibition in the guideline. Storkk (talk) 07:54, 14 August 2019 (UTC)
@Storkk: "I struggle to see why this is something for which we need to create a rule." I've had to deal with several of them. I felt it would be rather inappropriate to name and shame them. One of them was particularly annoying, and without a rule to point to they fail to see why they are harming the project. And no, not "any size reduction of (non-png) files would make them easier to edit". Reducing a .jpg by 2% does not make it easier to edit. - Alexis Jazzping plz09:26, 23 August 2019 (UTC)
@Storkk: Your ping didn't arrive. I think it has to be on a new line. When they upload an SVG that's turned into unreadable high density rubbish, any user who tries to create a derivative work from that is harmed. (happened to me) When they "optimize" files and it's not lossless, they harm those files. (seen it) When they accidentally swap files when overwriting (because this shouldn't be done by hand), they harm the project. And these things are done for.. no gain whatsoever. - Alexis Jazzping plz09:51, 23 August 2019 (UTC)
@Alexis Jazz: Thanks - I didn't know that; I thought it just needed to be signed. I believe all of the above fall afoul of policies and guidelines we currently have. Storkk (talk) 10:41, 23 August 2019 (UTC)
Maybe this should be about optimizing bitmap images in particular. SVG would be more nuanced, for sure. I have had some of my SVG uploads optimized -- quite legitimately, as the older converter I was using resulted in a needlessly huge file. I have also seen some silly re-uploads of SVGs just to make the file size a tiny bit smaller (even sometimes removing invisible elements that aid in positioning/editing, just to make it smaller). On the other hand, there could be valid changes to make an SVG more readable when editing by hand, or optimizing some of the drawing commands for faster rendering. The rules there should be more nuanced, as some are hand-editable (and thus have readability concerns), and don't have the "lossless" problems that bitmaps do. Carl Lindberg (talk) 15:18, 23 August 2019 (UTC)
As usual, this requires a modicum of common sense and understanding what one is doing: two things that are virtually impossible to ameliorate by creating hard rules. There are very legitimate reasons for potentially reducing filesizes for simple raster images: poor default settings can lead to immense filesizes which can be reduced (often 20 fold or more) by simply using indexed colors and judicious recompression. I have personally experienced this frequently when including screenshots into a PDF produced using LaTeX... losslessly converting the PNGs to indexed color reducing the PDF from dozens of megabytes (quite hard to email) to hundreds of kilobytes (easy to email and share). We should not (IMO) have a prohibition on a step that frequently makes our media easier to re-use without damaging quality, regardless of how frequently this step is also mis-used. Storkk (talk) 16:45, 23 August 2019 (UTC)
Those are fair points. The rule though is more about smaller optimizations like pngcrush, jpegoptim, etc., so uses well outside those areas would still seem to be reasonable. Maybe it should read "The same file with no change but a slightly reduced file size"... but it's possible it would need to be more carefully worded than that too. I know I have overwritten to remove an image profile which prevented display in many browsers. And there could be images with outsize resources internally mostly unrelated to display (excessive thumbnails or metadata or something). Carl Lindberg (talk) 17:26, 23 August 2019 (UTC)
Assuming that the overwrite only slightly reduces filesize, and that it does not have an otherwise deleterious effect that is already prohibited by policy & guideline, I'm back to struggling to see the harm. This whole endeavor (the wikipedias as well as commons and other sister projects) is built on thousands upon thousands of people making small incremental changes that many people would consider trivial. Granted, I personally agree that these particular edits (again, assuming no deleterious effects already prohibited) can be close to pointless... but until I see the actual harm I can't endorse this. Storkk (talk) 18:48, 23 August 2019 (UTC)
It creates another copy of the file, which uses added space. The old file is still stored (though without being able to see its metadata on the file page); we just add a slightly smaller version on top. I mean, if someone changes an 85MB PNG to 82MB with pngcrush, that is a fair amount of storage that is more or less wasted. Oftentimes those tools may accidentally strip some metadata on the way, etc., or may not be lossless. It's somewhat easy to make mistakes with command line arguments, too. Jpegtran has some modes which are not lossless. Reducing the file size significantly (if lossless) is a good thing, but a marginal reduction usually doesn't help much if at all, and just adds more copies of the file to be stored. Using pngcrush etc. just to squeeze a few more bytes out should be discouraged, I think. If it reduces from 85 to say 10 somehow, well that's different. Not sure the best way to get that into the guideline, but this seems reasonable. This is a guideline, not (hard rule) policy. And it would be listed in the "minor improvements" area, whereas the ones that you describe seem far from minor. Carl Lindberg (talk) 19:05, 23 August 2019 (UTC)
[OK] Lossless file size reduction of at least 50% while preserving all metadata, color profiles and software compatibility. Vector graphics (e.g. SVG) only: the same, but highly generic metadata may be removed, code readability has to be preserved and invisibile guide elements should also be preserved.
File size reduction overwrites that do not meet all those requirements should not be performed without community consensus.
Still feels like creating rules for the purpose of creating rules, and I am extremely skeptical that the creation of this rule will be a net benefit to the project. But it appears I'm in the minority. Storkk (talk) 08:27, 2 September 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 15:33, 9 July 2019 (UTC)
Support as proposer. - Alexis Jazz ping plz 10:03, 29 June 2019 (UTC)
Oppose I support the direction of this proposal, but not its destination. I can see a requirement for an admin (or even a licence reviewer) to somehow store their warnings somewhere, but a regular user should be absolutely free to wipe their talk page every 5 minutes. History of the page is already a log, there is no reason to make a contributor of media to become a master archivist. Of course, I do understand, that this proposal technically states what a user may do, rather than stating what they may not do. So I could be brought on board to support this if we create a warning along the lines of "Immediately stop warning people, who are doing things that are explicitely allowed! (Yes, you may remove this warning)". But I must be honest, I would support that just to make a point and would not use such a template myself in most cases. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 06:01, 1 July 2019 (UTC)
Option 1
inbetween
alternate
Option 2
is not clear. BTW, why the vertical bar inside curly brackets? 4nn1l2 (talk) 02:39, 13 June 2019 (UTC)
is clearer than 
. 4nn1l2 (talk) 00:52, 8 July 2019 (UTC)
instead. –LaundryPizza03 (dc̄) 12:01, 13 June 2019 (UTC)
. — Jeff G. ツ please ping or talk to me 12:27, 13 June 2019 (UTC)
used on enwiki. A variant with bigger symbol was aesthetically unappealing. –LaundryPizza03 (dc̄) 21:49, 13 June 2019 (UTC)
.svg){kind=link}
Comment What about text copyright violations included in filepage descriptions, usually as descriptions, esp. when the file itself has no copyright issues? -- Tuválkin ✉ ✇ 02:10, 15 June 2019 (UTC)
Weak oppose See discussion section for my reasoning. Gestumblindi (talk) 18:57, 11 June 2019 (UTC)
Neutral Honestly I don't see how "admin lite" would help otherwise qualified people who are controversial pass this although I could see it helping increase the show of support of candidates that people feel uneasy about giving the ability to block but feel fine about giving them other admin-like abilities. I also don't see current admins supporting this proposal if above votes are any indication. And I'd vote for Patrick Rogel to get the mop. (since Alexis mentioned them in the discussion). Abzeronow (talk) 17:01, 13 June 2019 (UTC)
Strong support Actually I am quite surprised that there isn't something like this already. At this moment I would not want to even try to become admin, but something like this would be an area where I could help out a project. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 18:24, 25 June 2019 (UTC)
Question I am not trying to re-open this discussion or anything, but I noticed that regarding the second proposal that there are 5 (five) oppose "votes" (4 sysops) and 6 (six) support "votes" (no sysops), while I can see that the majority would be too slim to allow for the creation of this user group (at least I am certain that this page has an unwritten rule of maybe 80% (eighty percent) support or something), I also see that some opposes are conditional (such as the ability to delete files/pages) and there are some neutral "votes" so I wonder why this proposal seems to be de facto rejected after there was a slim majority support for one iteration of the user group. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:44, 9 July 2019 (UTC)
wikimedia.org -- Eatcha (talk) 13:36, 9 July 2019 (UTC)
.svg){kind=link}
File size reduction overwrites that do not meet all those requirements should not be performed without community consensus.