Commons:Village pump/Proposals/Archive/2023/11

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

Scale bars

Hi, I'm a fish out of water here, having temporarily escaped from the English Wikipedia. Today our featured image is the particularly beautiful picture of an Inuit harpoon, here[1]. I was wondering if there is any way to encourage creators of such beautiful images to consider also doing an option that includes a scale-bar? It's often quite obvious to the photographer how big the item is, but without anything for reference, much harder for an encyclopaedia-user. The inclusion of a ruler, or some object of known size, really helps. Maybe it could be included in a guideline somewhere, I don't know? This is absolutely not a criticism of those photographers kind enough to provide the really valuable resource that is Commons. This harpoon really is a gorgeous photo of a very significant item. Elemimele (talk) 21:14, 7 November 2023 (UTC)

@Elemimele: it's certainly encouraged, but for an image which a private individual takes in a museum it's probably not an option. - Jmabel ! talk 22:00, 7 November 2023 (UTC)
@Elemimele: Please have a look at the description where the size of the object is given as 172 x 9 x 6 cm. --AFBorchert (talk) 07:40, 8 November 2023 (UTC)
@AFBorchert: , yes, the description is really useful. Since images can often be used without the description being immediately visible to the reader, would it be acceptable for Wikipedia editors etc. to use description dimensions to add an artificial scale-bar and re-upload it as a variant image where a visual indication of scale would be helpful in the target? Elemimele (talk) 18:01, 9 November 2023 (UTC)
You can always create derivative works, and any given Wikipedia can always choose to prefer them (or not). - Jmabel ! talk 02:52, 10 November 2023 (UTC)

Mass block that prevents all users from editing images should be reverted

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Let's try to keep the conversation all in one place. You opened another discussion at Commons_talk:Overwriting_existing_files#Policy_change_should_be_reverted that's already received responses. The Squirrel Conspiracy (talk) 01:44, 10 November 2023 (UTC)

The new policy that has been enforced quietly and without much discussion over at Commons:Overwriting existing files has put a site-wide block on the ability of all editors (except those with relatively rare privledges) to edit images. This is in violation of both the spirit and normal practice of Wikipedia which encourages editing and fixing of errors and the improving of articles. It prevents users from fixing poorly uploaded images (very common) where they've been uploaded in low resolution from some government site. It prevents users from updating maps as they go out of date. It relies on users to add an unknown template in order to allow corrections to their images. This policy should be reverted. It's created a "lords and commoners" division with regards to image editing, something that is completely unknown across Wikipedia. Ergzay (talk) 19:42, 9 November 2023 (UTC)

What alternative do you suggest to handle the huge amount of policy violating and harmful overwrites? GPSLeo (talk) 20:18, 9 November 2023 (UTC)
Uploading under a different name is still allowed. Ymblanter (talk) 20:57, 9 November 2023 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Asking for help for commons (beginners) 4.0...

I believe the issue has been discussed several times since at least 2016, but until recently (in 2022) there are edits by also experienced wikipedia editors searching for help at the talk page of Help:Contents and there are likely no answers to come. I suggest to remove the link to Help:Contents at the left sidebar of the dropdown menu (in version Vector 2022), and replace it with a link to Commons:Help desk below the one to the Village Pump instead. For Welcome (also a part of the Village Pump) a similar solution already exists. Paradise Chronicle (talk) 20:17, 11 November 2023 (UTC)

