Commons:Village pump/Proposals/Archive/2020/05

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

MediaWiki:LicenseReview.js as a gadget

ADDED:

Thanks to Ahmad252, LicenseReview is available as a gadget now. Any admin can notify those who use various versions of the script ("userscripts") of the new gadget using MassMessage or any other means. 4nn1l2 (talk) 14:25, 4 May 2020 (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.

Hello.

On 29 March 2020‎, 4nn1l2 copied the content of User:Majora/LicenseReview.js to MediaWiki:LicenseReview.js. I remember this was once proposed when Majora was still active, but as Majora wasn't an interface administrator and because they were the main maintainer of the script, the idea was rejected. However, now that they have, unfortunately, retired from Wikimedia projects, it seems to be a good idea in many aspects. Now that it is available in MediaWiki namespace, I propose adding it to the list of gadgets, as it has been listed on Template:Image-reviewerWelcome and because it's the main license reviewing script. I suggest adding it to the "Tools for authorized users" section in the gadgets list, and limiting it to users with the patrol user right (limiting based on user groups is not possible; see mw:Extension:Gadgets). Ahmadtalk 23:31, 14 April 2020 (UTC)

Votes, MediaWiki:LicenseReview.js as a gadget

Discussion

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:08, 15 May 2020 (UTC)

Proposal: hotkey for Wikidata Infobox in edit window

(No response on this question on /Technical, so I try here now.)
I would like to request to add a hotkey for {{Wikidata Infobox}} in the edit window (similar to the buttons for DEFAULTSORT, NAMESPACE, etc.): is this the right place to propose? Thanks, Eissink (talk) 14:57, 15 May 2020 (UTC).

I added that on MediaWiki:Edittools. Now you'll see the button for categories. – Kwj2772 (talk) 07:22, 16 May 2020 (UTC)
Thanks you, Kwj2772, but I am not sure what you mean and what you did and I don't know what the category button has to do with it. I see in the script you added {{Wikidata Infobox}}, but it's not showing in my edit window. Do I need to change something in my preferences? Thanks, Eissink (talk) 08:59, 16 May 2020 (UTC).
Now I see it does show up! Thank you very much. Eissink (talk) 09:27, 16 May 2020 (UTC).
This section was archived on a request by: pandakekok9 10:42, 18 May 2020 (UTC)

Proposal: Modify block policy

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.
The proposed new section concerning checkuser blocks has now been added to the policy based on the below community consensus. odder (talk) 09:58, 21 May 2020 (UTC)

Following consensus gathering discussion at Commons talk:Blocking policy, I would like to formally propose Commons:Blocking policy be modified to include the following:

Proposed addition

Checkuser blocks

Checkusers may need to block an editor, on the basis of technical checkuser evidence, due to disruption caused by abuse of multiple accounts or IP addresses. These blocks are marked as a {{Checkuserblock}} in the block summary and must not be reversed by non-checkusers without consulting a checkuser.

As checkuser data cannot be shared publicly and a checkuser block may involve other pertinent non-public information, an unblock appeal for a {{Checkuserblock}} must only be reviewed by a checkuser. A reversal of a check user block by an administrator without consulting a checkuser may result in the removal of permissions.

The rationale for this proposal is to remove ambiguity for who may review a checkuser block. A new section is proposed (rather than changing a single word), similar to the section for oversight blocks, to ensure this is clear. ~riley (talk) 07:14, 18 April 2020 (UTC)

Note: " without consulting a checkuser." has been added as of 19:14, 18 April 2020 (UTC) per discussion below. ~riley (talk) 19:14, 18 April 2020 (UTC)

Votes (block policy)

  •  Support as nominator. ~riley (talk) 07:16, 18 April 2020 (UTC)
  •  Support per discussion at the policy's talk page. --pandakekok9 07:25, 18 April 2020 (UTC)
  •  Oppose This change increases the non-transparency of Commons Checkusers without any proportionate increase in good governance (accountability). The case that caused this proposal shows a checkuser behaving badly with zero repurcussions, nor any credible governance process to hold them to account. That's pretty damning for this project or the meaningfulness of the high level of trust that Checkusers should have and in theory must demonstrate. A good change to the checkuser policy would be to address these serious gaps in good governance and "trustworthiness" for those that are honoured to hold Checkuser access. --Fæ (talk) 07:26, 18 April 2020 (UTC)
I do have concerns regarding transparency if you will see the discussion on the policy's talkpage. However, clarifying policy is top priority. Figuring out how to scrutinize the CUs is not abandoned though, GMG brought up an idea of forming a "local ombudsman" which are elected just in case a review of CU is needed. A local OMB can be granted temporary access to CU tools in cases where the community wishes to see if CheckUser was misused. pandakekok9 07:32, 18 April 2020 (UTC)
No, establishing the most basic good governance for Checkusers is "top priority", not low level and unimportant fiddling with the wording of the policy to have slightly better norms. Interim proposals will only make it less likely that the more serious changes to this project's governance of Checkusers will ever be implemented. --Fæ (talk) 07:35, 18 April 2020 (UTC)
Seperate issue that needs to be addressed at a seperate time - let's take this one proposal at a time and start with the ones that are easier to tackle. As we all know, tackling anything to do with governance and oversight is not easy. Opposing this proposed policy (which is pretty standard across Wikimedia projects) because of a lack of trust and oversight rather than working to propose or fix those issues is not helpful. ~riley (talk) 07:44, 18 April 2020 (UTC)
Or, you could just let me vote in a consensus without criticising me, and by implication putting off any other member of this community who might think about opposing this proposal because it fails to address the core issue.
I'll not be replying further, times are hard enough. Thanks in advance. --Fæ (talk) 07:49, 18 April 2020 (UTC)

Discussion (Modify block policy)

Discussion and suggestions/modifications welcome but please first read Commons talk:Blocking policy to avoid discussing in circles. ~riley (talk) 07:16, 18 April 2020 (UTC)

@~riley: I would assume it ordinarily requires an uninvolved checkuser but not sure. Perhaps worth asking one of the checkusers? --Green Giant (talk) 11:17, 23 April 2020 (UTC)
I think the last sentence is too strong. If a non-CU Admin removes a CU block, the action should be immediately reversible by a CU, but I don't think the Admin should be severely sanctioned. And, yes, I certainly agree that CU blocks can be changed only by another CU -- but it may not be an "uninvolved CU" -- since there are only a limited number of CUs, there may not be an uninvolved one, as in the recent case with Alexis Jazz. .     Jim . . . (Jameslwoodward) (talk to me) 13:21, 23 April 2020 (UTC)
I have perhaps the opposite perception; it seems to me so weak as to be devoid of meaning. "[M]ay result in the removal of permissions" is a mere statement of possibility (it is not, for example, "shall" or "will"). Permissions may be removed, or they may not be--the sentence has no genuine substance. Undoing a valid block and/or wheel-warring is inherently an abuse that "may result in the removal of permissions" whether related to CU action or not; articulation of related consequences/sanctions belongs at COM:DEADMIN. For our purposes here, I agree with Jim: removal of a CU block by a non-CU admin is an invalid and immediately reversible action. To the extent the removal is repeated, the "routinely" in "acting against policy and routinely abusing their status" (COM:DEADMIN) ought to be considered met. Эlcobbola talk 14:24, 23 April 2020 (UTC)
The sentence is intended to indicate that there is grounds for a de-admin request to be opened. Terms like "shall" or "will" would imply that permissions could be removed without the opening of a de-admin request. What wording would you propose instead, elcobbola? ~riley (talk) 05:53, 29 April 2020 (UTC)
None of this would remove the requirement for a community deadmin discussion, but would provide grounds for such a discussion. GMGtalk 00:10, 30 April 2020 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 08:16, 22 May 2020 (UTC)

SVG transfer request

Please, transfer it:File:CRAI_logo.svg on Commons with the {{PD-Ineligible}} and {{Trademarked}} licenses. They are accepted and approved licenses. Thanks! --2001:B07:6442:8903:D593:17B6:C48B:30AE 16:28, 21 May 2020 (UTC)

This section was archived on a request by: Speravir 00:40, 23 May 2020 (UTC)

suggestion concernant ce fichier: File:COVID-19 Outbreak Hospitalized in France 13 Regions & DomTom.svg

Bonjour Je voudrais faire une remarque sur la carte de France que vous éditez.

A- en haut à gauche le nombre de décès tient une très grande place qui ne se justifie pas. B- en haut à droite les nombres d'hospitalisés, en réanimation et guéris sont écrits en tout petit. 

  C'est pratiquement illisible alors que la date tient une place énorme.

Pourquoi ne pas mettre le A à gauche où il y a plus de place et le B à droite ?

C- en bas à gauche il doit être possible de mettre ce tableau verticalement pour le rendre lisible.

Cette carte est très bien faite et vous pourriez la rendre encore plus lisible. Merci d'en tenir compte si possible. Cordialement

Henri DIDELLE henri.didelle@gmail.com — Preceding unsigned comment was added by 2A01:CB15:803D:D500:345B:9A4E:13:410E (talk) 14:27, 7 May 2020 (UTC)

This page is for discussing proposals relating to the operations, technical issues, and policies of Wikimedia Commons - I would suggest contacting the person who has been updating the file every day: @Antidote2020: . If it needs further discussion, that should probably take place either on the file's talk page or Andidote2020's. Storkk (talk) 14:40, 7 May 2020 (UTC)
@Henri Didelle : merci pour vos remarques et compliments, je vous invite à poursuivre ici → File talk:COVID-19 Outbreak Hospitalized in France 13 Regions & DomTom.svg. Antidote2020 (talk) 19:39, 7 May 2020 (UTC)

Patrol reform

See Commons talk:Patrol#Patrol reform. pandakekok9 10:50, 19 May 2020 (UTC)

Category:Buildings by year of photographing

Where is the best place to have an overall discussion about Category:Buildings by year of photographing and the various types of buildings as subcategories? It's really a Category:2018 photographs by subject question as bazaars, castles, cinemas, educational institutions belong within the building by year category. At the same time, it's not clear when you actually get back to the same buildings from the top-level subject. Category:Buildings photographed in 2018 is a subcategory of Category:Structures photographed in 2018 which is a subcategory of the (all red links) Category:Architecture photographed in 2018 which I assume is supposed to be the top level category for photography by subject. We kind of need an overall discussion. -- Ricky81682 (talk) 01:49, 22 May 2020 (UTC)

  • Problem: There has been long a large discrepancy between the volume of file uploads and the capacity of Wikimedia Commons to check whether they actually conform to copyright laws. The bottleneck is the limited number of admins: While any user can upload and review a file, only an admin can decide the case.
  • Consequence: There is a huge backlog of pending cases, waiting weeks and months for being finally sighted and decided by an admin, while the copyright violating material stays on Commons – against the law. Even more, many uploaded files that are copyvios are never detected as neither users or admins more closely review them.
  • Solution: Files could still be uploaded by any user, but they should only be cleared for use after they have been reviewed by another user or admin for adhering to copyright laws. Only this way it is ensured that the number of checked and uploaded files is identical.
  • Comment: The current checking system is dependent on random chance. It is only a question of time that third parties (press, companies, major copyright holders) become aware that Wikipedia Commons is not only the largest online image deposit but might be also its largest copyright violator. The damage to Wikipedia's reputation would be immense and lawsuits may follow. We need to be proactive to avoid such a situation. Gun Powder Ma (talk) 11:47, 22 May 2020 (UTC)

Votes

  •  Oppose per the arguments on the Discussion subsection. It's just not practical, with the size of the patrol and LR backlog and small number of active volunteers right now. --pandakekok9 13:48, 23 May 2020 (UTC)

Discussion

  •  Comment I think this system will introduce even more delays and backlogs. I sympathize with the problem but do not like the solution. --Jarekt (talk) 15:14, 22 May 2020 (UTC)
  • Agree with Jarekt. The delays will only get longer, and people will not have the gratification of uploading images and using them right away, which will likely just prevent good images from being uploaded as it's too much bother. There is a reason the DMCA exists, if stuff was missed -- that is kind of the purposes of those, to avoid the lawsuits. Those will be handled promptly. Also keep in mind that most things we call "copyright violations" really aren't -- the lack of fair use is policy, but our actual usage often still falls under that. Many uploads are more policy violations, rather than actually being illegal. Obvious problems via speedy delete usually happen fairly fast. It's far from perfect, but I think the potential damage in this proposal far outweighs the possible benefit. Carl Lindberg (talk) 19:07, 22 May 2020 (UTC)
  • Rather than random, copyvios are most frequently connected via the same upload account. Significant copyvio activity is often resolved by mass speedy deletions without needing people to accidentally discover each file. Those that monitor recent changes spot and tag these obviously connected uploads pretty efficiently. --Fæ (talk) 19:31, 22 May 2020 (UTC)
  • This doesn't seem practical due to current backlogs. More COM:AF, bots, speedy deletion criteria and restricting mass uploads from Flickr would reduce the problem.--BevinKacon (talk) 11:16, 23 May 2020 (UTC)
  • I'd love to see a solution to this issue. I spend quite a bit of time looking at new uploads these days. Quite a number need more than the amount of time I can spare to be anything like happy with licensing. It might be useful to look at the simply personal images (which seem far more prevalent these days) but it's a thorny problem. --Herby talk thyme 11:23, 23 May 2020 (UTC)
  • I agree that there are a fair number of bad files being uploaded here, but I don't really think we have the number of active volunteers here to make the proposal work. Patrolling and license review operate in similar ways, and both have massive backlogs. I imagine a lot of users (excluding the ones probably reading this, to which this is their home project), just upload images ad hoc when required for use on another project. If this was no longer quickly possible (this process would become backlogged), then this supply of images would dry up. I'd rather have a useful image host with a few copyvios than a completely copyvio free host with no media to host. ~~ Alex Noble - talk 12:08, 23 May 2020 (UTC)
  • I heard on a long ago previous discussion about the possibility of automatic copyvio checking via TinEye or Google Images. Is it still being worked on right now? pandakekok9 13:50, 23 May 2020 (UTC)
  • I'm not going to "vote" against it as there's clearly no consensus to implement it, theoretically a system of clearance could be implemented for users with proven bad trackrecords of copyright abuse in lieu of blocking. The original proposal is a useful idea, but unfortunately will introduce more problems than it solves. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:05, 23 May 2020 (UTC)

Create a Commons equivalent of Wikipedia:Embassy (Q1197883)

Last year I suggested to close inactive, unattended versions of Village Pumps in other languages: Commons:Village_pump/Proposals/Archive/2019/06#Close_inactive_non-English_village_pumps. So many users vow to keep them, but still no actual measures were taken to improve answering requests for help.

Today I saw someone referring ppl to the Turkish VP. 🤣 Come on it's long deserted!

The better solution would be to notify a Turkish user to help, so the Embassy comes to mind. Surprisingly, there isn't one yet?! There's only a Commons:List_of_administrators_by_language?

Therefore, I suggest a list should be set up and users can sign up to volunteer for any languages. Maybe a bot can be devised to keep the list up to date by removing inactive (>1 year?) volunteers from time to time. (But some most common languages, such as English, might not need a list.) Then when ppl see foreign languages they cant help with, they can invite a user from the Embassy to attend to the newbies.--Roy17 (talk) 01:26, 27 May 2020 (UTC)

  •  Support Good practical proposal. As a side note, Wikipedia finally got unblocked in Turkey a few months ago, so I expect a more natural flow of Turkish users on Commons too. User:E4024 may help ppl with regard to Turkish language. 4nn1l2 (talk) 02:45, 27 May 2020 (UTC)
  •  Support · Good idea. -- CptViraj (📧) 04:00, 27 May 2020 (UTC)
  •  Support Huh, I thought we already have some kind of embassy. We're a multilingual project after all. If this proposal passes, I would immediately volunteer in a "Tagalog Embassy". :) --pandakekok9 05:07, 27 May 2020 (UTC)
  •  Weak support Though COM:LP states that Commons is multilingual, there is no doubt that English is the most frequently-used language on Commons. Meanwhile, language-specific Village Pumps are seriously inactive, so the main language of such discussion board should be limited to non-English language.廣九直通車 (talk) 06:13, 27 May 2020 (UTC)

I would like to clarify that, my proposal is to maintain a list of active users who can help with each language, so that users can find one fluent speaker to answer questions on demand. The proposal is NOT to replace the various VPs, regardless of their activity. For example, the Turkish request was special:permalink/421939064#Telif_Hakki. If the proposed list had been set up, the first responder could have invited a user straightaway, rather than pled for help (which could only be picked up by a Turkish user by chance) and eventually sent the user to the unhelpful, deserted Turkish VP.--Roy17 (talk) 11:51, 27 May 2020 (UTC)

Page protection

Images that are sexual content are on Commons so that why we need to put some measurement to secure it we all know we are in 21st century and research is not limited so people young than the age of 18 will have access to these. We should but many opinion on ground to solve this problem. Some people can see this has a advantage to criticize Commons and discourage other from using it. We need to act fast let put idea on table. Tbiw (talk) 02:36, 13 May 2020 (UTC)

Discussion

Ban certain custom licenses

As we've seen at Commons:Deletion requests/Template:Resolution restricted-by-sa and Commons:Village pump/Archive/2020/05#Images licenced under GFDL-1.2 and CC-BY-NC-(SA/ND), there are many problems with custom licenses, the two main ones being: 1) legal uncertainty due to not being backed by a formal legal document; and 2) incompatibility with other free licenses. I would like to call upon the community to help draft an addendum to COM:L to ban certain types of custom licenses after some date in the future, similar to Commons:Licensing#GNU Free Documentation License.

In my opinion, the ban should at the very least include {{Resolution restricted-by-sa}}, but should not be so broad as to ban {{PD-self}} (even if {{Cc-zero}} is preferred). Some potential points of contention are:

  1. What is the definition of "custom license"? The most obvious definition would be "a license whose text exists only on a wiki", but there is a loophole: uploaders who want to use a custom license could just put it on their personal website.
  2. Should we ban only ShareAlike custom licenses, or something broader? ShareAlike is particularly odious because it only works in practice if there is a large enough ecosystem of works under the same license to remix with, and that obviously doesn't exist for custom licenses.
  3. If we want to ban more than ShareAlike custom licenses, where do we draw the line? Again, we probably don't want to ban {{PD-self}}.
  4. Currently, the way we deal with custom licenses made by third parties (think big organizations/governments) is with a community review on COM:VPC to see if the license is acceptable. Assuming we want to continue accepting third-party custom licenses, how do we distinguish between those who are allowed to create custom licenses and those who aren't?

Note: There is nothing to !vote on yet. Once we come up with a formal proposal, we can proceed with a !vote. King of ♥ ♦ ♣ ♠ 00:27, 24 May 2020 (UTC)

  • Perhaps develop a whitelist of acceptable base licenses already present on the site? It doesn't have to be exhaustive to the point of spelling out individual country variants of Creative Commons, of course (i.e all those at Category:CC license tags), but it would allow us to control on a more basic level what is and isn't permitted in terms of what goes in to custom templates. — Huntster (t @ c) 04:53, 24 May 2020 (UTC)
    I think a whitelist might be too restrictive and add too much bureaucracy. We would have to maintain the whitelist and have a community-wide discussion every time we wanted to add a new license. I don't want to change the current approach, where anyone can create a tag for a (published) license they believe in good faith to comply with COM:L and someone else can raise it for discussion or nominate it for deletion if they disagree. -- King of ♥ ♦ ♣ ♠ 05:17, 24 May 2020 (UTC)
  •  Comment 1) Copyright is too much of a minefield for us to leave things like license tags up to single individuals. 2) We should focus on streamlining our content for re-users by standardizing our media's meta data as much as possible rather than catering to a bunch of individuals' egos. If you're asking me: Ban all custom license tags made up by individual users for their own stuff. Especially the ones that are just a variation of the regular CC-tags with custom colors etc. Custom licenses by third party organizations are a different matter, of course. --El Grafo (talk) 10:09, 24 May 2020 (UTC)
    I like the idea, but it can be hard to define. Where do you draw the line between: 1) a Commoner who has no other accounts; 2) a Commoner who also has a personal website; 3) someone who has a personal website but isn't really a member of the Commons community; 4) someone who operates a website that others can contribute to, but still contains mostly their own works; 5) someone who operates a popular website that lots of people contribute to? I assume we want to allow the last scenario. Case in point, after Unsplash stopped using CC-0, we stopped accepting photos from them not because it was a custom license per se, but because the terms of the license were unacceptable (i.e. the prohibition against "compil[ing] photos from Unsplash to replicate a similar or competing service"). If Unsplash switched to an acceptable custom license, then I'm sure we'd still be accepting photos from them. -- King of ♥ ♦ ♣ ♠ 17:09, 24 May 2020 (UTC)
    @King of Hearts: If it's "someone" (i.e. an individual) rather than some kind of organization, that should be a yellow flag. Definitely exclude 1) and 2), have an obligatory structured community review for everything else. I'm very much with Colin on this one. We really need to tighten up our rules and procedures if we want to be taken seriously – reliability is not what Commons is knonw for, unfortunately. --El Grafo (talk) 10:45, 3 June 2020 (UTC)
  •  Comment What about a type of procedure where every new license template has to become aproved by a couple of license reviewers and/or admins. --GPSLeo (talk) 20:47, 24 May 2020 (UTC)
  •  Comment I think that what @GPSLeo: suggest is a good idea. It is simple and can go fast. For example if we say 5 admins support and no disputes.
