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

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

Hi, its nearly 2023, so per COM:HIRTLE, we need to make a copyright tag for works that were renewed published by the US Copyright Office in 1927, and therefore entered the public domain in 2023. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 22:59, 24 December 2022 (UTC) (Editing renewed to published, I seemed to have mistyped a word. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 10:58, 25 December 2022 (UTC))

I've brought this up every year here and at en.ws and there's always a phab: ticket for it. As I recall, the solution last time was to make the copyright tags dynamic, so that they always just subtract 95 from the current year. —Justin (koavf)❤T☮C☺M☯ 23:24, 24 December 2022 (UTC)
@Matr1x-101: How would this differ from {{PD-US-expired}}? And I'm not sure I follow about "renewed in 1926". I believe that anything renewed in 1927 would long have been in the public domain, the issue is things first copyrighted in 1927, no? - Jmabel ! talk 01:39, 25 December 2022 (UTC)
@Jmabel: , yeah, I meant first published, not renewed, sorry. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 10:56, 25 December 2022 (UTC)
{{PD-US-expired}} would be the tag that you want. Nothing new is needed it will update the year it displays when the calendar changes. Carl Lindberg (talk) 05:32, 25 December 2022 (UTC)
@Carl Lindberg: , I meant published after 1927, not renewed. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 10:59, 25 December 2022 (UTC)
@Matr1x-101 Unless I misunderstand what your concern, I think it's addressed: PD-US-expired will change to use Jan. 1, 1928 automatically. —‍Mdaniels5757 (talk • contribs) 16:06, 25 December 2022 (UTC)
Okay, then everything's fine! --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:58, 25 December 2022 (UTC)
This section was archived on a request by:   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:01, 25 December 2022 (UTC)

Requests for comment: 2022 overhaul of categories by period

Commons:Requests for comment/2022 overhaul of categories by period.--RZuo (talk) 07:42, 5 December 2022 (UTC)

Notifying everyone of an RfC

Hi, just notifying everyone of an RfC happening here. It's discussing files that were poorly imported from other wikis (often just cut and pasted) that don't preserve the history. --Matr1x-101 {user page - talk with me :) - contribs!} 12:43, 19 December 2022 (UTC)

Template_talk:Subject_by_century#Allowing_a_prefix?

Hi, I just wanted to ask if it's at all possible to create navigational templates by century that allow a prefix, as per the discussion in the link. --Enyavar (talk) 14:13, 21 December 2022 (UTC)

AI generated media guidelines

Per the discussion at Commons:Village pump#Category:AI generated images, I've created a very rough draft of some guidelines for AI generated media on Commons. Feel free to edit boldly and discuss on the talk page. Nosferattus (talk) 03:00, 30 December 2022 (UTC)

Enable ProveIt or Citoid on Commons

References are often used here:

