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.

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 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]
  • not fully convinced yet; maps are both media (like drawings, the current position) and a topic or at least part of various topics in both society and science. Cartography (and maps) is a subfield of "Earth Sciences" , in the "Sciences" menu, albeit it's of course applied sciences. Maps are also important subfields of "Places", "History" and "Politics" in the "Society" menu, and I don't see why they wouldn't even partially fit under the "Nature" menu. Let's also not forget the "by location" rider!
    So, I could imagine to keep "Maps" under "by type", but the "(Atlas)" - the single gallery page in that whole Content Box - could be moved to the entry "▶By location (Atlas)". --Enyavar (talk) 11:21, 17 September 2024 (UTC)[reply]
    Of course it can be seen in many ways, but I'm thinking about accessibility. If you are looking for paintings, you click "Art", then "Art by medium", and then "Paintings" (that said, I think this could also be simplified; "Art" -> "Paintings" would be fine). For maps, you click "Earth sciences", and you don't see anything about maps, or even a category where you can find "Maps" root category inside. Maybe if "By type" section was expanded by default, as "By topic" is, would be much more accessible. MGeog2022 (talk) 13:01, 26 September 2024 (UTC)[reply]
Yeah I don't know. I've looked into this and thought about it more at least a couple of times since it opened and the fact is that how the front page is laid out isn't very super intuitive or user friendly to begin with. So you could move things around, but I feel like it needs a better design and overhaul for any minor changes to be meaningful or make a difference. --Adamant1 (talk) 13:31, 26 September 2024 (UTC)[reply]
Yes, maybe a full revision of main page is needed. I started talking about this on Village Pump's main page, and now we have ended up having this (half-abandoned) proposal, this comment on Talk:Main page, and maybe something more elsewhere, and maybe to get nowhere. I have some regret about starting this whole thing. MGeog2022 (talk) 19:24, 26 September 2024 (UTC)[reply]
@MGeog2022: I wouldn't be that doomer about it. There's lots of stuff on here that's worth bringing up but just not actionable at the time. Probably someone will bring up something similar in the future though. It happens. You at least pointed out something that needs to be improved even if there's no solution to it at this point. That's the important thing. --Adamant1 (talk) 11:55, 28 September 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]
I think we rather need measure to automatically revert such edits Absolutely yes. I think the risk of losing well-intentioned IP edits in Commons is quite low (for example, I had edited Wikipedia as an IP user many times before I registered, but I've never thought of editing Commons as an IP user). MGeog2022 (talk) 21:27, 26 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]

Simple edit confirmation

[edit]

Instead of a CAPTCHA it is also possible to show a warning and require the user to confirm their edit. I would propose to make a one week test where we show IPs a warning "You are publicly editing the content of the page." and they have to hit the publish button again but with no CAPTCHA. GPSLeo (talk) 15:59, 26 September 2024 (UTC)[reply]

 Support Makes more sense. I think it's worth giving that a try but one week is short so somebody would need to have a good way of tracking relevant changes and creating some stats to see whether it's been effective. Or are there any better ideas what to do about Unregistered or new users often moving captions to other languages? Prototyperspective (talk) 20:58, 26 September 2024 (UTC)[reply]
 Support A month is probably better though. --Adamant1 (talk) 21:05, 26 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]

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]
 Support -- Ooligan (talk) 16:04, 30 September 2024 (UTC)[reply]
 Oppose I would like to get notified about disuse as well. Otherwise this proposal sounds like unnecessary “gamification”. Good files get used. And, more importantly, remain in use. ‑‑ Kays (T | C) 07:35, 8 October 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]

The reasoning there is somewhat correct, in that virtually all photos published by UPI before 1989 are public domain for lack of copyright notice. But the key word is published. Getty acquired the UPI archive, which doubtless includes many photos that had never been published before. So we can't make a blanket statement that photos from the UPI archive are public domain. Any photo on Commons should include some evidence that the specific photo was published without copyright notice, to satisfy COM:PRP. If there were to be any template for photos that don't have such evidence, it should be a cautionary disclaimer template to warn potential re-users that the photo's PD status hasn't really been established. (That's just my opinion; the Commons community would probably lean more towards deletion rather than disclaimers.) Toohool (talk) 17:27, 14 September 2024 (UTC)[reply]

Strickt overwriting rule for adding or removing transparency

[edit]

With the darkmode being added to Wikipedia the fact if a graphic has an white background or a transparent background is getting very important. I think we can expect many users overwriting or requesting to overwrite files with a transparent background to add an white background as the graphic is not readable with dark mode without a background added though other ways. To avoid trouble on this I propose the following clarification to the Commons:Overwriting existing files guideline:

  • Adding or removing a transparent background is always considered a substantial change requiring upload as a new file.

GPSLeo (talk) 06:57, 15 September 2024 (UTC)[reply]

 Oppose I support the spirit of the proposal but I think that changing an image to remove the white background should not require upload as a new file in many cases. I would support it if it was only about removing transparent backgrounds. I think transparent backgrounds are better for many reasons, mainly one can readily use them in other images using the existing background or giving it the background one wishes it to have. It can be a real hassle or not worth it to add some image with a white background into an image like an infographic with another background. It's similar to why SVG is preferred over jpg files. Concerning dark mode, I think technical changes are needed so that transparent background images are readable on it. Is there any issue for that? One shouldn't have to resort to changing the background to be able to view images with transparent background in dark mode – it could set a greyish white as the background or inverse the font color if dark mode is enabled. Prototyperspective (talk) 11:17, 15 September 2024 (UTC)[reply]
If you make the background of a graphic transparent every page where the graphic is used needs to be adapted to make the file readable in dark mode. This is possible but if someone overwrites a file no one on a Wiki where the file is used will get notified. They have to switch to dark mode and look on the page to see that something changed. With upload as new file and then using universal replace there is an edit on the page that notifies the users that something changed. GPSLeo (talk) 11:51, 15 September 2024 (UTC)[reply]
I think the software needs to be so that pages don't need to be adapted. However, maybe it's only made so that people can specify whether the background is transparent and the text black manually such as specifying it where it's used e.g. [[File:..|thumb|transparent]] so that's a good point – I would support if this was changed so that one can upload as a new version with transparent background if the file is either not used in any Wikimedia project or one adjusts all of these uses to be dark mode compatible. By the way one can check for used transparent background images here (may be dysfunctional). Prototyperspective (talk) 12:09, 15 September 2024 (UTC)[reply]
  •  Comment presumably if the original was created and uploaded by a still-active Commons user, they can consent to a change, no?
  •  Comment in some cases, the best solution may be a 1-pixel white border. - Jmabel ! talk 15:49, 15 September 2024 (UTC)[reply]
 Support. If the readability of transparent images on a dark background is an issue, this should be addressed at a technical level, e.g. through a MediaWiki feature request to allow images to be displayed with a solid background (e.g. [[File:Transparent image.png|thumb|background=white]]). Replacing transparent images to work around the lack of this feature is not appropriate. Omphalographer (talk) 21:29, 19 September 2024 (UTC)[reply]
Do not add a white background to this symbol. Make a new file with a different foreground.
  •  Oppose The background should not be a part of the illustration. For example, if a symbol happens to have a white background, then it should be OK to overwrite the image with a transparent background. I do not see that as a substantial change. If a flag is supposed to have a white background but happens to have a transparent one, then it should be OK to overwrite the file with a white background. That would be a correction rather than a substantial change. If a file's black marks disappear into the background in dark mode, that is not a reason to rewrite a transparent background to white. In that situation, there should be a new file, but that new file should not have a white background (the background is not part of the image); instead it should change the foreground color to contrast with the dark mode. Glrx (talk) 03:28, 20 September 2024 (UTC)[reply]
  •  Oppose - the general idea is okay and reasonable, but I'm unhappy with the word "always", when the main concern is that a black-on-transparent graphic becomes invisible in dark mode. But let's suppose a typical yellow/orange emoji-graphic on white background. Switching the white to a transparent background would be better to support both modes, to no detriment for the readers. Ergo, this is a case of "it depends". A lot of graphics may even have to be tweaked to support dark mode as well; so allowing adding/removing backgrounds would be beneficial. The rule should be that adding/removing backgrounds in graphics is a substantial change that needs to be carefully done with both bright and dark modes in mind. --Enyavar (talk) 04:24, 20 September 2024 (UTC)[reply]
  •  Support I think. If recently uploaded, it's fine to change, particularly by the uploader. But in general, adding or removing a transparent background always has the potential to break existing usages, and we'd prefer both options be available. Even an emoji which would work in light or dark mode may not work if it happened to be on a yellowish background for some reason (with a white background). It may make sense to have a default background color in image boxes, which remains light even in dark mode -- for non-transparent images it would make no difference, but a default of a lighter color (unless changed intentionally) probably would preserve most image usages in dark mode just fine. Carl Lindberg (talk) 05:08, 20 September 2024 (UTC)[reply]

Redirect undermaintained Species Galleries to Category pages

[edit]

Hey all, I have been thinking about this for a while so wanted to put it out there.

I have been watching a lot of the Taxon galleries and have been noticing a pattern:

  • the vast majority of them have less than 10-15 pageviews a month, some as few as 0 or 1, and have barely any information -- nearly 90% of the time, it has less Taxonomic information than Wikidata, which in turns means that the gallery page is far less informative or easy to translate than the Category Wikidata Infoboxes, which include all of the identifiers currently used in special templates on the gallery pages.
  • Moreover, almost all of the gallery pages haven't had any images updated since ~2013-14. This means that most of the time, images are low quality or don't represent the biodiversity very accurately. Especially on taxons, there has been a lot of subsequent work to partner with Natural History organizations, Flickr or INaturalist to add additional photography and media, and the editors working on taxon categories have been far more active.
  • Additionally, by both having a Commons Category and a Gallery page, it targets navigation from Wikipedias and other sources using interwiki links towards the less useful set of media files.

I propose that we redirect the Gallery pages to their corresponding taxonomic category, if:

  • The page contains less than 500 bytes
  • Hasn't been edited since 2016 (or hasn't had more than 2 edits since 2016)
  • and has less than 15 pageviews a month

