Commons:Village pump/Proposals/Archive/2022/10

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

Allow interface administrators to set the content model

PASSED:

The editcontentmodel right will be added to the interface-admin group. For the Phabricator ticket, see phab:T320752 4nn1l2 (talk) 18:44, 13 October 2022 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I propose to add the editcontentmodel right (Edit the content model of a page) to the interface-admin group (Interface administrators). Currently, that right is exclusive to regular administrators (compare Special:UserGroupRights); this means that interface administrators who aren’t also regular administrators cannot fulfill certain edit requests – whenever a page that should be JavaScript has a title not ending in .js, as is common for the i18n of some gadgets, see e.g. MediaWiki talk:Gadget-Cat-a-lot.js/ne or MediaWiki talk:Relgen.js/i18n/sr. There are currently two interface admins who aren’t sysops, Putnik and myself; IMHO it would be good to grow that number (not every technically competent gadget developer needs to have access to admin tools, as long as they can be trusted not to abuse interface admin privileges), and empowering non-sysop interface admins to do more relevant work on their own means less work for the other administrators. On several other wikis, the editcontentmodel right has been granted to template editor (enwiki, mrwikisource, viwiki) or engineer groups (ruwiki, cswiki); as far as I can tell, there isn’t yet another Wikimedia wiki where interface administrators have the editcontentmodel right, but I assume this is only because the separation between regular and interface administrators is relatively recent, not because it’s a bad idea in principle. Lucas Werkmeister (talk) 18:45, 4 October 2022 (UTC)

 Support, this is a no-brainer. In fact I believe it should be done globally for the entire group (but don't let that suggestion derail any local decision here, changing things like this globally would take a lot more time). Jon Harald Søby (talk) 18:52, 4 October 2022 (UTC)
 Support sounds very reasonable to me. Jean-Fred (talk) 20:19, 4 October 2022 (UTC)
 Support It seems logical to me. - Nikki (talk) 20:23, 4 October 2022 (UTC)
 Support good idea. Raymond 05:21, 5 October 2022 (UTC)
 Support, good idea.   — Jeff G. ツ please ping or talk to me 00:26, 6 October 2022 (UTC)
 Support, do not see why not.--Ymblanter (talk) 05:47, 7 October 2022 (UTC)
 Support --Krd 06:41, 7 October 2022 (UTC)
 Support Christian Ferrer (talk) 10:39, 7 October 2022 (UTC)
 Support Agathoclea (talk) 10:43, 7 October 2022 (UTC)
 Support Completely reasonable. — Huntster (t @ c) 13:09, 7 October 2022 (UTC)
 Support. Interface admins are trusted to edit JavaScript, so they should also be trusted to declare existing pages to be JavaScript. Indeed, I wonder if this right should be removed from sysops, since it seems to provide a way to bypass the usual restrictions on editing JavaScript... --bjh21 (talk) 14:17, 7 October 2022 (UTC)
 Support Ruthven (msg) 06:41, 9 October 2022 (UTC)
 Support, trusted users who were specifically split from regular administrators because they were expected to fulfil these functions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:15, 10 October 2022 (UTC)
 Support Totally non-controversial, helpful, and consistent with the user right. —Justin (koavf)❤T☮C☺M☯ 09:19, 10 October 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --4nn1l2 (talk) 21:40, 13 October 2022 (UTC)

Size option for Global replace

I had proposed a size option that should be included in the Global replace function. SpinnerLaserzthe2nd (talk) 17:55, 7 October 2022 (UTC)

@SpinnerLaserzthe2nd Sorry, I do not understand what you're proposing here and why. You'll have to provide a bit more information. Greetings, El Grafo (talk) 07:05, 13 October 2022 (UTC)
Never mind. SpinnerLaserzthe2nd (talk) 08:01, 13 October 2022 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --El Grafo (talk) 08:52, 13 October 2022 (UTC)

Tracking file usage on RegiowikiAT

On Commons talk:Tracking external file usage I've just proposed adding RegiowikiAT to the list of wikis that Usage Bot tracks file usage on. Please leave comments there. --bjh21 (talk) 00:07, 6 October 2022 (UTC)

Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. proposal accepted, code deployed --El Grafo (talk) 13:16, 17 October 2022 (UTC)

photos Quarry

Which kind of photo can I upload? — Preceding unsigned comment added by Altanvir10 (talk • contribs) 12:29, 11 October 2022 (UTC)

See Commons:Welcome. Basically, freely-licensed media that has educational value. —Justin (koavf)❤T☮C☺M☯ 12:38, 11 October 2022 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --RZuo (talk) 22:08, 4 November 2022 (UTC)

Open letter

Hello, the open letter to the WMF is to be finalized. Kind regards, Ziko van Dijk (talk) 10:38, 9 October 2022 (UTC)

@Ziko: , a lot of this could actually be remedied by implementing a local Community Tech Wishlist (something which I have been proposing for years), unfortunately the Wikimedia Foundation (WMF) hasn't expressed any desire to launch one here locally and every year the consistently prioritise smaller wiki's. The German-language Wikipedia has its own local Community Tech Wishlist and the features requested there are available for all MediaWiki software-based websites. Unfortunately, I have no idea how to contact Wikimedia Deutschland (WMDE) to get separate Community Tech Wishlists for the Wikimedia Commons and Wikidata. Of course, simply hiring more technical staff or simply recruiting more tech savvy volunteers would also solve this. If anyone reading this knows how to contact Wikimedia Deutschland (WMDE) then please forward my idea for separate Community Tech Wishlists for the Wikimedia Commons and Wikidata. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:20, 10 October 2022 (UTC)
@Donald Trung Dear Donald, I use a lot of your pictures, thanks for that! - There was recently an online meeting of WMDE staff members who deal with the Community Tech wishlist. I suppose that they would answer you that WMDE only dares to build software improvements in contact with the German language Wikipedia community, but that Commons and Wikidata are the concern of the WMF. Anyway, I am sure that @Johanna Strodt (WMDE) or @Thiemo Kreuz (WMDE) are happy to talk to you. Ziko van Dijk (talk) 09:36, 10 October 2022 (UTC)
Ziko, Wikimedia Deutschland (WMDE) also does a lot for Wikidata. Unfortunately, I haven't seen them discuss the Wikimedia Commons that often. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:39, 10 October 2022 (UTC)
True. So, I don't know, just ask Johanna or Thiema, I'd say. Ziko van Dijk (talk) 09:41, 10 October 2022 (UTC)
Hello Donald Trung and thanks for the ping, @Ziko. I will take your suggestions to our software department. I'm mostly absent this week, so it might take a while until you hear from me again, but I will get back to you. -- Best, Johanna Strodt (WMDE) (talk) 09:45, 10 October 2022 (UTC)
Johanna Strodt, Alright. But I must stress that the proposal is for a low priority wishlist at first, so not much resources would have to be dedicated to it and initially only a handful of proposals be accepted if it's possible. If more interest exists then I think that if the WMDE or the WMF would be willing that they could invest more resources. But the initial proposal isn't to just copy the Wishlist Survey word-for-word. Not sure if I'm articulating correctly what I'm trying to say here. I understand that Wikimedia Germany doesn't have endless resources so most would probably be done by volunteers, but it could be volunteers working under the co-ordination of Wikimedia Germany. There are probably many cost-saving ways to implement this. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:53, 10 October 2022 (UTC)
  • A bunch of people have already signed it. There are aspects of the letter I find opaque as mud, so I won't sign it, in its current form.
  • Could the bulleted points be changes to numbered points, so people with questions about them could refer to them, by number? Geo Swan (talk) 19:22, 11 October 2022 (UTC)

Open letter to the Foundation about Wikimedia Commons

Dear friends of free knowledge,

Wikimedia Commons is in crisis. There are numerous concerns and complaints about our central media platform, for many years.

Therefore, this open letter asks the Wikimedia Foundation to Think big! about the future of Wikimedia Commons.

In late August 2022, we at the Commons Photographers User Group talked about Wikimedia Commons. The result of these and other talks is this open letter.

We invite everyone to sign this open letter to show how important Wikimedia Commons is to you. You may be a regular Commons contributor, a Wikipedian, an editor of Wiktionary or Wikivoyage, or maybe you represent an affiliation. We also strongly invite other people who are involved with Commons directly or indirectly, maybe in the context of a GLAM.

Please inform others about this open letter.

Kind regards, Ziko van Dijk (talk) 22:38, 10 October 2022 (UTC)

Shall registered users be notified via Mediawiki-notice in watchlists about the letter? I think this leads to more signatures. George Ho (talk) 23:42, 10 October 2022 (UTC)
I won't be signing it for one reason - WMF made a total cock-up of ENs en:Visual Editor so much so that nobody on the project wanted it and it was (and still is) utter crap to use, If WMF did anything it would only be a half arsed job and would be worse than what we currently have. What we have now is severely outdated but I'd rather have outdated than unusable. –Davey2010Talk 00:14, 11 October 2022 (UTC)
  • The open letter, if I understood it correctly, requests paid staff devote efforts to making the commons interface (1) easier to use; (2) support more powerful features. Oops, can these two requests really be met, at the same time? Maybe, if the implementers are geniuses. However, if I understood him, User:Davey2010 is saying the paid programming staff weren't geniuses, and made a dog's breakfast, with en:Visual Editor. I wouldn't know, as I only made a brief effort to try it out, and have stuck with the old editor.

    But the WMF paid programmers have made a mess of other things, like the moronic upload wizard. They have made dubious changes, to long-standing default settings, with no prior discussion, and without any advice how to reset our preferences so we can keep the system operating the way we are used to. Sometime in the last year or two some bright spark decided, without consulting us, to change how the search box works. Apparently the search functionality I got used to for over a dozen years is now known as "special search". Developers, I curse every time your unrequested "improvement" sends me to the new search results, not the search results I want. I curse you every time I use it.

    I am with Davey2010 on this one. I don't trust the current support staff.

    I will raise an issue related to this on Commons talk:Village_pump/Proposals#Issue related to Open letter to the Foundation about Wikimedia Commons, 2022-10-11.

  • Albert Einstein is supposed to have said something like: "Simplicity is beautiful. Everything should be made as simple as possible, but no simpler..."

    The WMF community should bear this aphorism in mind when thinking about requesting interface simplifications.

    How much of the time, when naive users complain interfaces aren't simple enough, isn't the real issue that the naive users have yet to make the effort to understand the inherent complexity of the tasks they are attempting? When naive users find an interface hard because they don't understand a complicating wrinkle in the underlying task, then, I suggest, simplification is not desirable, at all. Geo Swan (talk) 19:17, 11 October 2022 (UTC)

* "How much of the time, when naive users complain interfaces aren't simple enough, isn't the real issue that the naive users have yet to make the effort to understand the inherent complexity of the tasks they are attempting?" Excellent point, agree! And one of the largest continuous issues with new users is not understanding the basics of free licensed media. -- Infrogmation of New Orleans (talk) 21:03, 13 October 2022 (UTC)
  • nobody on the project wanted it and it was (and still is) utter crap to use does not line up with my experience. Back when the VE was rolled out, it was premature, loaded with bugs, and implemented too forcefully. I was among the many raising objections to the way it was forced before it was fully ready. A functional Visual Editor was definitely something people wanted, though, and the current version is that, more or less. It could be improved (ref names come to mind), but it makes a world of difference to new users in general, opening up the possibility of editing to large populations intimidated by the source editor. I haven't heard anyone complain about it in, well, years I think, and in the meantime have had many of the new people I work with tell me how easy/functional it is when the prospect of editing Wikipedia is itself intimidating. YMMV. That is to say, Visual Editor is an example of a good product implemented too soon and with inadequate community relations. There are plenty of reasons to mistrust the WMF, but when the foundation does something at least money is being thrown at it, hiring a team of people to work on it. The alternative is exactly what we want to get away from on Commons: an infrastructure of abandoned, unmaintained bits and pieces that volunteers jump in to donate their time/experience to for a while, and then linger after those volunteers no longer have the time. So many of our bots, our gadgets, our scripts, etc. frequently fail and need the kind of investment that only the WMF can provide. — Rhododendrites talk |  21:39, 13 October 2022 (UTC)
  • The letter states "Commons requires a good knowledge of English, even though it strives to be a multilingual platform." I do agree with this. Watching Commons from the start, I'm rather startled by how much this is so - and saddened, even though English is my own primary language. The footnote says "One example are the names of categories." I recall early discussion was to have all plants and animals in Latin per standard binomial nomenclature, (names of Popes also in Latin), other common nouns in simple English, and all geographic names in predominant local language, with category redirects as convenient. Unfortunately English (sometimes complex/advanced) has taken over, often in the name of "consistency" as an abstract goal, rather than usability as a practical one. We could certainly use more active translations. -- Infrogmation of New Orleans (talk) 21:16, 13 October 2022 (UTC)

Move Template:VN to Template:Vernacular names

in view of potential confusion with {{Vn}}, a redirect to {{Neutral}}, i suggest renaming this template to use the full name.--RZuo (talk) 18:37, 19 October 2022 (UTC)

Delink dead "Leave feedback" at https://commons.wikimedia.org/wiki/Special:UploadWizard

https://commons.wikimedia.org/wiki/Special:UploadWizard has "Leave feedback" leading to https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback with

"This page is presently inactive and retained primarily for historical interest. (...) you may try using the talk page (though your voice may not be heard) or start a discussion at the Village pump."

According to https://commons.wikimedia.org/wiki/Commons:Village_pump#Delink_dead_%22Leave_feedback%22_at_https://commons.wikimedia.org/wiki/Special:UploadWizard

"This is set as $wgUploadWizardConfig['feedbackPage'] in CommonSettings.php. If left out it defaults to linking to "UploadWizard's bug tracker", wherever that is[3]. Updating the link would require going through the procedure for Requesting wiki configuration changes, which usually starts with a proposal at Commons:Village pump/Proposals"

18:38, 18 October 2022 (UTC) Mateusz Konieczny (talk) 18:38, 18 October 2022 (UTC)

i suggest letting "Leave feedback" link to com:vp.--RZuo (talk) 18:37, 19 October 2022 (UTC)
Probably better COM:VP/T, plus a link to phabricator for people who feel comfortable reporting their own bugs. Maybe someone could set up a pre-filled form akin to the Wikidata Bug Report Template so that things end up in the right place automatically? El Grafo (talk) 09:18, 20 October 2022 (UTC)

Archive Commons:Flickr batch uploading as dead

I opened request there then noticed that last one was done in 2015. See https://commons.wikimedia.org/w/index.php?title=Commons:Flickr_batch_uploading&action=history (there are some later removals, but not because job was done).

Can we archive and delink this as a dead trap? And move still open requests to https://commons.wikimedia.org/wiki/Commons:Batch_uploading ? Mateusz Konieczny (talk) 10:53, 11 October 2022 (UTC)

I notified people listed as participants Mateusz Konieczny (talk) 11:06, 11 October 2022 (UTC)
" @Mateusz Konieczny: thanks for the notification. Go ahead and bury it." Mateusz Konieczny (talk) 19:34, 13 October 2022 (UTC)
I'd personally suggest to move this section to be a COM:RFC Liuxinyu970226 (talk) 04:41, 12 October 2022 (UTC)
Really? Delinking blatantly dead page that is utterly abandoned since 2015 seems quite obvious to me and just wanted to confirm it. Mateusz Konieczny (talk) 10:57, 13 October 2022 (UTC)
Nah, RFC is a zombie. This is the right place.
Commons:Flickr batch uploading is not even a zombie. Suggest to tag it as {{Historical}} to prevent people from wasting their time there. El Grafo (talk) 11:30, 14 October 2022 (UTC)

I made the first edits in [1] and [2] and [3] (feel free to revert it, if you think that it should be done with more waiting or more bureaucracy) Mateusz Konieczny (talk) 10:57, 13 October 2022 (UTC)

I plan to make further, without listing them here. They should be easy to find in my editing activity Mateusz Konieczny (talk) 19:51, 13 October 2022 (UTC)
i suggest processing all remaining requests and archiving them, then redirect the page to Commons:Batch uploading.--RZuo (talk) 22:08, 4 November 2022 (UTC)

Monthly notice of changes to the sysop team

i propose a monthly notice be compiled on VP, which tells of any sysop elected and any who resigns or is removed.

i was just looking at Commons:Administrators/Inactivity section/Aug-Sep 2022. 2 resigned and 5 were removed! but they just vanished without the community's attention. RZuo (talk) 11:40, 20 October 2022 (UTC)

@RZuo: Anyone interested can watchlist Commons:Administrators/Inactivity section and Commons:Administrators.   — Jeff G. ツ please ping or talk to me 20:24, 20 October 2022 (UTC)
I was thinking about starting Administrators' newsletter on Commons. -- CptViraj (talk) 05:13, 22 October 2022 (UTC)
I think it would be great to have a general newsletter with information about new proposals, new tools or other notable projects. GPSLeo (talk) 07:29, 22 October 2022 (UTC)
i'll proceed to starting this newsletter, initially with a focus on sysop changes.
i plan to name it "Commons Gazette".--RZuo (talk) 22:08, 4 November 2022 (UTC)

Adopt Commons:Depiction guidelines as a guideline

Proposal: Adopt Commons:Depiction guidelines as an approved guideline and have it listed on Commons:Policies and guidelines

Rationale. Whilst I know there are different positions and arguments on the topic, the absence of agreed general guidelines create confusion.

  • There is a first rather historical page where the general topic is introduced Commons:Depicts, which includes some historical recommandations (apparently outdated given the discussions I could read). This page also include good contextual information about what a depict is, how to add them, what it is useful for etc. In short, this page goes beyond guidelines.
  • There is a more recent page going into a lot of details, Commons:Structured data/Modeling/Depiction. Whilst the essence of it is good, the high level of detail, some unfinished or outdated examples etc. make it difficult to propose as a guideline page. It is also hard to find and maybe too complex a page for a newcomer or occasional contributor.
  • There is no easily found page that an occasional contributor could find to get the basics (for example, there is no mention of the topic on Commons:Policies and guidelines)
  • There is currently no page where we can point a newcomer to, for them a basic understanding of the topic.
  • And... of course... perhaps due to historical reasons and wishful hopes about Wikidata, there is no clear agreement about depicts addition, resulting in editors reverting others, which is simply... a loss of everyone time :)