However citoid and Help:Gadget-ProveIt aren't enabled here, even if you manually activate the VisualEditor in your Beta settings here. So:

  • Many people don't use the templates and instead write the sources "manually":
    • The format is inconsistent across pages.
    • It's often in the uploader's language instead of a standard international format that anyone can read. Good luck reading references in Chinese, for instance: File:南宋疆域图（简）.png.
    • There are bare URLs, often pointing to "dead" websites, using a template would enable bots to automatically archive these URLs as on Wikipedia.
  • Many people copy/paste the equivalent templates from Wikipedia, however these templates aren't identical. For instance "first1" isn't displayed here (see Template_talk:Cite_book#Extra_authors) so the authors are often hidden on Commons ("first" or "author" should be used instead on Commons).

So I suggest enabling ProveIt (remove the "hidden" parameter, see Help_talk:Gadget-ProveIt#Enabled_here?) and/or citoid to allow people to automatically generate citations based on a URL, doi, or ISBN and provide better references to readers. What do you think? A455bcd9 (talk) 12:24, 13 December 2022 (UTC)

Support for enabling both. (ie. formal citoid support on visual editor at site configuration and adding provelt to gadgets) -- Zache (talk) 12:36, 13 December 2022 (UTC)
Support since I've seen both tools do much good in other wikis. Sophivorus (talk) 13:16, 13 December 2022 (UTC)
@Sophivorus: If we enable these tools here they will not be enabled by default: right? Only editors who manually enable them in their preferences will be able to use them? A455bcd9 (talk) 13:23, 13 December 2022 (UTC)
@A455bcd9 Regarding Proveit, yes. Regarding Citoid, I'm not sure but I think it'll be enabled for all users. Sophivorus (talk) 13:32, 13 December 2022 (UTC)
@Sophivorus OK for ProveIt. Regarding Citoid, as the Visual Editor isn't enabled by default on Commons (it has to be enabled in the Beta features) I think that all users won't have access to Citoid by default BUT all users who have already enabled the Visual Editor on Commons will then automatically see the Citoid gadget. Am I correct? A455bcd9 (talk) 14:14, 13 December 2022 (UTC)
@A455bcd9 Probably, yes. Sophivorus (talk) 14:17, 13 December 2022 (UTC)

Adding NOTHERE to Blocking policy

Looking at this current discussion, there is an argument that the blocks do not fall under Commons:Blocking policy. I suggest adding the equivalent of en:WP:NOTHERE to blocking policy. I think this would actually reflect consensus here as I vaguely recall blocks of users who spend their time either fighting or making up copyright claims or misusing the help desk or are just somewhat trolling overall (but not harassment of another user specifically which is covered). Ricky81682 (talk) 22:59, 27 December 2022 (UTC)

I also note that categorization fighting (namely a failure to follow consensus) is a common reason for people to be blocked and could either be considered edit warring or just plain disruptive editing. Ricky81682 (talk) 23:10, 27 December 2022 (UTC)
Sorry, but what does NOTHERE mean? Block anyone who's blocked on :en:Wikipedia? (because that's the subtext here). Or is it for some other reason that you "vaguely recall blocks of"? Andy Dingley (talk) 23:23, 27 December 2022 (UTC)
Not here to assist in assist in the creation of a media repository of free-to-use images. I said equivalent as we are not an encyclopedia and there are plenty of people who edit here who are blocked on other projects. NOTHERE isn't even a policy on English and official policy here only lists "common" reasons for blocks. Ricky81682 (talk) 23:40, 27 December 2022 (UTC)
So of the ten headings for Commons block policy, which are you planning to block Benlisquare under? Uploading anime style represenations? Unislamic uploads?
Your stated position is completely inconsistent: you're advocating NOTHERE, then confirming that's it's not even a policy on en:WP. You're looking to block people for the same reasons as Wikipedias, then acknowledging that "there are plenty of people who edit here who are blocked on other projects". Or did you mean "misusing the help desk"? (We don't have a help desk) Andy Dingley (talk) 23:56, 27 December 2022 (UTC)
What is Commons:Help desk if not a help desk? Ricky81682 (talk) 00:00, 28 December 2022 (UTC)
Sorry, I thought you were still talking about Wikipedia. Where misuse of the question-based reference desks does attract abuse, and sometimes blocks. The Commons help desk is much more restricted, simply on how to use Commons, and I've never seen a block arise from it. Andy Dingley (talk) 00:12, 28 December 2022 (UTC)
Let me look over history and see if I can find examples. I'm trying to figure out a generalized description as "misuse of Commons resources" is not accurate. I do know people have been blocked for uploads that are used to be disruptive on other wikis (I'm thinking of flags mostly) but maybe this is an exercise going nowhere if people would rather have blocks done without any explanation provided. Ricky81682 (talk) 00:34, 28 December 2022 (UTC)
I do not think we need a real policy change but maybe we should rename "Vandalism" to "Vandalism and counter productive behavior". The word Vandalism means damaging something without any further intention behind it. Many of the users blocked are not blocked for intentional harm but due to ignorance or because of being only here to distribute their (political) message. GPSLeo (talk) 08:01, 28 December 2022 (UTC)
“counter productive behavior” is rather broad and open to interpretation. Bidgee (talk) 08:35, 28 December 2022 (UTC)
No, this is just an extension of this bizarre public humiliation war against a user who uploaded too many AI-generated pictures of boobs and threw a tantrum about it. We have our own NOTHERE, it’s “not a web host” and “not an amateur porn site” and we don’t randomly use them against active users we particularly dislike. Dronebogus (talk) 00:31, 29 December 2022 (UTC)
NO. a "catch-all crime" is a hotbed of abuse of power.--RZuo (talk) 20:55, 29 December 2022 (UTC)

Make renaming policy more strict

Nearly every day there are disputes and complaints on renamed files. For solving this I would propose the following changes to the renaming policy without limiting renaming to admins only.

I refer to the criteria of the current Commons:File renaming policy.

Under the new policy renaming should only be done in the following cases:

  1. By the uploaded under any of the current cases.
  2. By an administrator if they see an urgent need.
  3. By every file mover unter the criteria 2, if it is really only a name like img_0001.jpg. Under criteria 3, 5 and 6. In all of these cases the uploader can undo the renaming and the person who wanted the file renamed has to discuss this with the uploader.
  4. Renaming in other cases of criteria 2 and 4 has to be proposed and the uploader can veto withing 14 days. If the uploader disagrees an admin has to decide after hearing the arguments of both sides. If the uploader agrees or does not respond the file can be renamed. If the uploader is blocked the files can be renamed directly.

GPSLeo (talk) 16:52, 29 December 2022 (UTC)

  • Oppose Your case for these changes is poorly made and very unclear. You have given no justification for these changes, and the changes you mean aren't precisely stated.
Most obviously the effects here would be to limit the actions available to filemovers and limit some to admins only. That is both technically problematic (filemovers can move any files, the permissions limit doesn't recognise your definitions) and it's also placing admins as "content judges", something we've always opposed.
You are unclear as to whether you're discussing requesting renames or making renames. Uploaders (point #1) can't rename, they can only request.
Are your arbitrarily numbered bullet points related to the numbered policy reasons? (then why not type in the numbers and make them stable? – we've been down that path before)
Your #2 "By an administrator if they see an urgent need." is effectively "these policies may be ignored at the whim of any admin". That is a terrible change (we've just seen a case of that, which you were active in commenting upon). How about an admin who decides to rename "young girl" to "disgusting pornography against my own religious views"?, because matters of personal or religious offence are always the most urgent thing ever!
Your #3: isn't it always policy (under BOLD for one) that any editor, not just an uploader, can challenge a rename, until we've discussed it and demonstrated consensus for a change (or not). Uploaders can't "undo" anything here.
Your #4: introducing a new discussion period and a 14 day delay (twice that of a DR) before we can perform simple renames of filenames. It also gives uploaders a veto, whatever the issue!
Also #4: "an admin has to decide after hearing the arguments of both sides." Seems to be ignoring consensus, also permitting an involved admin who made the first change to simply ignore the discussion.
None of this is in line with Commons policies or principles. It's also giving several more excuses for poor and subjective admin decisions against policy or the consensus amongst editors. Andy Dingley (talk) 18:53, 29 December 2022 (UTC)
Yes these rules are complex but I tried to find a way to restrict file renaming a bit more without totally banning it or limiting to admins only. Yes the points are assuming that the uploader has renaming rights, but as most active uploaders have these right this is the regular case. The second point with the urgent need is only because of the fourth case and is of course limited to the renaming guidelines. The current state is that the uploader does not have any kind of prioritized opinion on their file names. To Number 4: I do not understand why you say this is something totally new? This is very similar to the procedure of deletion requests or the categories for discussion process.
But of course an other alternative could be using the same procedure as for categories for discussion for file renaming, then we would not need such kind of complex case handling procedures and rules.
On the need for these changes:
On the Commons:Administrators' noticeboard/User problems there is currently one long linked to file renaming.
On Commons:Administrators' noticeboard/User problems/Archive 101 there are three cases.
On Commons:Administrators' noticeboard/User problems/Archive 100 there are two long cases.
On the German Forum there were two long discussions in October and November. GPSLeo (talk) 19:45, 29 December 2022 (UTC)
i skimmed thru some discussions.
i'd say most quarrels about file renaming are due to two kinds of users:
  1. unqualified, careless filemovers (who make useless cosmetic changes, apply rules wrongly...)
  2. stubborn uploaders (who refuse any renaming of their files, even if renaming is clearly justified)
and the solutions accordingly would be:
  1. remove filemover
  2. ignore them
anyway, i dont seem to see urgent needs to change COM:MOVE.--RZuo (talk) 20:55, 29 December 2022 (UTC)
Oppose per Rzuo. There’s nothing so bad about the current policy it needs changing. This is terrible and confusing needless bureaucracy. On top of that this is ANOTHER attempt at giving admins even more unchecked power despite the fact that there is a long dispute at the noticeboard over at least two admins overstepping their bounds. Please read the room and withdraw this. Dronebogus (talk) 00:58, 30 December 2022 (UTC)
User:GPSLeo writes, "The current state is that the uploader does not have any kind of prioritized opinion on their file names." This could not be farther from the truth. They select a filename on uploading, and if it's an appropriate filename, it is very unlikely ever to be changed by anyone else. ("Unlikely" doesn't mean it can't ever happen, but it is rare for a well-named file to be renamed to something else unless the uploader wants to modify it themself.) - Jmabel ! talk 01:31, 30 December 2022 (UTC)
  •  Oppose, regarding the owner being able to veto it. If you contribute something to the Wikimedia Commons you are contributing it to be improved by others, see "Commons:Ownership of pages and files" "You agreed to allow others to modify your work here. So let them.", as long as it's an improvement it should be welcome. Also, not sure why blocked uploaders should be seen as second (2nd) class users, if they have talk page access (TPA) they should be able to make reasonable arguments. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:10, 14 January 2023 (UTC)
  •  Oppose It look like you want to eliminate COM:FNC 2-6 to an admin opinion situation. That is more open to vague interpretation not more strict. What is the purpose of 3 if admins could do it themselves? If it is not settled, I think admins currently ask for there to be some sort of consensus on the file talk page rather than force a move. We should probably have a better system that say if the file move request is rejected or opposed after the fact, then what should be done. -- Ricky81682 (talk) 00:04, 15 January 2023 (UTC)
 Oppose The proposal should have been titled ‘Make renaming guideline more confusing’, because Commons:File renaming is indeed labelled as a guideline, and making it more confusing is exactly what this proposal does. Other users above have already discussed that confusion, but there are even more issues:
  • The new guideline still allows renaming ‘by the uploade[r] under any of the current [criteria]’. One of the current criteria is: ‘At the original uploader’s request.’ At first glance, this appears to make all that stuff about uploader vetoes redundant. But the current criterion comes with a footnote: ‘If a file mover feels that a proposed new name is disruptive or inappropriate, they can suggest a different name or decline the request.’ Combine this with uploader vetoes, and surely nothing good will happen.
  • There are two different types of uploader vetoes. In some cases, the uploader can undo the rename at any time, and repeating the rename then requires discussion. In other cases, the uploader has only 14 days (but still twice the standard length of a deletion request!) to object. This is just more confusion with no explanation at all.
  • The uploader can undo renames made under the current criterion 5, and repeating the rename then requires discussion. But the current criterion 5 is for changing names that violate policies and guidelines. Why is this eligible for an uploader veto at all?
Brianjd (talk) 14:40, 20 January 2023 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2022/12&oldid=773167811"