I have a sample query with Petscan of the kinds of taxons pages this would include. And based on massviews for the first 20000 or so of these gallery pages, I estimate that we would probably be redirecting ~ 80% of the pages if we only used the pageview criteria, the other two will reduce it substantially but make it easier to evaluate the quality of the remaining ones.

Once this step is done, we could look at the remaining taxon Gallery pages to evaluate if they are providing sufficient value to users or are worth trying to maintain. I get the impression that there would be a second tranche of redirects if we are thinking about reader value and maintainability, Sadads (talk) 13:55, 19 September 2024 (UTC)[reply]

Pinging a few users that have been editing the pages, or responding to my first few dabblings in doing this manually : @Prototyperspective @Mateus2019 @JopkeB @‎Llez, @MPF, @AnRo0002 Sadads (talk) 14:01, 19 September 2024 (UTC)[reply]
 Support Agree 100%; the gallery pages no longer have any useful value, and most of them should be redirected to the relevant category, or deleted. I'd also widen the criteria for inclusion somewhat, to say 'Hasn't been edited more than 2 times in the last 8 years', so subsequent small maintenance edits (e.g. for replacement or removal of deleted or misidentified files) doesn't prevent redirection. - MPF (talk) 14:15, 19 September 2024 (UTC)[reply]
I would endorse that switching from "Hasn't been edited since 2016" to "'Hasn't been edited more than 2 times in the last 8 years'" -- that would definitely be a better scope for getting rid of unmaintained stuff, Sadads (talk) 14:33, 19 September 2024 (UTC)[reply]
 Support the proposal as specified for the reasons given. Prototyperspective (talk) 14:57, 19 September 2024 (UTC)[reply]
Another major issue here not mentioned so far is that in the MediaSearch under "Categories and Pages" by default galleries are also shown. Depending on the search phrase, there's often many of them. Especially in such cases but also in general, this means category and help pages are buried underneath so people, especially people not yet very familiar with WMC, won't find them. Gallery pages seem to show up there near the top and most of them are not useful and even when they are I think it's rather unlikely people using that search searched for galleries there. When I search for categories (less often also help pages or prior discussions) I usually go there and then click Namespaces and then select Custom and unselect Gallery. New users and unregistered people casually browsing the site shouldn't be expected to find that. As a solution I'd propose moving galleries a bit down in these search results and what's proposed here would probably also substantially contribute to making that search much more useful. Prototyperspective (talk) 23:03, 24 September 2024 (UTC)[reply]
That's certainly a problem. Right now if you look for "roses" it's impossible to ever to any categories in the search results because there's 2,000 galleries for every minor sub-species. I'm not sure if making galleries show up lower in the results would work though. Since there's probably always going to be more categories having to do with a particular subject then galleries. Meaning galleries will just end up being hidden at the bottom. The better solution is having standards about it and not letting people create galleries in mass for every minor subject. Admittedly I haven't looked into these galleries that much, but at least the ones for roses seem to have been created in a semi-automated way as part of paid editing campaign or something. So I doubt there's much chance of it being duplicated. Probably the same applies here. There's almost zero chance of someone creating 40,000 or however many it is unless their using a bot or something. So there just needs to be better standards and regular review of new galleries once the current crop is cleaned up. --Adamant1 (talk) 00:38, 25 September 2024 (UTC)[reply]
That's a good example. It doesn't even show the category of the exact same name, Category:Roses, near the top but only underneath a pile of likely irrelevant galleries. To clarify: I didn't mean that all categories come first and then all galleries below them – just that their relative relevance is decreased and I don't know if the Wikimedia search algorithm is transparent/open. So galleries would still show high up if they are very relevant such as having a name that matches the search term 1:1, just not so many at the top and maybe only below a few most-relevant cats. One could also consider things like reserving the top 3 search results for category and help pages and several other things like that. Standards and what has been proposed here would help a lot and may be more helpful in that regard compared to improving the search engine algorithm but both things can be done and if the latter is implemented that may take quite a while until it's applied. Prototyperspective (talk) 10:34, 25 September 2024 (UTC)[reply]
@Prototyperspective: Maybe it would be worth just disabling galleries in the search results by default like they do with talk pages and the like. I doubt anyone uses the search to specifically look for a gallery right off the bat and they show up in the drop menu anyway. So it doesn't seem like it's necessary to even show them in list of results to begin with. At least not by default. --Adamant1 (talk) 17:56, 25 September 2024 (UTC)[reply]
I would support that. Prototyperspective (talk) 17:57, 25 September 2024 (UTC)[reply]
I think it would be useful to have some data how much of the traffic for Galleries is from Search vs Interwiki Links vs Google + referrals -- my bet is the later two are a much higher driver of traffic than the search, but it would be good to know if a decision like that would reinforce evidence of galleries in Decline-- this should be part of a followup set of discussions related to galleries, Sadads (talk) 18:35, 25 September 2024 (UTC)[reply]
 Disagree