I do not know if we need a formal approval for licenses that is just some intro and an official license. For example: {{Cc-zero-Scot Nelson}}.
What about licenses like "User:xxx/Some-license"? They are easy for the uploader to make. But they are also easy for the user to change. That could be a risk.
The question is also how we find files that uses an "illegal" license. --MGA73 (talk) 09:43, 25 May 2020 (UTC)
  • I don't like the suggestion that a new licence type should be approved by anything less than full community scrutiny. Why on earth do we have to "go fast"? Too easy to game, and well known that some Wiki chapters (e.g. Austria) were/are dominated by GFDL-1.2 supporters who were not in the slightest interested in contributing outside of Wikipedia. The same was for Saffron Blaze with their {{Resolution restricted-by-sa}}. I don't think we should allow novel licences that are defined only on wiki. I also agree that a "share-alike" licence only works if it has cross-licence compatibility with other licences or is itself a hugely popular licence choice, and has been developed by an organisation with access to professional legal advice. I think we could come up with policy on "share-alike" that says firstly that any such licence needs community approval before acceptance, and secondly a short-list of characteristics such a licence has.
As for custom "licence" templates, I think they must always include an official template, so that the official licence cannot be tampered with. I see the use in them providing additional information about the copyright owner or how to contact them, etc, but as always, we should review them to ensure nobody tries to sneak extra restrictions into them. -- Colin (talk) 10:22, 25 May 2020 (UTC)
  • The problem I'm having is that some users identify (what they think is) a problem with a commonly used free licence (for example CC-BY-SA) and then write their own licence. These users typically don't have a legal team checking the licence, so the custom licence risks having much bigger errors than the licence that the user was trying to fix. In some cases, the licence could be seen as a lottery ticket where it is impossible to know how a court would rule if the right holder sues for copyvio. However, I can't think of a clear definition of such licences. Requiring licences to be approved by the community before their use on Commons sounds like a good idea.
