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/2024/08.

COMMONS DISCUSSION PAGES
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.

Proposal to add perceptual hashes to SDC

[edit]

First proposal was three support, two against. Second proposal two against. Both has couple of comments. Result from this is no-consensus for adding imagehashes using bots. --Zache (talk) 07:20, 22 August 2024 (UTC)[reply]

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 asked this first on bot permission page, where they suggested that I should make this as proposal first.

So, I propose that the addition of perceptual hash (phash and dhash) values will be extended to all images on Wikimedia Commons as Structured Data on Commons (SDC) values. Currently, values are added only to a subset of images, such as images from Finna.

Background

Perceptual hashes are checksums which can be used to identify visually identical images even if they have been scaled, re-compressed, or subjected to minor alterations. Proposed hashes are effective for detecting if the images are identical but they are not effective for detecting similarity in cases involving cropping or rotation changes. Hashes are also implementation specific and in this proposal I am using Python Imagehash library.

For example FinnaUploadBot uses perceptual hashes to:

  • Confirm that images in the Finna repository match those on Wikimedia Commons, ensuring higher resolution re-uploads and metadata updates are done to correct images in Wikimedia Commons.
  • Prevent duplicate image uploads.
  • Find existing duplicate photos.
  • Update identifiers pointing to external repositories if they have been changed.

These are common use cases for developers of mass upload tools and usage could be extended for other tools also. Adding perceptual hashes to SDC would enable users to easily access the hash values without needing to download the commons image files first, allowing for wider use of the hashes. Additionally, SPARQL queries can be used to detect duplicate photos. Example query: https://w.wiki/A6qZ

Wikidata properties to be added to images

Example images with properties P9310 and P12563.

See also

Current status

Proposed implementation

For broader accessibility, adding hash values to SDC is the most straightforward approach. As adding hash values to all 100 million photos on Commons using bots is impractical, I suggest the following approach:

  • Begin by adding hash values to photos uploaded from GLAM archives and Flickr using bots. This would create a platform for tool creators to match photos between archives and check if a photo already exists on Commons. It would also serve as a shared platform with external parties such as GLAM and Flickr Commons to develop the idea further.
  • Investigate how to implement better methods for including automatically generated information in SDC without the need for adding these using bots. Other similar automatical values could include mime type, image width, image height, file size etc.

Feedback and insights from you will be invaluable for refining this proposal. Thanks. --Zache (talk) 16:43, 17 May 2024 (UTC)[reply]

 Weak support and I agree this should ideally not be done by bots. See also Commons:Requests for comment/Technical needs survey/UploadWizardSDC. If there is interest I could add this to GLMA files as proposed with my bot. Just let me know. --Schlurcher (talk) 07:05, 23 May 2024 (UTC)[reply]
 Support: This seems to me to be a good idea. Do you have any idea how you'll handle invalidating the hashes when a user uploads a new version of a file? --bjh21 (talk) 15:56, 23 May 2024 (UTC)[reply]
One solution could be to track recent changes to index all uploads and then set the latest value as "prominent" and the rest as normal if there are multiple values. --Zache (talk) 20:38, 23 May 2024 (UTC)[reply]
 Oppose Strictly say, hashes does not provide structural information. Should be part of database + API to access hashes. --EugeneZelenko (talk) 14:02, 28 May 2024 (UTC)[reply]
@EugeneZelenko: You are actually wrong. If we can calculate similarity by comparing the hashes it contains structured information about the content they represent. --Zache (talk) 14:19, 28 May 2024 (UTC)[reply]
Hashes could not create links between items (regular properties) or external sources (identifier properties), so why they are claimed to be structural? --EugeneZelenko (talk) 14:33, 28 May 2024 (UTC)[reply]
Structured information can contain other data types than URI:s and identifiers, such as numbers, booleans, strings, timestamps, etc. In this case, perceptual hashes contain information about the content's features in a well-defined format. --Zache (talk) 14:59, 28 May 2024 (UTC)[reply]
 Support: I agree with the proposal. I already do it for the files imported by User:OptimusPrimeBot. I'm really happy to see new people interested in making things move forward for the perceptual hashes/detection of duplicates. It's still a pain to detect duplicates accurately and this proposal will help to improve the tooling. vip (talk) 22:20, 28 May 2024 (UTC)[reply]
 Oppose. There may be value, but there is also cost. My watchlist is sometimes hammered with SD additions such as this SVG file is an SVG file. Make additions to millions of files, and the cost might be millions of seconds of people's time. Glrx (talk) 16:12, 17 June 2024 (UTC)[reply]
@Glrx: FYI you can omit those changes by unticking the Wikidata box on the watchlist page. — Rhododendrites talk |  12:33, 1 July 2024 (UTC)[reply]
@Rhododendrites: That does not solve the problem. Furthermore, I want to see and correct nonsense changes to my watched files. Glrx (talk) 13:58, 1 July 2024 (UTC)[reply]
I am sure that you know, but you can also change visibility of the bot edits in the watchlist from settings. -- On more general level comment, I understand your argument, however, there is ongoing flow of files all the time and it is normal (ie. there are bot and other automated edits to categories, wikitext fixes, SDC additions) and solution for that it will fill the watchlist should not be banning those edits as it would block improving the metadata of the files, but improving the filtering/grouping of the changes so that only relevant are visible by default. --Zache (talk) 12:21, 4 July 2024 (UTC)[reply]
  •  Question did the already added hashes turn up any duplicates?
Enhancing999 (talk) 19:06, 17 June 2024 (UTC)[reply]
Sure: SDC Finna results you can see with this query https://w.wiki/A6qZ (and internal database where hashes arent limited to Finna images the number would be couple magnitudes higher) --Zache (talk) 19:59, 17 June 2024 (UTC)[reply]
 Comment Note that the Structured Content team in the WMF has a ticket for something similar phab:T362352 - not on our roadmap for this quarter, but very likely to get attention this financial year CParle (WMF) (talk) 11:52, 16 July 2024 (UTC)[reply]

Revised proposal 10.8.2024

[edit]

I planned to close this proposal after Wikimania, where I would talk with people about imagehashing. So this revised proposal is based on that and I would like to get quick poll what people think about it.

Based on the discussion above, there is no consensus for adding images by bot to SDC. One valid opposing opinion was that it would generate too many edits. Based on this current plan is to proceed by cleaning up the dataset, providing API and direct SQL access, and improving documentation which would support the upload tool development. I am also investigating how to publish the dataset for SPARQL via Ontop software. However, I still have one question related to adding information to SDC.

Would it be useful to add information about detected duplicates to SDC?

