Commons:Village pump/Proposals

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

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

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

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

 

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Arbitration Committee for Commons[edit]

In the last months we had many disputes between users in many cases involving admins in the dispute. To solve this Commons should also get an Arbitration Committee to find good solutions for these long lasting discussions and disputes. There was a proposal from 2007 Commons:Arbitration (failed proposal) but this was rejected because Commons was much smaller and such an instrument was not needed. I would propose the following concept:

  • The ArbCom has ten members elected for two years. If one member leaves there will be a new election for replacing this member.
  • Everyone can candidate for the ArbCom and admins can still do their regular admin activities.
  • In the election candidates with the most support votes and with at least 2/3 support votes are elected.
  • Decisions are done by fife of the members. ArbCom members they were somehow involved in the prior discussions on a case are excluded from the case.
  • Everyone can bring a case to the ArbCom, but the ArbCom can decide to not accept the case and leave it to e regular admin decision.
  • Copyright related discussions are not a topic for the ArbCom.
  • The ArbCom should fine a decision within 14 days.
  • The decision together with an explanation will be published.
  • The subjects of the decision or a group of ten users can request a reevaluation of a case by the ArbCom.

This is a first concept to create a guideline and then implementing this. --GPSLeo (talk) 06:56, 14 January 2023 (UTC)Reply[reply]

Discussion[edit]

I am wondering what advantages this will bring to the Wikimedia Commons. For years I have thought of proposing a Commonswiki ArbCom myself but having closely looked at the English-language Wikipedia's ArbCom I realised that it can also have a lot of issues, namely I seem to find a lot of formerly productive users being ArbCom banned but very few seem to ever be unbanned. Having looked at the Dutch-language Wikipedia's ArbCom I'd say that I find their level of transparency better, e-mails sent to the Nlwiki ArbCom are published and other users can give their insights and opinions on the cases, this actually makes it a more community-driven thing. But still, the main thing I see ArbComs do it add another level of bureaucracy and often making it impossible to get unblocked. Users who are ArbCom banned can get blacklisted from e-mailing them and not even know that they're Blacklisted essentially making any future unbans impossible.

I do think that we should have an Appeals Court for indefinitely blocked users with no access to e-mail and talk page as there is no such system or UTRS here, but for everything else I can hardly think of anything that the ArbCom really improve. The ArbCom cannot dictate guidelines and policies, only their interpretation.

Again, I really like the idea of a Commonswiki ArbCom, but having seen how they can bureaucratise content creation at the Enwiki I am not sure if they'd actually be beneficial to the Wikimedia Commons. Perhaps we should have a less powerful ArbCom here that deals with less. An advantage to an ArbCom is that they can actually take action against abusive admins as the current system here is severely broken (something which user "Alexis Jazz" brought up several times before he quit editing here), but I'm not sure if the benefit of occasionally getting rid of the few bad apples is worth the creation of a powerful ban hammer that can stifle discussion about topics that have been brought up to it (which other users will claim are "done" and "dead horses" if brought up later).

I'd support the creation of an ArbCom with less powers than the Enwiki one, perhaps limited to reviewing admin actions and reviewing blocks and appeals. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:57, 14 January 2023 (UTC)Reply[reply]

If the Commonswiki ArbCom cannot talk about copyright ©️ can it then basically only talk about interpretations of "COM:SCOPE"? As basically "COM:LICENSING" and "COM:SCOPE" are the only two (2) rules around here from which all other rules eventually stem, I don't really see how having a small council dictate how to interpret this would be more beneficial than wide community discussion as is the rule today. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:59, 14 January 2023 (UTC)Reply[reply]

I think the copyright restriction is missing the mark. If a user dispute originated from a copyright dispute, this ArbCom absolutely should be able to handle it. Instead, the restriction should be replaced with: "ArbCom does not have the power to order the deletion or undeletion of any pages, or to pass any binding community-wide policy without community consensus."
One thing I've observed is that there tends to be a lower threshold for indefinitely banning or blocking users on English Wikipedia than on Commons. The creation of an ArbCom will probably make Commons more like English Wikipedia in this respect. Whether that's a good idea - who knows? -- King of ♥ ♦ ♣ ♠ 04:11, 15 January 2023 (UTC)Reply[reply]
I would exclude copyright related questions from ArbCom topics because they are complex legal questions and they might not have the ability to discuss them in a proper way. The ArbCom should focus on social problems. And yes I also would see the scope of the ArbCom on reviewing admin decisions, but not blocking someone after the discussion is also a decision that could be reviewed by them. --GPSLeo (talk) 06:41, 15 January 2023 (UTC)Reply[reply]
One additional thing that the ArbCom could handle is appeals of blocks involving non-public information (i.e. CheckUser or Oversight blocks), although this would require, like English Wikipedia, that arbitrators be granted these permissions. Overall, I think this is a good idea, although I'd probably fiddle with the criteria. —‍Mdaniels5757 (talk • contribs) 18:38, 15 January 2023 (UTC)Reply[reply]
One of the requirements Copyright related discussions are not a topic for the ArbCom. is quite strange given what this project is revolved around and should be removed. Some cases that could involve copyright issues may need to be clarified by those elected based on existing policies here, if need be. Also what Mdaniels5757 said. Other than that, an Arbcom is needed for this place. 1989 (talk) 07:55, 16 January 2023 (UTC)Reply[reply]
Symbol strong support vote.svg Strong support Having an ArbCom was long overdue. I agree that an ArbCom shouldn't deal with copyright, that's a job for the wider community. It should deal with incivility, assumptions of bad faith, complex abuse of permissions (especially filemover!), etc. However, my main concern is: How will the ArbCom maintain language neutrality? --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 21:46, 16 January 2023 (UTC)Reply[reply]
  • I'm in support as long as ArbCom remains focused on human behaviorial issues since as admin/filemover decisions and not on copyright issues per se. One can dispute whether an admin's closings are repeatedly bad (and thus at undeletion all the time) without getting into the actual copyright issues that are underlying them. Similar with someone who starts a bunch of deletion requests that go nowhere because they are a controversial view of copyright (the issue is whether that itself is disruptive). The problem is, unlike English, topic bans aren't that common an option so if the only options are bans or no bans, you don't have many tools to use to control behavior. I suspect this will become mostly a fight over "admin abuse" like ANU is becoming since there are few other things that go to the level above that of admins. -- Ricky81682 (talk) 22:11, 16 January 2023 (UTC)Reply[reply]