I'm sorry, it's late and I'm tired, so maybe this is all on me, but I don't follow this proposal, or maybe it's that I don't use Vector 2022 so I don't know what dropdown menu you are talking about, but how would Commons:Help desk (a place to ask a question) replace Help:Contents (the top-level page of the "help" content. They seem to serve very different purposes. Are you saying we don't need to show people where to find help on their own, and should aim them all to asking questions to be answered by actual volunteers? That doesn't seem even vaguely scalable, so I'm guessing I've misunderstood. - Jmabel ! talk 02:35, 12 November 2023 (UTC)
Hey dear Jmabel, sorry to keep you awake ː). No rush, don't worry, it's been like this for several years so if it stays like this a bit longer it'll be ok. And maybe it is also meant to be like this. In Vector 2022 there are three horizontal bars to the upper left, and if one hits them, a drop down menu shows up. And at the Help talk:Contents there are six discussions since 2014 out of which three are concerning on where help is to be found. Likely only six because most editors on commons already know there is hardly any help to receive there. But some still believed there will be help and I am pretty sure they'd have found some help much faster if they were directed to the Commons:Help desk. Paradise Chronicle (talk) 03:23, 12 November 2023 (UTC)
Hehehe, yeah maybe it is meant to be like this, but it is a bit confusing, at least to me. I removed the protected redirect to the Help desk for now. Because when I hit that one, I was told only administrators could edit the page. Now the redirect works and one gets to ask a question straight. Paradise Chronicle (talk) 03:44, 12 November 2023 (UTC)

Deprecate PD-US

There have been discussions about this every now and then on the template talk page, but they haven't generated any sort of clear consensus due to lack of consensus, so I'll ask the community here.

This template is overly broad. There are more specific templates avaliable (Category:PD US license tags), and it is always better to use a more specific PD template over this. Furthermore, having a very broad template would encourage copyright mistakes ("this would probably be PD"). Therefore, it should be deprecated and put on some kind of backlog. —MATRIX! {user - talk? - useless contributions} 21:26, 22 November 2023 (UTC)

EDIT: It seems I have been a bit unclear on what deprecate means. I mean that we should add a custom non-transcluded edit notice to the top discouraging use (something like {{Deprecated}}).

  •  Support Although it's kind of pointless if the template is being automatically added to files by the DPLA bot. But conversely, there should really be more of an effort on the DPLAs end to use more specific licenses when they can anyway per The Squirrel Conspiracy. Or at least on the bots/Dominics end if the DPLA doesn't want to do it themselves for whatever reason. --Adamant1 (talk) 08:56, 26 November 2023 (UTC)
  •  Support Deprecate for future uses. It should always be possible to be more specific. {{PD-old}}, a similarly broad and unspecific tag, is already marked as deprecated ("PD-old is a deprecated generic template which should not be used for new uploads"). Gestumblindi (talk) 12:47, 26 November 2023 (UTC)
    • It is not always possible to be more specific. PD-old had a single direct replacement (and there is nothing preventing its use actually; the "deprecation" is only in its documentation). I would certainly support discouraging use of PD-US when one or more of the other specific tags can be used, which should be most cases, but I can't support altogether banning its future use. We certainly aren't going to fix the millions of existing uses. PD-US is still very useful for bulk uploaders, and in certain situations where we don't have full date knowledge, but enough to know it's PD beyond a significant doubt. I haven't needed to use it often, but I'm pretty sure I have a handful of times. The documentation does say If at all possible, please use a more specific tag so that aspect is covered in the documentation, though adding a similar note to the actual template may be a good idea. I think the tag has been removed from the upload tools as an easy option, which is also good. "Deprecating" in the style of PD-old, which is mainly just wording in the documentation, may be fine (though there are still valid uses, so it would only be deprecated when a more specific template can be used). Not sure that adding any non-transcluded element to the top is much different than the wording in the documentation really, though it could be made a little bit stronger. Carl Lindberg (talk) 15:57, 26 November 2023 (UTC)

image-reviewer → license-reviewer

Hi. I propose to change the technical name of the license reviewer user group from image-reviewer to license-reviewer. This will make it in consistent with the group's real name, and also in general everyone uses the term "license reviewer" and not "image reviewer", and it is correct too, as the group members review all type of files and not just images. I see no reason why this shouldn't be done. We'll have to do following things for this:

  • Request on Phabricator for technical stuff (config, WikimediaMessages, migration...)
  • Update abuse filtes
  • Update MediaWiki pages (includes Gadgets)
  • Update user scripts if any
  • Update required Commons, Template, Help pages (like COM:LR)