Hence, the proposal to adopt a short and basic guidelines page, which is a curated version build on the two other pages and on discussions I could find out on talk pages. Thanks for your attention

Anthere (talk) 11:30, 28 October 2022 (UTC)

  • I appreciate this effort. In general this looks good. I added a couple little bits that I think are uncontroversial. My only objection is that it includes contradictory language. It says you should add multiple depicts (P180) statements, both general and specific then two paragraphs down it is recommended to add multiple depicts statements, both general and specific. However, this redundant tagging is disputed so please don't do it on a large scale.. Do it, but it's disputed so don't do it much? From what I've seen, the only reason it's disputed is because of (a) misunderstanding about what depicts is for, (b) misunderstanding its similarity to categories, and/or (c) carry-over best practices from working with categories. Can we just get rid of that "As a consequence..." line altogether and see how it goes? — Rhododendrites talk |  13:25, 28 October 2022 (UTC)
    Looks good to me. Anthere (talk) 20:42, 28 October 2022 (UTC)
    Hi, I agree with @Rhododendrites. I have edited these sections for more precision. Furthermore, I have added an example in the section on the differences between Structured Data and the Commons Category system. Beat Estermann (talk) 11:17, 2 November 2022 (UTC)
  • I think we should improve the original guideline draft and not create a new one, also for keeping the version history. --GPSLeo (talk) 15:59, 28 October 2022 (UTC)
  • But which original ? As I mentioned earlier... the first page include elements way beyond the guidelines and still include historical recommandations. The second would be more like it, but is a work-in-progress that would require serious work before being ok. A V2 ? None of those two pages will disappear. I will add a note in the talk page to better credit. Anthere (talk) 20:42, 28 October 2022 (UTC)
  • We may want to add a paragraph on where to use depicts (P180) and where to use digital representation of (P6243), and - if applicable - how to use them in combination with each other. Beat Estermann (talk) 11:26, 2 November 2022 (UTC)