A very rough estimate is that there are 2-3 million photos in Commons that are almost identical. (Sample images: https://w.wiki/Asxj) The estimate contains many false positives and negatives and legimate duplicates. Added SDC properties would describe the relation between images and how the relation was detected. This would allow users to query duplicate images and support cleanup/organizing tasks.

Added properties could be like

... and qualifiers

If this is supported, the following steps would be to discuss it on the SDC modelling talk page to define and document how related photos should be described in SDC and then request the bot permission for the task. @Schlurcher, Bjh21, EugeneZelenko, Don-vip, Glrx, CParle (WMF), and Enhancing999: --Zache (talk) 09:52, 10 August 2024 (UTC)[reply]

  •  Oppose. I looked at the earlier query a long time ago, and I just looked at the recent query. I am underwhelmed. TIFF and JPEG duplicates are deliberate and well known. Book titles that vary in capitalization can be found with text searches -- not necessarily to locate duplicates for clean-up but rather for users to locate material they are interested in using (a core function of Commons). If I'm searching for a particular image, then I'm happy if I find two or three or even more. If the titles are descriptive enough, then I might find them. Yesterday, I was looking at Category:Harper & Brothers logos; there are near duplicates there, but if I find one of those files, then I've found all in the category. To measure value, I need to see how much value these properties add and how much it costs. Near duplicates do not bother me. That takes me to another point: is there a need for deletions? So what if Commons has 1 million near duplicate files? If everything works, are we going to burden the community with 1 million DRs? The biggest benefit might be pairing images and merging their information. One image might have a good description but poor source information; a matching image might have a poor description but detailed source information. How frequent is that scenario? I need to see the benefits and the costs. Right now, I'm seeing lots of bot automation with a high human cost but little benefit. Glrx (talk) 14:29, 10 August 2024 (UTC)[reply]
    Information that one image is same than some other is needed also to other things to deletions. One relevant use case is just to be able query what is there and filter out duplicates in results. Another one is to be able to sync and compare metadata between files. About deleting images, afaik, my guess is that any deletion would be focused on smaller sets. Ie. on cleaning up specific category/author/collection, not in million photos level. --Zache (talk) 15:17, 10 August 2024 (UTC)[reply]
    There are obviously different points consider, but I found
    "but if I find one of those files, then I've found all in the category."
    somewhat funny, as it tend to add duplicates to the same category, because they hadn't been identified before. The other day, I did find a category full of duplicates, but haven't decided what to do about them. (It was by date of photography category). Enhancing999 (talk) 17:33, 10 August 2024 (UTC)[reply]
  •  Oppose. I think this belongs to Commons database. --EugeneZelenko (talk) 14:57, 10 August 2024 (UTC)[reply]
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.

Introduce new non-file deletion right

[edit]

Processing deletion requests on empty or moved categories is a very often needed but not very critical task that has to be limited to admins. Therefore I would propose that we introduce a new right that allows trusted users to delete categories, galleries and (if possible) own user pages. GPSLeo (talk) 17:09, 24 May 2024 (UTC)[reply]

I don't think this is technically possible. Per mw:Manual:User rights, it doesn't appear that rights like "delete" can be restricted to specific namespaces. (And given that pages can be moved between namespaces, it's not clear that any such limitations would be effective.) Omphalographer (talk) 03:58, 26 May 2024 (UTC)[reply]
It is currently not possible but we need consensus that we want this feature before we can request the development that is requited to enable such a feature. GPSLeo (talk) 16:36, 26 May 2024 (UTC)[reply]
Of the last 5000 (un)deletions, >90% were files; just 371 (7.4%) were categories, 3 (0.06%) were user pages, 8 (0.16%) were templates, and <10 were galleries. While I have no objections on principle to unbundling deletion rights, this doesn't seem like it would address any deletion backlogs. It would probably be better to focus our energies on cultivating well-rounded users who would make good admins. Pi.1415926535 (talk) 05:34, 28 May 2024 (UTC)[reply]
 Support although not technically possible atm, we can request a phab task. Maybe ability to delete everything except files and MediaWiki stuff (similar to eliminator right on some wikis) is a better idea. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 15:45, 12 June 2024 (UTC)[reply]
  •  Oppose No concept shown. Who appoints them, what is the requirement? Can the delete only, or also restore and view deleted versions? If or if not, how is this helpful, and why don't they become regular admins? --Krd 18:02, 20 June 2024 (UTC)[reply]
  •  Oppose No satisfactory answer to my question above. I'd be happy to entertain an RfA from someone that does category work and wants the mop to do categories for deletion closing, though. The Squirrel Conspiracy (talk) 05:54, 30 June 2024 (UTC)[reply]
I could certainly use it. I doubt anyone would give me full privileges just to delete categories though. Nor would I even necessarily want them. --Adamant1 (talk) 06:04, 30 June 2024 (UTC)[reply]
  •  Oppose, a lot of users I've seen have an annoying habit of tagging good alternative titles for categories as speedy deletions (such as old names for a building or alternative names for a place in a different language), it's also not uncommon for people to empty useful categories and then tag them for speedy deletion as "useless empty categories". This user right will only make this type of behaviour worse. We need more useful redirects, not less. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:58, 19 July 2024 (UTC)[reply]
@Donald Trung: You happen to know much redircts effect load on the database like normal categories do? Because if they do have any effect it seems like the amount of categories that currently exist cause a lot of problems with the database and I think you could argue a lot of redirects are totally useless. I know I've seen plenty of them myself that probably aren't worth retaining. Putting aside ones for alternate names for things in different languages of course, which are probably worth retaining but at least from what I've seen make up only a small amount of redircts. --Adamant1 (talk) 15:31, 10 August 2024 (UTC)[reply]
@Adamant1: The complaints we get from the sysadmins don't relate to the number of categories, but to the number of category links: phab:T343131. That is, the number of connections between pages and categories that they're members of. Nothing should be a member of a category redirects, so category redirects are no more expensive than any other kind of page. If we wanted to make category redirects cheaper, removing them from Category:Category redirects would save 760,000 links, as would turning them into normal redirects. --bjh21 (talk) 17:14, 10 August 2024 (UTC)[reply]
 Oppose dont need so many kinds of cleaners. RZuo (talk) 16:15, 1 September 2024 (UTC)[reply]

Adding a level mechanism for gamification

[edit]

For specific actions you execute, you earn points that rank up your level. This could motivate users to keep contributing. Points could be earned for files in use, promotions as Quality Image or Featured Picture, and contributing for a comfortable climate, or by helping other users.

The idea might seem unconventional, but I would like to know what the point of view is here. :)

Greetings! --PantheraLeo1359531 😺 (talk) 11:11, 5 August 2024 (UTC)[reply]

 Support overall but the details are debatable. This is why I was requesting making the Leaderboard and Achievements pages of the Commons app available on desktop too and then extending these to also consider other metrics all of which are similar to what you suggest here and/or could be used for such. Note that points can incentivize problematic things like adding media to lots of Wikimedia pages where they aren't useful, nominating way too many pictures, and so on. It's not an unconventional idea, it's quite logical and plausible that such things can motivate users and lots of other sites have such to facilitate user contributions for good reasons so nothing about it is unconventional. Prototyperspective (talk) 11:59, 5 August 2024 (UTC)[reply]
Yes, I think details should be discussed separately :) --PantheraLeo1359531 😺 (talk) 13:51, 5 August 2024 (UTC)[reply]
If we do anything like this, we need to be very careful to structure it in a manner where you cannot score points by doing things that are, in fact, counterproductive. We have had bad experiences such as a contest for adding "depicts" that rewarded adding bad "depicts" values to an image, or flipping back and forth over and over between a pair of values. Plus, we also need to be aware that whatever we reward will probably be done more, even at the expense of other things being done less.
Also, it needs to be an opt-in system. I'm sure I'm not alone in not wanting my actions here "scored" against some more or less arbitrary set of criteria. I want to work on what I think is important, not what some algorithm things is important. - Jmabel ! talk 21:56, 5 August 2024 (UTC)[reply]
 Oppose Sometimes gamification has benefits, but there's a huge risk of people making unhelpful edits just to rack up points. There's already enough ways to reward people for their contributions anyway. Plus I'm also not a fan of how things like edit counts and length of memberships are usually used on projects like these to either give people a pass for bad behavior when both are high or demean new users when they are low. Do we really need yet one way more thing people can do that with? Probably not. If people want another example of where this can and often does go wrong look into how many images are uploaded by people participating in Wikiloves Monuments events that just end up getting deleted as COPYVIO. A good percentage of the time people just participate in the events for clout, which leads to more work on our end. Anyway, If anything we should get rid of edit counts and account creation dates on the User contributions page. --Adamant1 (talk) 23:20, 6 August 2024 (UTC)[reply]
  • I had the idea on creating something I would call "Wiki Loves Allstars" or just "Wiki Allstars" where there are badges for thinks like "take photos of 100 differnt lakes" for one level and "take photos of 1000 lakes for the highest level" or "take photos of all townhalls in Berlin". But that is hard to count with the category system, that would only work with structured data. GPSLeo (talk) 05:17, 7 August 2024 (UTC)[reply]
    Good idea! --PantheraLeo1359531 😺 (talk) 17:04, 9 August 2024 (UTC)[reply]
  •  Oppose As we know from experience with FP, QI, Wiki Loves xxx, Photo Challenge etc.pp., more competition among users does not necessarily add more quality where this is really needed, but instead more drama potential where it's definitely not needed. --A.Savin 06:14, 7 August 2024 (UTC)[reply]
    These are all about competing candidates for some recognition. But gamification mechanisms do not necessarily involve these – people simply get stats for their positive contributions and maybe things like badges based on them, so unlike these competitions there aren't 'winners' and 'disqualified or nonwinning' entries. One could build it to precisely increase quality where this is really needed, there is not one kind of gamification and maybe that's the wrong term here anyway.
    Secondly, why doesn't WMC abolish these photo challenges then? I think they are distracting, misrewarding and misplacing focus – by now there are photos for nearly everything (at least when it comes to what these challenges are about). At the same time, illustrations are missing for very many even quite large Wikipedia articles even when those would be much more educational and helpful for readers to understand the subject. Currently, we have stats & leaderboards for the wrong or too simplistic things (like edit counts) and challenges for things that aren't that constructive (anymore). Building this more deliberately would enable a more nuanced and intentional approach that facilitates the site to become more useful, close gaps, keep people engaged or to join, and raise quality. Prototyperspective (talk) 16:54, 15 August 2024 (UTC)[reply]
 Oppose at least for now. Similar concern with Adamant1's. The intent of the idea is good, but only invites media files that will eventually be either speedily-deleted (if either obvious stolen Internet pictures or out-of-scope personal or self-promotional files) or nominated for deletion (if the files show recent monuments from 100+ countries that do not allow or permit commercial panorama exception). Provided that around 50 more major countries (the likes of Romania, Philippines, Taiwan, Indonesia, and/or UAE) reform their laws to accept commercial uses of their public buildings and monuments (buildings+3D works at least), and that we gain the ability to efficiently filter obvious COPYVIOS or out-of-scope files, I'll be open to this suggestion (at least "weak support"). JWilz12345 (Talk|Contrib's.) 08:28, 7 August 2024 (UTC)[reply]
 Comment short of any broad gamification, I think it would be great if someone wanted to put in the work to create targeted, judged competitions of various sorts. E.g. one specific to self-taken pictures suitable to illustrate some selected set of Wikipedia or Wikivoyage articles that currently lack illustrations (or that lack good illustrations). That might be specifically confined to ones where we know there shouldn't be an FoP issue. Or a judged competition to make new gallery pages (or to improve ones that currently have ten or fewer images). The issue is to have a group willing and able to (1) set an appropriate goal, (2) publicize the competition, and (3) judge the results. But they need to be things focused on quality, not quantity. - Jmabel ! talk 18:50, 7 August 2024 (UTC)[reply]
Thank you for your comments, there are several good opinions in my mind :) --PantheraLeo1359531 😺 (talk) 17:04, 9 August 2024 (UTC)[reply]
  •  Comment, I'm all for user recruitment and user retention and I genuinely think that there could be good models for gamification, but this would have to be an opt-in system. Overall, the best "prize 🏆" is that you know that your educational works will help other people learn new things, so I can't fully support such a system. However, the main issue with an opt-in system is that it won't have a wide reach, it kind of reminds me of that Wikipedia "video game" where new users can get points and rewards for doing things, while writing this comment I found it here where this video game is called "The Wikipedia Adventure", I believe that it's some sort of tutorial game and that could be helpful for newbies, but there are unfortunately also a lot of negative side-effects to gamification. We already have competitive games at the Wikimedia Commons with even real life rewards and even cash prizes, namely photo challenges.
If we'd introduce gamification we should probably do it in fields like Structured Data for Wikimedia Commons (SDC) or categorisation before we would bring it in the domains of content creation and / or deletion. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:18, 9 August 2024 (UTC)[reply]
 Oppose gamification = enshittification. Only enshittification at least has the excuse of benefiting investors; why spread this cancer to a non-profit? What’s next, wiki-NFTs? Dronebogus (talk) 00:11, 10 August 2024 (UTC)[reply]
It is wonder NFTs didn’t take off after this! ;)
I also oppose gamification, would cause more problems than it tries to solve. Bidgee (talk) 02:04, 10 August 2024 (UTC)[reply]
This is why I’m glad Jimmy Wales has taken a hands-off approach to WM in recent years instead of using it as a vehicle to advance some weird ideological agenda like Elon Musk and Xitter or Larry Sanger and his half-dozen anti-Wikipedia pet projects. Dronebogus (talk) 07:58, 10 August 2024 (UTC)[reply]
+1 to that, Dronebogus. --Enyavar (talk) 12:28, 14 August 2024 (UTC)[reply]
No exaggeration please, there is no mentioning of NFT --PantheraLeo1359531 😺 (talk) 12:08, 14 August 2024 (UTC)[reply]
{Explanation for why these two things would be the same missing} To answer your question, for example because it would motivate people, make contribution more engaging, retain contributors, and increase the quality or availability of content. NFTs and investors have nothing to do with this at all. And constructive contributions quantifications are exactly in line with being a nonprofit and a diametrical approach than monetary return you refer to with NFTs, investors and enshittification. This would address enshittification if anything. For that and in general, it wouldn't be good to positively acknowledge things like quantity of files uploaded – instead one could show number of files in use, number of original files in use, and number of files fulfilling media requests (closing any of the many gaps in free media). There are potential problems like people putting files into use that are not adequate but I don't think it would be a large problem and it can be addressed. Prototyperspective (talk) 16:32, 15 August 2024 (UTC)[reply]
  •  Oppose as well, as per Adamant1. I have once participated in a Fandom-Wiki, where gamification was included, and it led to stupid things like awards for editing 100 articles the same day, and for editing at least once each day for a year. Awards for uploading images, for creating stubs, etc. While I think that the 10 most active users were genuinely interested in improving the content, we were competing for who got the most awards; and that may have been intimidating for newcomers who got demeaning starter awards with little chance to "catch up" on the leaderboard unless they rush-edited their way into it, or unless the big fish got lazy. At least nobody patronized or bullied the "lower ranks", but it was a pretty little harmonious community after all. The most benefitial effects for gamification of a wiki are: a) starting an entirely new wiki from scratch, quick. Or b) improve newcomer retention (and then you must cut off scoring rather early, to make clear that the game is not the purpose). --Enyavar (talk) 12:28, 14 August 2024 (UTC)[reply]
    What makes you think the gamification would be similar to Fandom Wiki's instead of well-thought out? And it is not intimidating for newcomers but engaging and motivating if they get badges for reasonable tasks. Why would the gamification points be the purpose, people see quantifications of their contributions, and most wouldn't see any sense in trying to get the points for the points sake with nonconstructive edits which would quickly get detected anyway. Prototyperspective (talk) 16:19, 15 August 2024 (UTC)[reply]
  •  Oppose any kind of "For specific actions you execute, you earn points that rank up your level" system for risking perverse incentives from the minority of players who care more about the points than the actions. I've recently been clearing up behind this year's meta:Wikipedia Pages Wanting Photos, where novice users are offered prizes for adding as many Commons images as they can to Wikipedia each July and August; it means well, but you can guess what the side effects are.