Please point out other things if any. Thanks! -- CptViraj (talk) 05:13, 2 November 2023 (UTC)

Discussion

I do not think this is a problem. The technical term for Admins is sysop and for Oversighters it is suppress. But if we do a change here we should also consider the proposal I made some month ago (Should we simplify user rights?) to remove the dedicated rollback right and give this right to all patrollers and license reviewers. GPSLeo (talk) 15:27, 2 November 2023 (UTC)

I personally dislike sysop for admins as it is no longer relevant and can be confused with system administrators but it is a MediaWiki core setting so a big mess and not in our hands, while the license reviewer is a local Commons group, so it makes sense to keep it consistent and updated, and it is in our hands so easy to manipulate. For the proposal you linked, I personally agree with Mdaniels5757 there. For now, I'd say let's please keep that seperate as then this proposal will be wider in scope then it's original non-controversial (?) subject. -- CptViraj (talk) 17:26, 2 November 2023 (UTC)
Not to say I'm against the idea, but don't you think "license-reviewer" is to close in wording (if not purpose) to the Volunteer Response Team or that there is a chance people will mix them up? --Adamant1 (talk) 20:10, 2 November 2023 (UTC)
Well, non/new users have always confused them and will continue to do so. But I have never seem them calling it image reviewer, as our help and project pages use the term license reviewer and established users also use the latter term in general except while talking in technical way, so I believe it won't make a much difference for them. Even if they are using/reading/understanding the former term then it could be misleading for them as it suggests that the group members review only images but that's not the case, they can also get confused believing license-reviewer and image-reviewer are two different user groups, so I think it makes sense to change it and make it consistent. And for us, established contributors, who understand workings, It was license reviewer with VRT access or without VRT access, and will remain the same. -- CptViraj (talk) 09:13, 3 November 2023 (UTC)
@CptViraj: Wouldn't that be solved by calling it "file reviewer" then? I don't think just because "image" doesn't work that it necessarily means "license" does. --Adamant1 (talk) 20:33, 4 November 2023 (UTC)
@Adamant1: The sole role of the user group is to review licenses, and that's what it makes different from patrollers, otherwise files can be reviewed by patrollers, too. So I believe 'file reviewer' could cause confusion. Also 'license reviewer' has become a common name now, changing it completely won't be a good idea IMHO. -- CptViraj (talk) 21:12, 4 November 2023 (UTC)
That makes sense. Thanks for clarifying it. --Adamant1 (talk) 16:08, 6 November 2023 (UTC)
  •  Support OK for me. Yann (talk) 17:28, 2 November 2023 (UTC)
  •  Support OK for me, too.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:57, 6 November 2023 (UTC)
  •  Support --Adamant1 (talk) 16:08, 6 November 2023 (UTC)
  •  Weak oppose I do not see the need for the change of this internal parameter. A change could break a lot of (unmaintained) tools. --GPSLeo (talk) 16:10, 6 November 2023 (UTC)
  •  Support Killarnee (talk) 06:22, 7 November 2023 (UTC)
  •  Support it is never too late to implement the changes required. Thanks --C1K98V (💬 ✒️ 📂) 06:35, 7 November 2023 (UTC)
  •  Oppose per GPSLeo. It's a purely cosmetic change that has the potential to break things. Commons is already struggling under backlogs basically everywhere; if we lose a tool or two it'll only get worse. The Squirrel Conspiracy (talk) 10:42, 7 November 2023 (UTC)
  •  Weak oppose I would support a change, provided the concerns by GPSLeo and The Squirrel Conspiracy are addressed. We are risking here that tools are not updated accordingly and would need to know beforehand what could possibly break and who is ready to fix it. Filter 70 would have to be updated as well. --AFBorchert (talk) 15:57, 7 November 2023 (UTC)
  • In the proposal itself, I have already listed the on-wiki things (including the AF above) that will need updating. If anyone know any other gadgets/tools/scripts/etc.. please help list them, leftovers can be fixed. I'll be happy to update the things that I could, will surely appreciate more hands. A cosmetic change but IMO we shouldn't be afraid to do them when it is possible without causing heavy disruption, this isn't going to shut the site, the group has been renamed before. This isn't gonna get implemented overnight, discussion is likely going to be open for several months, all the replacement points can be found out, and if passed, we can do it with proper planning, thus minimising the chances of breaking things but I cannot guarantee 100% smooth transition, after all these things is a process of continual refinement. -- CptViraj (talk) 19:19, 8 November 2023 (UTC)
  •  Support --Ooligan (talk) 20:10, 8 November 2023 (UTC)
  •  Weak oppose I don't see a large benefit and it could potentially break unmaintained tools. The previous renaming to fix the capitalization seems like it was a lot of work to coordinate. Apparently fawiki also uses this user group, so it would need to be coordinated with that wiki as well. Frankly, it doesn't seem like it's worth all the effort. Nosferattus (talk) 16:16, 9 November 2023 (UTC)
    Hi. The work you see on phab is on system administrator/patch uploader's side (could be volunteer or staff), I'm sure they won't refuse to help and implement if there is consensus, some of it was done with maintenance scripts (semi-automatic), some of it won't be required as they were one-time fixes, if you see the dates, you can see that most of it was done on the same day. The previous rename was an uncontroversial maintenance change done by the sysadmins themselves to make the user groups in line with others, it included both fawiki's group as it required fix too but that's not a case here. The fawiki user group has nothing to do with ours, both are independent from each other. -- CptViraj (talk) 19:36, 9 November 2023 (UTC)