Symbol oppose vote.svg Oppose it's impossible to select rational people from a pool full of the opposite. it will just end up with another bunch of self-important buffoons.--RZuo (talk) 20:27, 18 January 2023 (UTC)Reply[reply]
@RZuo: Please point to a previously identified "bunch of self-important buffoons" with consensus or retract your statement.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 04:56, 19 January 2023 (UTC)Reply[reply]
@RZuo I concur with Jeff G.. Also, the fact that someone happens to disagree with you doesn’t automatically make them irrational. Brianjd (talk) 14:11, 20 January 2023 (UTC)Reply[reply]
+1 Or otherwise bunch of self-important buffoons look like another propaganda for me. Liuxinyu970226 (talk) 05:49, 29 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support A Commons ArbCom is a good idea. I also agree that copyright related discussions should be excluded from ArbCom. Abzeronow (talk) 17:34, 19 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support Without Arbcom, all new Checkusers and/or Oversighters have to be granted by stewards, which may be a lot of unfair spending of times, with Arbcom, we can grant em by ourselves. --Liuxinyu970226 (talk) 07:05, 22 January 2023 (UTC)Reply[reply]
No, I don't think this will change will an ArbCom. Checkusers and Oversighters are elected by the community, but the bit is given by stewards. Yann (talk) 10:51, 22 January 2023 (UTC)Reply[reply]
Symbol oppose vote.svg Oppose not completely, but in general, One of the worst things about ArbCom on enwiki is that it has never actually worked when it comes to dealing with admin abuse; editors yes; admins, no... as I have noticed for years that if you are an admin on enwiki, you do not fear the arbcom cause in most cases they will protect 'their own', even former admins...sad reality...so trying to make this project on par with enwiki is a bad idea..again as i said, in general, this project needs an arbcom level uhm "entity" but unlike enwiki, it should not be made up of admins and CU's only, thats is where this idea falls flat on its ass... if you are going to have 10 members, 5 of them have to be non-admins and picked from the community or else we end up with a pack of cockatoos running the zoo, atleast two users with CU access and 3 experienced admins, or else we end up like the US supreme court where one party has intentionally packed it with their own people allowing them majority and ability to change or enforce laws (which we already saw a negative outcome for in case of Roe-v-wade)...also i have to kinda agree with RZuo in terms of picking rational people to run this, we have a limited number of those uhm in this asylum as most have either left or have been bullied out..not sure where we would even go about selecting the right ppl for this cause after a recent issue of admin abuse on this wiki (one of which was very diabolical), i'm not sure i can trust new admins on this project..my only reason to support an arbcom was a recent block by admin of a crat on another wiki here for 6 months, this IMO was admin abuse and that admin refused to budge on this block or talk about it so yeah we need something to control abuse by admins on this project but at this stage arbcom (the way illustrated above) isn't the answer.. it will just create more issues..--Stemoc 02:49, 25 January 2023 (UTC)Reply[reply]
You are going to have a hard time finding people who are experienced enough here and interested enough to join ArbCom but aren't admins here. Ricky81682 (talk) 06:44, 25 January 2023 (UTC)Reply[reply]
very much the point, 10 years ago, we could have but it will be harder now which may mean limited candidates if this does go through, also 10 years ago, INC could have fielded all 10 candidates on his own :P ...thus my point of corruption here being so high that we no longer have the right people to run this project.... Stemoc 07:20, 25 January 2023 (UTC)Reply[reply]
I also don't think an Arbcom full of failed admin candidates is ideal. Either way, I assumed the criteria for Arbcom was going to be people from the community. If so, we will likely end up with admins because they are supported by the community. Ricky81682 (talk) 08:02, 25 January 2023 (UTC)Reply[reply]
thats the reason why arbcom is a huge fail on enwiki, all admins protecting admins, lets not do the same here and expect a different result, lets try something different, its odd we call it an arbitration "committee" and yet its basically an admin only committee, last i checked 95% of editors on enwiki are not admins and yet are not represented..rather have a few failed admins candidates selected for a committee that fully understands the plight of regular contributors than a bunch of egotist narcissists thinking they hold the power to decide the fate of people who actually "contribute" to the project ..a balance would be good..... the reason why i want non-admins is when INC was on his egotist run back then creating havoc and i was seeking help from admins here to do something about it, they refused, even when it got confirmed then he ran another admin account, and yet admins here would no ban him....I even went to meta which was my homewiki then and even pointed out how pathetic admins on commons were cause just like enwiki, they were protecting their own and refused to do anything about it and then global ban failed cause they decided it was a local problem and our local admins here were useless, if our useless admins and CU's had done their job correctly then and CU'ed him and found out his socks and blocked them, i would have trusted them more but nothing changed, INC was eventually Global banned a month later but if was due to something he did on another wiki cause admins on our wiki are and have been unfortunately pathetic when it comes to doing the right thing..this is why we should try something different .. why give people who want more power to get more power?.... Stemoc 01:42, 26 January 2023 (UTC)Reply[reply]
Presumably many users here are familiar with the internal operation of enwiki (and specifically their ArbCom, but some users (like me) are not. Multiple users above have posted comments that look like rants, which just makes things worse; it would be more useful to post evidence instead. Brianjd (talk) 04:32, 26 January 2023 (UTC)Reply[reply]

New speedy deletion criterion proposal[edit]

I propose to add the following speedy deletion criterion:

X. Images globally replaced by text
This includes images globally replaced by HTML, wiki markup, and LaTeX.

Rationale: These kinds of uploads are quite common and deletion is uncontroversial. Currently, they have to go through a full deletion request and bind extra administrator resources. Once these images are replaced by HTML/wiki markup/text/LaTeX, they serve no educational purpose and can be deleted.

Note: I think my wording definitely could be better, so please drop suggestions!

--Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 20:05, 18 January 2023 (UTC)Reply[reply]

@Matr1x-101 Can you give me an example? Ricky81682 (talk) 02:21, 19 January 2023 (UTC)Reply[reply]
An example should include an automated way to make the replacements.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 04:29, 19 January 2023 (UTC)Reply[reply]
@Ricky81682: Just visit Category:Images with a TeX equivalent for some examples. And that's only LaTeX! --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 08:36, 19 January 2023 (UTC)Reply[reply]
I'm skeptical about this. I'm happy to get rid of mathematical formulae that someone hacked into MS word and exported to png (or jpg *shudder*) because they didn't know how to otherwise get that into their article (assuming they have indeed been replaced). I'm happy to get rid of things like File:Activité E s = 0,9 .jpg, but images like File:Calculation of refractive index increment.jpg have qualities that cannot be replicated by putting the formula into TeX. Files that are about the typesetting like File:Blahtex-comma-bug-1.png should not be deleted for this reason. Similarly, the whole archive of Mathematical formulas from Brockhaus and Efron Encyclopedic Dictionary is not something we should nuke without discussion just because we can replicate them in TeX.
I'm talking about random text/maths in an image (like this file) that has been screenshotted off MS word or something else. We should leave anything handwritten/scanned from paper out of this SD criterion, due to concerns about ambiguity. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:56, 19 January 2023 (UTC)Reply[reply]
In any case that should Symbol oppose vote.svg exclude things like PDF scans of public domain books that have equivalents on Wikisource. 1) These are still important as source material and 2) A wall on sans serif text on a wiki is not a replacement for a properly typeset book page.
Taking a step back, these are essentially being considered for deletion as out of scope. With the notable exception of unused personal images, we do not normally speedy delete out of scope images. That's because 1) these are often much less clear cut as one might think and 2) them being low-risk images, there is absolutely no need to hurry. For anything but legal reasons, blatant abuse, and things like obvious duplicates, we should probably stick to a regular DR. El Grafo (talk) 11:39, 19 January 2023 (UTC)Reply[reply]
The speedy deletion criterion for selfies ({{Selfie}}) was accepted, so I don't see what the problem with this is. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:39, 19 January 2023 (UTC)Reply[reply]
@Matr1x-101 I'm not saying there is a problem, just that we should be careful about introducing new CSD. Anything scope related has the potential to be controversial, so we should think twice and make sure the new criterion leaves as little room for interpretation as possible. The original proposal was unacceptable, the new one below might work. Looking back at the 2018 discussion, important points for the acceptance of COM:CSD#F10 were that 1) selfie uploads are indeed very common, 2) often users kept re-uploading selfies after their initial uploads were deleted. So it was (is) a very common problem plus related to abuse. At least abuse doesn't seem to play a role in this proposal. How common is the problem we are talking about here really? El Grafo (talk) 10:43, 20 January 2023 (UTC)Reply[reply]
@El Grafo, it's quite a big problem. If we look at Category:Images with a TeX equivalent, there's ~600 images (incl. images in subcategories). Let's assume 150 have been globally replaced by TeX (really conservative estimate). That's 150 deletion requests! And that's only images that have been reported with {{Use TeX}}. There are probably hundreds, if not thousands of low-quality maths formulas, that haven't been reported. And that's only Maths formulas! I don't know much about the numbers for screenshots of text (because no one uses {{ShouldBeText}}, its hiddencat has 2 members), but I suspect it to be even more. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 22:24, 20 January 2023 (UTC)Reply[reply]
The fact that there are so many images doesn't mean it's a problem for DR. The category doesn't even say what needs to be done there. Do you have examples of DRs where it's a SNOW keep which would show that it's enough of a problem so that a CSD is helpful? I don't see any of those listed for deletion so examples would help. You may be jumping the gun here with a CSD. Ricky81682 (talk) 02:01, 25 January 2023 (UTC)Reply[reply]
Imo, there's not much reason to keep these around, but there's also not much reason to get rid of them fast - or at all. They don't break copyright law, they're not vandalism or abuse, and they don't embarrass or offend anyone (other than our collective OCD). "Deleting" them will not even free up storage space, as they're just being hidden from public view. Just tuck them away somewhere where they don't clog up otherwise useful categories and move on to more important matters ... El Grafo (talk) 09:13, 25 January 2023 (UTC)Reply[reply]
Another thing to keep in mind is that Commons is a project on its own that does not only serve the Wikimedia projects. Sure, on Wikipedia you can render the structural formula of 6-hexane using TeX, but I'm sure there's a target audience for an easy to use graphics file like File:6 - hexane.svg. --El Grafo (talk) 11:16, 20 January 2023 (UTC)Reply[reply]