I'd rather see a more engineered game system where useful, mundane Commons tasks (confirming categories, rating new uploads for issues, etc) could be processed through an engaging but unscored interface. --Belbury (talk) 17:43, 15 August 2024 (UTC)[reply]
The other day someone told me that I was probably working in a particular area just to easily increase my edit count. Not that I was, but some people do have that mentality and thing like edit counts are clearly a point of contention sometimes. Why add other stuff on top of it? I don't really feel like getting insulted by some thin skinned user just because I happen to get some stupid badge as part of normal editing. Although things like that could be mitigated by making the gamification private to the user, but then it kind of defeat the purpose to do the gamification that way. Regardless, we should be doing things to decrease the toxic and petty reactionary nonsense on here, not increase it. --Adamant1 (talk) 11:44, 26 August 2024 (UTC)[reply]
Then people don't look at irrelevant edit counts when considering other people's contributions which is just one way this can be used alongside for example motivation and general interest in one's own contributions. I think the case you describe is / would a very rare case and isn't a problem and when it comes to userfriendliness the least significant issue. Not only does such an example carry less relevance when it comes from you by whom I have heard many insults including against me and which may have facilitated this rare example you cite, but when a welcoming atmosphere is the subject, this would very much increase the positive atmosphere here and provide more feedback to users. The clearest cases of what could be described as toxic and petty reactionary nonsense that I witnessed here came from you so this is a quite strange comment.
In any case, I came to comment replies in this thread too late and the starting comment is quite suboptimal, for instance in that it's about monolithic points rather than different kinds of stats that one can look at separately. Prototyperspective (talk) 12:24, 26 August 2024 (UTC)[reply]
I mean, sure I can be petty sometimes. That's a different then if the pettyness is specifically based on arbitrary things like a person's edit count or gamification though. Which is what my example and this discussion has to do with. Personally, I don't tend to insult, put down, or badger people based on arbitrary things like how many edits they have or how long they have been a user for. Maybe that's your jam though. I don't really know or care, but it is an issue and that happens pretty frequently on these types of projects.
Even outside of Commons literally 99% of the way people handle things on Wikipedia is by looking at a users edits, account age, and then acting according based mostly (if not totally) on that information. Same for Wikidata and I image a lot of other user editable websites. The main reason people like you, me, and a few other users involved in this discussion haven't been indefed at this point is because we are valuable contributors (however that's being judged). It's certainly not because of our upright, civil behavior or whatever lmao. It doesn't magically stop being something people tend to do or judge people on just because the person your responding to acts petty sometimes either. Sorry. Enjoy the cope though. --Adamant1 (talk) 14:39, 26 August 2024 (UTC)[reply]
literally 99% of the way people handle things on Wikipedia is by looking at a users edits, account age, and then acting according based mostly (if not totally) on that information Doubt to say the least. Prototyperspective (talk) 14:44, 26 August 2024 (UTC)[reply]
  •  Oppose This will almost certainly incentivize the wrong kind of behavior. We already have contests, barnstars, etc. and let me go on the record (again) as stating that editcountitis is silly. —Justin (koavf)❤T☮C☺M☯ 12:33, 26 August 2024 (UTC)[reply]
 Comment Complementary to my pro here are some challenges to this that could be considered coherent arguments against, specific to WMC, and may be of interest (incomplete list, each problem with some thoughts on potential remedial approaches):
  • People are facilitated to make changes (such as uploading files or adding their files to Wikipedia) for the sake of increasing their stats/points/badges/levels which can result in more problematic contributions
    • The things shown would need to be well-selected (like "Number of images in use on a Wikipedia" instead of "Number of files uploaded") and fine-grained (like "Number of files categorized" instead of "Edit count"). If we implement this intentionally then this can be done. It can't be done well if stats and contributions metadata are just some byproducts. Secondly, this would be noticed (for example by complementary stats of how large the share of self-uploaded files put into use only by the uploader) and considering results of similar features doesn't seem likely to be a big problem, especially when also considering the advantages in the context of Wikimedia projects that have a large lack of active editors and partly declining activity/users. Third, they would be shown separately so if a user intentionally or unintentionally propped up some contribution evaluation like "edit count" then the other ones can be looked at (also by the users themselves) or be considered as context when looking at a user's contributions to this volunteer project.
  • A lot of constructive contributions are not included and people will be disadvantaged/biased by that or complain (or vice versa if to them unconstructive things are included) – for example talk page posts that contribute constructively to a question by e.g. solving the problem a user had would also need to be considered as positive activity instead of e.g. just activities like uploading
    • This is already the case with the already implemented Suggested Edits. More things can be added over time, maybe even in a modular kind of way. Even when missing many things, this could be better than having nearly no such thing except for mainly edit counts. There would be some dedicated page about that and people interested in this subject could address or work on complaints about it there which would not annoy other users. It doesn't seem likely that these gamification points/stats/… would result in any tangible benefits for the users like anonymous monetary return based on the level of recent contribution so people wouldn't really care much about imperfections with it.
  • Things may be unreasonably weighed – for example when it comes to edit counts by moving 1 k files to another category at once using cat-a-lot is not the same as manually reverting 1 k manually detected cases of vandalism&co
    • This is already the case with Edit counts which is what people can see for their own contributions, may be motivated by, can compare to other users, and can glance over when looking at other users. If you don't like that and consider edit counts useless that doesn't change this reality and as is is nothing but a Pro to implementing more reasonable and comprehensive feedback/stats.
  • WMC community wouldn't agree on what gives points/badges or is facilitated or by how much
    • They don't have to. One could make it dynamic like a table with many columns can be sorted by whatever column(s) you're interested in. When there are different stats/badges/… whatever you think is irrelevant can be ignored. If there are levels per badge or even per user's magnitude of constructive contributions, like those of Wikipedia:Service awards, then the user could personally adjust the weightings or select a premade weightings-combination.
  • If closing identified gaps, such as by providing requested media, is recognized and facilitated with dedicated comparable badges, then closing of gaps and ~first provision of missing needed/useful files is left out.
    • One could also consider the number of used files in the categories by subject of the file and increase weighting if there are nearly no other media in the respective cats or only unused ones. This would be difficult but wouldn't really be needed as one could do this by greater consideration of whether and how files are being used.
This certainly wouldn't be easy to implement well easily. Prototyperspective (talk) 15:09, 26 August 2024 (UTC)[reply]
@Prototyperspective: I think it is even tougher than you imagine. E.g. "Number of files categorized" => sticking lousy categories on a lot of files. That's almost a dead match for the problem we had when people were rewarded for adding "depicts". "Number of images in use on Wikipedia" => we already have enough people fighting to get their image used rather than someone else's possibly better image.
I'm all for contests of pretty much whatever sort with human judges looking for quality, not just quantity but remain completely skeptical of anything with an automated metric. - Jmabel ! talk 00:07, 27 August 2024 (UTC)[reply]
"Number of images in use on Wikipedia" There really needs to be more and/or better collaboration between projects. I don't really see how gamification would solve that or anything else mentioned by Prototyperspective though. Mainly it just seems like solution looking for a problem. What are we actually trying to solve or improve here though? Is it purely increasing raw edit count? If so, there's already betters and less involved ways to do that. Is it to get more people to add images to Wikipedia? Again, there's already there's already better and less involved ways to do that to. So really what's the actual issue here that gamification is suppose to be fixing or otherwise improving? --Adamant1 (talk) 00:19, 27 August 2024 (UTC)[reply]
Well that could be the case. But I think it's worth working on this and I think the downsides may be substantially larger in extent and complexity than outlined but not as intense as you may think – people don't act so problematically if these things don't result in anything tangible anyway. Think of it like improving the Feedback system of the platform so people get more feedback to be more engaged / motivated / entertained when contributing and just track their stats out of interest.
For example, number of files categorized may be considered by some to not be positive compared to other kinds of edits that may be behind edit counts and this is breaking down edit counts by type to some degree so you can track your own edits by type for instance. Now I do think it should be encouragements but I wasn't suggesting this comprehensive component to reach some mature version right away rather being developed while already being usable before solving all its main problems. For instance, files to which only cats like meta maintenance cats like display resolution cats got added may also be tracked separately and most importantly: people adding inappropriate cats for increasing these numbers would get some notification because they get a large share of / multiple reverts among their edits. Also so many files lack categories that this may not be as big of a thing especially if there were more task requests that people could simply complete to increase their stats.
I haven't seen people trying to get their own image used vs others and the larger problem is that even people's own uploads remain unused when lots of articles miss images with e.g. tracking files put into use by the uploader getting tracked in special ways and e.g. a rule to not readd an own image yourself when some other editor removed it could solve this.
As for human judges vs automated metrics – the art would be to craft an automated system fed by human data including human judges' data (like FPs, photo challenges, file uses, new things) that results in high quality results. It shouldn't be some liveless undynamic algorithm giving feedback itself, it would be human judges / the platform community providing feedback through this systematic framework and functions. This means it's only less direct and manual. It's not just about quantity, neither solving a requested media nor uploading or creating files that are useful enough to illustrate Wikipedia articles is about quantity.
Adamant1, that is about illustrating how the metric would be better than merely "Number of files uploaded". It could be refined further or get substats/…. If you're asking about the general advantages of "gamification" (and I think it's more about "gamification-like feedback"): it would safeguard WMC's future not just over the next 10 years but over the next decades / long-term and greatly increase constructive contributions, make the platform more fun to contribute, motivate more users to become new active users here, and so on. I don't think the potential benefits can be overstated and I think starting somewhere with this would be better than worrying a lot about likely problems on which there is insufficient experimental data and many plausible ways to address them. Prototyperspective (talk) 00:14, 28 August 2024 (UTC)[reply]
I don't even disagree with most of your response. I think your mixing things up here though or have an unrealistic view of what exactly "gamification" is to begin with. I say that because we have some forms of gamefication already. For instance featured and valued images, badges, tracking edit, category, and page view counts Etc. Etc. The question for me is if those things need to be improved or do we need to implement something else and in exactly areas. To give one example, having "featured galleries" would certainly increase and improve galleries on here. But that's literally all "gamification" is. So then what specific areas do we need more or better versions of that in and how exactly should go about it? Because your certainly able to go off on winded diatribes about the general merits of adding "gamification" to Commons but 15 messages later I still have yet to you say exactly what your talking about or how it would be different or better then the gamification mechanisms we already have. You want badges, cool. We already essentially have those. So what should changed or improved about them? You want artificial systems ran by judges, cool. We already have that to a degree with the featured and valued images systems. So what exactly is wrong with or needs to be improved about those things? --Adamant1 (talk) 00:30, 28 August 2024 (UTC)[reply]
Yes there already are lots of gamification elements and components. To answer your question, more and better gamification such as not just mere edit-counts which aren't insightful and badges provided automatically (there are basically no badges here) as well as things not covered by the current system like valuing all sorts of contributions that aren't photographs nominated as featured pictures and ways to evaluate overall constructive-contributions. Not an artificial system run by judges but using judges' data and built and continuously refined by humans (the Wikimedia community) and possibly personalizable to some extent so people can change what they think is more constructive. For example, I think implementing requested Wishlist items and phabricator code issues is one of the most constructive ways to contribute. One thing I forgot to mention is that WMC probably is in less need of new active contributors and keeping people engaged and productive than Wikipedia. Prototyperspective (talk) 09:57, 28 August 2024 (UTC)[reply]
More and better gamification such as not just mere edit-counts which aren't insightful People don't do it on here as much as Wikipedia but I've certainly seen plenty of people list editing milestones on their user pages as if they are meaningful. Perhaps there could be a special message or award barnstar for them, but I fail to see how creating a basic "level system" would be any different. It's pretty much the same to me if I'm a level 2 user or have 200,000 edits. The former just has less zeros, but as far as I'm concerned there's nothing about it that's inherently more meaningful then the raw edit count.
there are basically no badges here We have award barnstars. I guess they aren't technically badges, but again, I've certainly seen plenty of people list them on their user pages as if it's an accomplishment and meaningful to receive one. You could just rename them badges and they be essentially the same thing though. I think the main issue is that they aren't given out enough on here and it's seemingly random. So there's certainly things that could be improved there, but I don't think replaces them with "badges" would really make that much of a difference at the end of the day.
like valuing all sorts of contributions that aren't photographs nominated as featured pictures I guess we just have different ideas of how you go about that. For me it's more about having a community that's welcoming to and usable by new editors, clear guidelines, manageable goals and clear projects to work on that involve calibration with other users, Etc. Etc. At the end of the day it doesn't matter if someone becomes a level 2 or whatever because they reached some editing milestone if their still spending 99% of their time aimlessly whittling away by themselves in some corner of the project while being attacked every time they have even basic interaction with anyone else on here. It's not magic, if you want people to be motivated and contribute more you have to give them a basic purpose for contributing and/or people who care about them and the work they do to interact with. Otherwise it's just an exercise in mindless clicking that ultimately leads to nothing but frustration and burnout regardless. Although I do agree that featured pictures probably doesn't really accomplish anything meaningful, but we do have a lot of photographs on here. So it's clearly not a complete waste.
And ways to evaluate overall constructive-contributions. What about telling other users they are doing a good job sometimes? I don't disagree that there's value in that, but it should be something that is evaluated and celebrated by other users. Not just some mindless automated standard that has nothing to do with collaboration or the wider community. At least it if being done on site. It would be interesting to see if there's a way you could something along the lines of what's being talked about here through something on ToolForge though. I just don't think it's within the goals or purpose of the project to do it on site so to speak. But something like that shouldn't come at the cost of the other things I've pointed out. We're better off making this more inviting, streamlined, and user friendly then having some arbitrary slot machine style badge and/or level system regardless. Although I understand and don't even disagree with your motivations for wanting those things. --Adamant1 (talk) 15:12, 28 August 2024 (UTC)[reply]
I created a draft page for my gamification idea Commons:Wiki Allstars. GPSLeo (talk) 16:24, 28 August 2024 (UTC)[reply]
Cool. I like your idea. It seems to have a good balance of humor and flexibility without just being a mindless, automated exercise in button clicking to rack up points or whatever. --Adamant1 (talk) 16:50, 28 August 2024 (UTC)[reply]