Somewhat related to this are the big boilerplate templates which some users put on file information pages, such as User:Ralf Roletschek/Autor4. This template could be seen as a disclaimer. Many GNU and CC licences require you to include certain types of disclaimers with all copies of the work. For example, according to CC-BY-SA 3.0: You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. We rejected GFDL because the requirement to include a copy of the licence with every copy of a file is too restrictive, and then it's bad if people can circumvent this by providing a huge disclaimer of warranties which all reusers have to include a copy of. It is my understanding that a disclaimer has to be quoted verbatim (keep intact). In other words, it can't be translated, and if the licensor provides the disclaimer in multiple languages (in this case English and German), you may have to provide a copy of all language versions of the text. I think that we need to restrict the use of disclaimers. --Stefan2 (talk) 11:23, 25 May 2020 (UTC)
  • I think some of my concerns with custom licences have been voiced by others above. I have no problems with very very basic licences such as {{PD-self}}, {{Copyrighted free use}} and {{Attribution}}. But the ShareAlike ones are the ones I have huge problems with as some of them are contrary maybe not to the letter of policy, but definitely to the spirit of this project. And the flaws in the language of these tags are also problematic, as Stefan2 mentions above. I would in favour of a ban on custom ShareAlike tags / licences, and ones that are clearly more restrictive than CC-BY-SA-4.0. I would also be in favour of community involvement and approval for any custom licences--custom CC tags, namely the OTRS created tags that are a CC licence summary + OTRS permission should be exempted. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 19:27, 25 May 2020 (UTC)
  • I agree with User:El Grafo about banning all custom licenses in the future, where custom license is defined as some license written by individual user or group of users for their works. Customized clarification of existing license, like CC license + OTRS template or CC license + attribution text is OK, but elaborate custom templates with additional explanations or translations are not. No additional restrictions on top of base license, for example CC-by for noncommercial works and contact me for commercial permission (Thar is not allowed already but I am not sure if it is spelled out anywhere). I would go as far as having different set of available licenses for "own works" (uploaded directly to commons or indirectly through flickr or some other website). I would vote for phasing out {{PD-self}} in favor of {{CC-zero}}; {{Attribution}} in favor of CC-BY licenses, and no {{Copyrighted free use}} for own works. So for Own works first published after some data we would have a whitelist of few dozen licenses. Transfer of older files from wikipedia or flickr would be OK under the old rules. --Jarekt (talk) 02:35, 26 May 2020 (UTC)
  • I generally do not like the idea of outright banning free licenses. Our project scope and mandate is to allow files which are free by the definition at freedomdefined.org . That does include custom licenses. It is very common for sites out there (say government sites) to have a rights statement that is effectively a free license -- I feel this will be used as an excuse to delete such works. I do agree that any custom license tag should go through a community review before being allowed, and I do agree that Commons users coming up with their own licenses is also often problematic, so there should be some sort of review process for them. But an outright ban I think is contrary to the project scope, which is deeper than just policy. The GFDL was on the edge I thought, as those are technically free but people were using the terms against the spirit of free licenses. Banning anything further I disagree with; it feels like we are now going down the slippery slope to only allowing CC licenses for administrative sake, rather than serving the user base. However, there should be a way to point to a community discussion on a license, and to mark any license tag (perhaps using the 10 person criteria mentioned below), with possible deletion pending the outcome. Maybe even just a special type of DR with an additional notice being posted to Village Pump/Copyright. Carl Lindberg (talk) 14:31, 9 June 2020 (UTC)