So... about Commons:Depiction guidelines

  •  Support the current version of the proposal Anthere (talk) 06:53, 5 November 2022 (UTC)
  •  Support - a very timely guideline that adds to greater understanding of expectations of depicts, etc. Islahaddow (talk) 09:15, 9 November 2022 (UTC)
  •  Oppose - This is very different from what the current guideline, Commons:Depicts, says (emboldening in original): These generic "tags" should not currently be added if more specific depicts statements already exist We should not be recommending to tag a picture of bearded collie with "dog"; such use should be strongly deprecated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:22, 9 November 2022 (UTC)
    I tend to agree with @Andy on this. However, we should make sure that there is a subclass/superclass relationship between "dog" and "bearded collie" in Wikidata, which was not the case until I made the following edit. If the edit remains unchallenged, I would suggest that we adapt the example in the guidelines accordingly. Beat Estermann (talk) 12:31, 14 November 2022 (UTC)
    I have updated the guidelines. The issue pointed out by @Andy Mabbett should be resolved now.
    It might be useful to keep a list of relationships expressed on Wikidata, which software programs making use of depicts statements are expected to resolve on their side. At this point, I guess we would mainly expect them to handle subclass / superclass relationships, (failing to do so would lead to a situation where we would tend to clutter the metadata with quasi-meaningless depcits statements along every ontological tree), parent-child taxon relationships, "same as" relationships, and synonyms.
    Do we also expect them to handle <instance of> organisms known by a particular common name (Q55983715)? (this would be required to get from Rough Collie (Q38650) via dog (Q144) to Canis familiaris (Q20717272) or to Canis lupus familiaris (Q26972265)) - Personally, I think this is asking too much from software programs.
    -- Beat Estermann (talk) 15:44, 21 November 2022 (UTC)
  •  Support per what I wrote above. — Rhododendrites talk |  12:30, 9 November 2022 (UTC)
  •  Oppose The topic seems to be too fresh and too unsettled. We have skilled editors disagreeing about what should or shouldn't be added? If I have a picture of Winston Churchill taken in 1942, I need to add depicts man, prime minister, and WC? Let the structured data people get consensus about what should be done and then come back. Glrx (talk) 19:23, 9 November 2022 (UTC)
    • @Glrx: There is already consensus across the Structured Data on Commons people. There are just some Commons regulars who think it's inefficient and should work more like the category system. It does not work that way. The debate is really between using structured data on Commons like it's supposed to be used, having a whole bunch of different standards/expectations and winding up with a mess, or not using it at all. As far as I'm concerned, the first one is the only one that makes sense, and all of this "it's inefficient" business can always be redirected to lobby developers to build out some form of hierarchical depicts framework for the future. That does not exist now, and there are no plans for it to exist in the future (at least last I heard). It's been three years, and 99% entirety of the confusion around this is centered on the "but I want it to be hierarchical" argument, which was codified by a handful of Commons users working with incomplete information on that initial Depicts page + inertia. — Rhododendrites talk |  19:33, 9 November 2022 (UTC)
      But why should we use depicts (P180) for the general statements? Why not using two different properties? main subject (P921) also exists or we can create a new "tag" property. --GPSLeo (talk) 19:42, 9 November 2022 (UTC)
      Please don't dismiss our valid objections by mis-describing us in this fashion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 9 November 2022 (UTC)
      +1 --Beat Estermann (talk) 13:05, 14 November 2022 (UTC)
    I think it is important that we settle on a version of the guidelines that reflects the current state of discussion / rough consensus within the community - be it just for the very pragmatic need of having a basis for telling (new) users how to approach the issue in practice. In my opinion, having one common, admittedly imperfect version of the guidelines out in the open (e.g. by linking to them directly from help pages, the ISA Tool, etc.) is be better than having a couple of contradictory versions tucked away somewhere in the depths of the wiki.
    Regarding your concrete example: If the man on the image is known to be "Winston Churchill", there is no need to add "man"; this can rather easily be inferred from the information on Wikidata. Maybe we should come up with a list of common cases where we assume that the tools making use of "depicts" statements should be able to make the inference on their side.
    The "prime minister" part of your example is more tricky: I think there is currently agreement that we should not directly add occupation (or role) in depicts statements, but we are lacking clear instructions (at least in our current version of the guidelines) how exactly to express this type of relationship: <depicts> "Winston Churchill" <in the role of> "prime minister" (please correct me if I am wrong and a solution has already been found to deal with this issue). On second thought, the same issue would also apply to the Lassie example, "Lassie" being a role played by a specific dog. - In my view, the way forward is to accept some level of fuzzyness for now and to further refine our practice (and along with it the guidelines) as we move on.
    --Beat Estermann (talk) 13:01, 14 November 2022 (UTC)
    @Beat Estermann "Lassie" was a role played by a number of dogs, starting with "Pal" (who took the stage name of "Lassie") and continuing with descendants of that dog. See en:Lassie and en:Pal (dog).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:15, 14 November 2022 (UTC)
    There is "how it currently works, according to those who developed and run the structured data on commons team" and there is "how some Commons users think it should work". The guidelines should reflect how it does work, not how some people think it should/could/might in the future. The "issue" you're referring to is a desire for it to work differently. I don't disagree with the idea that it would be great to better integrate other properties, but whatever guidelines we have should reflect the current situation, and the people who implemented structured data on Commons say depicts for Lassie should include "dog". Anyone who wants it to change should work with the structured data on Commons folks, lobby for changes, and then, when they're ready, we update the guidelines. Last I heard, there were no plans to make depicts "inherit" higher level items (like dog from collie). Yes, it would also be nice to get some sophisticated AI to automatically detect the subject, too, but we shouldn't put "the AI will take care of it; don't add any categories" into a guideline. — Rhododendrites talk |  16:38, 21 November 2022 (UTC)
    "how it currently works, according to those who developed and run the structured data on commons team" I dispute that "how it currently works" is accurately captured by the proposal; and the views of the "the structured data on commons team" are of no special authority in deciding policy; it is the Commons community as a whole which is sovereign here. You do not speak for the "the structured data on Commons folks". "dog from collie" is already inherited by SDC, since it relies on Wikidata, where that relationship is encoded. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 21 November 2022 (UTC)
    No, I am not connected to the SDC folks and obviously don't speak for them. I'm relaying what I've learned from them across a number of conversations. But maybe I've missed something -- you're saying that a search for "dog" using depicts on Commons will return pictures of collies even if the word "dog" isn't mentioned in depicts, categories, description, or filename? If that's true then I've seriously misunderstood something, or perhaps that inheritance just isn't as consistent as we're used to? What am I missing? — Rhododendrites talk |  19:30, 21 November 2022 (UTC)
    I'm not saying anything of the kind. If I were you would read it in my post. However, your question - and your post below - implies an apparent fault with search, and if that is the case, search needs fixing; the solution is not to resort to crude keyword stuffing, and thereby irredeemably breaking SDC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:20, 22 November 2022 (UTC)
    The comments above reinforce the impression that the topic is not yet settled, so an official guideline is inappropriate. I do not buy the argument about describing how it works today. The comment suggests that the project does not have a clear idea of what it is trying to accomplish. I do not want the community told to do something today and then told what they should have done something else tomorrow. Glrx (talk) 19:10, 21 November 2022 (UTC)
    I think that's reasonable. I also think it's reasonable to want it to work differently. My hope is that one day we can get a full suite of well-integrated properties that are easy for people to add here. However, depicts is not something that's being workshopped for implementation in the future -- it's already here, and used by an awful lot of people every day. We should have clear guidance about how to use the tool that exists today without assuming that major changes will be made that allow it to work differently. This precise discussion has been going on for years now. Right now, unless I've missed something, a search for "dog" does not return collies based on depicts. if we don't want collies to show up in searches for dogs reliably, then tell people not to tag with dog. If we want collies to come up when someone searches for dogs, we should have them tag it as dog. Then, if it should work otherwise, start the work to make it work otherwise and update the guidance accordingly. If anyone is certain that development will someday come, then I suppose we can say that searching for dog will someday be able to return pictures of collies, so let's not bother adding "dog" now even if it means limited functionality in the short-term -- I would get that. I just don't support that because who knows when/if that will actually change. I'll make this my last comment here for a while btw. Don't intend to bludgeon. — Rhododendrites talk |  19:26, 21 November 2022 (UTC)
  •  Support Having two opposing sets of guidelines prevents new users from being able to use Depicts at all. While it would be great to have search use the hierarchy encoded on Wikidata the fact is that this isn't done and is also not likely to be done (thanks El Grafo for the link to the mailing list). Having broader depicts tags is still useful for multilingual search as the broader concepts are a) more likely to have many translations, b) more likely to be a term users actually search for. I'm personally not to worried about people tagging it too broadly if you make it clear in the guideline that you tag as broadly as you believe it would be useful to search. /Lokal_Profil 09:52, 1 December 2022 (UTC) (not with my WMSE hat on)
  •  Support I don't think it is technically complex task to do distinction between general and specific OR detect if there is already more specific tag already set. If we try to enforce this then it would be a problem when users are importing images from source databases and would try to import the metadata alas. From this point of view it would be much easier just to scrap the limitation. (I have coded "more specific category detection code for imports couple of times and based on these this feels like problems filled rabbithole which is too complex to follow for most of the editors ) --Zache (talk) 04:46, 7 December 2022 (UTC)