New speedy deletion category for COM:PENIS?

[edit]
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There appears to be clear consensus that this already falls under F10. The Squirrel Conspiracy (talk) 03:17, 29 August 2024 (UTC)[reply]


I’d say that the overwhelming majority of new uploads depicting genitalia nominated for deletion are deleted, so it doesn’t make sense to have DRs for every single one. Therefore I propose a new speedy deletion rationale: F11 [I think that’s the applicable number]: low-quality or unremarkable close-up photos of human genitalia. Thoughts? Dronebogus (talk) 08:59, 10 August 2024 (UTC)[reply]

A good idea, but I'd limit this to recent uploads. If it's been there even a month, this is probably not a ground to request speedy deletion. - Jmabel ! talk 19:18, 10 August 2024 (UTC)[reply]
  • My main issue with this is that we have anti-porn crusaders. There are some users who hate any type of nudity and these people might misuse this, heck, they might even remove all actual file usages on Wikipedia and then tag them as speedy. As I've seen some anti-porn crusaders remove images for Wikipedia and then claim that these images are "out of scope" here because they are not in use. Also, are there any statistics on how many low quality nudity images that aren't realistically educationally useful actually get uploaded here? Usually when I see them they are from single-purpose accounts and more often than not these accounts get reported and nuked. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:14, 10 August 2024 (UTC)[reply]
As nearly all these files already fall under F10 (and if not mostly under F1) I do not see the need for a new criterion. GPSLeo (talk) 22:17, 10 August 2024 (UTC)[reply]
I don't think it's super clear that they fall under F10 or F1 considering how many are nominated for deletion instead of speedy deleted. I certainly didn't know either one of those were an option and I'm pretty competent with when it comes to getting images deleted. So maybe there should at least be a note about it under either the section for F10 or F1 if nothing else depending on which one is actually applicable. BTW, one of the draw backs of not having it explicit is that someone can just cry foul about censorship if they want and turn the SD into a normal deletion request, which I think could be avoided by having it as a specific deletion rational as opposed to using a more general one. --Adamant1 (talk) 23:40, 10 August 2024 (UTC)[reply]
The reason why many things they are speedy deletion cases are nominated as regular deletions is just because people do not know that speedy deletion exists and the default interface does only show regular deletion nomination. GPSLeo (talk) 08:47, 11 August 2024 (UTC)[reply]
Is there a SD gadget? Dronebogus (talk) 08:49, 11 August 2024 (UTC)[reply]
Sort of: Help:QuickDelete. It only supports a couple of CSD criteria by default, but you can add more (as I have) by editing your user JS. Omphalographer (talk) 06:01, 12 August 2024 (UTC)[reply]
@Omphalographer: Can I just copy the code from your common.js file into mine to enable the extra features or will screw anything up? (I ask because apparently mind has some code for Cat-a-lot that I rather not mess up if I don't have to) --Adamant1 (talk) 11:43, 12 August 2024 (UTC)[reply]
You should be able to drop that code in alongside the Cat-a-Lot preferences, yes. Omphalographer (talk) 20:56, 12 August 2024 (UTC)[reply]
There is COM:TWINKLE but that's under development. —Matrix(!) {user - talk? - uselesscontributions} 07:27, 13 August 2024 (UTC)[reply]
@Matrix: Pending that, I use m:User:Xiplus/TwinkleGlobal for speed (it uses the generic {{Speedy}}), but some may prefer to use {{SD}} with a particular criterion from COM:CSD in parameter 1 and follow through (if you do that, please check your work the first time).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:07, 13 August 2024 (UTC)[reply]
@GPSLeo: You make a good point. Speedy deletions are kind of obscure. Maybe that's something that can or should be integrated into the interface somehow. I'm not sure a gadget would be best way to go about it since there's just as much chance that won't know about or use the gadget anymore then they do with speedy deletions to begin with. --Adamant1 (talk) 04:56, 12 August 2024 (UTC)[reply]
I think simplified speedy deletion should be a default feature for all autoconfirmed users (I’m not sure IPs and brand new accounts can be trusted not to abuse it or misunderstand it) Dronebogus (talk) 08:16, 12 August 2024 (UTC)[reply]
In the future this will become part of the m:Incident Reporting System which asks the users multiple questions to guide the report to the correct place. GPSLeo (talk) 13:07, 12 August 2024 (UTC)[reply]
 Oppose. I understand where you're coming from and I agree in principle, but "low quality or unremarkable" is too subjective for a speedy deletion criterion. Omphalographer (talk) 05:59, 12 August 2024 (UTC)[reply]
A better standard would probably be "self-created" but then it sounds like that's already adequately covered by F1 and F10. --Adamant1 (talk) 07:23, 12 August 2024 (UTC)[reply]
How about “close-up photos of genitalia that are of unusably poor quality and/or not substantially different from existing files?” “Unusably poor” would be things like being blurry, low resolution, badly lit, etc. Dronebogus (talk) 08:14, 12 August 2024 (UTC)[reply]
"Not substantially different from existing files" is still fairly subjective, and it isn't something that an admin processing speedy deletions can verify at a glance. Unusably low quality is more objective, but would that address a meaningful number of these uploads? Omphalographer (talk) 09:14, 12 August 2024 (UTC)[reply]
How is it more or less subjective than “Low-to-medium quality selfies and other personal images of or by users who have no constructive global contributions”? Not substantially different means it doesn’t illustrate any significant, underrepresented variation on the sexual anatomy— namely genital modification or medical conditions. If it is a completely normal penis or vulva without either of those, or depicts an example of modified or abnormal genitalia we have countless images of (i.e. a circumcised penis) it’s not substantially different from existing files. Dronebogus (talk) 09:21, 12 August 2024 (UTC)[reply]
 Oppose I assume F10 "(selfies) and other personal images of or by users who have no constructive global contributions" should already be applicable. No need to give the religious bunch an extra rule. Alexpl (talk) 12:46, 12 August 2024 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


New section for Atlas of the World and Category:Maps at Commons main page -> Content -> By topic

[edit]

I propose moving the 2 links currently at Commons main page -> Content -> By type -> Images -> Maps (Atlas) to a new entry in Commons main page -> Content -> By topic -> Cartography Maps (see discussion below for the name change). Maps are a topic/subject in itself, not merely a type of media, and the Atlas of the World, as a system of galleries, is unlike any other link in "By type" section, and should be more easily accessible. MGeog2022 (talk) 12:02, 13 August 2024 (UTC)[reply]

 Support, as proposer. MGeog2022 (talk) 19:37, 13 August 2024 (UTC)[reply]
 Support – I have contributed in the atlas pages, and these should be well-known to average readers. Sbb1413 (he) (talk • contribs • uploads) 12:44, 14 August 2024 (UTC)[reply]
  •  Oppose "Cartography" is the wrong word for a gallery containing images of maps. Cartography has to do with map creation, not the maps themselves per se. Plus it's kind of a specialist term that most people outside of the industry don't use or know about to begin with. --Adamant1 (talk) 15:14, 14 August 2024 (UTC)[reply]
    @Adamant1: From Wikipedia, cartography is "the study and practice of making and using maps". The word is quite familiar to me long before I started map making in Commons. So I find nothing wrong with using "cartography" to categorize map galleries and atlas pages. Sbb1413 (he) (talk • contribs • uploads) 15:18, 14 August 2024 (UTC)[reply]
    I'm aware of what the definition of cartography is. I actually studied it in college. That's besides the point though. Things on the main page should 1. Be understandable to a general audience 2. Follow how the categories/galleries/files/Etc. Etc. are termed. At the end of the day these aren't galleries for images of people "studying or making maps." Their galleries of maps. So it's makes zero sense to call them that on the main page. Just like it makes more sense to have a link on the main page for Category:Animalia instead of Category:Zoology. Even though both technically relate to animals. As I assume the point is to link to images of animals, not people in lab coats dissecting specimens or whatever. --Adamant1 (talk) 16:33, 14 August 2024 (UTC)[reply]
    @Adamant1, no problem if Cartography is not the best word: we replace it for Maps. The matter here is if you can see Category:Maps and Atlas of the World when you load Commons main page, or if you have to miraculously know that you have to expand By type section and have a detailed look to find them. MGeog2022 (talk) 09:35, 15 August 2024 (UTC)[reply]
    Sorry, perhaps I used Cartography word wrongly because of Spanish (my native language) word Cartografía, which is often used to refer to maps themselves. Maybe English Cartography isn't used in the same way. MGeog2022 (talk) 09:47, 15 August 2024 (UTC)[reply]
    I don't care if the term used is Maps or Cartography, since my native tongue Bengali often use মানচিত্র to cover both topics, although it has a specific term for the study of maps (মানচিত্রবিদ্যা). Sbb1413 (he) (talk • contribs • uploads) 09:53, 15 August 2024 (UTC)[reply]
    OK. I'm fine with this if we go with maps then. --Adamant1 (talk) 11:46, 15 August 2024 (UTC)[reply]
  •  Oppose. Current scheme better and more accessible. Maps are images rather than topics. Maps is more accessible than cartography. Glrx (talk) 17:43, 14 August 2024 (UTC)[reply]
    @Glrx, please tell me in what way having to expand a section (By type section) to find it, is more accesible than having it already visible when you load Commons main page, as is the case with By topic. No problem with using maps in place of cartography, that wasn't the main thing here. Maps are images rather than topics: of course each map is an image and not a topic. But maps, as a whole, are more of a topic than a media type, as photos or diagrams (you wouldn't generally look for photos or diagrams without a subject; with maps, while searchs by subject are also frequent, you also may want to have a general look at a structured collection of maps from all around the world). MGeog2022 (talk) 09:41, 15 August 2024 (UTC)[reply]
    @MGeog2022 and Glrx: I think the compromise would be to put Maps under both Images and By topic. Things don't have to be strictly hierarchical (or "breadcrumbed", as we call it in Wikivoyage). Sbb1413 (he) (talk • contribs • uploads) 09:48, 15 August 2024 (UTC)[reply]
    @Sbb1413, OK. Atlas could remain in By topic only, and Maps in both, since is both a topic and a type of media. MGeog2022 (talk) 09:52, 15 August 2024 (UTC)[reply]
    We have 3  Support votes (including Adamant1 vote change) and 1  Oppose, and no votes within the last days. I don't know if this is enough to proceed with the change (in Commons main page, removing link to Atlas from By type, and adding new section Maps in By topic, with both links to Atlas and Category:Maps), and who could do it (that is, someone who can edit Commons main page). MGeog2022 (talk) 12:49, 20 August 2024 (UTC)[reply]
    I don't know if there's a specific amount of time that needs to pass or number of votes that have to happen before a proposal is closed, but there's no reason this can't just stay how it is for at least a couple of more weeks to see if anyone else has comments or anything else changes about it. A week isn't really long enough to judge the wider communities opinion about anything. --Adamant1 (talk) 09:57, 21 August 2024 (UTC)[reply]
    Of course there is no hurry. OK, let's wait for some more time. MGeog2022 (talk) 12:25, 21 August 2024 (UTC)[reply]
  •  Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:52, 21 August 2024 (UTC)[reply]