Draft

Here's my first attempt to codify it:

Custom licenses are licenses created by Wikimedia users for their own works. Because they have not undergone strict scrutiny and legal review, they present a risk to reusers and hence are considered deprecated. No work may be uploaded to Wikimedia Commons on or after 1 July 2020 under a license whose text exists only on a wiki or other user-editable site, unless the license is used on works by at least 10 unique authors as of 30 June 2020. (The purpose of the latter provision is to grandfather in long-standing license templates such as {{PD-self}}, which continue to be permitted despite the existence of more favored licenses such as {{Cc-zero}}.)

Thoughts? -- King of ♥ ♦ ♣ ♠ 16:59, 7 June 2020 (UTC)

Maybe add something like "exceptions can be made with community consensus" to prevent later discussions on changes for adding of more templates like the PD-self example? --GPSLeo (talk) 22:52, 7 June 2020 (UTC)
Another gray area is credit tags vs actual licenses. A note stating that they are only licensing the uploaded resolution, i.e. they do not intend to license expression at a higher resolution if the photo is found elsewhere, is fine -- that is not a license, but rather simply identifying the expression being licensed. A *request* to be contacted etc. is also fine. It's when the wording gets into restrictions on what the user can do, that it can be a problem. Such credit-type tags can also start out fine, then be edited into the more dubious areas, as well. Carl Lindberg (talk) 14:38, 9 June 2020 (UTC)
I disagree that such a resolution-restriction note is not a problem. If using a licence like CC the licence applies to "the work of copyright" and it is up to legal experts to determine if another copy of the file at a different resolution is "the same work". CC forbids users from adding further restrictions to their licences. CC is not a file-based licence, and CC and WMF have already clarified this. -- Colin (talk) 10:09, 10 June 2020 (UTC)

Draft 2

I took into account GPSLeo's suggestion, and added custom restrictions to the mix per Clindberg and Commons:Village pump/Copyright#Licences restricted to a certain resolution, but higher resolution uploaded. I also tweaked the wiki part because not all wikis are user-editable, and such licenses are permitted (e.g. wmf:Wikimedia 3D file patent license).

Custom licenses are licenses created by Wikimedia users for their own works. Because they have not undergone strict scrutiny and legal review, they present a risk to reusers and hence are considered deprecated. No work may be uploaded to Wikimedia Commons on or after 1 July 2020 solely under a license whose text exists only on Wikimedia Commons or other user-editable site, unless the license is used on works by at least 10 unique authors as of 30 June 2020. (The purpose of the latter provision is to grandfather in long-standing license templates such as {{PD-self}}, which continue to be permitted despite the existence of more favored licenses such as {{Cc-zero}}.) Furthermore, uploaders may not impose additional mandatory terms or restrictions upon otherwise permissible licenses, unless the license explicitly allows such terms to be imposed (such as specifying the manner of attribution for a CC-BY license). Exceptions to allow or disallow specific licenses can be made with community consensus.

@Mattbuck, Ww2censor, Fæ, and Jarekt: Pinging users at the other discussion. -- King of ♥ ♦ ♣ ♠ 18:22, 9 June 2020 (UTC)

  • This sounds good. I wonder if we could also allow removal of any custom license "clarifications" even if it not contradicting the license. I find them confusing as each should be studied to verify that they do not contradict the license. Also should we do anything about double licensing like {{FAL}} (which few people understand) and CC-BY-NC (which is easier to understand). I would like to no longer see any double-licenses with CC-BY-NC or CC-BY-ND. --Jarekt (talk) 18:57, 9 June 2020 (UTC)
    I think both those points are tangential to the discussion here, which is to ban a certain type of license from qualifying a file as appropriately licensed; your points are both cosmetic details which affect only the file description page, not the copyright status of the file. If those "clarifications" are non-material, then other users can remove them without permission of the copyright holder. Likewise, if we don't even want to display non-permitted licenses at all, then we can just edit them out, leaving only the permitted one (by the way I am not in favor of this). But neither of those affects the conditions under which we accept a file as appropriately licensed. -- King of ♥ ♦ ♣ ♠ 19:03, 9 June 2020 (UTC)
  • I'm not that keen on either draft. What's a "user-editable site"? I can create a website for $10 and publish a licence definition. Have we established if custom non-SA licences are a problem we need to solve? Which ones would we not permit now? I think the case is strong for banning ShareAlike licences that are not legally compatible with existing major SA licences (CC compatibility) or have not themselves already achieved a high degree of acceptance worldwide. A licence that says "You can reuse this but only if your JPG is no larger than an unspecified JPG on a website that is user-editable by anyone at any time" is not "free". Can we have a draft that just bans novel ShareAlike licences without community review.