Null edit to avoid auto-archiving. -- CptViraj (talk) 17:38, 8 December 2023 (UTC)

Restrict webp upload？

https://commons.wikimedia.org/w/index.php?sort=create_timestamp_desc&search=filemime%3Awebp

i suggest restricting upload of webp files to autopatrol users (like mp3), because very often webp uploads are copyvio taken from the internet or previews of svg logos. RZuo (talk) 14:07, 22 November 2023 (UTC)

 Strong support second in motion to @Yann, Abzeronow, and Glrx: et.al.. Examples of my autogenerated messages of WEBP copyvios: this, this, and this. And I can still remember the very first WEBP file I encountered here, which is a copyvio itself! Commons:Deletion requests/File:Beijing Skyline.webp. JWilz12345 (Talk|Contrib's.) 08:17, 26 November 2023 (UTC)
  •  Support Would reduce copyvios for sure; I'm not sure the proportion is as high as some have mentioned based on spot checking, but I usually check the ones that look obvious so it's not exactly a random sample. Gnomingstuff (talk) 23:05, 29 November 2023 (UTC)
  •  Oppose I think in general, discriminating on filetype is a bad direction (same with mp3). It further complicates and obfuscates the upload process and doesn't stop copyright violations, it stops contributors. Most of these can easily be spotted by filtering the upload list on new contributors. Or we can just ban SVGs as well, because most logos are copyvios. —TheDJ (talk • contribs) 18:46, 30 November 2023 (UTC)
    If we would have enough people checking the unpatrolled uploads we would not need such filters. Unfortunately we do not have enough people checking uploads and edits and therefore need tools to reduce the workload. GPSLeo (talk) 19:31, 30 November 2023 (UTC)
    I think that creating these kinds of non-transparent and highly confusing roadbumps is part of the reason WHY we don't have enough people. That's my point. And I note that just two posts below this we already have someone getting tripped up with the SVG translator software because of a similar rule #File overwriting filter blocks SVG Translate. It's one of those 'a small cut doesn't seem so bad, until they are a thousand cuts"-kind of problems. Considering how much ppl complain about UploadWizard, stuff like this isn't helping lower the barrier to entry either. —TheDJ (talk • contribs) 11:07, 9 December 2023 (UTC)
    Plus we could just make patrolling itself easier by having uploads sorted per date, a single patroller can simple take a few minutes to patrol all new ".webm" files. Do this for every file type and we don't need to exclude people from uploading. If a patroller only wants to patrol videos, sounds, PDF's, Etc. they now have to go through all uploads, but by making it easy to filter out and making these pages easily accessible to everyone and transparent (like OgreBot's Uploads by new users) we could easily patrol everything with fewer people. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:55, 9 December 2023 (UTC)
 Support. Very few cameras or image editing tools output WebP images; when one is uploaded, it's almost always because it was downloaded from a web site which automatically converts images to that format for display (and, thus, is very likely to be a copyright violation). We already have abuse filters which block other types of uploads from new users which are overwhelmingly likely to be problematic, like MP3 files (Special:AbuseFilter/192), PDFs (Special:AbuseFilter/281), and small JPEGs (Special:AbuseFilter/156). Omphalographer (talk) 04:25, 3 December 2023 (UTC)
  •  Oppose, per TheDJ. Additionally, this would exclude a lot of people who contribute to other Wikimedia websites but aren't necessarily active here, a user could be a trusted user, an admin, or a prolific contributor, Etc. on another Wikimedia website and "a noob" at the Wikimedia Commons. They could have good knowledge of how video files work and which ones are and aren't free, but they will find that they can't upload anything here. If we keep making the Wikimedia Commons more exclusive we will fail at our core mission to be for all Wikimedians. If new users are more likely to have bad uploads then we should have a page like "Commons:Uploads by unpatrolled users by filetype/.webm/2023/12/09" (which includes all users who aren't auto-patrolled), this will simply exclude too many people. We can't know which people and uploads we exclude because a user with a free video file will come here, attempt to upload, see "You have insufficient privileges for this action", and then never return (without ever telling anyone what (s)he wanted to upload and why they didn't). "Anyone can contribute to" is the core of every Wikimedia website, the moment you compromise this you lose whatever made this place Wikimedia. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:49, 9 December 2023 (UTC)
  •  Strong oppose, outlawing a file format will just lead to such files being converted into a different format, and be uploaded in a different way - but now with less possibilities to scan and patrol for it. This is classic prohibition: By outlawing X, users of X will find new ways to still do it, but in places where it can no longer be observed easily. I'm not even arguing in favor of the allegedly "just" 10% .webp images that are in fact okay, which is a valid concern as well in my opinion. So: Use this helpful file format to scan more efficiently for copyvios, rather than outlaw it and have the copyvios enter Commons nonetheless but via still uncharted routes. --Enyavar (talk) 15:25, 18 December 2023 (UTC)
  •  Comment Giving that WebP files are essentially Google replacements of JPGs, PNGs, and GIFs, we cannot restrict the WEBP uploads into autopatrol users until we restrict the uploads of these three formats too (as well as SVG, even for own uploads), because if a non-patrolled users restricted their WEBP uploads, they would easily convert these webp files to PNG or JPG as a way to upload these images into Commons. We should find a way to close the loopholes of new users to convert webp files to a different image format before we can restrict the WEBP uploads to users with autopatrol rights, even with its own user's webp uploads. Yayan550 (talk) 15:33, 2 January 2024 (UTC)
    • @Yayan550: I think you are missing the point here. Of course if they know what they are doing they can convert the file. The idea here is sort of a "speed bump" for a pattern that usually indicates someone who is ignorantly uploading a copyright violation. - Jmabel ! talk 19:24, 2 January 2024 (UTC)
      Precisely. And, as I noted above, we already have AbuseFilter "speed bumps" for other types of uploads, like MP3 files, which are particularly likely to be copyvios. We're aware that users can bypass the filter and upload those files after conversion, but we can explain why an upload is being blocked in the AbuseFilter message (cf. MediaWiki:abusefilter-warning-mp3), and we can review the filter logs to see if users are deliberately bypassing the filter for infringing content. Omphalographer (talk) 21:24, 9 January 2024 (UTC)
  •  Support Infrogmation of New Orleans (talk) 20:01, 9 January 2024 (UTC)
  •  Support The issue seems similar to MP3 files. It's about a practical approach based on experience. No one, I assume, has anything against MP3 or WEBP as file types in principle, but it's just a matter of fact that Commons uploads of these file types tend to be copyvios more often than others, so a measure similar to the MP3 upload restriction already in place seems only sensible. The proposal is not about "outlawing" the format but restricting it to autopatrol users. Gestumblindi (talk) 14:22, 14 January 2024 (UTC)
    •  Comment as I detailed above, this will only result in circumvential behavior by circumstantial users (those who upload ~20 files once and never again). So yes, it will bring the DETECTED number of copyvios down. --Enyavar (talk) 10:11, 29 January 2024 (UTC)
 Support will bring the number of copyvios down. Only <20% of copyright violating users will actively evade by using an online file converter. Also I doubt that many competent users would use a WebP as a file format, most would use png/jpg/svg. —Matrix(!) {user - talk? - useless contributions} 16:53, 23 January 2024 (UTC)
 Support yes, per Yann. Hide on Rosé (talk) 08:01, 4 February 2024 (UTC)
 Neutral Enyavar and TheDJ made good points and I suggest these two points are addressed by support-voters. ( Oppose banning filetypes just because they're often copyvios, otherwise in 50 years all filetypes are banned and maybe PNGs are next. Instead I'd suggest WMF uses its millions of funds to get a bot working that detects "most-likely & likely copyvios to review" using tineye/google image reverse search and similar methods.  Support On the other hand, I don't know how often webp are copyvios and why that is and practicality etc brought up by support voters is a big point that must be considered. I just suggest that if the filetype is banned, it's only for a certain duration and/or this is revisited after some months or so. One could then try to see if it brought the actual (not just detected) number of copyvios substantially down and whether it made them harder to detect.) Note that for example all images in open access CCBY Nature studies seem to be webp files. Prototyperspective (talk) 12:21, 6 February 2024 (UTC)
  •  Support Yes please, zero chance of any webp being free..--Stemoc 06:42, 9 February 2024 (UTC)
    Please clarify what you mean by zero chance of any webp being free since as is that is provably false (for example one can convert a png image on WMC to webp) and directly above your comment I just wrote all images in open access CCBY Nature studies seem to be webp files. As such, without clarification your vote is based on a refuted rationale and thus should be dismissed if not corrected. If you refer to the fileformat, webp seems to be an open format. Prototyperspective (talk) 12:13, 9 February 2024 (UTC)
  •  Support I agree that the majority of the webp files are unfree/copyright violation, and I see no reason to keep such files on Commons. --A1Cafel (talk) 10:21, 15 February 2024 (UTC)
 Weak oppose as a great point by Enyavar. If we know that most .webp files are copyvios, we can delete them as they can by easily detected. If .webp files are banned, users are simply going to be converting it in .png or .jpeg, making it a whole lot tougher to detect the copyvio. On the other hand, maybe many new users are just going to abstain uploading webp images after it is restricted. I think banning .webp files are a risky choice. Contributers2020Talk to me here! 07:14, 24 February 2024 (UTC)