[edit]

See Commons:Village_pump#Add_"Upload_file"_link_for_mobile? for discussion. Enhancing999 (talk) 12:57, 15 August 2024 (UTC)[reply]

FAQ
  • "Why isn't this limited to some skin or some type of devices like mobile view?"
We don't want to be asked again about pages at Commons not having upload links. I feel it's sufficiently embarrassing as such.
  • "why is this titled "bug/feature request"?
We don't really know if know if the missing upload link is a feature (people shouldn't upload at Commons? but then why?) or a bug (developers didn't implement that part of the specification).
  • "why can't I edit the initial proposal to my likening?"
The initial poster here took it upon him to formulate the proposal. If you wan't to do a separate one, add this in your comment".

Enhancing999 (talk) 09:41, 16 August 2024 (UTC)[reply]

  •  Support for "upload file" link for mobile, thinking in the users who have no other option, without forgetting the concerns of administrators about the possible increment of COPYVIO cases and the possible need to take appropriate measures to prevent it. MGeog2022 (talk) 13:47, 15 August 2024 (UTC)[reply]
  •  Oppose For the same reason's I gave in the Village Pump discussion. I'm not a fan of how this is being framed as a simple bug when that doesn't appear to be what it is either. Rather it appears to be something that just hasn't been implemented, not a problem due to a coding error or whatever that's causing the site to act differently then it should be on mobile devices. --Adamant1 (talk) 16:34, 15 August 2024 (UTC)[reply]
@Enhancing999: What evidence do you have that it's a bug and not just an unimplemented feature? I'm sure your aware that they aren't the same thing and that framing it as a "bug" just makes this looks like something that should already be implemented as opposed to a request for a new feature or whatever. --Adamant1 (talk) 16:34, 15 August 2024 (UTC)[reply]
The question was raised in the discussion, please feel free to comment there and explain why a site to upload media shouldn't have an upload link and how core feature was omitted. Enhancing999 (talk) 17:07, 15 August 2024 (UTC)[reply]
I already did. So why not answer the question? What exactly makes this a bug and not just something that hasn't been implemented? Your the one claiming that's what it is and saying it's only missing for some devices. So it should be easy to provide some evidence. Otherwise I'm just going to argue that this shouldn't be accepted no matter how the vote goes because of the misleading, false framing of the issue. --Adamant1 (talk) 17:18, 15 August 2024 (UTC)[reply]
I don't see your answer there (VP). Feel free to vote multiple times on this proposal here (VP/P). Enhancing999 (talk) 17:24, 15 August 2024 (UTC)[reply]
No answer about how it's a "bug" then? Thought not. I guess you won't mind if I change the title to what it was in the Village Pump discussion then. --Adamant1 (talk) 17:26, 15 August 2024 (UTC)[reply]
 Support Mobile users should also be able to upload images. Many people don't have a desktop computer but only a phone. Uploads through mobile devices could be tagged somehow so they are easier to check for copyvios the bulk of which a tineye-/google-image-reverse search bot could do. Prototyperspective (talk) 17:01, 15 August 2024 (UTC)[reply]
@Prototyperspective: Is there metrics anywhere saying exactly how many people on mobile actually use the site or would upload media to it in the first place? You'd have to agree that it doesn't really matter how many people do or don't have a particular device if none of them actually use the website to begin with. --Adamant1 (talk) 17:20, 15 August 2024 (UTC)[reply]
For me it is a bit unclear on what the proposal is about. Where should the link be added? Only on Commons in mobile view or also on other Wikis and the Wikipedia mobile app? GPSLeo (talk) 17:50, 15 August 2024 (UTC)[reply]
I don't know. The current topic no longer represents my proposal and Adamant1 signaled we must gain his approval to change it back. I reported them to COM:VP/U. Enhancing999 (talk) 17:58, 15 August 2024 (UTC)[reply]
Where exactly have I signaled that people need to gain my approval to change the topic. I literally said on your talk page that you were free to change the title as long as it makes sense and accurately represents the original request. It's not me that you don't feel like rewording it to get rid of the spelling mistakes and use proper English. --Adamant1 (talk) 18:14, 15 August 2024 (UTC)[reply]
You can formulate an alternate proposal in a different thread and vote multiple times to oppose this one if you don't like it. Clearly you didn't change it to correct spelling. Enhancing999 (talk) 19:53, 15 August 2024 (UTC)[reply]
That was the title of the discussion that you linked to and told everyone to look at to see what this is about. Plus you can read Novem Linguae's comment below this one "Changing the apps is not part of this proposal. Just the Minerva skin, which is the mobile browser skin." So how exactly is the title wrong or for an alternate proposal when this is literally about adding a "Upload file" link to the mobile browser skin? --Adamant1 (talk) 20:09, 15 August 2024 (UTC)[reply]
Changing the apps is not part of this proposal. Just the Minerva skin, which is the mobile browser skin. It would go in the left menu towards the bottom. I currently have the patch written as affecting all wikis, but I am being pressured in gerrit code review to change it to just affect wikis with UploadWizard installed, for technical reasons. Commons is the most important stakeholder, so I see getting commons signoff as the minimum first step here to keep proceeding with the patch, and as a yardstick for what the other wikis are likely to think of this. –Novem Linguae (talk) 19:44, 15 August 2024 (UTC)[reply]
Screenshot of current patch: https://phab.wmfusercontent.org/file/data/6pk4pztn3tq54y4r2vrs/PHID-FILE-2fyfnb6ofjltwerpf5nv/image.png –Novem Linguae (talk) 21:56, 15 August 2024 (UTC)[reply]
@Novem Linguae: I'd probably support the proposal if it was confined just to the Minerva skin and mobile. It seems like @Enhancing999: wants to make it about other things that have nothing to do with either one though. So I think you and him need to discuss this and figure out what's actually being proposed here before it's moved forward. Otherwise it's not really clear what exactly is being proposed here and @Enhancing999: doesn't seem to be willing to clarify things or change the proposal to be more specific. I'd probably support if I knew exactly what I was voting on though. --Adamant1 (talk) 23:22, 15 August 2024 (UTC)[reply]
I've boldly edited the proposal title to be minerva only. I have no interest or ability to patch the many different apps, so I think that is a misunderstanding. I hope everyone finds this clarification acceptable. –Novem Linguae (talk) 05:55, 16 August 2024 (UTC)[reply]
Thanks. I changed my vote to support. I have no issues with trying this out with Minerva and then expending it from there later if doesn't lead to people uploading a bunch of extra COPYVIO. --Adamant1 (talk) 07:40, 16 August 2024 (UTC)[reply]
For me it is still not clear if you want a link on every Wikipedia article to upload a photo on the topic or not. For Commons it is just making a link that already exists in the Infobox more visible. GPSLeo (talk) 07:43, 16 August 2024 (UTC)[reply]
The proposal is to add an "Upload file" link to the left menu of the Minerva skin, as in this screenshot. This link would appear on every page on Commons when the menu is open (it defaults to collapsed and needs to be clicked). –Novem Linguae (talk) 08:03, 16 August 2024 (UTC)[reply]
If only on Commons and not all Wikis I would  Support. On category pages the link should open the Wizard prefilled with the category. GPSLeo (talk) 09:01, 16 August 2024 (UTC)[reply]
We can't really determine here what other wikis do. We can stop them when some users come through the wrong channel. What part suggests that this should be for other wikis? Enhancing999 (talk) 10:01, 16 August 2024 (UTC)[reply]
You really sure you want to do that? You've had multiple people tell you the proposal was vague and two different users thought the title should be changed. Plus it's pretty clear that what Novem Linguae is working on is the only thing being worked on at this point. I'm more then willing to retract my support if your going to be that way about it, but I'd rather the proposal just be confined to Novem Linguae's original plan then oppose it just because you can't take other people's advice or deal with it being confined to just the Minerva skin for now. There's no reason there can't be a wider proposal to fix the bug or whatever after we try it with the Minerva skin for awhile to make sure it doesn't lead to more COPYVIO. --Adamant1 (talk) 09:33, 16 August 2024 (UTC)[reply]
You are free to post your opinion here. Please make sure to include plenty of points that come to your mind and repeat them over and over, even if ultimately you don't consider them relevant. Just let us know before. We can guess about repetition. Enhancing999 (talk) 09:52, 16 August 2024 (UTC)[reply]
I don't think I've said most of what in the message your responding to before. So I'm not really sure what your talking about with the repetition. It's pretty clear you don't have actual response outside of acting snide though. Please continue to be condescending in your messages and make a bunch of needlessly back handed personal comments in response to good faithed questions or attempts to resolve this in a way that everyone would be satisfied with though. --Adamant1 (talk) 10:02, 16 August 2024 (UTC)[reply]
I'd recommend re-titling this to "‎Proposal: Add "Upload file" link for mobile skin (Minerva) in browsers" and removing the FAQ. This will laser-focus the proposal into something small and passable. "Incremental progress" (get a little bit passed now, then a little bit passed later) is a good way to move things forward. I'd also recommend not dragging participants of this proposal to AN/UP. Seems like a sideshow that will just distract from the proposal and create animosity. –Novem Linguae (talk) 10:13, 16 August 2024 (UTC)[reply]
Are there any skins that shouldn't have links? Enhancing999 (talk) 10:17, 16 August 2024 (UTC)[reply]
  •  Oppose Per Enhancing999's clear ownership issues and unwillingness to confine this to the Minerva skin for now. As well as them making it needlessly personal in the FAQ. I'm more then willing to support an alternative proposal just for the the Minerva skin though. But I don't really see a reason to support a vague proposal about apparently none exiting "bugs" or "devices." Especially when the proposal can't even be bothered to explain exactly what their talking about. --Adamant1 (talk) 09:51, 16 August 2024 (UTC)[reply]
It's at Commons:Administrators'_noticeboard/User_problems#Adamant1_(15_August_2024) (as removed it from the FAQ). Enhancing999 (talk) 09:58, 16 August 2024 (UTC)[reply]
Qoute from Matrix "Enhancing999, COM:AGF is a policy. Calling Adamant1's changes "headline vandalism" from the start is clearly assuming bad faith. You also don't have to give a "final warning" right from the start. Just discuss the changes." Clearly you've completely missed the point. --Adamant1 (talk) 10:08, 16 August 2024 (UTC)[reply]
I think you should have known that you even broke the link you likely followed when you first came to this thread. Enhancing999 (talk) 10:21, 16 August 2024 (UTC)[reply]
@Enhancing999: Anchors can alleviate that problem.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:57, 16 August 2024 (UTC)[reply]
I think you could train Adamant1. Enhancing999 (talk) 11:03, 16 August 2024 (UTC)[reply]
 Oppose I can't even work out what, tangibly, is being proposed here. Opposing on principle for vagueness. - Jmabel ! talk 16:25, 16 August 2024 (UTC)[reply]
 Oppose It failed ten years ago and I can´t see why it would fare better this time. --Rudolph Buch (talk) 22:03, 17 August 2024 (UTC)[reply]
[edit]

This is to allow underserved mobile users to upload directly without having to use a desktop or special app, or switch to another skin. Yes, I know that this would probably increase the percentage of copyvios uploaded, but that's what the tracking is for.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:55, 16 August 2024 (UTC)[reply]

  • As with the previous similar proposal,  Support. The proposed tracking would mitigate the possible increase in COPYVIO cases, as Jeff G. said (I wasn't aware of it, but there is a Commons mobile app that already allows uploads from mobile devices, so perhaps allowing uploads from mobile browsers doesn't increase COPYVIO so much; on the other hand, having the app, this change isn't so critical, but in any case it would be useful for rare cases of users who can't or don't want to install the app). MGeog2022 (talk) 11:13, 16 August 2024 (UTC)[reply]
    The app is only for Android and even of Android users an estimated >50% users probably either don't know of or don't want to install that app so it's not rare at all. Prototyperspective (talk) 17:36, 16 August 2024 (UTC)[reply]
  •  Support --Adamant1 (talk) 11:20, 16 August 2024 (UTC)[reply]
  • Neutral. This seems to go the opposite direction than other recent proposals to reduce or eliminate cross-wiki uploads. I'd much rather see a link to the Commons Upload Wizard. - Jmabel ! talk 16:27, 16 August 2024 (UTC)[reply]
    Why would this proposal not be a link to the Commons Upload Wizard? I think that's what has been proposed but I'd also support another Upload form if it's either that or no upload capability. (Secondly, it would be nice if at some point mobile users were made aware of the Commons app here but I think it would first need to get a proper Explore/Home page.) Prototyperspective (talk) 22:37, 17 August 2024 (UTC)[reply]
Didn't we use to have this and then we voted to disable this ? —TheDJ (talk • contribs) 17:15, 16 August 2024 (UTC)[reply]
@TheDJ: It appears so per the post of 22:03, 17 August 2024 (UTC) below.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:29, 17 August 2024 (UTC)[reply]
 Support per my support above. Prototyperspective (talk) 17:34, 16 August 2024 (UTC)[reply]
And when it comes to copyvios, please see my proposal here: meta:Community Wishlist/Wishes/Bots detecting copyvios on Commons (image reverse search etc). It's absurd people still do this largely manually. Prototyperspective (talk) 09:10, 18 August 2024 (UTC)[reply]
Certainly, that would automatically detect an important part of copyvios automatically in a moment. Administrators then would have much more free time to investigate well the most complex cases and for other tasks. MGeog2022 (talk) 09:51, 18 August 2024 (UTC)[reply]
 Oppose It failed ten years ago and I can´t see why it would fare better this time. (Sorry for repeating this - but isn´t the proposal as well repeating the one above?) --Rudolph Buch (talk) 22:03, 17 August 2024 (UTC)[reply]
@Rudolph Buch: I see. Thanks for the link. Perhaps the current Admin team has a different perspective from the Admin team of ten years ago, I'd like to hear from them, so I requested their opinions at COM:AN. Regarding the repetitive nature of this proposal, I was trying to avoid a certain user's ownership issue.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:34, 17 August 2024 (UTC)[reply]
I feel like the proposal from 10 years ago is for something significantly different from what is being proposed here. Bawolff (talk) 08:56, 19 August 2024 (UTC)[reply]
Interesting post from almost exactly 10 years ago. Supposedly this was before upload wizard and its tutorial and with mobiles from back then. Weirdly they then built a tool to do the same from Wikipedia directly (or was that before?).
 ∞∞ Enhancing999 (talk) 14:06, 27 August 2024 (UTC)[reply]

I believe User:Sannita (WMF) is on vacation the next week-plus, so he won't be likely to weigh in at this time from the point of view of the team that does the Upload Wizard. - Jmabel ! talk 01:05, 18 August 2024 (UTC)[reply]

I know from WMF contacts who would probably rather not be named that they consider it a much worse user experience when people upload files, a large number of which are deleted, than when they cannot upload at all. I suspect that rather than tweak here and there, the whole issue around expansion of ability to upload should should be discussed broadly, including plans for how we will evaluate the results. In fact, those plans for evaluation should probably be the first step. - Jmabel ! talk 01:11, 18 August 2024 (UTC)[reply]

I was initially against this myself but I don't see why we can't use Jeff G. idea to track files uploaded by the skin and then keep a tally of how many end up being COPYVIO going forward from there to see if it actually causes that much of an issue long-term or not. Then the skin can just be disabled if it ends being a problem. I'm not an expert on this by any means, but I assume that wouldn't be an option if uploads were enabled more broadly on mobile in general outside of Minerva. --Adamant1 (talk) 05:45, 18 August 2024 (UTC)[reply]

 Support I understand people are gun-shy due to past events, but i think this is a good thing. Many of the past attempts involved "simplifying" the upload form to help mobile users, and ended up effectively simplifying away the part where users are instructed not to make copyvios. As long as this is linking to the normal upload wizard, than i suspect this will go a lot better than the previous mobile upload stuff. There is always a risk-benefit trade off with making things easier of course. I think the best way to reduce risk here, is to tag uploads via this method (as suggested above), but also agree before hand on a cut-off date where things will be re-assessed and disabled if they go badly. For example, after 1 month of trying this, have another discussion to decide on next steps. Bawolff (talk) 09:14, 19 August 2024 (UTC)[reply]

CAPTCHA for many IP edits

[edit]

There is a new feature that allows AbuseFilters to require a CAPTCHA before uploading an edit. I would like to enable this for many IP edits, especially IP edits on mobile. The aim of this is to reduce the huge amount of accidental and nonsense edits. Are there any concerns against this? GPSLeo (talk) 10:06, 18 August 2024 (UTC)[reply]

No, it would be good to reduce maintenance time to free up time for other tasks. However, I doubt this is enough and have called for better vandalism/nonsense-edit detection like ClueBot does it on Wikipedia here which may also be some context for this thread. Prototyperspective (talk) 10:25, 18 August 2024 (UTC)[reply]
Detection of nonsense after is was published is not our problem, this is possible with current filters. We do not have enough people looking on the filter hits and reverting the vandalism. We therefore need measures to reduce such edits. If we do not find a way to handle this we need to block IP edits entirely. GPSLeo (talk) 10:56, 18 August 2024 (UTC)[reply]
I think we rather need measure to automatically revert such edits. Detection is a problem if it's not accurate enough that it contains too many false-positives that people don't implement them. The proposal is not just about detection but also about what follows from there – for example one could also automatically revert them but add the edit to a queue to check in case the revert is unwarranted. Prototyperspective (talk) 11:00, 18 August 2024 (UTC)[reply]
We might to want to experiment mw:Moderator Tools/Automoderator. It won't probably work perfectly at a first experiment, but we will at least know some indication of where it works and where it doesn't. whym (talk) 01:18, 1 September 2024 (UTC)[reply]
Very interesting! Thanks for the link, it's very constructive and if possible please let me know when WMC enables this or when there is some discussion about enabling it.
It could save people a lot of time and keep content here more reliable/higher quality. I think there's not even auto-detection for when e.g. 80% of a user's edit have been reverted for checking the remainder and whether further action is due. Prototyperspective (talk) 23:18, 1 September 2024 (UTC)[reply]
Capchas are supposed to stop robots from spamming, right? Why would this stop some random human IP user from posting “amogus sussy balls”? Dronebogus (talk) 14:05, 18 August 2024 (UTC)[reply]
Seconding this. CAPTCHAs should only be used to prevent automated edits, not as a means of "hazing" users making low-effort manual edits. Omphalographer (talk) 20:12, 18 August 2024 (UTC)[reply]
Maybe candidates could be edits that are currently fully blocked but have some false positives that could be let through?
 ∞∞ Enhancing999 (talk) 13:59, 27 August 2024 (UTC)[reply]
You did not consider the full rationale of OP, he wrote huge amount of accidental […] edits and this measure would be partly and probably mainly be about greatly reducing accidental edits. OP however failed to name some concrete specific examples which have been brought up in a thread elsewhere. I favor better detection of nonsense edits and automatic reverting of them but requiring captchas for IP edits on mobile or for certain actions may still be worth testing for a month or two to see whether it actually reduces these kinds of edits. Prototyperspective (talk) 16:43, 27 August 2024 (UTC)[reply]
I'd totally support requiring captcha's for edits on mobile in general, not just for IP addresses. I know personally I make a lot of editing mistakes on mobile just because of how clanky the interface is. There's also been plenty of instances where I've seen pretty well established users forgot to sign their names or make other basic mistakes on mobile. So I think having captcha's on mobile for everyone would be a really good idea. --Adamant1 (talk) 17:59, 27 August 2024 (UTC)[reply]
In Special:Preferences there is an option "Prompt me when entering a blank edit summary (or the default undo summary)". Enabling this seems like a good way to provide a chance to briefly stop and review what you are trying to do. I wonder if it's possible to enable it by default. A captcha answer has no productive value, but a good edit summary will do. whym (talk) 01:15, 1 September 2024 (UTC)[reply]
I'd support that as long as there's a way for normal, logged in users to disable it if they want to. I think any kind of buffer between making an edit and posting it would reduce bad edits though. Even ones that are clearly trolling. A lot of people won't waste their time if they have to take an extra step to post a message even if it's something like writing an edit summary. --Adamant1 (talk) 01:34, 1 September 2024 (UTC)[reply]
There is something to be said for en:WP:PBAGDSWCBY and en:WP:ROPE (I know, we don't ban here, just substitute indef for ban).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:01, 1 September 2024 (UTC)[reply]
@Jeff G.: True. That's one of the main reasons I support requiring people to have an account since it seems to be much easier to track and ban editors that way. --Adamant1 (talk) 02:05, 1 September 2024 (UTC)[reply]
@Adamant1: Like it or not, we still have "anyone can contribute" right on the main page.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:17, 1 September 2024 (UTC)[reply]
@Jeff G.: Anyone can still contribute if we require accounts. I could see not requiring accounts if there was legitimate reason for it, but I've put a lot of thought into this over the last couple of years and can't think of one single legitimate reason why someone wouldn't be able to create one. We'll have to agree to disagree though. I can understand why they let IP edit Wikiprojects back in the day though, but the internet and people are just different now and the project should be able to adapt to the times. --Adamant1 (talk) 02:21, 1 September 2024 (UTC)[reply]
This does not help in cases this is about as theses types of edits always have auto generated edit summaries and no way to edit the edit summary. GPSLeo (talk) 04:32, 1 September 2024 (UTC)[reply]
Maybe that is a software problem to be fixed? It already says "(or the default undo summary)" after all. Reminding users to add a bit more to what's auto-generated seems like a natural extension. whym (talk) 18:54, 1 September 2024 (UTC)[reply]
The Wikibase UI does not have such a feature and in the many years of Wikidata it was not considered a problem that changing the edit summary is not possible. GPSLeo (talk) 20:24, 1 September 2024 (UTC)[reply]
Can Commons customize that in their Wikibase instance? It's not yet implemented in the Wikidata UI, but on the API level Wikibase supports edit summaries according to d:Help:Edit summary. whym (talk) 23:38, 1 September 2024 (UTC)[reply]
I make much fewer editing mistakes on mobile when I use my new portable bluetooth mini keyboard. Touch-typing in the dark, however, can still be problematic.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:52, 1 September 2024 (UTC)[reply]

One week test

[edit]

There is definitely no consensus to use this feature for now but there were some people suggesting to make a test. Therefore I would propose that we make a one week test and then evaluate the results. GPSLeo (talk) 19:37, 2 September 2024 (UTC)[reply]

Why? How is that useful? No consensus to implement means no consensus to implement, period. I can guarantee it will not gain any more consensus with a test version. Dronebogus (talk) 21:08, 2 September 2024 (UTC)[reply]
There were some people suggesting to make a test. There is also no consensus against some kind of measure. GPSLeo (talk) 14:11, 3 September 2024 (UTC)[reply]
There is also no consensus for it. I feel like you’re just projecting whatever you like onto the discussion to make sure your proposal gets through somehow. It sucks when people don’t like your idea, but “seeing” consensus where none exists is not the way to fix that Dronebogus (talk) 19:54, 3 September 2024 (UTC)[reply]
 Oppose. As I noted above, this is not an appropriate use of CAPTCHAs - their purpose is to prevent automated edits by unauthorized bots, not to prevent "accidental or nonsense edits". Omphalographer (talk) 20:42, 3 September 2024 (UTC)[reply]

Adding JPEG XL as new file format (*.jxl)

[edit]

As new formats rise over the years, I would like to suggest the implementation of the JPEG XL file format because of its advantages. These include

  • better compression quality compared to JPEG compression
  • more modern version of the antique JPEG standard
  • Swiss army knife: free file format, compresses lossy and lossless, supports transparency channel, supports HDR, supports animation
  • set to replace the old JPEG format
  • will probably become more popular within the next years

It is a rather young format but worth to look at 👀 --PantheraLeo1359531 😺 (talk) 15:52, 19 August 2024 (UTC)[reply]

PS: And easier to implement as textured 3D meshes which still hangs in the pipe --PantheraLeo1359531 😺 (talk) 15:54, 19 August 2024 (UTC)[reply]
@PantheraLeo1349531: when you say you "suggest the implementation of the JPEG file format" I assume you meant to say "suggest the implementation of the JXL file format". - Jmabel ! talk 18:13, 19 August 2024 (UTC)[reply]
Yes, "JPEG XL" or "JXL" :) --PantheraLeo1359531 😺 (talk) 06:45, 20 August 2024 (UTC)[reply]
Please edit it above.  → Enhancing999 (talk) 12:10, 27 August 2024 (UTC)[reply]
Industry support & reception for jpeg XL is pretty mixed. It is rather unclear if this format will take off or be relegated to a footnote of history. Seems a bit early to add support unless there is some specific benefit to commons. Bawolff (talk) 00:38, 20 August 2024 (UTC)[reply]
I was just reading about AVIF files the other day. Both of them seem to be trying to unseat JPEGs but to mixed results so far. Although at least according to what I was reading AVIF is the more popular format between the two. Who really knows though. Regardless it's probably better to wait until it's clear which one will win out, if either one will, before adding support for it. --Adamant1 (talk) 12:50, 20 August 2024 (UTC)[reply]
Hmm... Chrome and Firefox currently don't officially support this format, from what I read. Rather only Firefox Nightly build has been testing it out for a long while. Chrome gave the format a try as an experiment and then gave it up. I see third-party browser extensions rendering JXL files for these browsers.
Safari currently supports the format only if the version is 17 or later, and iPhone XS (oldest so far), macs running Sonoma (version 14), iPad 6th-gen, iPad Pro 2nd-gen, or newer can capably run Safari 17.
Other lesser-known browsers render the format, but they are currently unsupported by MediaWiki. George Ho (talk) 17:17, 20 August 2024 (UTC)[reply]
 Oppose obscure, experimental format that needs to be adapted by the wider internet community before we bother hosting it. Per Adamant1 AVIF files are probably a better choice for a new format to host. But why do we need yet more ways of storing a still image on Commons? We should focus on novel media types like 3D models, virtual reality, interactive software like games, etc. that could vastly expand our educational capabilities. Dronebogus (talk) 04:39, 25 August 2024 (UTC)[reply]
Ok, yes, 3D-Models are the way to go and very useful --PantheraLeo1359531 😺 (talk) 12:04, 27 August 2024 (UTC)[reply]
AVIF sounds fair --PantheraLeo1359531 😺 (talk) 12:06, 27 August 2024 (UTC)[reply]

Enable accessibility features for logged-in users with Vector 2022 by default

[edit]

I'm proposing enabling the accessibility features beta features (like dark mode) by deafult for all logged in users using Vector 2022 skin. This will help us get more bug reports (here), and will make Commons more ready if we decide to switch to Vector 2022. English Wikipedia already has this by default for everyone. So I think it's a good idea to enable for logged in users with Vector 2022 now. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 16:12, 26 August 2024 (UTC)[reply]

Vector 2022 is not yet adapted to the special needs and functionalities of Commons. If I understood it correctly the WMF team will start working on it after the implementation on Wikipedia is done. We should therefore not make it a default for new accounts. Giving a beta feature to new users first is not a good idea. But of course having some people already using it would be good to find where adaptions to Commons are needed. GPSLeo (talk) 16:34, 26 August 2024 (UTC)[reply]
Is there even a way to select it on a per user basis at this point? --Adamant1 (talk) 18:54, 26 August 2024 (UTC)[reply]
Vector 2022 is available, dark mode only if you add "?vectornightmode=1" to the url. There might be some possibility to enable it with user JavaScript but I could not find how to. GPSLeo (talk) 19:18, 26 August 2024 (UTC)[reply]
Well darn. That's a hassle. It doesn't look like the site works very well with dark mode at this point anyway. Although it would be nice to have without the weird URL thing being involved. --Adamant1 (talk) 19:26, 26 August 2024 (UTC)[reply]
@GPSLeo: It's actually in settings. First enable Vector 2022 as your default skin, then go to Settings > Beta features and accessibility features should be there. Then it will be in your sidebar. —Matrix(!) {user - talk? - uselesscontributions} 13:48, 27 August 2024 (UTC)[reply]
Oh, you are right. I did not try to save one setting change first and then look for new available options. Thanks for that hint. GPSLeo (talk) 13:57, 27 August 2024 (UTC)[reply]
You might have misunderstood the proposal a bit. Since Vector 2022 is not the default skin, most people using it on Commons are experienced users, so they should probably be able to handle a beta feature. It will not be a default for new accounts under this proposal. —Matrix(!) {user - talk? - uselesscontributions} 13:49, 27 August 2024 (UTC)[reply]
If only experienced users use it, they should already have made their choices about the defaults for beta features. If not, this just bothers inexperienced users with buggy features.
 ∞∞ Enhancing999 (talk) 13:56, 27 August 2024 (UTC)[reply]
This is a "if they can't find it, they have no right to use it" argument. That's a bit arrogant if you ask me. —TheDJ (talk • contribs) 21:10, 3 September 2024 (UTC)[reply]
I'm in favor. I've been fixing dark mode issues here and there. It really isn't that bad as people assume. And really the only way to find what else needs fixing, and motivating people to fix their favorite templates, is if they use the feature and run into the potential remaining problems. —TheDJ (talk • contribs) 21:08, 3 September 2024 (UTC)[reply]

No US/COO license since template?

[edit]

Shouldn't there be a {{No US license since}}, for files that only has a license which works in the COO but not the US, and a {{No COO license since}}, for files that only has a license which works in the US but not the COO? Or what is the community's stance of creating such templates? Jonteemil (talk) 14:45, 27 August 2024 (UTC)[reply]

@Jonteemil: I assume COI is "country of something-that-begins-with-"I". Definitely not in Commons:Glossary. - Jmabel ! talk 18:38, 27 August 2024 (UTC) Dealt with by edit above. - Jmabel ! talk 00:07, 28 August 2024 (UTC)[reply]
Generally, COI is used for conflict of interest: en:Conflict of interest or Wikipedia:Conflict of interest, though this may not fit here. --Túrelio (talk) 18:50, 27 August 2024 (UTC)[reply]
I assume COI means "country of origin" but Jonteemil fat fingered it and the I was meant to be an O. --Adamant1 (talk) 21:46, 27 August 2024 (UTC)[reply]
Yes, correct, sorry for my too fast thinking. Country of origin (COO) is what I meant.Jonteemil (talk) 23:32, 27 August 2024 (UTC)[reply]
 Support good idea, should probably be created. —Matrix(!) {user - talk? - uselesscontributions} 09:35, 28 August 2024 (UTC)[reply]
Maybe it shouldn't imply timed deletion, but it could be good for tracking —Matrix(!) {user - talk? - uselesscontributions} 10:15, 29 August 2024 (UTC)[reply]
I'm not sure lack of a US license is a speedy deletion reason, which is implied by such a template. Much of the time, a work will be PD in the US as well, if PD in the country of origin. And if not, it will usually involve the URAA restorations, which can be rather complicated and are not valid speedy deletions (you have to demonstrate renewal by the URAA, often involving historical copyright laws of a country, in order for deletion to happen -- a possibility of the URAA restoring a work is not enough for deletion per policy). Carl Lindberg (talk) 03:56, 29 August 2024 (UTC)[reply]
I was thinking that the file would be kept for seven days until the license is added, such is the case with {{No license since}}. So it wouldn't be speedy deleted. Jonteemil (talk) 14:22, 29 August 2024 (UTC)[reply]
That is still considered a "speedy deletion", just not instant. - Jmabel ! talk 18:31, 29 August 2024 (UTC)[reply]
At least COM:D lists speedy deletion and deletion tagging as distinct procedures. --Geohakkeri (talk) 18:48, 29 August 2024 (UTC)[reply]
@Geohakkeri: I stand corrected. I never noticed that distinction. - Jmabel ! talk 21:32, 29 August 2024 (UTC)[reply]
That is still closer to the speedy deletion process, and avoids a regular DR, which the URAA probably should require. You could always add {{Not-PD-US-URAA}} if you think the URAA applies, and mark for regular deletion, giving the explicit reason why the URAA applies. Current policy puts the onus on the nominator to show that the URAA actually does apply (or at least requires a review by someone who can show that); the policy states that a URAA claim without any further provided info is not enough for deletion, for something PD in the country of origin. This proposed tag seems like it would have no need to show that evidence, with a much higher chance of deletion -- i.e., it seems like a way to circumvent that part of policy, in a somewhat contentious area (even though I think we don't delete URAA-restored works enough). If we want a tag which points out there is no US license, though with no deadline, maybe that works -- something like {{Disputed}}, though less alarming. I think Not-PD-US-URAA would apply in virtually all valid cases, though, so if you can't add that not sure it's worth marking at all. Carl Lindberg (talk) 14:23, 31 August 2024 (UTC)[reply]
 Oppose
how many dmca takedown targets are such files that have a valid licence in their country? RZuo (talk) 16:08, 1 September 2024 (UTC)[reply]
@RZuo I don't quite understand your question. Jonteemil (talk) 15:11, 6 September 2024 (UTC)[reply]
@Jonteemil: I believe RZuo is asking how often we've had a DMCA takedown notice for a file that is (or whose creator claims it to be) copyrighted in the U.S., but which is not copyrighted in its country of origin. - Jmabel ! talk 20:51, 6 September 2024 (UTC)[reply]
We've had one for Israeli photographs, and this removal for the Diary of Anne Frank. Since 2022 (Commons:Office actions/DMCA notices/2022–23 and Commons:Office actions/DMCA notices 2024, we've had 9 DMCA notices for 21st century works, one for बाणभट्ट की आत्मकथा (by Hazari Prasad Dwivedi (1907-1979) so not PD-India or PD-US), and one for Nebra Sky Disc, a work out of copyright in the US and its home nation. It's a pretty limited sample, and older works are pretty sparse in it at all, so I don't think that's a really useful question.--Prosfilaes (talk) 21:34, 11 September 2024 (UTC)[reply]
 Support It would be good as a maintenance template if nothing else. Although I don't think files should automatically qualify for deletion just because of it. People should still put in the effort to find an appropriate license for the United States regardless. We do require that things be PD in both the United States and country of origin though. I've seen plenty of instances where files don't have licenses for the United States. --Adamant1 (talk) 08:45, 12 September 2024 (UTC)[reply]

Either restart archiving, or stop updating, mobile upload deletion tracking pages

[edit]

When a user lists a file for deletion using the AjaxQuickDelete or VisualFileChange widgets, and the file was originally uploaded from mobile, those widgets add the files to lists on these pages:

Both of these pages used to be archived by CommonsMaintenanceBot, but this process stopped in 2021, and the pages are now unreasonably large. This leads me to suspect that these pages are no longer being used.

Is anyone still using these pages? If so, can someone set up a bot task to start archiving them again; if not, can we stop adding files to them from the AQD/VFC widgets? Omphalographer (talk) 23:03, 29 August 2024 (UTC)[reply]

I wrote about this at Commons talk:Mobile app/deletion request tracking. If the list still serves some purpose (I don't know about that), I can do the archiving, albeit irregularly. whym (talk) 19:08, 1 September 2024 (UTC)[reply]
I see no reason to archive. Who looks at this old stuff ? Just blank the page. It's more efficient, and leaves less clutter in the searchindex. —TheDJ (talk • contribs) 21:15, 3 September 2024 (UTC)[reply]

Notifications when one's uploaded files get used

[edit]

I think more feedback would make contributing much more fun and keep people engaged and facilitate them to contribute more, have a positive experience and remain motivated. There are several kinds of interactivity / feedback here, some already are implemented, some would be difficult to implement well, and some are probably not overly complex to implement with nearly no downsides but many advantages and high usefulness. I think is of the latter kind.

On Wikipedia, one can already get notified when pages wikilink to an article one has started. This is simply interesting to the person who created the article and encouraging.

Could similar notifications be enabled for when files one has uploaded get used on another Wikimedia project? It could show a This file {filename link} is now in use notification for either all file-uses or the first use per file.

One could enable/disable these notifications in the preferences, like on can for when a WP article is linked (and maybe at some point one could also exclude a select subset of one's uploaded files where one would like to not be notified). Inexperienced contributors don't learn when or whether their files are being used which must be pretty discouraging and boring; it also does not provide feedback which of their files is what is probably among their most useful (encouraging more of these). One can currently see which of the files one has uploaded are used by putting them all in one category and then using a tool like GLAMorgan but I don't think there's a way if one's files are not in a category and that sends a notification when (best shortly after) a file gets used. Prototyperspective (talk) 22:49, 4 September 2024 (UTC)[reply]

  •  Support Although weakly. It's an interesting idea but I'm not to sure how useful it would actually be in motivating people to contribute to the project more. There's also already enough issues with ownership on here that I feel like this exacerbate. There's no practical reason why someone needs to be notified if one of their images is used or not somewhere. They don't really "own" or have any control over the images after uploading them anyway. Or at least they shouldn't. --Adamant1 (talk) 00:06, 5 September 2024 (UTC)[reply]
    Yes, they don't need to be notified but it's encouraging further contributions and making contributing more engaging. I don't think this would exacerbate problems but there could be some issues when people feel like the media they uploaded (or created and then uploaded) is used in a 'wrong' way. However I don't think it would be a significant/big problem (very rare and then solved on the article talk page / by other editors changing it) and the advantage that they could also spot mistakes in the file caption for example could easily offset that potential problem. People can already see when their files are used and I haven't heard this caused many problems, this would just make file-uses more widely and quicker known. Prototyperspective (talk) 00:18, 5 September 2024 (UTC)[reply]
    I think Jmabel asked on the Village Pump awhile ago if there was a way to search for files that are in use by a particular uploader. I feel like that would probably be a better way to do this. As I think there's a general interest in knowing who's files are being used where. All a notification does is let the person who uploaded the files know though. I don't think your whole that it would help for files that are being used "in a 'wrong' way" is really that valid either since uploaders have a tendency to be control freaks who think their contributions are being used wrongly regardless if they are or not. I could really care less if an uploader on Commons thinks a particular usage is "wrong." What matters if the person on Wikipedia's end who added it to the article and has prior experience in the area thinks it's correct. --Adamant1 (talk) 00:28, 5 September 2024 (UTC)[reply]
    When it comes to complex scientific illustrations and so on people can easily get things slightly wrong. It may be rare that some correction/adjustment is due and that the uploader checks the caption and implements such but I think minor talk page drama will be even rarer as I don't think uploaders have a tendency to be control freaks and haven't seen much or even anything supporting that (and that despite that people can already bulk check which of their files are in use). I think it would probably be best if there were two checkboxes in the Preferences – one about all notifications when a file is used and one for the first use of a file – with only the latter being the default. Probably half of the time if not more often, the uploader doesn't even see the notification because they stopped using the site and uploaded the files 5+ years ago. Prototyperspective (talk) 23:14, 5 September 2024 (UTC)[reply]
    I don't necessarily have an issue with it in that case and a few others, which I do ultimately support the proposal. But I still think the potential for something like this leading to more drama due to some uploaders having control issues is a problem even if that hasn't been your experience. I've certainly seem myself. Although admittedly not that frequently but it still happens. --Adamant1 (talk) 23:19, 5 September 2024 (UTC)[reply]
Two remarks:
  1. See Glamtool GLAMorous for the use of your (or anyone else's) uploads: fill in the user name, click on Show details and Do it! So you do not need to put them all in one category for this reason.
  2. It think this is a wish that you best can post on meta:Community Wishlist.
JopkeB (talk) 04:26, 5 September 2024 (UTC)[reply]
I think this should not be done through notifications but through the Growth dashboard that on Wikipedia already shows how often the edited articles are viewed. GPSLeo (talk) 05:53, 5 September 2024 (UTC)[reply]
@JopkeB Great, thanks – seems like I used to miss clicking on Show details with that tool. Don't know if it's a good idea to have that not be the default without any info about it on that page because "Show details" is not self-explanatory. Maybe I'll propose it in the Wishlist.
@GPSLeo I don't see a growth dashboard on Wikipedia so I don't know if that is still upcoming or only for some subset of new users. It seems to be on Wikipedia only but this is about and specific to WMC (and I would support having a similar dashboard here). Having both would be best imo where the user could choose which one to enable/use. Prototyperspective (talk) 23:26, 5 September 2024 (UTC)[reply]
Wikipedia can notify a user when an article they created is linked from somewhere.
supposedly settings can be tweaked by wmf to let the same kind of notification happen for files on commons? RZuo (talk) 14:24, 6 September 2024 (UTC)[reply]
 Support I would like to know if my uploads are being independently used without periodically checking individual files or relying on external gadgets. Dronebogus (talk) 15:02, 9 September 2024 (UTC)[reply]
 Support Sounds fair (had something similar in mind). Can be turned off if not needed. --PantheraLeo1359531 😺 (talk) 16:29, 10 September 2024 (UTC)[reply]

UPI template

[edit]

I've seen some UPI images at Category:United Press International photographs, with a lot of them having the same copy-pasted reasoning for the permission, basically saying that UPI didn't register copyrights or publish their photos with notices (see File:Roméo LeBlanc 1979.jpg). Deletion requests seem to support that, although newspapers can be able to have notices which would make it copyrighted (see Commons:Deletion requests/Files found with Bettmann). I was wondering if there should be a template similar to {{PD-US-not renewed-TIME}} with the notice from Category:United Press International photographs/the copy-pasted permissions text and the note about how it could have a notice but on the newspaper itself. reppoptalk 05:19, 9 September 2024 (UTC)[reply]

No idea why this is in "Proposals" rather than "Copyright", but as I understand it UPI images were distributed widely to newspapers etc., which itself constituted publication. At that point I would think copyright was lost, and it certainly could not be regained if some (or even all) of those newspapers chose to add a copyright notice when publishing. Alternatively, if I'm wrong about that: if any significant number of papers routinely published without copyright notice and were not enjoined, that would also probably place that published content in the public domain. - Jmabel ! talk 04:33, 10 September 2024 (UTC)[reply]
I just put it in proposals as I didn't know where templates should go lol. reppoptalk 19:53, 10 September 2024 (UTC)[reply]
@Clindberg: do you have any thoughts on this before someone creates a template? In particular, do you think my reasoning above is flawed? Anyone else you think we should bring in for their opinion? - Jmabel ! talk 15:49, 11 September 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=923259904"