We don't need to ban extra terms on licences: they are already banned by the licences. I think "Exceptions to allow or disallow specific licenses can be made with community consensus." is not necessary or useful or accurate. For example, we are not permitted, as a community, to just decide to accept NC licences or to start accepting Fair Use material. -- Colin (talk) 10:24, 10 June 2020 (UTC)
  • The premise seems reasonable to me. Some clarification may be in order, but generally a good idea. -mattbuck (Talk) 11:25, 10 June 2020 (UTC)
  • The term “custom” bothers me somehow. Perhaps we should define a “custom” licence as any licence not covered by a licence template. That seems to correspond to the normal meaning of the word “custom”; it also seems to be the best way to address the first major problem listed at the very top of this section (legal uncertainty). Brianjd (talk) 11:37, 10 June 2020 (UTC)

Draft 3

Colin had some good points. Unfortunately, perhaps "custom" is just too hard to define. However, when share-alike restrictions are involved we can afford to be more aggressive. Even if a share-alike license is published by an official organization and used by a few people (e.g. {{DSL}}), it's still pretty useless for new works. Let me propose a less ambitious version (much of it adapted from the GFDL ban):

Copyleft, or share-alike, is a feature which requires persons who wish to make a modified version of a work to release their modifications under a compatible free license. However, copyleft provisions work effectively in practice only if there is a large ecosystem of compatibly licensed content with which a work can be remixed. However, a work with share-alike restrictions is free in practice only if there is a large ecosystem of compatibly licensed content with which it can be remixed. Therefore, a share-alike license is not permitted as the only acceptable license where all of the following are true:

  1. The content was licensed on or after 1 July 2020. The licensing date is considered, not the creation or upload date.
  2. The license is not compatible with any version of a Creative Commons license or any version of the Free Art License.
  3. The content is primarily a photograph, painting, drawing, audio or video.
  4. The content is not a derivative work of copyleft software.

I think the "community review" part (re Colin) doesn't need to be included, as any community review that blesses a copyleft license would simply allow point 2 to be amended. -- King of ♥ ♦ ♣ ♠ 01:47, 23 June 2020 (UTC)

  • I propose two slight tweaks to the wording:
    1. “not permitted as the only acceptable license” seems to leave a loophole, where two licences, both of which meet the criteria above, are applied to a work, without any other licences being applied. The proposal should be reworded somehow to fix this.
    2. The word “acceptable” does not seem right. Note my use of the word “apply” in the previous item.
Regarding the proposal as a whole, I have a couple of comments:
  1. I hate copyleft, basically for the same reasons you cited in your proposal. So anything that restricts the use of copyleft licences is probably a good thing.
  2. Regarding the licensing date vs creation/upload date, I guess that makes sense for files already on Commons before 1 July 2020, but what about files licensed before 1 July 2020 and uploaded to Commons on or after 1 July 2020? I think those should be banned too, if they meet the other criteria.
Brianjd (talk) 04:59, 23 June 2020 (UTC)
I lifted the wording for both straight from Commons:Licensing#GNU Free Documentation License. I don't see a loophole, because both of them would be unacceptable licenses. The existing GFDL rule clearly implies that, for example, you can't dual-license your works under only GFDL + CC-BY-NC. (Getting on a philosophical tangent) I strongly support copyleft when applied to software, because with software there is a significant risk that a private company could make an improved proprietary version of free software that cannibalizes the original. Likewise, copyleft on Wikipedia text ensures that no one can fork it to make their own proprietary version. Unlike the previous two cases, media is by nature far less collaborative so it's not as necessary, but when CC has a 90%+ market share it doesn't really matter too much so I'm fairly neutral on CC-BY vs CC-BY-SA for images. -- King of ♥ ♦ ♣ ♠ 06:44, 23 June 2020 (UTC)
This sounds good to me, in general and I would be OK with small wording improvements if anybody finds better or clearer way of expressing the same concept. --Jarekt (talk) 03:36, 28 June 2020 (UTC)
I just noticed that the wording of the second sentence wasn't ideal (implying that the share-alike restriction isn't effective, when we really want to say is that the share-alike makes the work effectively non-free). I've made a slight tweak to that effect. As this is merely expository material there is no change to the meat of the proposal. -- King of ♥ ♦ ♣ ♠ 04:22, 28 June 2020 (UTC)
  • Thanks @King of Hearts: for the ping. I totally agree that we should avoid licenses that makes it hard to reuse files. But Commons is where all free files from wiki projects should be uploaded so I agree with Brianjd that the upload date should perhaps be changed to a license date. Otherwise we risk that files on xx.wikipedia can't be moved to Commons.