Disabling talk pages of deletion requests

While there now exists Template:Editnotices/Group/Commons talk:Deletion requests that notifies users to make comments on the deletion request pages themselves, it is evidently ignored, as seen in 54conphotos' comments on the talk page of Commons:Deletion requests/File:KORWARM2.jpg (which I transferred to the main page and in Amustard's comment on a Turkmen deletion request which I subsequently transferred to the mainspace. As it is very evident that the edit notice is being ignored, I am proposing that the "Talk" namespace be disabled in all pages with prefix "Commons:Deletion requests/". This should be a permanent solution to the incidents that should have been better avoided. For existing talk pages of deletion requests with comments, the comments (including mine if ever I had responded to uploaders in the talk page namespaces) should be transferred to the deletion requests mainspaces, with consideration to the dates of the comments or inputs. JWilz12345 (Talk|Contrib's.) 09:10, 26 November 2023 (UTC)

 Support At least, the use of DR talk pages should restricted to power users (admins, license reviewers?). Yann (talk) 09:37, 26 November 2023 (UTC)
@Yann that may be OK. Restricted to admins and license reviewers. Or the talk pages are still existing visually but those who don't have user rights, even autopatrolled ones, will be barred from editing talk pages and be presented with a boilerplate notice that they don't have the right to edit talk pages and should instead comment on the main discussion page, with a link to the DR itself in the notice (do not expect several new users to comprehend what they are reading in the notices). JWilz12345 (Talk|Contrib's.) 10:09, 26 November 2023 (UTC)
 Support --Krd 11:23, 26 November 2023 (UTC)
 Support Christian Ferrer (talk) 11:56, 26 November 2023 (UTC)
Thank you for pointing out this Template:Editnotices/Group/Commons talk:Deletion requests location in Wikimedia. This was not ignored as you said in your comment, it simply was no where to be found at the time I commented. It's a shame it's too late to place a comment there as I would have done so. Even your notes to me are very confusing as the names of Comments pages do not match up so I can find them as are all the previous notes received by others. Being new to this platform, I have found it very confusing to find things that are suggested when seeing comments by others.
Hopefully I will have the hours to research and better understanding of the workings of Wikimedia Commons in the future. Thanks again! 54conphotos (talk) 13:32, 26 November 2023 (UTC)
 Support or, if it's easier, systematically turn them into redirects to the relevant project page. - Jmabel ! talk 21:56, 26 November 2023 (UTC)
 Support --Adamant1 (talk) 00:35, 27 November 2023 (UTC)
 Support. Some good ideas above from Yann and Jmabel. We could also explore autotranscluding them to the bottoms of the DR subpages themselves.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:49, 27 November 2023 (UTC)
and restricting to admin and LRs per Hide on Rosé below.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:12, 30 March 2024 (UTC)
 Support. Yes, good idea, esp. with Jmabel’s and Yann’s additions. -- Tuválkin ✉ ✇ 11:34, 27 November 2023 (UTC)
 Support to restrict it to anyone with autopatrol, I think these users are knowledgeable enough to know that the talk page isn't to discuss the deletion. We must create an informal and easy-to-understand AF notice though. -- CptViraj (talk) 12:19, 9 December 2023 (UTC)
Another one, this misplaced comment by ApexDynamo, which I have transferred to the main nomination pages. CptViraj, I don't think even autopatrolled users are still knowledgeable enough to know that talk pages are not proper forums to comment. Example: misplaced comments by Exec8 (which I also transferred soon after initiating this proposal). I suggest the use of those talk pages must be restricted to admins/sysops and license reviewers. JWilz12345 (Talk|Contrib's.) 09:38, 14 December 2023 (UTC)
Still, rare cases for autopatrollers. IMHO we shouldn't unnecessarily take away the power completely, the problem is mainly caused by newbies/non-regulars. -- CptViraj (talk) 18:13, 23 December 2023 (UTC)
 Support I have never used a talk page of a DR nor have I seen one being used. The DRs are usually also frequented by very few editors and the comments can easily be distinguished from one another.Paradise Chronicle (talk) 22:13, 30 December 2023 (UTC)
One more problematic use, by @Balachon77: (see this). JWilz12345 (Talk|Contrib's.) 01:00, 8 January 2024 (UTC)
Another problematic use, by SiCebuTransmissionCorrecter (talk · contribs) – Commons talk:Deletion requests/File:Line construction of Hermosa-San Jose Transmission Line. The line constructs above Hermosa-Duhat-Balintawak transmission line.png. JWilz12345 (Talk|Contrib's.) 00:10, 9 January 2024 (UTC)
no no no no no no! SiCebuTransmissionCorrecter (talk) 01:12, 10 January 2024 (UTC)
Commons_talk:Deletion_requests/File:Afrikan_och_Afrikanska_x_Ingel_Fallstedt.jpg ? DS (talk) 14:50, 22 January 2024 (UTC)
@DragonflySixtyseven the discussion should have been made at COM:VPC or at concerned admin's talk page. Ping @Holly Cheng and De728631: for attention. JWilz12345 (Talk|Contrib's.) 21:35, 7 February 2024 (UTC)
I was the one who started the discussion about the undeletion date. That's the type of thing that makes sense to do on the DR's talk page. —holly {chat} 21:43, 7 February 2024 (UTC)
@Holly, do you think this was useful enough to you that you would be opposed to making this change? I don't see a lot of loss if you had to do something like this directly on the DR page. I realize we normally don't touch DRs once they are closed, but we do add categories to them (for example) and I've seen a closing admin go back and add to their rationale. It's also what we typically do on a DR for a single image if the image is kept, then later nominated again for deletion. This seems similar to that, though I think you'd want to put the new content below the {{Delf}} template. - 23:45, 7 February 2024 (UTC) — Preceding unsigned comment added by Jmabel (talk • contribs)
@Jmabel: If we stick the new content below the {{Delf}} and then it gets nominated for deletion again, won't that mess up the bot that does the archiving? In the case of undeletions due to expiration, that would probably be extremely rare. I suppose if that does happen, someone can always manually archive it. I guess I'm not opposed. The benefits seem to outweigh the possible risks. —holly {chat} 17:16, 12 February 2024 (UTC)
@Holly Cheng: I'm not certain even what archiving you are referring to. There's nothing I'm aware of that any bot does to the individual DR page, and I'm not sure what is Krdbot's rule to remove the transclusion of the individual DR in the page of DRs for a particular day. It's obviously able to cope with categories below the {{Cfdf}}, but maybe not other text. User:Krd, I presume you could answer this. - Jmabel ! talk 01:07, 13 February 2024 (UTC)
I meant the moving of individual DR subpages from the day page to the day archive page. —holly {chat} 17:58, 13 February 2024 (UTC)
Exactly. And I don't know User:Krdbot's rule for that, which probably only User:Krd can answer, unless someone feels like doing a bunch of research. - Jmabel ! talk 20:16, 13 February 2024 (UTC)
"Only Categories" is the answer, though I'm not sure to which exact question. Krd 05:42, 14 February 2024 (UTC)
That's too bad. Then it sounds like Holly's use case might be reason enough to keep the talk pages for these. Does anyone see a good workaround? - Jmabel ! talk 05:52, 14 February 2024 (UTC)
I think the use case is invalid, as the objection should better be on a user talk page. Does anybody watch deletion requests? I don't. Krd 06:08, 15 February 2024 (UTC)
@Krd I only watch DRs that I made, or that have significant interest in me that I am heavily involved, like responding to comments or questions every now and then. Though I heavily encouraged everyone to comment on DR pages themselves, not the DR pages' talk pages. On DRs that I am watching, I force the respondent (typically the uploader of the nominated file) to reply on the nomination page proper by moving their comment from the talk page to the nomination page proper and responding their question or protest, with the addition of a reminder for them to comment or respond on the nomination page proper. JWilz12345 (Talk|Contrib's.) 07:40, 15 February 2024 (UTC)
 Strong support I see no reason to nominate someone's talkpage for deletion unless there is a strong reason, i.e. vandalism, or purely disruptive nature. However, I think this is only a very small number of them, and it should be handled by senior users. --A1Cafel (talk) 10:18, 15 February 2024 (UTC)
Support I see no reason why the talk page of a DR is required. Admins should be allowed the edit permissions for maintenance reasons -- DaxServer (talk) 18:56, 14 March 2024 (UTC)
 Support Restrict to admin and LRs. Hide on Rosé (talk) 14:51, 27 March 2024 (UTC)
 Info one more problematic use, by BDS2006. I just blanked it and transferred it to the main nomination page. JWilz12345 (Talk|Contrib's.) 07:51, 5 April 2024 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2023/11&oldid=874370942"