Depiction guidelines discussion: Comment from WMF Structured Data Team

  •  Comment Do we have any comment or knowledge from the mediasearch team on how they are using the data / how they would like to use it? Currently, it seems that we want to add more general and more specific level tags as it makes querying easier (maybe?). It also makes adding the P180 values easier (based on for example source databases) as you don't need need to handle things like detecting if there is a more specific tag already which is kind of a complex thing to detect automatically. However, it would be interesting to know if the mediasearch team which is using the data for multilingual search has an opinnion that more overlapping tags are better than fewer specific. -- — Preceding unsigned comment added by Zache (talk • contribs) 02:25, 29 November 2022‎ (UTC)
  • Question: is there any discussion anywhere of why searching down the hierarchy is difficult, and is being postponed to the indefinite future? It's not like the hierarchy changes all the time. It seems to me that it would be pretty easy to trace from an item back to the root every time the item's instance of (P31) or subclass of (P279) value is changed—that is, take a moderate hit at "write" time, in database terms—and then this data could be used in the search ("read" time) without incurring any large read-time costs. - Jmabel ! talk 16:28, 29 November 2022 (UTC)
    @RIsler (WMF) and Keegan (WMF) made some statements in that direction Commons_talk:Structured_data/Get_involved/Feedback_requests/Computer-aided_tagging_designs#generic_vs_specific_tags here. I think it would be really helpful, if the people working on MediaSearch would elaborate a bit on this:
    • Can we expect searching for "dog" finding files tagged as dalmatians only at some point in the future?
      • If no: why?
      • If yes: when?
    Or in other words: is it worth holding out for something that might work at some point in the future if that means that things are less useful than they could be right now? El Grafo (talk) 08:20, 1 December 2022 (UTC)
    Related thread on the mailing list (Jheald, 2018): Wikidata considered unable to support hierarchical search in Structured Data for Commons. TL;DR: "Wikidata is too chaotic to reliably deliver the info that would be needed for this." Ouch. Don't know if that has improved since 2018. El Grafo (talk) 08:37, 1 December 2022 (UTC)
    When thinking of the many issues that can still be found in the ontological structure at Wikidata, I can relate to that. It would be interesting to know, though, whether an attempt has been made to formalize the requirements with regard to the ontological structure at Wikidata from the point of view of hierarchical search. In this case, its evolution could be tracked, and we would at least know whether things are getting better or worse over time. Once we know that, we could devise and implement strategies to make it better. --Beat Estermann (talk) 12:03, 1 December 2022 (UTC)
    My team (Structured Data) worked on SDoC, and I personally spent quite a bit of time trying to figure out how to search down the hierarchy during the project - actually specifically using the technique you describe @Jmabel. We gave up on it because it added lots of noise to the search index, and very often failed to add what we wanted - see here for more details. The underlying problem is, as @Jheald says in that email thread, that the wikidata ontology is too chaotic
    More recently we tried to use the WDQS to search down the hierarchy at search time. It was more successful, but being based on SPARQL was too slow for use in production, and even if it had been quick we were nervous about putting too much pressure on the query service.
    In mediasearch on Commons we're prioritising the user getting good results ("precision" in search-speak), rather than making sure that a particular image is returned ("recall" in search-speak). Currently if a user searches for 'poodle' then we return images:
    So I guess a question that needs answering here is - are users getting sufficiently good search results without having to drill down through the hierarchy? And if they are then how important is that a particular image of a poodle is returned when someone searches for 'dog'?
    If you guys think it's sufficiently important to take action on then I guess my team has more investigation to do (though I should point out that we are jam-packed with work at least until the end of the current US fiscal year, and wouldn't be able to do anything on this before then) CParle (WMF) (talk) 12:43, 2 December 2022 (UTC)
    @CParle (WMF) Thank you for the response, very much appreciated! To answer your last question first, yes, I think this is very important to figure out, for reasons you may not be aware of. Finding pictures tagged as Poodle when searching for "dog" was one of them major selling points of SDC when the project was started - or at least it was perceived like that by many, including myself. Some have given on on that, but some are still hoping and some seem convinced that it's the only way forward. If we want to move forward with SDC, we (the Commons community) need to figure out if it will be sufficient to tag poodles as such or if we also need to tag them as dogs. Personally, I'm fine either way. But I think I'm not the only one thinking along the lines of meh, I'll start tagging my uploads once we've figured out how to actually do that. This is a major blocker for SDC acceptance in the community, imho.
    Some semi-random thoughts to keep the discussion going:
    • Looking at your list of problems in the Wikidata ontology at the top of phab:T199119, it seems like many of them have been resolved meanwhile. To me it seems like a lot of these problems are due to errors in Wikidata - things that are fixable once someone is aware of them. That way, a search on Commons returning unexpected results may well be the trigger that's needed to fix something on Wikidata. We see that happen in other circumstances all the time.
    • The poodle/dog example may not be a good one. Searching for "dog" will give you plenty results so you won't particularly miss a couple of poodle photos that the search didn't find because id didn't know that poodles are dogs too. But for less conventional topics, you may need to dig deeper, and you may need the search function to do that for you. If I don't find enough good images when searchig for "dog", I might try searching deeper for poodles and huskies because I know they are kinds of dogs. But I have no clue about locomotives, so I'd really appreciate the search finding images of Southern Pacific 4449 when I'm searching for steam engine. (Still a bad example, because we have lots of images of steam engines.)
    • Maybe it doesn't need to be an always-on feature. Call it a "comb the desert" mode and false positives are much less of a problem immediately.
    El Grafo (talk) 10:16, 5 December 2022 (UTC)
    Trying to build a picture in my head here of the user problem we're trying to solve ...
    • From an uploader's point of view I understand that I'd like to be able to tag my image with Southern Pacific 4449 (Q7570267) and have it show up in a search for "steam engine". I'm not sure that's a practical expectation in a collection of millions of images though - we already have thousands of images of steam engines, and even if you tag your image with "steam engine" there's no guarantee it'll show up anywhere near the top of the result set
    • From a searcher's point of view I'm likely to be searching for a good match for my search term rather than a particular image. Ontology-descending search would definitely be useful in this case if we had a node in the ontology with few results, but where nodes lower down had many results. I can't think of a concrete example though, and I'm not sure whether this is a common scenario. If it is I'd love some examples
    • If it's a more strategic thing we're trying to achieve - like to highlight wikidata ontology issues - then maybe we could create some sort of search keyword to trigger a "comb the desert" approach like you describe based on descending down instance of (P31) or subclass of (P279) links. This would have the advantage of not degrading regular search. deepcat search does something similar for categories already, so this might be something that the WMF could explore
    CParle (WMF) (talk) 14:24, 5 December 2022 (UTC)
    Going in order of your points:
    • Uploaders feeling that their contributions are being valued is good, but not always possible. Making uploaders feel like their work is being disregarded, however is a bad thing. I don't need my images to turn up at the top of the results. But if I upload a picture of a doughnut and I cannot find it at all when searching for "doughnut" just because I was trying to be a good uploader and tagged it more precisely as a chocolate doughnut, that can be quite frustrating. Especially when I took the time to set up proper lighting in a studio etc. - but the search function favors the blurry phone snap of a Berliner someone uploaded with a description like "German doughnuts have no holes lol" (that last bit obviously being irrelevant to the greater question here).
    • It is difficult to come up with real-world examples, partially because only a tiny fraction of files already has depicts statements at all at the moment. But as pointed out below, a simple search for "car" gives you a bit of an idea. This will happen anywhere where experts divide things into smaller classes than the general public would search for, especially in biological taxonomy and technology. Looking at the Category tree might give an indication for that. And to make things worse, it seems like the good pictures with a clearly identified subject get the precise meta data, while the crappy ones stay in the more general categories because even the experts cannot figure out what exactly they show. Compare e.g. Category:Photographic lenses, where all the high-quality pictures of modern lenses are hidden away in the sub-categories. Look at how a search for "airliner" already favors crap like this, because people who know their stuff would never bother to use the word "airliner" anywhere in their file description, file name, or categorization.
    • Yes, deepcat is what I had in mind when proposing this.
    El Grafo (talk) 11:47, 7 December 2022 (UTC)
    @CParle (WMF): Thanks for posting here. Someone else suggested, if I understand correctly, that the issue of general vs. specific depicts statements could at least in part be solved by using other properties like main subject (P921). Do you have thoughts on that (and how it would work with media search)? — Rhododendrites talk |  14:23, 5 December 2022 (UTC)
    Hi @Rhododendrites! We could certainly add main subject (P921) to the properties that we search, but that's just adding another search signal to the ones we already use, and doesn't necessarily add weight to either side of the debate
    The overarching questions to me, from a search perspective, are:
    1. Does the current search provide good results for a search term? If not then what specifically are the problems?
    2. If there was a policy of only having specific depicts statements, might that degrade the current search? If it might then we ought to plan an experiment to see how much it'd degrade, and figure out whether any degradation would be mitigable via an ontology-descending search
    CParle (WMF) (talk) 15:14, 5 December 2022 (UTC)
    Just very quickly, more later: assume we would enforce a policy that required specific "depicts" statements only. That would mean that, ideally, every picture of an automobile would have a depicts statement about its specific type such as Honda Civic (Q216747) only. Actually, given the Commons Community's collective OCD, something like Honda Civic 11th generation (Q107002471) is probably more likely. With how the searcdh currently works, that would mean that for anyone searching for a picture of some kind of car, any "depicts" statement would by design be out of the equation entirely. The search might still give reasonable results based on the other criteria, but to be honest, results for "car" are pretty bad right now.
    We already have this problem in the category system: The more us Commons curators geek out about precisely categorizing things, the more difficult it gets for the average Joe to actually find something (See for example the Category:Gliders tree). Or to view it from the other direction: Media with sloppily coarse meta data is easier to find. SDC/depicts currently has the opposite problem of there barely being any files actually having "depicts" statements at all. But if SDC eventually takes off, we need to be prepared for the pendulum swinging into the opposite direction. El Grafo (talk) 10:27, 7 December 2022 (UTC)
    It could be a workable solution that the search would use wikidata P180 QID values from categories in the search index. ( Example File:Poodle_(4320409945).jpg -> Category:Poodles -> Category:Poodles (Q55330462) -> category's main topic (P301) -> poodle (Q38904) -> instance of (P31) dog breed (Q39367), subclass of (P279) dog (Q144) )
    This proxying would need hand-tuning, so it would work best if there were a Lua module in commons that could be edited by the community and would output QID list in a format suitable for the search index. As a task, it would be something like the current template:wikidata infobox. Based on a quick test, it would be doable. (example: Module:P180fromCategory) So the biggest question is if adding a module for this to every file namespace will generate too much server load. If it is not then this would be usable way to add more information to search index which would especially improve the multilingual search. -- Zache (talk) 11:46, 7 December 2022 (UTC)
    The difficulty is that ascending the ontology tends to add lots of noise to the search index - this will be true whether we use Lua or MediaWiki to do it. TBH if we're going to have another look at this I think it'd be better to do it inside MediaWiki itself (more scalable) CParle (WMF) (talk) 11:34, 9 December 2022 (UTC)
    For crowdsourcing the finding and fixing problems from rules of getting P180 values ( = redusing the noise), the current P180 values from categories need to be visible, and rules to generate them should be editable for wiki editors. Because of this, it would not scale in terms of volunteer human labor work if the editing needed to be done through git and MediaWiki update cycles. However, I am sure that from the technical point of view, it would be more efficient if the code were directly in MediaWiki so it is a trade between how it will scale from the code point of view and how it will scale from a crowdsourcing perspective. -- Zache (talk) 18:01, 9 December 2022 (UTC)
    Hmm actually that's a fair point. We won't be working on this within the next 6 months, but if we are after that having editor-editable rules is definitely something we ought to look into CParle (WMF) (talk) 10:37, 13 December 2022 (UTC)
    Ok so my takeaway from this and your other comments above is - without ontology-descending search we're incentivising users to use less precise depicts (P180) values, because their images are more likely to be found that way.
    Makes sense. It doesn't follow that ontology-descending search will be practical to implement, but it's certainly a good argument in favour of it. Like I said my own team is flat-out until July 2023, but I'll raise it as a possible project for after then
    (just fyi there are ~10M images out of ~90M total files on commons with 'depicts' statements atm) CParle (WMF) (talk) 11:49, 9 December 2022 (UTC)

Change the name of POTY from "POTY [year the photos were promoted to FP]" to "POTY [current year]"

This year, last year, and some years in the past we have run Picture of the Year late in the year. This causes some confusion when we run, say, "POTY 2021" in late 2022. It sounds like we're talking about last year's event. The reason we name it that way is because the candidates are Featured Pictures promoted in 2021. I'd argue that it's less important for voters to know when the pictures went through the FPC process than to clearly communicate the name of the current event.

Proposal: Starting next year, the event which votes on FPs promoted in 2022 will be called "Picture of the Year 2023". I am not proposing to change this year's because it starts soon and this change would likely require some modifications to the scripts that generate it.

  • That would be great, but for as long as we have had POTY, we have had trouble getting people to run it. The technical side is not something one can undertake with no knowledge, and there's no real documentation available, so there aren't many people who can run it. It would be nice to get a more sustainable system set up, but as ever, Commons could use more techfolk, and I see no reason to expect a change for next year. Ultimately, I think unless we can somehow bet on someone setting it up in January/February every year, we should change the name. — Rhododendrites talk |  13:53, 27 October 2022 (UTC)
    "there's no real documentation available, so there aren't many people who can run it" - I think this is the problem. Instead of changing the name, it would be much more important and sustainable to document the process and find Wikipedians to join the organization of the vote. Stepro (talk) 16:32, 27 October 2022 (UTC)
  • Yes that would be better. Are you volunteering? Many of us have advocated for it (and/or other changes) for years. At some point you have to do your best with what actually exists. POTY is much more outward facing than our other process so we owe it to the broader community to be as clear as possible about what it is. — Rhododendrites talk |  17:28, 27 October 2022 (UTC)
  •  Oppose It is the picture of the year when it was promoted as FP. Having the current year in the name but voting on last years pictures does not make sense. Many publications are published late in the following year with the year they are about in the title. --GPSLeo (talk) 16:26, 27 October 2022 (UTC)
  • ? What proportion of our hundreds of voters do you suspect understand that they're voting specifically on photos promoted in some internal process called featured pictures candidates in a specific year vs. just look at the pictures and vote? — Rhododendrites talk |  17:28, 27 October 2022 (UTC)
    I think there are criteria to have the right to vote on the photos. So you will have some knowledge about Wikimedia projects when you are voting. And if we are only talking about the voting we could just make a banner without a year. The published results should definitely have the year as they have it now. --GPSLeo (talk) 17:54, 27 October 2022 (UTC)
  •  Support - I get the current way and I don't ...., It would make much more sense to have it for the year it's being run instead of being a year behind .... but that being said if Rhododendrites is correct regarding lack of people behind the scences then maybe POTY should be done away with completely. I enjoy participating in it but could I live without it ? Absolutely. –Davey2010Talk 18:52, 27 October 2022 (UTC)
  •  Support --Kritzolina (talk) 19:18, 27 October 2022 (UTC)
  •  Oppose – There are other contests that take place in the year following the season "season" they are deciding winners for, e.g. the Academy Awards, the Super Bowl. I'm used to POTY being the same. What's the possibility of running both the 2021 and 2022 contests early next year, assuming people can be found to run them. What level of technical competence is required to manage the contest? Dhtwiki (talk) 05:43, 29 October 2022 (UTC) {edited 04:01, 9 November 2022 (UTC))
    • The Super Bowl and Oscars in 2022 aren't called "Super Bowl 2021" and "Academy Award 2021". If you search anywhere for "Super Bowl 2022", though, you're taken to the Super Bowl that took place in 2022. If you search for "Oscars 2022", you're directed to the Oscars that took place in 2022. — Rhododendrites talk |  12:41, 29 October 2022 (UTC)
      • Super Bowl 2022 decides the 2021 season; the Oscars awarded in 2022 are for films from 2021. The way that POTY is currently labeled seems more logical and shouldn't be confusing. Dhtwiki (talk) 00:08, 30 October 2022 (UTC)
NO.--RZuo (talk) 22:08, 4 November 2022 (UTC)
  •  Support Like the Oscars, I agree that the format "POTY [year]" naturally implies that the competition was held that year, rather than some criteria of the pictures that appeared in that instance of the competition. So if we are to keep this formatting, I think it makes sense to go ahead with the above proposal. But I don't think this is optimal, because the important thing IMO is the year that the pictures were promoted, not the year when the competition is held (in the Oscars case, it seems the competition itself is sometimes more important than the films). So ideally, we'd be able to come up with something like "2006's Picture of the Year" or "Picture of the Year from 2006" which imply that the pictures are from 2006, rather than implying the competition ran in 2006. (Admittedly neither of these names are as snappy as "POTY 2006".) Renaming to more clearly align with the photo's promotion date might also allow us to do something like "2021-2022's Pictures of the Year" if we aren't able to run a competition annually. -M.nelson (talk) 12:11, 5 November 2022 (UTC)
    Changing my 'vote' from Unsure to Support as I support changes in general to resolve the confusion that comes from the current naming scheme. -M.nelson (talk) 19:33, 18 December 2022 (UTC)
  •  Oppose I really want to have it much earlier in the year. We already have November, and it hasn't started yet. For me this is the problem, not the name. --Stepro (talk) 12:44, 5 November 2022 (UTC)
  •  Support Given the current state of POTY, this makes sense to me. I think it's a good idea to call it POTY 2023 and just note that the pictures were promoted to FP in 2022 - people can figure that out. My hat is off to anyone who has worked to make POTY happen, it is a lot of work that unfortunately receives complaints at times or mostly is ignored. I can understand why it's hard to find people with the motivation and skillset. As with many things in life, it's easy to ask why POTY is so late, but much harder to take up the task and make it happen. Glennfcowan (talk) 04:29, 7 November 2022 (UTC)
  • I would tend to  Oppose. -- Ikan Kekek (talk) 19:53, 8 November 2022 (UTC)
  • I think there is room for a compromise, like take FPs from November 2022 to October 2023 and then run the vote in November/December 2023. This way the majority of photos are nominated in the current year. I think this follows how most people online do their "best of the year" proclamations in December even though the year isn't technically over. To get on this schedule, we'd want to do the 2022 POTY in Feb/March, and then align to the new schedule. Legoktm (talk) 08:57, 15 November 2022 (UTC)

Protect all nudity and sexuality related files from IP edits

Files in the field of nude people and files related to human sexuality are much more often vandalized than other files. The in many cases the vandalism consist of harassing language to the people depicted on the photo. If this kind of vandalism if not reverted immediately it is a serious personality rights problem. To solve this problem I would propose that we protect all files under the following categories form IP edits:

An other less invasive solution could be that we do not protect all files, but protecting all files indefinitely if they got vandalized once. --GPSLeo (talk) 15:50, 28 October 2022 (UTC)

A good idea to protect those categories so that volunteers can spend their time better than checking and repairing vandalism by anonymous users. Wouter (talk) 09:35, 5 November 2022 (UTC)
@GPSLeo I am somewhat biased towards these kind of categories, and have never observed such vandalism. Was it quickly revdel’d in each case? Or have I just not been looking at enough histories? Brianjd (talk) 14:22, 5 November 2022 (UTC)
 Oppose: "in many cases" is not a convincing argument. I could only support such a motion if the OP could show that, say, 80% of IP edits to such images were vandalism. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:04, 9 November 2022 (UTC)
 Oppose per above. Also because it depends on a hopelessly undefined category. Nude or partially nude people is in Nudity or partial nudity, whose long-running CfD is a mess. I noted there that even bare feet qualify as nudity, at least in one user’s opinion!
The category problems just keep going. Just to pick some random examples, Human sexuality contains Books about human sexuality and Lewinsky scandal. I expect there are many more subcategories that should not be protected in the way proposed here. Brianjd (talk) 10:42, 9 November 2022 (UTC)
 Weak support Sexuality-related media could definitely be a magnet for some very bad edits and should probably be held to higher scrutiny than your average content, but this could also just be a rule of thumb than a straight up rule. —Justin (koavf)❤T☮C☺M☯ 10:47, 9 November 2022 (UTC)
@Koavf How does this work as a rule of thumb? Protection is already handled by administrators, who are elected by the community for their good judgement; they don’t need this rule. Brianjd (talk) 11:43, 9 November 2022 (UTC)
And as I wrote, it wouldn't be a rule. A rule of thumb is general good advice, so the way it would be enacted is that admins would keep their eyes on these categories and media and pay special attention to them. I don't even understand what you don't understand about what I wrote. —Justin (koavf)❤T☮C☺M☯ 11:45, 9 November 2022 (UTC)
@Koavf I’m obviously using rule as an abbreviation for rule of thumb. I’m saying that admins already have good judgement and don’t need this rule of thumb on top of that.
Also, admins don’t have time to pay special attention to these categories; they barely have enough time to do things that actually require admin rights. So what are you actually proposing? Brianjd (talk) 11:53, 9 November 2022 (UTC)
I am proposing what I just wrote. I don't know how to reword it. —Justin (koavf)❤T☮C☺M☯ 12:00, 9 November 2022 (UTC)
 Oppose can you provide evidence of widespread vandalism that would justify the protection of such broad topic? I have seen some but should we also remove the ability for them to list a file for deletion? I think that it would be of no benefit. Bidgee (talk) 12:11, 9 November 2022 (UTC)
  •  Comment Like Bidgee above, I think such a proposal should be based on facts, on actual "evidence of widespread vandalism" in the subject area. That is, if it can be shown with actual data that there is significantly more vandalism and related issues there than on Commons in general, I would support the proposal, otherwise oppose. Gestumblindi (talk) 00:56, 7 December 2022 (UTC)
 Oppose no evidence provided we need such drastic measures. I think we can SNOW close this. Dronebogus (talk) 01:06, 30 December 2022 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2022/10&oldid=728587620"