Speaking of wiki projects I think that we should make a general notice to all wikipedias about the change of licenses. Many wikipedias do not have users that know or care much about copyright. So a general notice with a suggestion that the wiki do not accept files with the bad licenses from now on and with a link to a page explaining the problem. I'm not sure every wiki knows that GFDL has been banned. Anyone here know how to make such a global letter?
If wikis should have a chance to comment and not just get a notice about it perhaps the date should be August instead. --MGA73 (talk) 08:19, 28 June 2020 (UTC)
Actually, "the upload date should perhaps be changed to a license date" - you are agreeing with my original wording, and disagreeing with Brianjd. Almost no one uses share-alike licenses apart from CC/FAL (and even FAL is a small minority), so I don't think the specific cutoff date / notification matters too much because in practice it only affects a few contributors who intentionally use a weird license like {{Resolution restricted-by-sa}} at the moment. Remember that there are even some people (a significant minority) who are arguing we should retroactively delete files already under that license. -- King of ♥ ♦ ♣ ♠ 16:32, 28 June 2020 (UTC)
Huh? Okay I may have read something wrong. So just to be a little more clear:
GFDL is an example of a bad license but starting a mass deletion af GFDL files would be too much I think. If anyone have used a valid license I think the situation is the same. That is why I think we should give wikis a chance to stop using whatever licenses they use. But I also think we should advice them to stop using any non-standard licenses.
But what I would agree to delete is files if the license was never really valid. The discussions started with {{Resolution restricted-by-sa}} that have terms that are unclear. I might vote keep on those files but if we have any licenses that are worse then I would probably vote delete to the files.
As for the suggested text it looks fine to me (I'm not a native English speaker). However if we want to limit the use and make it easier to check we could say the file should be uploaded to any wiki project before <some date>.
Question: File A is uploaded to Commons with a soon to be bad license. Then I use file A and make some changes and upload it as file B with the same bad license. Would that be acceptable or not with the suggested ban? --MGA73 (talk) 22:26, 28 June 2020 (UTC)
We wouldn't require wikis to stop uses any existing media under a soon to be bad license; any media available under such licenses before 1 July 2020 are grandfathered in, and it would not be a violation of this proposed policy to use existing images (i.e. add them to articles) after the cutoff date. All that changes is that you can no longer upload new photos under such licenses. In practice this is a very rare phenomenon, done only by people who have a political objection to our standard licenses, and they are probably aware of this conversation so it won't be a big surprise to them. People at other Wikimedia projects are not going to come across these licenses randomly; they are not mentioned at any of the common places to find licenses (COM:L, Special:Upload, Special:UploadWizard, etc.). If this proposal passes we can go down Category:License tags and tag any unacceptable ones to warn potential uploaders.
I prefer "license date" over "date uploaded to a Wikimedia project". There could be some 1990s files under a weird license that we'll probably want to accept.
For your question, good point. The GFDL ban didn't actually specify either, but I think common sense dictates that we accept such files. Incompatible share-alike works can only be relicensed under the same license, so to include modified versions of grandfathered bad share-alike files in the ban would have the effect of turning the SA provision into an ND provision, which is definitely a step in the wrong direction. -- King of ♥ ♦ ♣ ♠ 23:14, 28 June 2020 (UTC)
  • Though this is my first comment on this proposal, I have been following a bit on this discussion. This draft in general looks okay to me, and a lot better than the first two drafts which suffer from the problem of defining "custom". I would suggest simplifying the photograph, painting, drawing of the third criteria into "static image", then add "animation" to the said criteria to avoid any ambiguity. My suggestion would make it simpler to look at, while still being unambiguous. --pandakekok9 02:06, 29 June 2020 (UTC)
    The reason why we had that line for GFDL is that the GFDL is designed for text documents, and so we continue to accept it in such cases. Note that the GFDL actually falls under our proposed definition of "unusual share-alike license", so we don't want to ban any uses of GFDL which are not already covered by the GFDL ban. It's possible for a text document to consist of a static image. -- King of ♥ ♦ ♣ ♠ 02:46, 29 June 2020 (UTC)
    Yes, it's possible for a text document to consist of a static image, but it doesn't necessarily mean it's primarily a static image (i.e. a PDF file containing only one page where a majority of the content is a static image, or a PDF consisting only of slides, without or almost without any text). I think my suggestion actually closed a loophole (kinda), since "static image" includes screenshots. Someone who didn't like the GFDL-only ban could publish their GFDL photographs on another website, make a collage of it, and screenshot it. They would then upload the screenshot to Commons with the GFDL as the only license. If someone nominates their upload for deletion, they would just argue that their file is not a photograph, painting, or drawing, but a screenshot of a collage of GFDL photos. Of course they violated the spirit of the policy, but I think technically they would be correct. pandakekok9 02:41, 30 June 2020 (UTC)
    We don't need to account for every possible loophole. This is a policy issue, not a legal issue, so at DR the argument "goes against the spirit of COM:L" is very much valid. In your specific case, it's either just a collage (so they can't argue it's a screenshot even if that's how it was made), or it's a screenshot and does not fall within COM:SCOPE, and the action required to bring the image in scope (namely, cropping it) would cause it to fall under the ban. -- King of ♥ ♦ ♣ ♠ 02:55, 30 June 2020 (UTC)
  •  Comment The problem with this proposal is that different people seem to be talking about slightly different things: The first group wants to make sure that we have a library of freely licenced media and want to ensure that the media that we have is distributed under a free licence; The second group want to make sure that we will not have a library of non-freely licence media and want to ensure that the media is not distributed under a non-free licence. The problem is that sometimes it is difficult to figure out the impact of the policy in regard to these two positions, especially since sometimes they actually oppose one another. I am considering adding an extra NC licence on all of my files in case there is a project out there that is already distributed under a NC licence and they cannot incorporate FAL into it. Of course, if somebody were to beging a new project, I would urge them to chose FAL or in the worst case CC-BY-SA / GFDL, but what if the project has already been ongoing. I am a copyright holder, and I can distribute my work under as many different licences as I want, and they are allowed to be contradictory, a reuser may chose which licence to use. Also I find it completely baffling why we have such anger towards Share-Alike licences here; some people want to take something without contributing, and we have supporting them, but people who want to contribute are made to jump through hoops. Let people contribute under whatever Free Licence they want, and make tools for reusers to find a work that fits with their project. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 08:00, 2 July 2020 (UTC)
    @Gone Postal: We are not banning uncommon share-alike licenses entirely, or even non-commercial licenses for that matter. You can even put a license saying "You may use this image freely if you belong to the Church of Scientology" if you want. The point is that to be considered truly free, an image must be under at least one acceptable license. Everything else is just icing on the cake. -- King of ♥ ♦ ♣ ♠ 15:17, 2 July 2020 (UTC)
    And there is no such thing as "a library of non-freely licence media". All media by default is "all rights reserved", so even if uploaders don't put an NC or GFDL license on it, all CC media is already multi-licensed under the CC as well as "all rights reserved". -- King of ♥ ♦ ♣ ♠ 15:20, 2 July 2020 (UTC)
    Thanks for pointing out another problem with this discussion, there is a huge confusion about the legal status of works. "All rights reserved" is an old phrase that was used some time in the 20th century, when in some countries to protect one's copyright you had to put such a phrase on your work. It said nothing about the licence. Today there is no such thing (all rights are reserved as soon as you put your work in a tangible medium), but if there were, you would have to put "All rights reserved" in order to distribute your work under CC-BY or GFDL or whatever. Creative Commons attempt to make a play on words, sometimes using "Some rights reserved", but that is not a legal instrument either. In other words you cannot multi-licence as "all rights reserved", just as "I am a sovereign citizen" is not a driving licence. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:17, 3 July 2020 (UTC)
    And I think that my comment is probably unclear. While two first drafts are just trying to find a problem to solve, the third one is disruptive. Not only is it bad, but the opposite of it would be better, something like No user should be allowed to pressure another contributor to change their preferred free licence. Any user who engages in such behaviour should be brough to administrator's attention for a ban. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 13:26, 3 July 2020 (UTC)
    Just to clarify: Do you believe that {{Resolution restricted-by-sa}} (the license that started this whole discussion) should be banned going forward? Why or why not? -- King of ♥ ♦ ♣ ♠ 15:53, 3 July 2020 (UTC)
    I am a bit split on that. Legally, (although I will accept me being wrong if given an authoritative source) I believe that it is likely that the court would decide that different resolutions of the same image are not different works, and thus distributing one work under a stated licence places all of that work under that licence. However, at the same time I can see a way that an organisation that keeps all of its media private and proprietary may be approached with the proposal to make their images/videos available under a smaller resolution under a free licence. I see benefits of both approaches for our project, but would want to have an authoritative statement from a lawyer that practices internationally if the first one is chosen. Emotionally I lean towards giving the creator maximum freedom to release their work under whatever licence, and hoping that they make a right choice rather than trying to trick them. One thing that I would be definitely opposed to, is "burning the bridge" in the form of approaching a creator asking to release a small thumbnail under a free licence, and then uploading a large image/video with the text that it's the same work and the licence is not revokable. Also if the small version is released, it should be OK under the licence to increase the resolution by editing the image/video or by mixing it with other free media, so a licence that would state "No derivative work above WxY resolution" should not be allowed, as that is not a free licence (in my opinion this is not what the licence you linked states). I know that I didn't answer Yes/No, but I hope that an honest answer is what you were looking for. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 04:13, 8 July 2020 (UTC)
    I'm afraid you're in the minority here; almost everyone else unequivocally believes that that particular license should be banned going forward, though their reasoning may differ. (I approach it from more of a free culture angle, while others believe the license is simply legally invalid.) -- King of ♥ ♦ ♣ ♠ 19:48, 11 July 2020 (UTC)

Proposal: avoid excessive use of gender in diffusing categories

Proposal:

Subcategories based on gender should be permitted for a profession if and only if one of the following applies:
  1. physical appearance is important to that profession (e.g. acting, modeling)
  2. gender is highly relevant to that profession for some other reason (e.g. vocalists; athletes in most competitive sports).

Besides professions, this should apply also to categories about affiliation with an institution or organization (e.g. members of the faculty of a particular college or university; alumni of a particular college or university; people associated with a particular newspaper or magazine) or receiving a particular award (e.g. Nobel laureates).

To be clear: categories about gender as such are fine (we certainly want to keep Category:Men by name and Category:Women by name); the issue is about intersecting and diffusing categories. And, as with any other category about people, categories about gender may be difffused by nationality and even subregional classification (e.g. U.S. states) is fine: e.g. there is no problem with Category:Women of the United Kingdom or Category:Men of Washington (state) .

Jmabel ! talk 01:12, 15 May 2020 (UTC)

Votes (gender categories)

Take Category:Female writers for example.
Does gender matter for writing as a profession? Maybe not. However, commons dont only serve commons but all wikis. Many wikis distinguish writers by gender: Category:Women writers (Q7944338). Their users might find it odd that the corresponding cat does not exist on commons. Deleting these cats might create unnecessary hurdles for both the categorising effort and finding media for use.--Roy17 (talk) 13:54, 15 May 2020 (UTC)
@Roy17: Do you have a different, perhaps looser, guideline to propose, or do you think that because of that example there should be no rule at all on this? - Jmabel ! talk 14:33, 15 May 2020 (UTC)
Writer is a very general topic and it encapsulates the problem of this proposal. lawyers, politicians, physicians, photographers... are some other common professions that come to mind. this proposal is gonna get rid of all of their subcats. then ppl are gonna ask, why some jobs are listed in Category:Women_by_occupation (or the men cat) while these most common ones are not?--Roy17 (talk) 14:45, 15 May 2020 (UTC)
  •  Strong oppose Without refining the categories to some extent you have a general pool that is too broad to be of any use. Your proposal to refine them by nationality is not based upon historical reality. 1) Nationality is a fairly recent development in the scheme of history. Prior to the development of national borders, people identified with their community and ethnic culture; 2) Women, did not have nationality in their own right in the majority of countries in the world until the 20th century (in France 1927, the US 1922-1940, in Canada 1940, in Britain (and most of their colonies) until 1948, etc.) In many instances, they became stateless if they divorced a foreign spouse, i.e. Maymie de Mena or even if their nationality was settled were still required to take on the residency of their spouse in various US states, see Patsy Mink, into the 1960s. In some countries women still do not have their own nationality; 3) Nationality has often changed by the whim of war or treaties, redrawing boundaries on a map with no relationship to the culture to which people identify. Communities, even movements, fought long hard battles to be recognized legally for their identifying ethnicity, gender, beliefs to be validated and protected by law by numerous "nations". Simply categorizing people by national boundaries diminishes the complexities of their existence and removes the context of their history; it also can reclassify people into a category to which they never identified except on paper. It impacts readers/searchers as well, by making it far more difficult to find the subjects they might be interested in reading about or adding a photograph to, as it has broadened the grouping so that it has become irrelevant. This and the one below are both IMO bad ideas. SusunW (talk) 17:31, 15 May 2020 (UTC)
  •  Support While IMHO Commons usually should support category-equivalents for wikipedia articles (and "wikidata content items"), with regard to categories I do not think is strictly necessary to provide the equivalent here. If somewhere "a" wikipedia does an inconvenient categorization, Commons should not be required to replicate the same schema here. IMO occupation+nationality (meaning 'citizenship') should be generally avoided too (except maybe for sportspeople and the like) (using a broader notion of "significant country/region/place wrt that occupation wrt that person" instead), but that's not being discussed here. Commons categories are not intended to provide reading stuff. Women by occupation and Men by occupation categories might be deleted if they are a problem, hanging "female actors" and "male actors" only from "Actors" instead. Strakhov (talk) 18:31, 15 May 2020 (UTC)