So problems are that a lot of Taxon galleries are less useful because they have old images, are small, have not enough information and have less than 15 pageviews a month. Is that the case? Why is it a problem that:
  • old images are used? Do organisms change overtime? Do the images not show good enough what an organism looks like? I always thought that organisms do not change a lot within a century.
  • they are small? The number of 500kb also means that even a gallery page with eight images, like Penstemon gracilis, would be emptied. Up to now we have used a limit of one image (a gallery page with one image may be deleted, one with two or more should be kept).
  • offer not enough information? Add a Wikidata infobox and you have access to all the information that you may wish for within the Wikimedia family. For me a gallery page is also useful for a quick view: a visual answer to the question what is the subject about (and not having to click on many subcategories within a category), and then maybe click through for more information.
  • they have less than 15 pageviews a month? Commons is not a commercial organization where only images or gallery pages may stay that have a minimum use or pageviews. Gallery pages in the end of the long tail can also be useful and valuable.
And I totally disagree with MPF that gallery pages have no longer any useful value and most of them should be deleted. I use them often and in general I find them useful. JopkeB (talk) 16:25, 19 September 2024 (UTC)[reply]
When it comes to your example, the gallery is not more useful than the category page. It's less useful and has several other issues such as newly uploaded images added to the category not showing up in it. Prototyperspective (talk) 16:32, 19 September 2024 (UTC)[reply]
It is not about this example, it is about gallery pages with eight images that might be deleted when these criteria are used. JopkeB (talk) 16:41, 19 September 2024 (UTC)[reply]
Good point, thanks for clarifying. Maybe the minimum should be lowered but I support a 500 bytes minimum and find it quite a good choice. Prototyperspective (talk) 16:45, 19 September 2024 (UTC)[reply]
@JopkeB The example you share of Penstemon_gracilis is a perfect example of where the gallery has less information that the Category (exact same pictures, less information). And a good example of where we have already 8 different other pages where you could get the same data (5 Wikipedia articles, A Commons category, a WikiSpecies page, and a Wikidata item). The page has been used 185 times since 2016, whereas the category has been used 103 times. We have basically split the audience, but created twice the work for the volunteer editors maintaining the page. Moreover, the Gallery would require an editor to actively maintain the page to include new novel information, such as images in Category:Penstemon_gracilis_-_botanical_illustrations, Sadads (talk) 18:06, 19 September 2024 (UTC)[reply]
Ditto to @Sadads, the Penstemon_gracilis page @JopkeB cites is a perfect example of why the galleries are useless; that gallery includes no information at all that is not in the category, and omits several things that are in the category, like filenames and file sizes.