Revising the wording[edit]

Hi, so I'm revising this criterion's wording, because there seems to be concerns about deletion of handwritten/scanned text. Also, wikicharts/graphs are explicitly excluded.

X. Images globally replaced by text
Images globally replaced by HTML, wikitext, and/or LaTeX, with no reason to keep. This criterion should not be used to delete handwritten or scanned works.

--Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:56, 19 January 2023 (UTC)Reply[reply]

@Matr1x-101: I have moved your signature to below the proposal so that (hopefully) future responders can use the reply tool. Also, when a speedy deletion criterion has to use the phrase ‘with no reason to keep’, something is wrong. Brianjd (talk) 14:02, 20 January 2023 (UTC)Reply[reply]
[W]ith no reason to keep sounds pretty redundant on second thought, so that phrase should probably be removed.
Also, the phrase "with no reason to keep" is not strictly required, for this criterion to work. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 22:10, 20 January 2023 (UTC)Reply[reply]
  • Pictogram voting comment.svg Comment, I'm not sure if this is a good idea in general for speedy deletion, let's say that we have a text graph or index of a specific subject, this is an index that was later copied to be a part of a Wikipedia article and is converted to wikitext. Now you run your own website and want to include the index on your own website and simply want to copy the Wikimedia Commons' image, but you find that the file is gone and can only copy the wikitext but the formatting of the wikitext doesn't work for your website. What do you do? In this case nothing, as the original file is irretrievable for non-Commonswiki admins. Is this really that common of an issue that it has to go through speedy deletions rather than regular deletion requests? What if the file was used on other websites (outside of Wikimedia Wiki's) and links to the Commonswiki file? I simply don't see which problem this solves that regular DR's can't handle and uncontroversial cases are as easily closed as speedy deletions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:28, 20 January 2023 (UTC)Reply[reply]
    • +1. Unpopular opinion: The same applies to raster graphics or photos used as templates for SVG variants. In my humble opinion, it is very bad practice, not to say gross mischief, to delete these after the SVG has been created. --Smial (talk) 11:19, 25 January 2023 (UTC)Reply[reply]

When copyvio is incidental and easy to fix, place a burden on deleters to do so[edit]

Tons of w:WikiProject Apple Inc. images keep getting speedily deleted for incidental copyvio (e.g. a picture of a MacBook Air, that is partially copyvio because of the copyrighted wallpaper).

Because these are speedy deletes, there isn't any time for anyone on enWiki to react by blurring the wallpaper to "rescue" the image. File:IPhone 14 Pro - 2.jpg was just speedily deleted, despite being used on the high-traffic w:Apple Inc. article. It's untenable. Pictures of modern Apple products are extremely rare. We no longer have any good (non-render) images left of the iPhone 14, and without my past interventions, we wouldn't have a single pic of the iMac M1 or the MacBook Air M1/M2 either.

Propose, specifically for pictures of computers, where the copyvio is incidental:

  • Impose a burden on deletion nominators. The copyvio can be fixed without deleting the picture, so deleters should have a burden to fix it, before deleting the previous revision. (edit: withdrawn; I invite contributors to comment on Davey2010' and King of Hearts' proposals instead)
  • Or: figure out a way to give people on enWiki a chance to fix these issues, before these images are lost to time.

Surely there's a better way than this. DFlhb (talk) 17:39, 20 January 2023 (UTC); edited 01:28, 21 January 2023 (UTC) Reply[reply]

  • Symbol support vote.svg Support the following exception to COM:CSD: If only a portion of an image is a copyright violation, and the image is COM:INUSE in a way that would not be rendered useless by the removal/cropping/blurring of the offending portion, then the image is ineligible for speedy deletion. This applies as well, for example, to a collage of 5 pictures of a city where one of its components is deleted as a copyvio. So compared to your proposal, I am expanding the scope to be not specific to computers, but also limiting it to only in-use images, since not every photo of a copyrighted iPhone screen is worth saving via editing. I also don't want to put the burden on deletion nominators in general; as long as they use DR, those wishing to retain the image will have ample opportunity to fix it. -- King of ♥ ♦ ♣ ♠ 17:59, 20 January 2023 (UTC)Reply[reply]
  • Clearly "speedy" should not happen in these cases, but I think there should be no specific burden on the deleter. The normal deletion process gives plenty of time for someone to "rescue" the file. "Burden on the deleter" to fix rather than delete means that no one could ever delete on this basis. - Jmabel ! talk 18:54, 20 January 2023 (UTC)Reply[reply]
I think the correct CSD template for such cases is {{Dw no source since}} wich already gives seven days so solve the problem. GPSLeo (talk) 19:13, 20 January 2023 (UTC)Reply[reply]
The problem is that in a lot of cases, it qualifies for F1 or F3 as well. Some users will exercise good judgment and use DR or one of the 7-day options when more appropriate, but others just try to get an image deleted as quickly as possible, and right now what they're doing is technically compliant with CSD policy even if it is not the best option. I think we should tweak the policy to explicitly ban people from using speedy when the image can plausibly be fixed and there is clear value in doing so. -- King of ♥ ♦ ♣ ♠ 19:22, 20 January 2023 (UTC)Reply[reply]
@King of Hearts: I'd have no problem with that. - Jmabel ! talk 20:22, 20 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support - I would go one step further and say these images should not be deleted at all but instead moved to a category where people can check it from time to time and blur the images if and when they have time, I've rescued plenty of images like this and would be more than happy to help from time to time, –Davey2010Talk 22:17, 20 January 2023 (UTC)Reply[reply]
I far prefer this version to mine. I also really like King of Heart's idea, and the ineligibility for speedy. I support both both your idea and KoH's, and now oppose mine (burden on reviewers) due to the good arguments presented above. DFlhb (talk) 23:11, 20 January 2023 (UTC)Reply[reply]
Symbol support vote.svg Support, exactly what Davey2010 said. Also, I have noticed a number of DR's where the nominators have said that "this image is likely in the public domain but incorrectly tagged" like this one, maybe these should also have a category like "Likely free files with an incorrect license" or something. The Wikimedia Commons has a steep learning curve and many who have taken the time to learn the right licenses aren't taking the time to help others out, I think that a lot of well-meaning users come here to upload public domain files but don't know how to properly tag them and then see all their images deleted, this then translates into low user retention and this is because the burden is placed 100% (one-hundred percent) on the uploader to do everything right all the time, people will improve if you take the time to teach them, but if you speedily delete their images they're less likely to return. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:21, 20 January 2023 (UTC)Reply[reply]
Symbol oppose vote.svg Oppose Saying that the burden is on the would-be deleter to fix it amounts to saying these can never be deleted. If there is no way to delete images that have elements that are problematic with respect to copyright, regardless of how long they sit there without being fixed, we will accumulate large numbers of such images. They should not be speedied, but a week is plenty of time for someone to fix this for a given image if they care. - Jmabel ! talk 01:19, 21 January 2023 (UTC)Reply[reply]
There is clear consensus against my initial proposal, so I'm withdrawing it. King of Hearts' and Davey2010's proposals seem the most likely to achieve consensus, so I'm editing the opening post to invite readers to comment on those proposals instead. Best, DFlhb (talk) 01:28, 21 January 2023 (UTC)Reply[reply]
  • Oppose the original withdrawn proposal. The "figure out a way" isn't actually a proposal so I assume that's to be ignored. King, is your INUSE proposal an exception to F1 only or an exception to all CSD claims? An F1 exemption may make some sense or at least require a discussion could be helpful but I need to do more thinking. I disagree with Davey's proposal as I expect we will just end up with an indefinite holding cell with lots of copyrighted / questionably copyrighted images forever. Category:Items with disputed copyright information has over 4600 images and I imagine INUSE ones will grow indefinitely just as well. I don't know if one continued discussion here is helpful or separate subsections would be better since the original proposal in this discussion has been withdrawn and it's no longer clear what people support or oppose. -- Ricky81682 (talk) 00:44, 25 January 2023 (UTC)Reply[reply]
    @Ricky81682: Primarily F1/F3, but the general spirit of my proposal is: "If an in-use image otherwise meets CSD but can edited so that it 1) no longer meets CSD and 2) continues to be useful in context, then it is ineligible for CSD." I could imagine this applying to F10 as well, e.g. a selfie of a non-notable person taken with a notable person. (On second thought, I think "in use" can be expanded a bit; we can also include categories which have relatively few images. The point of this qualification is just to ensure we don't waste time trying to save images not worth saving because we have lots of similar images; "in use" is another way of saying "best in class", but "rare" should count as well.) -- King of ♥ ♦ ♣ ♠ 01:13, 25 January 2023 (UTC)Reply[reply]
    I think making it a part of multiple CSD criteria is a bad plan. F3 could be revised to cut the "it is best for such issues to be resolved in a formal deletion request" splitting the baby language and just require a DR for FoP, and de mininis cases (which these are in a way). I don't think F1 needs to be messed with except maybe "The entire content ..." at the start to make sure no one tries to shoehorn the F3 exceptions into F1 (which would still require an admin that goes along with it). The INUSE issue may be irrelevant if we adjust the procedures for these cases. Otherwise most admins I think would take a INUSE example to a DR rather than speedy it and just open themselves to the drama that would occur from that (exception being the INUSE spam walled gardens). Ricky81682 (talk) 01:53, 25 January 2023 (UTC)Reply[reply]

Create a Commonswiki Community Tech Wishlist[edit]

The "Commonswiki Community Tech Wishlist" would be a localised version of the Community Wishlist Survey.
Introduction.

I would like to propose the creation of a localised version of the Community Wishlist Survey. This survey will function largely the same as the ones that currently exist at the Meta-Wiki and German-language Wikipedia.

I also prefer not to go into too much detail, namely if it should be annual or bi-annual, if the accepted proposals should number only a few or many. Whatever the outcome of that will likely be based on the available resources.

Benefits.
  • As the Wikimedia Commons is vastly different from other Wikimedia websites the technical needs of this website are also vastly different, something that positively affects the Wiktionary can also be used to help Wikipedia and Wikisource, but as this website primarily deals with multimedia its needs require more specialised proposals to deal with them.
  • Because of the much larger communities at various language Wikipedia's proposals dealing exclusively with issues faced by contributors and re-users of the Wikimedia Commons will likely not get upvoted much in a global survey, meanwhile these would receive proper discussion in a localised wishlist.
What this proposal isn't.

This proposal only exists to establish local consensus to have such a survey, it does not guarantee its establishment nor implementation. If approved we could use this proposal to show that local consensus exists. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:49, 24 January 2023 (UTC)Reply[reply]

Votes (Commonswiki Community Tech Wishlist)[edit]

Discussion (Commonswiki Community Tech Wishlist)[edit]

  • Obviously this wouldn't be for this year or maybe even next year, this proposal mostly exists to show both the Wikimedia Foundation (WMF) and Wikimedia Germany (WMDE) that the Wikimedia Commons needs specialised technical support that it simply isn't getting from the global community. At the Meta-Wiki survey the Commonswiki is only one (1) category like this but here we could have multiple copies for multiple specialisations like categorisation, uploading, deletion, undeletion, importing, simple maintenance (basically asking for unmaintained tools to be adopted by the WMF and / or WMDE if they're willing, for example the countless of issues with Flickr2Commons and Video2Commons), Etc. The proposal has to be this general because all the specifics would have to be negotiated with the Wikimedia Foundation (WMF) and / or Wikimedia Germany (WMDE) what is possible based on their resources. But if nobody here says "hey look, this project really needs some help from software developers" then our issues won't get fixed. We often run into technical problems here only to find out that the Commonswiki only receives the bare minimum to support it. Old features are rarely maintained, new features are rarely implemented, and some issues have been talked about for years without anyone addressing them. There currently doesn't seem to be a general software feedback nor feature suggestions portal at the Wikimedia Commons, meanwhile technical proposals that have been approved by the community get archived and nothing happens because nobody with the technical skills to make them happen is implementing them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:49, 24 January 2023 (UTC)Reply[reply]
  • The Community Tech Wishlist has dedicated staff and funding behind it. Are you proposing requesting a grant to fund a separate wishlist for Commons? Or would this wishlist just be a list of things Commons needs, which volunteer developers may wish to address? — Rhododendrites talk |  14:17, 25 January 2023 (UTC)Reply[reply]
    • @Rhododendrites: , if possible I would like to request the WMF and / or WMDE to dedicate some resources towards this project as many tools are either unmaintained or have bugs caused by changes in the MediaWiki software itself. I think that volunteer developers should also be used but I have no idea how and where to request them to aid with these things, from what I've seen volunteer developers can also help with items on the existing community tech wishlists on other Wikimedia websites. Even if neither the WMF nor the WMDE would dedicate their resources to this it would still be a good roadmap for volunteer developers to show which technical matters are most pressing. For example I've seen multiple complaints in the Village pump regarding Flickr2Commons not detecting duplicates in some cases but then very little is done to improve the software, but if the software here can detect it why can't we just add the same technology to Flickr2Commons? My guess is that the people with the technical know-how simply don't know about this issue at all or may not know how pressing it is due to not enough people reporting on it. Currently there's no feature request hub at the Wikimedia Commons and even if someone would propose a feature here it's unlikely to actually get picked up by the people with the technical skills to do so, perhaps due to them not being aware of it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:18, 26 January 2023 (UTC)Reply[reply]
    YES, please create a community-backed system for defining technical improvements that the community needs and request resources for implementing these. -- Zache (talk) 17:07, 27 January 2023 (UTC)Reply[reply]
  • Why would we need a whole seperate Wishlist when we have meta:Community Wishlist Survey 2023/Multimedia and Commons ?, I appreciate it's not on Commons itself but then neither is EN things as far as I know. –Davey2010Talk 22:02, 25 January 2023 (UTC)Reply[reply]
    • "I appreciate it's not on Commons itself but then neither is EN things as far as I know." The main issue is that the number of active editors on other Wikimedia websites far outnumber Commonswiki contributors, Active users of the Wikimedia Commons (Users who have performed an action in the last 30 days) currently number 37,254, compare this with the 125,895 of the English-language Wikipedia, meanwhile the the German-language Wikipedia only has 19.240 active users yet has its own community tech wishlist, this doesn't prevent users from voting and proposing in both. The Meta-Wiki's wishlist doesn't have to change either, as multimedia still affects other Wikimedia websites, but it doesn't affect them in the same way as here as they don't import or work with the same tools as we do. The main difference is that tools that work on Wikipedia often work on other written content-based projects, what affects the English-language Wikipedia also affects the Arabic-language Wikipedia, Croatian-language Wikipedia, Persian-language Wikipedia, Urdu-language Wikipedia, Etc. Meanwhile the Wikimedia Commons is the second (2nd) largest Wikimedia website by active users (behind the English-language Wikipedia and ahead of Wikidata with 24,415 active users), despite this almost all Foundation resources go to Wikipedia's and Wikidata and this is because the unique needs of this website aren't properly addressed through the current method. Just look at the recent open letter to the Wikimedia Foundation (WMF) entitled "Think big - open letter about Wikimedia Commons", most of the points listed in this letter are technical in nature and after almost a decade of there being a community tech wishlist at the Meta-Wiki these still aren't properly addressed yet. Another advantage is that less pressure on Commonswiki technical issues will allow the issues of smaller projects to have more chances to succeed at the Meta-Wiki list as well. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:35, 26 January 2023 (UTC)Reply[reply]
    • Pictogram voting comment.svg Addendum to my comment immediately above, the 2020 wishlist also specifically excluded the Wikimedia Commons from its scope, and the entire top 10 (ten) of the 2022 survey only includes a single item from the "Multimedia and Commons" category and this entry even reads "Problem: SVG images are currently rendered as scalar images before being displayed in Wikipedia articles, because at the time SVG support was added, many browsers could not reliably display SVGs." (emphasis added), so the only "winning" proposal in this category primarily affects Wikipedia users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:42, 26 January 2023 (UTC)Reply[reply]
      • What about making a coordinated effort to use the community wishlist, and then use anything that doesn't get selected as a list of things we need. WMF has said they're going to be investing in Commons (see Commons talk:Think big - open letter about Wikimedia Commons, for example), and that could act as a roadmap without trying to start a separate wishlist project. Roadmap is fine, but starting a separate effort seems a bit much IMO. — Rhododendrites talk |  13:01, 26 January 2023 (UTC)Reply[reply]
      Thank you for your in-depth and helpful reply Donald, When you put it like that it does seem that Commons is being left behind, I want to support but do we really have enough people to make it work ?, Not that it's relevant but COM:POTY has been suffering as of late (there was a discussion on this somewhere) - If POTY is suffering what chance does this have ?, –Davey2010Talk 15:29, 26 January 2023 (UTC)Reply[reply]
        • "Roadmap is fine, but starting a separate effort seems a bit much IMO." Well, the current proposal is a bit vague, I don't think that they're mutually exclusive so honestly I think that a Commonswiki Community Wishlist might work different from the Meta-Wiki and German-language Wikipedia versions, replying to both comments, I think that a good way to implement it would be to have an indefinite technical feedback / suggestion infrastructure modeled on the Meta-Wiki and German-language Wikipedia community tech surveys where rather than having a fixed period of time where users can first suggest and then vote for new features this one would be more dynamic. I'll write the implementation below. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:15, 26 January 2023 (UTC)Reply[reply]
  • Going on what I wrote directly above this comment I thought that a good way to implement the hypothetical Commonswiki Community Wishlist would be by being both dynamic (users could suggest new features and proposals at any time) and indefinite. This version would have a "Top 10 (ten) most requested features" and an option to see all (open) suggestions based on popularity and a separate top 10 (ten) based on category. This would also shown volunteer developers which features are the most requested by the community and which bugs require the most immediate response (think the Flickr2Commons tool not properly detecting duplicates for example).
This would actually be a dynamic community-driven request list, we could ask the Wikimedia Foundation (WMF) and Wikimedia Germany (WMDE) to help us but this would not be expected, if neither the WMF nor the WMDE would want to invest their resources into these suggestions it would still be a list that volunteer developers could work on.
This would then be an easy community feedback mechanism where all users, be they novice or experienced, could suggest and discuss technical ideas to improve the software and make the Wikimedia Commons easier to use.
There would also be archives, implemented proposals would have their own archive (based on category) and withdrawn (including duplicate) proposals would also have a separate archive (also, per category) similar to how administrator requests are archived here today.
The individual suggestion pages ("proposals") would also be a place where volunteer developers could discuss them with the wider community bridging the gap between the contributors and the developers. This would make it separate enough from the WMD-funded and WMDE-funded wishlist surveys to be its own thing. If a proposal here has like 80 (eighty) votes and hasn't been worked on in a year then it would make sense that someone could suggest it at the Meta-Wiki for the WMF to take it over if no volunteer does it here, this could make this list a launch platform for future proposals that could be implemented by paid developers if no volunteers pick it up, but rather than being an annual or bi-annual closes survey this dynamic survey would be able to evolve with the project and remain open for engagement and discussion at any point of the year. I hope that I've worded what I'm trying to suggest clear enough. If this seems too different from the above proposal I can withdraw it and then make a clearer proposal based on the revised implementation above.
I also think that the above idea would work quite well on Wikidata as it's also a tech-heavy Wikimedia website with little overlap in its toolkit with other Wikimedia websites but that's an entirely different discussion.--Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:27, 26 January 2023 (UTC)Reply[reply]

Importing works of John Fielder[edit]

To stay brief, John Fielder, Celebrated Nature Photographer, Donates Life’s Work to Public Domain. Surely this should be imported into Commons, shouldn't it? Psychoslave (talk) 18:29, 29 January 2023 (UTC)Reply[reply]

Looks like it was donated to Category:History Colorado. Anyone have any experience or want to start a connection with the museum? I imagine that would be a lot better than just grabbing the images and trying to guess when or what he was photographing. Ricky81682 (talk) 21:58, 4 February 2023 (UTC)Reply[reply]
Where is the evidence of a Commons-compatible release? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:04, 6 February 2023 (UTC)Reply[reply]

Proposal: Improve Toolhub coverage of Commons tools by improving on-wiki tool documentation[edit]

Toolhub is a community managed catalog of software tools used in the Wikimedia movement. Technical volunteers can use Toolhub to document the tools they create or maintain. All Wikimedians can use Toolhub to search for tools to help with their workflows and to create lists of useful tools to share with others. You can read more about Toolhub in general on meta.

The Technical Engagement team is interested in talking with active contributors to Wikimedia Commons about finding more ways for the Commons community to use Toolhub. We are interested in having more tools that are helpful for workflows on Commons listed in Toolhub and for those tools to be more discoverable to folks who are contributing to Commons.

We think that updating Commons: Tools is one way to start on this problem. We are proposing a small project to build new templates and use them to make the list of tools readable by a bot.

If you are interested in discussing our proposal, or if you have your own idea to propose improving Toolhub integration with Commons, please join the conversation at Commons talk:Tools. Udehb-WMF (talk) 15:41, 31 January 2023 (UTC)Reply[reply]

Silence is approval ;) Be bold, revert where needed and discuss. —TheDJ (talk • contribs) 22:06, 21 February 2023 (UTC)Reply[reply]

Please, make your programs complete[edit]

When someone publishes a spoof photo on Wikimedia, the bot puts a notice on the deletion request page (delete2) and the log page (delete3), but the programming remains unfinished. Why should I go to the scammer's site to explain that you have cheated? The picture in question is here and it doesn't show a platypus. Could you complete the program so that many users do not have to do unnecessary visits? I also refer you to the request: "Also, you may want to check the Wikimedia projects that use this item, and then remove or, if possible, replace with a better item." - This was unnecessary text. Maybe you yourself are willing to replace the scams with superior pictures so that you don't leave it to others to do. Jari Rauma (talk) 12:59, 5 February 2023 (UTC)Reply[reply]

For the record, the bot did notify the uploader of your deletion request. It's just that Rudolphous removed that message from his talk page. So I don't see how any programming on the Commons side would be incomplete. De728631 (talk) 13:54, 5 February 2023 (UTC)Reply[reply]
Yes, you are right. The program seemed to have worked correctly, but the user deleted the message. So it's pointless for me to report to him about a note, even though such a prompt is in Wikimedia's instruction, which is therefore incorrect. Jari Rauma (talk) 14:29, 5 February 2023 (UTC)Reply[reply]
It is not incorrect, nor is it pointless to notify them. By removing the note, they are essentially certifying that they have seen it. The system is working correctly, as far as I can tell. — Huntster (t @ c) 14:43, 5 February 2023 (UTC)Reply[reply]
Hello from Finland! Huntster, you Anglish-master, the computer program did a good job of sending a message to the person. But I said, "it's pointless for me to report him. Please, don't change my words and subject. What is the logic behind your refuting your own words? When you answer this, we can discuss the meaning of the word "incorrectness". Jari Rauma (talk) 17:33, 5 February 2023 (UTC)Reply[reply]
@Jari Rauma: What bot? 2001:2003:F659:2D00:E192:F316:55C7:8830 used the QuickDelete gadget to tag File:Ornithorhynchus anatinus (37786073842).jpg for deletion, in the process notifying the uploader. Why do you feel compelled to follow instructions that were already followed?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 07:33, 6 February 2023 (UTC)Reply[reply]

Change UploadWizard feedback link[edit]

proposal: change the "Leave feedback" link on Special:UploadWizard from Commons:Upload Wizard feedback to Commons:Village pump.

reasons:

  1. Commons:Upload Wizard feedback is a dead page.
  2. the frequency of users' feedback is roughly a few times every month, so it's not expected to cause congestion on village pump. directing users to the most active public discussion page is good enough.

RZuo (talk) 17:23, 6 February 2023 (UTC)Reply[reply]

as for why it doesnt link directly to phab: phab:T209336.--RZuo (talk) 19:27, 6 February 2023 (UTC)Reply[reply]

  • Symbol support vote.svg Support = Feedback page has 261 watchers[1], VP has 3,225 watchers so not only would they recieve a reply much quicker there but they'd also recieve an actual reply as opposed to potentially being ignored (of course that could happen here too but it's highly unlikely), Makes sense, Easy support. –Davey2010Talk 17:37, 6 February 2023 (UTC)Reply[reply]
  • Symbol support vote.svg Support Village Pump definitely has more eyes on it, and certainly Upload Wizard should be fixed so uploaders are properly educated about Creative Commons licenses. Abzeronow (talk) 17:26, 7 February 2023 (UTC)Reply[reply]
  • Symbol oppose vote.svg Oppose VP is a good place for blowing off steam, but most actual problems should go either straight phabricator or to COM:VP/T. The current solution with a box explaining the different options is the better one, imho. Just remove everything else from the page so nobody thinks they're supposed to leave feedback right there. Essentially turn it into a landing page that redirects users to the right place for their problem. Also, change "Leave feedback" to "Report a problem" on Special:UploadWizard. WMF is not looking for feedback on the design of the whole thing any more, and in any case VP would be the wrong place to propose any changes. --El Grafo (talk) 08:12, 8 February 2023 (UTC)Reply[reply]
@RZuo, Davey2010, Abzeronow, and El Grafo: Why should we continue to feed into the myth that WMF developers care about feedback on the Upload Wizard?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:35, 12 February 2023 (UTC)Reply[reply]
Upload Wizard definitely needs some adjustments so uploaders don't put clearly public domain files as Creative Commons 4.0 files and adjustments could prevent this, and if WMF devs don't see this as a problem that needs fixes, then we should make sure feedback on that problem is in a forum with as many eyes as possible. Abzeronow (talk) 16:41, 12 February 2023 (UTC)Reply[reply]
When will we learn that most ppl dont care and understand. They have a goal and want to achieve it, they dobt care about rules. They need time to learn them. Give ppl time to learn. —TheDJ (talk • contribs) 22:04, 21 February 2023 (UTC)Reply[reply]
@Jeff G. what's your point? They consider it complete and have moved from active development to maintenance. That doesn't mean we shouldn't help people with solvable problems at VP/T. That also doesn't mean that we should stop reporting bugs at phabricator. What it does mean is that the feedback page is obsolete because feature requests posted there won't be read. Feature requests made on phabricator likely won't be answered either, but at least they can't claim they didn't see them. El Grafo (talk) 07:44, 13 February 2023 (UTC)Reply[reply]

Add "upload log" link to heading of mass DR on user[edit]

for example, Commons:Deletion requests/Files uploaded by Panoramio upload bot is for user:Panoramio upload bot. every heading has the format ".. (talk · contribs)".

i propose adding "upload log", that is, the format becomes ".. (talk · contribs · upload log)". the link will be [[Special:Log/upload/username]]. the link lets DR participants go straight to check a user's upload history, see how many red links there are...

to do this:

  1. on MediaWiki:Gadget-VisualFileChange.js/core.js, insert mdUploadlogPrefix: mw.config.get( 'wgFormattedNamespaces' )[ -1 ] + ':Log/upload/', after line 1892.
  2. on MediaWiki:Gadget-VisualFileChange.js/ui.js line 995, change '|contribs]])'; to '|contribs]] · [[' + vfc.mdUploadlogPrefix + target + '|upload log]])';.

RZuo (talk) 16:11, 11 February 2023 (UTC)Reply[reply]

Commons:Mobile app: Zusammenarbeit von Wikimedia Commons und OpenStreetMap / Wikimedia Commons and OpenStreetMap collaboration.[edit]

de:

Mit der Commons App einfach Bilder aufnehmen und automatisch mit Objekten in OSM verbinden.

Idee des Prozesses:

  • mit Commons App in OpenStreetMap Karte hinneinzoomen
  • Objekt auswählen
  • mit Commons App Foto aufnehmen
  • Das Foto wird veröffentlicht
  • anschließend wird im Knotenobjekt in OpenStreetMap unter Details der Schlüssel „wikimedia_commons“ mit dem Wert „File:Bildname“ hinterlegt

en:

Easily take pictures with the Commons app and automatically connect them to objects in OSM.

Idea of the process:

  • zoom into OpenStreetMap map with Commons app.
  • Select object
  • take a photo with Commons App
  • photo will be published
  • then the key "wikimedia_commons" with the value "File:Image name" is stored in the node object in OpenStreetMap under Details

see also: Commons:Mobile app/Feedback – Wikimedia Commons Molgreen (talk) 15:54, 12 February 2023 (UTC)Reply[reply]

Write from Commons directly into OSM dataset[edit]

Or another idea: would it be conceivable to write from Commons directly to the OSM database. Assuming you know the OSM object ID of a mapped object, you could add it like a category to the properties of the image --Molgreen (talk) 15:22, 14 February 2023 (UTC)Reply[reply]

I suspect the better route would be through Wikidata. Each Commons picture or category for which there is a WD item should have a link to that item, and each WD item that has a corresponding OSM object ID should link to that. Jim.henderson (talk) 13:58, 21 February 2023 (UTC)Reply[reply]
Unfortunately, linking from Wikidata to OSM elements has one major problem: OSM's object IDs are not permanent and can change when the map is edited. El Grafo (talk) 14:20, 21 February 2023 (UTC)Reply[reply]
Eqsily done, using https://wikishootme.toolforge.org/ -- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 21 February 2023 (UTC)Reply[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=734973234"