Is not only about sport. In Italian Wikipedia we struggle for the categories splitted by gender from a while, as they, apart from a few exceptions, are not allowed. And every time we organize our events based on female professions, our mostly used "base" for articles to write / translate are the Commons categories (as Wikidata queries are not yet "accessible" for a lot of users). So, no, apart from the identity and women's recognition and equality reasons expressed by others, there is also a practical issue. For us would be a big problem. --Camelia (talk) 21:41, 16 May 2020 (UTC)
Wikidata & Listeriabot do a great job creating lists. IMHO keeping gendered categories in Commons in order to have articles to write in it.wikipedia... doesn't make much sense. Wikidata works much better for that. And it's pretty easy creating those lists. Strakhov (talk) 03:05, 17 May 2020 (UTC)
  •  Oppose and — Strong oppose because a "hell no, are you out of your mind?" option isn't available. A broad general guideline is problematic for any number of reasons, and the one proposed above is absolutely horrible. Nationality per SusunW is a problem for all the reasons she lists, and "relevant in the profession" is nothing but ghettoization (pigeonholing people in only certain occupations opens another can of worms over whether "gender is highly relevant" in a category). This needs to be done on a case by case basis. Montanabw (talk) 19:47, 15 May 2020 (UTC)
    "Highly relevant to that profession" - as a subjective criterion, that means deciding on a case by case basis. What alternate criteria do you propose for guiding the "case by case" decision on whether to diffuse by gender? -- King of ♥ ♦ ♣ ♠ 20:18, 15 May 2020 (UTC)
    ”Case by case basis” is the default for all wiki discussions so doesn’t need special rules. The problem is your suggested limitations, which in practice become policy and getting exceptions is more drama-inducing than just leaving it well enough alone: I mean, are you serious that the criteria for diffusion should be “physical appearance is important to that profession (e.g. acting, modeling)“ and “gender is highly relevant to that profession” —two most unbelievably sexist criteria imaginable? You have got to be kidding! Montanabw (talk) 00:46, 16 May 2020 (UTC)
    Given that you've said "case by case basis", that implies that you do not believe that all professions should be diffused by gender. Can you give some examples of such professions, and why you would not diffuse them by gender? -- King of ♥ ♦ ♣ ♠ 04:10, 16 May 2020 (UTC)
    @Montanabw: You can try {{subst:User:Tuvalkin/Template:No way!}}… -- Tuválkin ✉ ✇ 01:00, 16 May 2020 (UTC)
  •  Strong oppose as per the many reasons given above. As someone who uses the Wikipedia categories regularly when creating off wiki discussions about women in various roles in life it would seriously limit my ability to work. When it is no longer necessary to talk about women's involvement in an area of life because equality has become so ingrained that it is a meaningless topic, then, and only then, should this topic be discussed again.Antiqueight (talk) 20:29, 15 May 2020 (UTC)
  •  Strong oppose per the solid reasons already mentioned. --Rosiestep (talk) 23:10, 15 May 2020 (UTC)
  •  Strong oppose I've been working on List of African-American women in medicine and it's already hard enough finding good photos for article like these. I can't imagine how much worse it would be if I had to sort through all of the images of doctors/nurses/midwives/PAs just to find what I need for these kinds of articles. There's no stigma is separating categories by gender, race or any other valid criteria. Leave things as they are. As a librarian, I would like to mention that even cataloging conventions for libraries have categories for gender, race, etc. It's professional and necessary. Megalibrarygirl (talk) 00:17, 16 May 2020 (UTC)
  • I  oppose, too. E.g.: When I created Category:Female tram drivers, and pretty much every time I add one more file to it, I wonder how useful / empowering / clarifying it is, versus how objectifying / segregating / exotifying it may also be felt. My goal was/is to illustrate a detail aspect of reality, as with any other category, but also to very clearly exemplify how women not only could, but actually can — do a “man’s job”. I am glad to add my vote to that of a few fellow female editors above. -- Tuválkin ✉ ✇ 00:41, 16 May 2020 (UTC)
  •  Oppose I had read the previous discussion, and I'd say this proposal has good intentions (especially the LGBT part). However, I agree with the opposers above. Such problem can't be solved by a very broad proposal. It should be dealt with in a case-by-case basis via CfD. If only CfDs are more active and closed more often... --pandakekok9 01:54, 16 May 2020 (UTC)
  •  Oppose for the reasons already given above, as they've stated things better than I ever could. I especially echo Antiqueight statement on equality. — Huntster (t @ c) 07:11, 16 May 2020 (UTC)
  •  Support soft  Oppose These diffusing categories are messy and generally unnecessary, this move is needed. Having taken a beat, I think this move could be made for some categorisations, but as a swift and unilateral move like this it might be too clumsy and cause too much unintended consequences that would swamp any perceived benefits. Smirkybec (talk) 10:14, 18 May 2020 (UTC)
  •  Oppose, strongly. This isn't about branding people, rather about search instruments. The proposal will remove a search instrument which, I am sure, is important to the reusers of content. People who come here for "stock photos" are looking for red brick buildings, yellow brick roads, and women operating pneumatic hammers. That's normal, especially given today's emphasis on "equal representation" of sexes in the media. Why discourage these specific searches by hiding Rosie the Riveter among many men? Retired electrician (talk) 10:54, 18 May 2020 (UTC)
    I guess the thing is, it is useful to have separate categories for men and women at work. What is not useful IMO is classifying portraits of people, who happen to be of an occupation but not actually depicting them engaging in that occupation, separately by male and female. -- King of ♥ ♦ ♣ ♠ 17:14, 18 May 2020 (UTC)
    @King of Hearts: That's precisely the kind of reasoning that I oppose. Reusers of free content don't seek "any" portraits, they have specific demands, they have already "painted the portrait" of what they need. They look for, say, bearded men wearing high hats or curvy blondes wearing ... where was I... never mind. The point is, sex - being probably the most important facet of human appearance, - is a valid and needed search criteria. Unconditionally, regardless of "depicting them engaging" or not. Retired electrician (talk) 11:37, 22 May 2020 (UTC)
  •  Support - Dividing most people-related categories by male, female, non-binary, etc. is pointless and arbitrary. We don't do this for race or age or hair color, so why do we do it for gender? Kaldari (talk) 04:00, 21 May 2020 (UTC)
  •  Strong oppose I think there is half men and half women (50%:50% ratio) in the world. (Maybe my vote is late but please keep it and cross over with note that it is non-valid if it is by progress of this discussion...) --Obsuser (talk) 18:11, 13 July 2020 (UTC)