Also well worth mentioning (which it hasn't been yet), is the complexity of renaming when a taxon is renamed (e.g. a change in the genus a species is in, or a former subspecies changed to a species): the presence of a gallery double the amount of work to do. This is a major problem with the massive backlog of taxonomic updates needed on Commons. - MPF (talk) 19:28, 19 September 2024 (UTC)[reply]
 Weak oppose
Yesterday and today, I checked roughly 430 of those pages. Most of them are not real gems of our project. That brings me to my main point: Commons is a project just like the Wikipedias. Some day, a colleage fills out one page and another time, someone else populates another one. Readers can jump to the main category anytime. A solution would be a contest "who illustrates / populates" poor taxon gallery pages - or a focus on taxon pages for a month (the 3 best users get a virtual ribbon). At the German Wikipedia, we have writing contests (e.g. Asia) but at Commons, there are only a very few (image contributions of a certain topic, or QI, etc.). I wonder what happened to the peoplz who created this mass of pages ... -- Did they all drop out? --Mateus2019 (talk) 16:58, 19 September 2024 (UTC) ← has no biology background beyond school education back in the 1970s to 1990s.[reply]
They may no know of categories and it takes an extra click that many won't do if the first page doesn't show already useful media. It could be that many of these have been created by bots but I haven't checked. In any case they hide the media in the categories. Prototyperspective (talk) 17:07, 19 September 2024 (UTC)[reply]
Yeah the problem is that the Categories and Infoboxes on the categories are much easier to maintain, higher value information resources -- and there is not a lot of editors working on the Galleries for the taxons (40k of them) and there is not a really compelling case to be made to work on them, when the categories and infoboxes do most of the work. Sadads (talk) 17:56, 19 September 2024 (UTC)[reply]
In my opinion the function of a gallery page is NOT to be complete nor to show all the available information about a subject, but to show a fine selection of all the media in relevant categories. Many categories show media of low quality, or media that look a lot alike, or have many subcategories where gems are hidden. In a good gallery a selection of the best media is shown, including the hidden gems of the subcategories, all to see at a glance. And they may have other funcions, see my list at Commons talk:Galleries#Add "criteria for creation of galleries" section to guideline. Categories and galleries are complementary to each other. In the case of toxan galleries they might give a quick glance of different aspects of a species.
What kind of maintenance is needed for gallery pages? JopkeB (talk) 04:01, 20 September 2024 (UTC)[reply]
To start with almost all of the ones I am encountering, have super low quality images, that could be better represented by new media that are higher resolution or a featured image. However, I also keep finding galleries with 1-3 images, that exactly replicate the category -- sometimes featuring quality images -- also not helpful if they don't help the reader get oriented to the topic. This is part of the reason I am suggesting a criteria of 500 bytes: larger than that, and there is usually some kind of meaningful description or "orientation to the topic" that would be lost -- usually its superficial, but at least there are captions, sections and some kind of filtering going on. Wheras the smaller ones (especially those without edits or pageviews), basically don't show the best of commons -- leading to the kinds of confusion of unfamiliar readers/editors/community members suggested above, and also to the neglect of maintenance of things like translation. 10:00, 20 September 2024 (UTC) Sadads (talk) 10:00, 20 September 2024 (UTC)[reply]
  •  Support I've been going through and adding categories to species galleries the last couple of days. Most of them totally pointless and have no way of being expanded because there isn't enough files on here having to do with the species to begin with. One thing that I think should be done with a lot of these small, unmaintained galleries is that they get up-merged to ones for the broader topic. A good example of that is the galleries in Category:Gallery pages of roses, most (or all) of which only contain a couple of images and have zero way of being improved. There's just always a tendency to take everything down to the lowest possible point on here for some reason though.
Regardless, there's no reason most (or all) of those galleries couldn't just be gotten rid or up-merged into one for roses in general, instead of us having to deal with, improve on, and maintain 2309 galleries for every single minor sub-species. Realistically we just don't have enough people who are interested in the area to improve the galleries. Let alone enough images to make it worth putting the work into to begin with. So I'd totally support just redirecting or deletion them in absence of a better alternative. I don't think they be kept as is indefinitely just because though. At the end of the day there should either be a clear, reasonable way to improve them or they should be gotten rid of however it's done. --Adamant1 (talk) 07:25, 20 September 2024 (UTC)[reply]
I agree completely. Small, specialized categories rarely deserve a gallery page of their own. Upmerge galleries to form a decent gallery corresponding to a parent category. I think Romanian Orthodox churches in Bucharest is a good example of doing this at the right level. Yes, many of these churches have categories of their own, but few deserve galleries of their own. - Jmabel ! talk 15:10, 20 September 2024 (UTC)[reply]
@Jmabel could you clarify if your specific comment is on the Roses or more generally in support of the taxons proposal? Sadads (talk) 16:31, 20 September 2024 (UTC)[reply]
Anywhere there is an analogous situation. One of the best features of galleries is that they allow us to juxtapose images from subcategories and help people identify what they are looking at without having to dig into a bunch of separate categories. Tiny, sparse gallery pages don't help with that. - Jmabel ! talk 20:02, 20 September 2024 (UTC)[reply]
 Support. Galleries make sense where there are enough images related to a broad topic that it becomes helpful to call out a few really good examples, or where there's some structure to a set of images which is difficult to show in a category. A great example of both is gallery pages for cities, where the page will often be organized around points of interest in the city, and will pick high-quality images from subcategories to illustrate each one. Creating galleries for species categories which only have a few images to begin with is a waste of time; there's no additional curation or organization that can be offered. Omphalographer (talk) 16:38, 20 September 2024 (UTC)[reply]
 Comment @Sadads commissioned me to write a Quarry query for this project ^^ https://quarry.wmcloud.org/query/86509 should implement the first two conditions, i.e. list small pages (for taxon galleries) with few edits since 2016. (I slightly tweaked the second condition to avoid including pages that were created post-2016 but had ≤2 edits.) The third condition, pageviews, isn’t available in Quarry, so someone™ will have to do that externally. But I hope this helps :) Lucas Werkmeister (talk) 17:27, 24 September 2024 (UTC)[reply]
All the galleries I've checked barely had any views. So I doubt it matters. The most important things are the size of the galleries and number of edits. --Adamant1 (talk) 17:32, 24 September 2024 (UTC)[reply]
@Adamant1 I ran it through massviews, and its less than 100 of the galleries have more than 15 pageviews in the last 30 days, Sadads (talk) 17:50, 24 September 2024 (UTC)[reply]
And, on average, the galleries have less than 3 pageviews a month, Sadads (talk) 18:11, 24 September 2024 (UTC)[reply]
That seems like a compelling argument for removing most of the small, unmaintained galleries. Omphalographer (talk) 00:41, 25 September 2024 (UTC)[reply]
The main issue is figuring out what makes a gallery qualify as "small" or not. It seems there's some resistance when it comes to galleries containing more then one image being deleted, but that seems like an extremely myopic and arbitrary place to draw the line. I've certainly seen plenty of galleries that weren't any more valuable just because there was one or two extra images. --Adamant1 (talk) 00:48, 25 September 2024 (UTC)[reply]
@Adamant1 @Omphalographer I think the byte count is really telling, the more I look into this (I ran @Lucas Werkmeister Quarry, without the limit to the Taxon Galleries: https://quarry.wmcloud.org/query/86513 -- and sampling from other generes/themes, low byte count = no captions, sections or sufficient contextual data to be useful in a way that is more helpful than a category page, right around 600 bytes you start getting sufficient description or complexity (i.e. multiple images in multiple sections). Sadads (talk) 00:52, 25 September 2024 (UTC)[reply]
That being said, I think the consensus in this discussion is on the taxon content, if we want to do the other topics I think we should start another discussion (once the taxons are gone, it will be easier to see what is being neglected here, Sadads (talk) 00:56, 25 September 2024 (UTC)[reply]
That sounds reasonable. I think around 600 bytes is a good place to deal with it at and then we can review and clarify where the final line should be from there as needed and/or with other topics. --Adamant1 (talk) 00:58, 25 September 2024 (UTC)[reply]
To Summarize:
  • Sort criteria for the purge are:
    • that the gallery is less than 550 bytes. I'm splitting the difference here between the 2 most popular proposals.
    • Less than 2 2 or less (see Adamant1's comment below) edits in the last 8 years.
  • Wikidata infoboxes for all the subspeices should be on the catagory pages.
  • The gallery policy should be updated and possibly changed to increase the quality expected of gallerys, and to require RFC (or equivalent, i.e. Village pump/propsals) before any form of mass gallery creation starts.
  • Organise and editathon (or similar) to perform all the taxanomic updates needed.
    • Make a method for editors/permission holders to help conribute.
Please let me know if I missed anything.
All the Best -- Chuck Talk 01:45, 25 September 2024 (UTC)[reply]
That sounds fine except I'd change the edit count to "two or less" since from what I've seen a lot of galleries get superficially edited by a bot at some point and I don't see why it should matter. --Adamant1 (talk) 01:59, 25 September 2024 (UTC)[reply]
@Alachuckthebuck I think the Wikidata Infobox is not a firm requirement before the redirects -- there are already several hundred that need to be fixed in Category:Redirects_connected_to_a_Wikidata_item -- I think the requirement is something we can fix afterwards, because we are going to need to fix the interwiki link mapping, and subsequently the addition of Infoboxes to some of those pages (it also simplifies the bot or AWB run to do it). I think the more important requirement is that the gallery is in a category that has the same name, Sadads (talk) 02:02, 25 September 2024 (UTC)[reply]
Makes sense, that was more summarizing the discussion, less about updating policy.
@Adamant1 Consider it implemented. All the Best -- Chuck Talk 02:48, 25 September 2024 (UTC)[reply]
Thanks. So what's the next step here assuming it has the support to be implemented? --Adamant1 (talk) 19:57, 25 September 2024 (UTC)[reply]
someone (probably me in a few hours) adds a new section summarizing the discussion into a set of suggestions under a new heading, then let that run its course. Then an uninvolved admin closes, and we start implementing the changes technically, probably will need someone on the WMF side to help with this, @Sannita (WMF), Who would be the right person to talk to for somthing of this scale server side? All the Best -- Chuck Talk 20:55, 25 September 2024 (UTC)[reply]
@Alachuckthebuck A summary of the discussion would be most welcomed, so that I can try to help you with the request. Please ping me when you are (or who will do the summary is) done with the summary. Sannita (WMF) (talk) 11:14, 26 September 2024 (UTC)[reply]
Never mind, I saw you already did it. Thanks! Sannita (WMF) (talk) 11:15, 26 September 2024 (UTC)[reply]
I am not sure that we need WMF support @Alachuckthebuck if we do a Bot, that does it incrementally over time at Commons:Bots/Work_requests, Sadads (talk) 13:56, 26 September 2024 (UTC)[reply]
If its done by a bot incrementally, CVN tracking becomes infinitely more difficult. All the Best -- Chuck Talk 16:28, 26 September 2024 (UTC)[reply]
CVN? Sadads (talk) 14:48, 29 September 2024 (UTC)[reply]
@Sadads: CVN is the Counter Vandalism Network of the Commons:Counter Vandalism Unit.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:29, 29 September 2024 (UTC)[reply]
Interesting @Alachuckthebuck & @Jeff G., why would redirects by a bot effect CVN? My understanding from bots on other wikis is that you can have their actions either autopatrolled, or clearly labeled with the bot label.
I have made a request, and maybe someone can do it easily (i.e. @Mike Peel?) Commons:Bots/Work_requests#Redirect_Galleries_per_Concensus, Sadads (talk) 12:26, 30 September 2024 (UTC)[reply]
@Sadads: AWB actions by my bot account are certainly flagged that way, but there are certain actions (generally with VFC, Cat-a-lot, or manually) that I do for Commons:Bots/Work requests with my main account, which is not flagged that way.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:38, 30 September 2024 (UTC)[reply]
All deletions go into the CVN-bot logs. those logs were the only indication that something was off when we had the whole Vietnamese artist mass no permission tag fiasco. All the Best -- Chuck Talk 14:41, 30 September 2024 (UTC)[reply]
We could also ignore bot edits, minor edits, and edits that only change categories. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 25 September 2024 (UTC)[reply]
I support that, assuming cat edits only include Hotcat and Cat-A-lot/other cat tools with edit tags (for technical reasons, makes sorting automatically possible without regex) To paraphrase into policy/technical speak:
  • Edits made by flagged bots, those marked as minor, and edits tagged with Hotcat,Cat-A-Lot or another catagory tool do not count toward the 2 edits or less threshold for inclusion.
Let me know if I missed anything. All the Best -- Chuck Talk 20:33, 25 September 2024 (UTC)[reply]
+2. That sounds reasonable. --Adamant1 (talk) 22:04, 25 September 2024 (UTC)[reply]

Summary Proposal by Alachuckthebuck

[edit]
  • (After purge and renames are complete) Add Wikidata infoboxes for all the subspecies should be on the category pages.
  • The gallery policy will be updated and changed to increase the quality expected of galleries, and to require an RFC (or equivalent) before any form of mass gallery creation. This needs proposal on the gallery talk page.
  • Organize a Backlog Drive after purge to perform all the taxonomic updates needed.
    • Make a method for editors/permission holders to help contribute to the drive who are not familiar with this topic area.
  • The first paragraph of the gallery policy has the sentance: Galleries must have a valid reason for creation, and not just be simple copies of categories, A selection of media from a large category, or a collection of categories, is acceptable. added to the end.
  • The first paragraph of the section When to create a gallery in the the commons' gallery policy has the sentence" The Bar for the creation of galleries is higher than categories, and a valid reason for creation is required for mainspace galleries. to the end of the paragraph.
  • Purge the Taxon Galleries with the following criteria:
    • The gallery is less than 550 bytes
    • 2 or less edits in the last 8 years (must be created before 2020 to apply). Edits by Flagged bots, Marked as minor, Cat-A-Lot, or HotCat do not count towards this limit.

All the Best -- Chuck Talk 02:56, 26 September 2024 (UTC)[reply]

Your final bullet point should exclude minor edits also. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 26 September 2024 (UTC)[reply]
@Pigsonthewing Done. All the Best -- Chuck Talk 16:28, 26 September 2024 (UTC)[reply]
Can someone close this? There appears to be a consensus to implement at least some of the proposals. All the Best -- Chuck Talk 17:17, 8 October 2024 (UTC)[reply]

Idea: Create eliminators file right

[edit]

The proposed policy page is here.

Currently we are only slightly backlogged, with 1087 DRs that are >1 month old as of speaking and who-knows-how-many CFDs. We also don't have that many active administrators (10-20). Here's why I think having eliminators would be useful.

Most of the backlogged DRs and CFDs (especially CFDs) are uncontroversial. These can be closed by most semi-experienced users. By having an eliminator role, we can reduce these backlogs without the extensive trust required for users to become admins. I have drafted a policy page, and have made the requirement per Commons:Eliminators#Rules for usage that eliminator actions must be accompanied by a speedy deletion tag set by another user or an uncontroversial/supported by consensus deletion request by another user to avoid the chances of false deletions.

I just want to gather initial thoughts on this idea so we can proceed further if it is viable. —Matrix(!) {user - talk? - uselesscontributions} 20:21, 26 September 2024 (UTC)[reply]

 Oppose despite the work overload for administrators, I think that anything that increases the risk of deletion of legitimate content should be avoided. I remember that the first (and to date, the last) time that I tagged files (uploaded by me) for deletion, due to a change of format, I thought: "Why is this so complex? I uploaded them myself only a few weeks ago, why can't I just delete them?". But I quickly realized that, however unfriendly it was for novices, it was necessary for it to be so. Once a file is uploaded, it can be used by anyone, it doesn't belong to you as uploader. I uploaded those images, among other things, to contribute in preserving them, so it makes full sense that it isn't so easy to delete them. MGeog2022 (talk) 21:08, 26 September 2024 (UTC)[reply]
 Support Anything to lighten the load on admins is a good thing, but there should be a limit to how long discussions can run before closing, in addition to a minimum length(2 days at least) to avoid someone slipping under the radar. If this gets approved, I volunteer to be the test user for the whole process. All the Best -- Chuck Talk 16:53, 27 September 2024 (UTC)[reply]
@MGeog2022, Undeletes are cheap, and if we have a seprate log for eleminiators, its easy to patrol edits. I only ever see there being 5-10 eliminators at any given time, as most people who would be eliminators are already admins. We @Matrix, what are your thoughts on requiring LR before getting eliminator, and allowing these users to grant autopatrol? All the Best -- Chuck Talk 16:56, 27 September 2024 (UTC)[reply]
I think it's best not to tie this right to license reviewers. There are Commons users that are familiar with copyright, but have no interest in reviewing files from Flickr. Furthermore, the implied journey of normal user -> autopatroller -> patroller -> LR -> eliminator is simply too long. A user's ability to interpret deletion policy and requests can be judged by previous DR history and questions from other users during the process. As for allowing these users to grant (but not remove) autopatrol, I think this is an all right idea in theory, considering license reviewers can grant (but not remove) license review status for other users, but in practice we don't really have that big of a backlog at COM:RFR so it would be quite redundant.
Also your statement that "there should be a limit to how long discussions can run before closing" is already happening: per COM:DR DRs must be open for 7 days before closure. —Matrix(!) {user - talk? - uselesscontributions} 17:43, 27 September 2024 (UTC)[reply]
I was referring to requests for the right, not for DRs. The autopatrol granting is because some editors (who are fantasic!) don't have autopatrol, but their (perfectly fine and above board) edits clog up RTRC, and dealing with that problem is where I see the utility (or just allow LRs to grant autopatrol.) Please let me know if I missed somthing. All the Best -- Chuck Talk 17:52, 27 September 2024 (UTC)[reply]
@Alachuckthebuck, OK, if eliminators are few and very trustable,  Support. I do know that deletions can be undone, but the problem with deletions, unless other editions, is that deleted files can't be viewed any more (except for very few privileged users), so a wrongly deleted file would not be so easy to detect (also, even if undeleted, most of its previous wiki uses wouldn't be restored, so some damage would already be done). MGeog2022 (talk) 19:22, 27 September 2024 (UTC)[reply]
@MGeog2022, If an image is in use on a wiki, than the deletion threshold is a lot higher, and In-Use images can only be deleted as copyvios, vandalism, or advertisements. That's it. As to undoing deletions, "deleting" a file on commons just hides it from the majority of users, and undeletion just unhides the file. Currently, I can think of about 4 users who would be given this right by the community, and never expect it to go above 20 unless commons becomes bigger than en-wiki. All the Best -- Chuck Talk 21:09, 27 September 2024 (UTC)[reply]
But 10 is the max I ever expect to see (including bots) hold the right. All the Best -- Chuck Talk 21:12, 27 September 2024 (UTC)[reply]
@Alachuckthebuck, false positives in copyvio could take place if people without enough knowledge could delete files. But, from what you say, it's about having less than 10 (very trusted) people as eliminators, to reduce workload to administrators. So, certainly, I  Support, then. MGeog2022 (talk) 12:45, 28 September 2024 (UTC)[reply]
 Oppose Proposed and declined dozens of times. Krd 20:20, 27 September 2024 (UTC)[reply]
And why do you oppose, other than proposals have failed before? All the Best -- Chuck Talk 21:10, 27 September 2024 (UTC)[reply]
For the same several good reason shown in previous discussions. Krd 04:13, 28 September 2024 (UTC)[reply]
No least: If the potential eliminators would just use the same time for commenting on deletion request, the problem was also resolved. More rights don't help to solve resources issues, but more active users do. Krd 06:35, 28 September 2024 (UTC)[reply]
@Krd, How do comments help make closing DRs easier? If its an open and shut case, an eliminator can close the DR, rather than commenting "Delete as (Generic reason here), Could have been CSD", and wait for an admin to come along and close. If its more complex, then they can comment as community members. But the majority of DRs don't need 5 community members, they need someone who has the technical ablity to delete the file to close the DR, and delete the file. If community members can close DRs as speedy keeps (and only a few even do this due to the effort involved in manually closing a DR as keep), why can't they close 7 day old DRs that should have been CSD tagged? That's the role of Eliminators: allowing admins to focus on the DRs that tend to stay open for weeks, rather than the 50 Open and Shut cases. All the Best -- Chuck Talk 23:57, 28 September 2024 (UTC)[reply]
Because the open snd shut cases are not a problem at all, but the difficult ones are. Krd 04:25, 29 September 2024 (UTC)[reply]
Thats why eliminators should exist, allow the admins to not worry about the simple stuff and just focus on the Difficult DRs. And also allow a path to increasing the size of the admin corps. Its a win-win All the Best -- Chuck Talk 05:58, 29 September 2024 (UTC)[reply]
Chuck, we admins can always close more open and shut cases, those are not the biggest issue in our backlog, the difficult ones are often open the longest because we need specialized information or it's not clear-cut on whether or not it fits a copyright exemption. We definitely want more non-admins to be active in DRs. Some of our most trusted users are not admins. Abzeronow (talk) 18:38, 29 September 2024 (UTC)[reply]
@Abzeronow: Are there categories for the difficult ones?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:45, 30 September 2024 (UTC)[reply]
 Oppose Anyone I would trust with this right, I would trust as an admin. The Squirrel Conspiracy (talk) 04:09, 28 September 2024 (UTC)[reply]
 Oppose : Exactly as The Squirrel Conspiracy says. - Jmabel ! talk 15:29, 7 October 2024 (UTC)[reply]
 Neutral :- @Matrix, In my opinion, unbundling the toolkit is not a solution. I would suggest that the community should take initiative and pitch potential candidates for RFA. That way it will ease the task for the community to decrease the backlog. Thanks --C1K98V (💬 ✒️ 📂) 04:32, 28 September 2024 (UTC)[reply]
I was talking to someone about doing that a few months ago but it seems like there just isn't any users on here would qualify, maybe some users from Wikipedia but I don't think anyone would vote for someone who isn't active on here even if they would be fine otherwise. --Adamant1 (talk) 11:45, 28 September 2024 (UTC)[reply]
some users from Wikipedia: I think this is a very good idea. If there are copyvio images in Commons and they are used in Wikipedia, this is is also a problem for Wikipedia, so it's of interest even for Wikipedia-only community members. MGeog2022 (talk) 12:50, 28 September 2024 (UTC)[reply]
Then I assume you're looking for potential candidates at the wrong place. Without RFA you're reaching to conclusions is not fair (community views might differ). Thanks C1K98V (💬 ✒️ 📂) 13:04, 28 September 2024 (UTC)[reply]
@C1K98V: I'm more then happy to look over a list and give my opinion on the candidates if you want to email me one. I spent a good amount of time a few months ago researching users on here to see if any of them wanted to apply for adminship though and couldn't find anyone who would qualify. That's not to say their isn't anyone, there were two users I thought might be able to pass an RFA at the time, but the pool of potential candidates is clearly extremely low. I don't even think there's that many active users on here to begin with. Let alone anyone who's untarnished enough to be an admin. --Adamant1 (talk) 17:27, 28 September 2024 (UTC)[reply]
 Oppose. I do not like such unbundling / fine divisions of labor. In addition, an eliminator could not undo her own mistakes. Glrx (talk) 13:12, 28 September 2024 (UTC)[reply]
 Oppose Deleting as important to the administrator's toolkit as blocking and protecting. I can only think of two people whom I wouldn't trust with the block button but with the rest of the tools. Basically, if they're trusted enough to delete and undelete, they are trusted enough to be administrators. Also, I'll note there really is not a RFR backlog, at least one request is being kept open so the requestor can get more edits. I'm also aware of a future RfA from a trusted user whom I would support. Abzeronow (talk) 21:03, 28 September 2024 (UTC)[reply]
Even if we only get two more people helping with the backlogs, thats two more people helping close DRs. Adminship is supposed to be Not a Big deal. This "admins are gods" mindset is everywhere on commons, and anything we can do to reduce that mindset is a plus. All the Best -- Chuck Talk 23:45, 28 September 2024 (UTC)[reply]
I would definitely encourage more people to become admins. I don't agree with "admins are gods" mindset, and as stated, backlogs exist for reasons other than number of admins. I've got at least three DRs that I can't close yet because I need information on the ToO of Serbia. Abzeronow (talk) 18:38, 29 September 2024 (UTC)[reply]
Here's a paradox: many users are too humble to consider applying to be sysop, whereas those who do often have big ego and cannot restrain themselves. (same is true for politics and management in real life, but there are more checks and balances. here users are often anonymous; positions are for life; participation is voluntary = bad money drives out good.)
so i have 2 suggestions:
  1. for the 1st part of the paradox: let's hold a "nomination call" once a year. users list names that they trust to be sysops.

    hope is that a listed user seeing the support they have will have confidence to apply.

  2. ease Commons:Administrators/De-adminship#Activity to "who has made 0 admin action on Commons in the past 12 months".
RoyZuo (talk) 15:24, 2 October 2024 (UTC)[reply]
The whole bad admin part doesn't exist right now, but the first part made sense. Would you be willing to be bold and be the first person to make such a list in userspace? All the Best -- Chuck Talk 15:33, 2 October 2024 (UTC)[reply]
Totally a side thing, but realistically how many new admins do either one of you think there needs to be for the backlogs to get dealt with? --Adamant1 (talk) 23:40, 4 October 2024 (UTC)[reply]
I think at least 20 more. I'd take part in a "nomination call" as I can think of a few users that I'd like to see as sysops. Abzeronow (talk) 17:34, 5 October 2024 (UTC)[reply]
That sounds about right. I have a list of 5 or 6 people I've been sitting on for a while now. Maybe we could create a special page or something for finding people and nominating them for adminship where we can list everyone. Although I'm hesitant to name people publicly or nominate them for the role if they don't want to be admins in the first place. But there's certainly people out there who would clearly qualify. There just needs to be a more organized, intentional effort to find them and make them administrators. --Adamant1 (talk) 17:46, 5 October 2024 (UTC)[reply]
@Adamant1, 20-50 depending on what backlogs you are talking about. And about 100 LRs working full time on the Flickr backlog All the Best -- Chuck Talk 23:25, 5 October 2024 (UTC)[reply]
Yall can do it now Commons:Administrators/Nominations. RoyZuo (talk) 14:05, 6 October 2024 (UTC)[reply]
 Comment it's essentially the main task of administrators. Why not just apply for that.
 ∞∞ Enhancing999 (talk) 22:10, 6 October 2024 (UTC)[reply]

Notice: LR's assigning LR

[edit]

Hello all. Putting in here for wider community involvement in a discussion about LR's granting the flag. Please do come around and contribute to the discussion at Commons talk:License review/Requests#Suggestion: Remove assigning of LR rights by LR. Regards, Aafi (talk) 06:07, 30 September 2024 (UTC)[reply]

Qualifiers for categories (which parts of videos)

[edit]

Here I'm proposing a way to sometimes specify to which parts of a video a category applies. Often categories only apply for a specific part of the video and it's just dumped into a category of files that are only about that or have that category as a main characteristic / subject throughout the video. For example a video containing a time-lapse clip may be in Category:Time-lapse videos even when 90% of it aren't in time-lapse. This can cause issues and there currently is no way to specify the metadata of which parts a category refers to.

Examples (see these first):

  • This video shows many animals at different points (e.g. Category:Videos of ants)
  • This contains a high-quality clip of a person using a smartphone normal for the early 2010s
  • This belongs into many subcats of Category:Drone videos by country even if it's appropriate to keep in the parent cat or in a cat like "Drone videos from many country"
  • This contains videos showing explanatory demonstrations of many different exercises (e.g. Category:Bench press)
  • Here @Kai Burghardt: added cat Videos from Rothenburg ob der Tauber with comment <!-- at 1:51 -->
  • This contains segments that are a drone video but it's not only a drone video. Same goes its cat Time-lapse videos of nature and its cat Videos of volcanic eruptions.

This could be implemented like sortkeys are implemented (which is [[Category:CatName|sortkey]]).

For example, one could specify which parts a category refers to like so (these are details that can be worked out): [[Category:Time-lapse videos|1:51]] or (better) [[Category:Time-lapse videos|1:51-2:23]]. One could also specify multiple segments e.g. like so: [[Category:Time-lapse videos|1:51-2:23,3:04-5:01]].

Files can also be sorted using the sortkeys but it's barely used and there's the risk people sort files in unexpected ways so people can't find stuff when looking through a cat alphabetically due to which replacing the sortkey functionality is something worth considering. However, one could also simply use another syntax instead of the well-known pipe for the segment-qualifier, e.g. [[Category:Time-lapse videos/1:51-2:23]] and in the very rare case that a sortkey is specified as well e.g. [[Category:Time-lapse videos/1:51-2:23|sortkey]].

Then of course there's multiple things that could be done with this valuable new data. I suggest that something is displayed next to these categories like a small timestamp and when clicking on it, it jumps to the video section of that timestamp using the neat temporal media fragment functionality (only instead of a link with ?start=1:12:30 it would need to be #start=1:12:30 so it doesn't reload the page but only jumps to that part of the video which is useful and needed and already possible on YouTube with its video chapter links).

One could also make the files show differently in the respective cat or get subcategorized automatically into e.g. 'Videos containing xyz' cats like "Videos containing time-lapse videos" so one can always see full time-lapse videos and videos only containing such separately or distinguish between these. Not right from start but at a later point one could maybe even make it so that video starts at the specified timestamp when opening the video from that category.

Note that people can also extract relevant parts into a new file, such as a clip or animated GIF about a particular fitness exercise for the category about that exercise from a long video about many exercises so setting the cats even when a file is not fully about something is usually useful. At a current discussion about Photographs of flags there was discussion about photographs where flags are only a minor subject. Trying to keep it short I think would solve multiple problems, be very useful, and substantially increase the data quality of WMC. What do you think? Prototyperspective (talk) 18:12, 30 September 2024 (UTC)[reply]

This sounds like a job for Structured Data, for example using time index (P4895) and duration (P2047) qualifiers on depicts statements; like this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 6 October 2024 (UTC)[reply]
Interesting but even if that was the case, this is about adding this functionality to the categories.
So if it was a widely used structured data property then this proposal would be about copying it from the structured data to the categories and adding this functionality at the category level in addition to the SD functionality. However, in contrast to categories (sortkey-like specifications thereof) I don't think the SD for that will ever be widely used (read, maintained, or written). Prototyperspective (talk) 17:41, 6 October 2024 (UTC)[reply]
Yes; I know that your point is "about adding this functionality to the categories". My point is that a tool to record the relevant metadata already exists, so investing the effort into creating a duplicate tool - especially given the limited developer resources we have - is probably redundant. Your suggestion that SD "will [n]ever be widely used" is bizarre. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:55, 6 October 2024 (UTC)[reply]
  • It's not duplicate. For example, you can't see see items in a category which only partially include the subject of the category.
  • SD are barely used and most users don't use them. Vandalized SD stays as is even for some of the most popular media files included in several large WP article because barely anybody watches changes to them or looks them up. Moreover, many files have false SD and nearly/virtually all of them have not nearly as much in metadata in the file as there is in the categories which are well-maintained and easily navigable and that even for new users.
  • The suggestion that people could instead go to the structured data enter some depicts statement and then set some qualifier for it where nearly all contributors never set any qualifier for some structured data property for a media file is bizarre in the sense of ignoring reality and wishful thinking. Even if people (ie readers and contributors) knew about structured data and actually used it (and I have enough items on my Watchlist to know contributors don't), then they still wouldn't know about or use the "time index" qualifier. I hypothesize that there's less than 40 files where this qualifier has been used out of the many millions of files on Commons and that for these items less than 5% of viewers of each file (not even considering the category) have actually benefited in any way (e.g. read the qualifier or have come across the file in contextualized way) from that SD being set.
  • If you think about this in terms of technical hypothetical possibility then I suggest you reconsider it in terms of this being about making functionality useful and used.
Prototyperspective (talk) 19:14, 6 October 2024 (UTC)[reply]
I've been thinking about this for a while now and can't for the life of me figure out how it would actually be implemented. Except for maybe creating subcategories of main sujects that have time stamps in their names. Like "videos of horses (1 minute into video)" or something but that seems less then optimal to say the least. I'm really strapped as to how else it could done besides through structured data though, which I agree isn't great at this point. But realistically how else would you do it aside from creating specific categories containing time stamps? --Adamant1 (talk) 21:36, 6 October 2024 (UTC)[reply]
  • how it would actually be implemented ... how else it could done besides through structured data though Well what do you think of what is proposed here? I've been thinking about this for a while as well.
  • how else would you do it aside from creating specific categories containing time stamps? if you're talking about specifically how it could be made available to the end user, then please see: there's multiple things that could be done with this valuable new data. I suggest that something is displayed next to these categories like a small timestamp and when clicking on it, it jumps to the video section of that timestamp using the neat temporal media fragment functionality (only instead of a link with ?start=1:12:30 it would need to be #start=1:12:30 so it doesn't reload the page but only jumps to that part of the video which is useful and needed and already possible on YouTube with its video chapter links). One could also make the files show differently in the respective cat or get subcategorized automatically into e.g. 'Videos containing xyz' cats like "Videos containing time-lapse videos".
Prototyperspective (talk) 22:08, 6 October 2024 (UTC)[reply]
I mean, you mentioned using sortkey with times. I'm not really clear on how it would work or fix the problem though. I don't think the idea of putting small timestamp would work either. I assume whatever solution you want to go with would have to be something that can actually be done with the current software. Otherwise your just proposing theoretical solutions that have little, if any, chance of being implemented. Not to say that's anything with developers, but from what I've seen the back end software running this seems to be pretty limited and there aren't even people maintaining exiting third party things like the crop tool at this point. So it seems like the only semi-workable options are doing it through structured data or categories. --Adamant1 (talk) 00:03, 7 October 2024 (UTC)[reply]
I am proposing a technical feature – a change to the software, apparently you misunderstood what this thread is about. Yes, there's too few developers and many of them work on niche products or subjects and I made a list of suggestions on how to change that which I think is the responsibility of the WMF and 'step 1' imo. Volunteer devs may also pick it up and there's also people who currently develop gadgets – this page is open for everybody to read. Here I made the case for it and described the technical concepts, sadly the chances of it getting implemented any time soon may be low nevertheless. Prototyperspective (talk) 23:04, 7 October 2024 (UTC)[reply]
I understand perfectly fine. I just don't think it can or will be done through a technical feature by changing the software. That's all. Although I do think it's possible to implement something similar with exiting features, but you clearly don't agree and that's fine. At the end of the day there isn't one single best way to fix things and probably a lot of it can or should be done through incremental steps on our end while we wait for the developers to change the software.
Either that or you could just say screw it and write a long winded essay about something that has almost zero chance of ever happening, at least not any time soon. Whichever. It's your choice since it's your idea to begin with. I'm just saying I think there's other ways to go about it besides a backend change to the software. Why don't you a open Phabricator ticket for this and see what kind of reception it gets though? Who knows maybe it would be a quick, easy thing to implement. --Adamant1 (talk) 01:17, 8 October 2024 (UTC)[reply]
Yes exactly, maybe it could something that is relatively quick and easy to implement (e.g. since the sortkey functionality is already there). I'll open a phabricator issue at some point but thought it would be a good idea to discuss these here and explain why it would be useful and how I think it could work – for example maybe somebody had an idea on technicalities of how the added metadata could be made available to the user such as e.g. adding a tooltip saying partial relevance to items to the respective file-titles in the respective category. This is not an essay but a technical specification of an idea/proposal with info on how it could be implemented as well as why it would be useful. Prototyperspective (talk) 08:54, 8 October 2024 (UTC)[reply]
@Prototyperspective: Fair enough. I didn't think about it working with the exiting sortkey functionality. And I'm not trying to say there's anything wrong with discussing it or laying out the details of how it would work. It's easy to lose people in the details though and I suspect the length of your original message is one of the reasons it's gotten so few responses. Which is to bad, because it's a good idea in general even if I disagree with some parts of it. I probably could have just worded the message better. I am interested to see if it's something the developers would want, or be able, to implement though. --Adamant1 (talk) 22:35, 8 October 2024 (UTC)[reply]
@Prototyperspective: This is a use case for structured data. Categories are the wrong tool for that. At the moment, however, COM:DEPICTS documents a conservative, restrained tagging policy. When subtitling I recognized the street scene and I’ve added a category just not to lose that piece of information, not because categories were a particularly good tool for that. (Also I did not know which qualifier the depicts statement to pair with.) Andy’s tagging approach seems legit, though. ‑‑ Kays (T | C) 07:35, 8 October 2024 (UTC)[reply]
This is a use case for categories. Structured data are the wrong tool for that. I didn't say you added any category or find them to be a good tool. That you used them despite thinking without giving any reasons that SD is a better tool is just a perfect illustration that they're better. Prototyperspective (talk) 08:44, 8 October 2024 (UTC)[reply]
You have expressed the use-case as "a way to sometimes specify to which parts of a video a category applies". That is bad practice, because it focusses on a particular technology, rather than what the user wants to achieve. The correct way to express the underlying use-case would be "a way to specify which parts of a video show a particular subject". Categories are not the right way to do that, and SDC is. But you don't like SDC, so we have this waste of electrons and screen space instead of a rational discussion to progress the matter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:37, 8 October 2024 (UTC)[reply]
Categories are the right way to do that and you have given zero reason why that wouldn't be the case. I think SDC are largely redundant due to categories and a huge time sink that is not well maintained and misses most data that is already in the categories. A rational discussion would be good – that I think consists of making points and addressing points. I don't think you have done so here. The explanation of how it could theoretically but not in practice be achieved to a small extent (e.g. not seen and used by readers) using SDC was constructive but that's about it. Prototyperspective (talk) 12:40, 8 October 2024 (UTC)[reply]
It's kind off topic, but at least IMO they aren't mutually exclusive and will probably coexist with each other for a while until structured data is more ubiquitous and user friendly. At the end of the day something like this probably can and should be done with both though. --Adamant1 (talk) 22:39, 8 October 2024 (UTC)[reply]

Commons:Deletion requests/mobile tracking

[edit]

Is Commons:Deletion requests/mobile tracking still necessary?

  1. how many active users watch or use it occasionally?
  2. any developers use it? (supposedly to check upload quality so they can tweak the software to reduce problematic files?)

i dont have stats, but i guess the proportion of uploads from mobile devices must be much higher than the page started before 2013. what's the percentage of commons users who mainly use mobile versions? 40% (my rough guess)? is this page still meaningful when a substantial number of users use mobile?

i propose the DR gadget stop listing new DR on this page. RoyZuo (talk) 15:43, 2 October 2024 (UTC)[reply]

@Alachuckthebuck: I don't see anything in the information for the bot saying it has anything to do with this. Can you clarify exactly how it helps the bot track things? --Adamant1 (talk) 21:38, 3 October 2024 (UTC)[reply]
It's used for analyzing bot edits after the fact, and also can help with RFCU and LTA detection. All the Best -- Chuck Talk 21:42, 3 October 2024 (UTC)[reply]
Uploads from mobile devices will still be tagged in logs. Disabling the automatic edits to the mobile tracking page won't change that. And I still don't understand how this relates to that bot. Omphalographer (talk) 03:30, 4 October 2024 (UTC)[reply]
I stand corrected, I thought that would remove the log tag. All the Best -- Chuck Talk 03:46, 4 October 2024 (UTC)[reply]

distributed_by

[edit]

Can we add "distributed_by" to structured_data? It currently gives the message: "The property distributed by should not be used on this type of entity, the only valid entity type is Wikibase item." We have over 1,000 news articles that were published_by newspapers, but they were distributed by the Associated Press or United Press International. We have even more images from both entities. RAN (talk) 18:21, 8 October 2024 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=935639998"