Comments

As proposer, I would be open to extending this to race and ethnicity as well as gender, but I think that case is less clearcut, and I'd like to see first if we have consensus about gender, leaving race and ethnicity to a separate discussion. Conversely, I think it is fine to diffuse categories by nationality and even subregional classification (e.g. U.S. states), as long as we understand that the same person may qualify for inclusion in more than one nationality, etc.

Motivation:

  • Categories keep being split and diffused by gender where gender has nothing to do with the matter. Diffusion by gender is not like diffusion by nationality, where we might usefully break up a big category into dozens of smaller categories: for gender, at least one of the resulting categories will always be at least half as large as the parent category. What possible purpose does it serve to split bass players, or non-fiction writers from the United States, or jazz composers by gender? How is this any more valuable than splitting categories by, say, height or hair-color?
  • Diffusing by gender often has the effect of "ghettoizing" the women in a mostly male profession.
  • What on earth are we then supposed to do with transgender or non-binary people in this respect?

How to put this in practice if adopted:

If adopted this would ultimately result in merging quite a few pairs of existing categories. We would not be able to do this all at once. However, I believe the direction to head would be clear:
  1. Stop creating additional categories that violate this policy.
  2. Categories where there is reasonable doubt as to whether diffusion by gender is appropriate will each merit a CFD discussion.
  3. For categories that clearly violate this policy, or for those where a CFD discussion results in a decision that this diffusion is inappropriate, the category can be turned into a {{Cat redirect}} to the appropriate ungendered parent category, and the usual bots that operate on that template will recategorize any files and subcategories appropriately. (Obviously, if anyone wants to move subcategories and files by hand, they would be welcome to do so; I'm just pointing out that in general no one will have to do that.)

(Thanks to the several people who commented at Commons:Village pump#Overuse of gender in categories, especially User:King of Hearts whose wording in that discussion I have drawn on heavily.)

Jmabel ! talk 01:12, 15 May 2020 (UTC)

Comment: I thought it was long settled that where categories listing gender exist, they are either to be fully diffused (no "generic" category and both a men and a women's category instead) or fully non-diffused AND if subcats are needed, then there are BOTH men's and women's subcats. I strongly oppose "ghettoizing" anyone by race, gender, nationality, ethnicity, and so on; i.e. there should not be a "general" category and then just a "female" category. However, there is probably a discussion to be had about how to categorize people who are non-binary in fully diffusing categories. I also think it is often not necessary to sex-segregate small categories ("Category:Professional underwater basket weavers of 1970", for instance). Overall, the creation of gendered categories should be handled on a case by case basis. Montanabw (talk) 19:54, 15 May 2020 (UTC)

Is it safe to assume this proposal is rejected and can be closed now?

IMO this proposal fails simply because it's based on the assumption that for example female drivers is created by dividing drivers into male and female, but actually it could also be women divided by jobs of which driver is one.--Roy17 (talk) 01:26, 27 May 2020 (UTC)

  • @Roy17: I find your wording to be very confusing. A clearer wording would be: This proposal fails because it assumes that, for example, “female drivers” is a subset of “drivers” defined by gender, when it might actually be a subset of “female people” defined by occupation.
I am only here to comment on the wording. Whether this is an accurate summary of the discussion, I will leave to others. Brianjd (talk) 11:19, 10 June 2020 (UTC)
  •  Comment I think that we can all agree that any "excessive" use should be avoided. The problem is to define what is excessive and what is not. If we have a category named "Women" and a category named "Writers" we could discuss if we need "Women writers" because it is possible to create that by intersecting the other two categories. But the same apply for any other categories. As long as we do not make so many categories that we will only have very few files in each category I think it is okay (I hate categories with only 1 or 2 files).
I see a bigger problem in the gender categories itself because some day someone will start arguing that gender is not relevant and question how do we define genders etc. --MGA73 (talk) 22:12, 20 June 2020 (UTC)

Rename COM:ANU

I propose to rename Commons:Administrators' noticeboard/User problems to Commons:Administrators' noticeboard/Problem users because the former is ambiguous: a) problems which normal users (but not admins) have because of the level of access; b) problems related to interaction of users.

User:King of Hearts tried to solve the issue with creating an edit notice (Template:Editnotices/Page/Commons:Administrators' noticeboard/User problems) but the problem seems to persist according to Special:Permalink/421492592#Sandbox got deleted (see the comment by User talk:Pandakekok9). 4nn1l2 (talk) 03:54, 25 May 2020 (UTC)

Yeah, the same here. Though I am near-native in speaking and reading English, when I look at "incidents" without enwiki lens, I don't expect it to be a venue to complain about other users. pandakekok9 04:12, 25 May 2020 (UTC)
Er, isn't COM:AN/U supposed to be a place only for disputes with other users? From {{Administrators' noticeboard}}: Report disputes with users that require administrator assistance. Further steps are listed at resolve disputes. The reason why this proposal was made is because we are receiving threads that are out of the scope of COM:AN/U. User naming can be reported to COM:AN/B, per COM:IU: Usernames that are obviously inappropriate may be blocked on sight by any administrator and may be reported at Commons:Administrators' noticeboard/Blocks and protections. I'm not sure what you mean by "language issues" though. pandakekok9 02:27, 26 May 2020 (UTC)
No, the text reads "You can report vandalism, problematic users, or anything else that needs an administrator's intervention." So the noticeboard is a place you can go to with any account problems, potentially with no history of disputes. This can include questions about things like adding archiving to a retired user's template breaking talk page, or a user might ask things about their own account like whether their signature text is allowed, or to remove/amend some of their user groups outside of the right application pages which normally only add these groups. Language issues was meant to include confusion about what words in different languages mean and whether this is worth taking further, like whether a user doing mass renaming is doing something against policy or not; again this need not have a history of dispute. --Fæ (talk) 10:08, 27 May 2020 (UTC)
It seems clear to me that the text quoted by @Fæ applies to AN as a whole, while AN/U has a more limited scope. However:
  • It might not be so clear to someone for whom English is not their native language.
  • The notice is confusing overall, as covered by some of the comments below.
Brianjd (talk) 11:44, 10 June 2020 (UTC)
Because there are "content disputes", which should be dealt with at the affected file/page's talk, and for those that need wider community discussion: COM:VP, COM:VPP, or COM:RFC. pandakekok9 10:52, 19 June 2020 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2020/05&oldid=440469211"