This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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.
Why do we need to nominate a FI which is work of a user for QI, when the quality of FI is better than QI ? Why not mark then them QI automatically ? -- EATCHA (talk) 05:37, 11 April 2019 (UTC)
I quickly poked at that list, and the first images I looked at weren't the product of Commons users. Quality images must be the product of Commons users.--Prosfilaes (talk) 22:39, 11 April 2019 (UTC)
Oppose QI is not a subset of FP. As noted, QI is only applicable to image taken by Commons users. Also an FP is allowed to have weaknesses in technical quality if the image has sufficient wow. A QI is not concerned with wow. A good example is POTY File:Jubilee_and_Munin,_Ravens,_Tower_of_London_2016-04-30.jpg which failed as an QI nom by Eatcha. Personally, I think the focus on technical qualities that are easily learned and measured (noise, blown highlights, CA, distortions), rather than artistic qualities (composition, light, moment captured) and subject qualities makes QI a forum of dubious merit. The raven's photo captured a great moment, where the birds seemed to be performing a little comedy routine, while capturing enough of the background to be recognised as the Tower of London. The image is highly used and well liked (per POTY) yet has technical flaws that QI cannot see beyond. I'm not sure what QI's purpose really is, beyond teaching people to pixel-peep. -- Colin (talk) 16:59, 12 May 2019 (UTC)
Oppose There are times when the "wow" overcomes the quality at FPC. I have some such FPs myself and I would never consider nominating them for QI and I hope no-one else does either. That would just be embarrassing. --Cart(talk)19:56, 12 May 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 09:03, 21 June 2019 (UTC)
Proposal to allow only Featured Media as Media of the day
REJECTED FOR NOW:
Too soon for now as the FSC and FVC projects have been started/revived as recently as May 2019. Feel free to propose this proposal again when there is a considerable stock of FSs and FVs, say 6 months later. 4nn1l2 (talk) 06:16, 21 June 2019 (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.
Oppose 1. it's too early as Alexis Jazz says 2. I don't like the extra layer of bureaucracy/gatekeeping in principle. Abzeronow (talk) 15:43, 13 May 2019 (UTC)
Comments (allow only Featured Media as Media of the day)
Comment, from what I can tell this would lower the diversity of files featured every day, I can't remember seeing any bad media on the main page, so what advantages would having extra gatekeepers have? The educational value of a file is more important than it's quality. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:18, 12 May 2019 (UTC)
I think the educational value is also part of the criteria for featured media. But we definitely need to wait some month until we have enough Featured Videos and at least one new per day. --GPSLeo (talk) 22:34, 12 May 2019 (UTC)
I do not see any lack of diversity in POTDs of the past month, I guess same will happen with MOTDs + their overall quality and educational values will increase if the above proposal is implemented. And please note that if this gets implemented then, there will be no problem with number of Featured Videos and sounds that are nominated as the user who are directly adding their files in MOTDs would instead nominate them first at the FSC and FVC and most importantly these near dead projects (FVC and FSC) will revive -- Eatcha (Talk-Page ) 12:15, 13 May 2019 (UTC)
@Eatcha: there is far less audio and video than there are pictures. I think one issue is that afaik not many people are involved with MOTD. The Featured video candidates project was only just started, so there isn't any featured media to pick from at this moment. - Alexis Jazzping plz12:43, 13 May 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 09:03, 21 June 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I've actually wanting to bring up some issues with the current policy (or rather the enforcement of it), there are several organisations such as the Swiss National Library, several other national libraries, GLAM's, and German companies that have operated Wikimedia SUL-accounts on Wikimedia Commons for years and have uploaded tens of thousands of images (a piece in some cases). These company accounts are very productive users and have donated a great deal of free knowledge to Wikimedia Commons, however I have also seen several username blocks on the ground that the user name represents a museum, company, Etc. If these companies confirm that they are official accounts through the Wikimedia Commons OTRS and can confirm that they own the copyright of the files that they're uploading then this would be very beneficial and could attract more GLAM institutions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:15, 24 May 2019 (UTC)
Meh, there's a bit too much paranoia about account names, when a bit more good faith where it makes little difference would save on bureaucracy. If User:KrispyKreme is uploading good quality photographs of donuts every month, and there are no obvious copyvio or spamming issues, nobody should care very much. We should only be slapping people with policies where the are problems, not hypothetical problems. --Fæ (talk) 18:16, 24 May 2019 (UTC)
@Fæ: if the person behind User:KrispyKreme is actually a wholesaler and they may or may not have extracted those photographs from PDFs that Krispy Kreme may send out to wholesalers (which we'd never detect as copyvio), that would be an issue. Even if it's simply a Krispy Kreme fan who happens to have a high-end camera, at some point it will probably be discovered that this fan is not actually the Krispy Kreme company. When that happens, all those delicious donuts will quite possibly be deleted per PRP. If you are going to say you're a well known company/person, I think asking for verification is reasonable. The donut fan that didn't quite think their username through would also be able to request a rename at that point and avoid future misery. Regardless, this proposal isn't even about any of this! The current wording is "Use of the names of "organizations" is prohibited unless you provide evidence" and my proposed text changes this to "Use of the names of organizations is only allowed on Commons if you provide evidence". If you want to propose an actual change to the policy, you can create a new proposal for that. I was even doubting if I would simply make an edit request or even just make the edit, because my proposed text doesn't actually change the policy. But quite some people seem to think (until recently, so did I) that using the name of an organization was forbidden. The proposed text clarifies this is not true and explains why some people may think that. (enwiki) - Alexis Jazzping plz19:35, 24 May 2019 (UTC)
Tiny suggested tweak because I like 'only' to be unambiguous: replace only allowed on Commons if you provide evidence with allowed on Commons only if you provide evidence. --bjh21 (talk) 11:21, 3 June 2019 (UTC)
Having read the proposal more thoroughly, the main policy change here seems to be to permit organizations, but not notable individuals, to validate an account by providing a link from an official Web page. Is there a reason behind this distinction? I'd be in favour of allowing that kind of validation in both cases. --bjh21 (talk) 11:25, 3 June 2019 (UTC)
@Bjh21: The text was restructured a few times, I think that was at least partly responsible for the difference. The current policy text doesn't really offer a method of validating an account by linking from an official web page. If Donald Trung and Vulphere are okay with this version I'll change it to that. - Alexis Jazzping plz16:39, 3 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 09:04, 21 June 2019 (UTC)
Partial blocks
An editor has requested comment from other editors for this discussion.
If you have an opinion regarding this issue, feel free to comment below.
Types of blocks
No functionality will change for sitewide blocks. All existing blocks will remain in place and the ability to block troublesome users from the entire wiki will remain as-is. In addition to sitewide blocks, we would like to introduce the ability to block a user from:
Editing one or more specific page(s)
Editing all pages within one or more namespace(s)
Emailing other users
Use cases
These types of partial blocks could be useful when:
An otherwise productive user has an agenda on a particular topic (e.g. politics, religion, etc.)
There is sustained vandalism to one page from an identifiable IP range (e.g. students from one sports team vandalizing pages about a rival team.)
Two or more users have been sanctioned with an interaction ban
A user abuses the Email User feature but is otherwise productive on-wiki
A user makes ill-advised edits to templates
Function
These partial blocks would work similar to sitewide blocks:
Can be set by administrators.
Can be set for usernames, IP addresses, or IP ranges
Will include standard block parameters: reason, expiration, talk and subpage inclusion, and the option to autoblock IPs.!--T:14-->
Will appear on the block log, Special:BlockList, and everywhere else sitewide blocks appear.
When a user has been blocked, they will see a block message displayed that explains what they are prevented from editing in addition to the rest of the block information (the admin who blocked them, when the block expires, the block reason, and how to request an unblock.) — Preceding unsigned comment was added by 2600:1702:38D0:E70:FD25:732E:F177:1A07 (talk) 19:04, 26 May 2019 (UTC) — Preceding unsigned comment was added by 2600:1702:38D0:E70:FD25:732E:F177:1A07 (talk) 19:06, 26 May 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I am often asked how to correctly specify the license information for Wikimedia Commons files when using the files. And often of the time I am insecure myself.
in German: Einbindung von „www.lizenzhinweisgenerator.de“ in alle Lizenzvorlagen
Häufig werde ich gefragt, wie man für Wikimedia Commons Dateien die Lizenzangaben bei Verwendung der Dateien korrekt angibt. Und meist bin ich selbst unsicher . . .
Ich möchte folgendes vorschlagen:
In alle Lizenzvorlagen (zum Beispiel: {{cc-by-sa-4.0}}) sollte der Link zu „lizenzhinweisgenerator.de“ eingebunden werden.
Oppose: While the tool is very useful, I don't think it's reliable enough to include in every licence template. At a minimum, it would be pointless to use it in templates that it can't understand, like {{OGL3}} or {{Attribution}}. It even gets some Creative Commons licences wrong. For instance, when applied to File:21 Market Place, Uttoxeter.jpg (requesting off-line, isolated, unmodified use), it yields Mike Faherty (https://commons.wikimedia.org/wiki/File:21_Market_Place,_Uttoxeter.jpg), „21 Market Place, Uttoxeter“, https://creativecommons.org/licenses/by-sa/2.0/legalcode. But that's not correct. CC BY-SA 2.0 requires including the title of the picture as specified by the author, and that's “Uttoxeter, Horse & Dove” (as shown in the picture's {{Credit line}}), not “21 Market Place, Uttoxeter”. I wouldn't object to its use on templates for which it generates correct results (perhaps just the CC 4.0 series?), but it should be limited to those. --bjh21 (talk) 10:24, 2 June 2019 (UTC)
If there is written: "Attribution: Mike Faherty", direct under the license statement then this, I think this attribution is correct. Habitator terrae🌍12:43, 2 June 2019 (UTC)
@Molgreen: In English, you could add "(attribution tool)" at the end of the "attribution" line in the CC licenses that require attribution. Can the file name or URL be passed to the tool in the URL? If so, what is the syntax for that? — Jeff G. ツ please ping or talk to me09:50, 2 June 2019 (UTC)
@Alexis Jazz: , @Jeff G.: , @Bjh21: Thank you for your feedback. You are of course right: the integration is only useful for the templates for which the license notice is correct.
And yes, the automatic transfer of the name of the file would be very useful. — Preceding unsigned comment added by Molgreen (talk • contribs)
example: https://lizenzhinweisgenerator.de/?lang=en&url=https://commons.wikimedia.org/wiki/File:20190512_xl_P1070615-gro%C3%9Fer-werder-im-liepnitzsee-bei-wandlitz.jpg thanks to Alexis Jazz --Molgreen (talk) 16:05, 2 June 2019 (UTC)
@Alexis Jazz: Did you create the template {{Lizenzhinweisgenerator.de}}? That's great! I think in German "Verwenden Sie den Lizenzhinweisgenerator zur einfachen und rechtssicheren Nachnutzung." would fit better. Thank You! --Molgreen (talk) 15:45, 2 June 2019 (UTC)
Comment This overlaps with the StockPhoto gadget, which is currently enabled for everyone (logged-in and logged-out) on all files. The question for me would be, is the lizenzhinweisgenerator a better choice for the functionality, and if so, what’s the plan to deprecate the existing UI. Jean-Fred (talk) 11:50, 9 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 09:04, 21 June 2019 (UTC)
Increase the maximum number of files in UploadWizard
ACCEPTED:
The maximum number of files in UploadWizard for autopatrolled users will be increased with no 'artificial' limit; a 'technical' limit may be introduced by developers which will be subject to their opinion. See phab:T226217 for more details. 4nn1l2 (talk) 09:49, 21 June 2019 (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.
Administrators and license reviewers can upload as many files as they want with UploadWizard, but all others are limited to a paltry 50 files. This can force users to upload a shoot in batches, use third party upload tools or even upload to Flickr first and import with Flickr2Commons afterwards, which has no such limit. - Alexis Jazzping plz21:10, 7 June 2019 (UTC)
Increase the maximum number of files in UploadWizard for autopatrolled users: votes
Increase the maximum number of files in UploadWizard for autopatrolled users. (this includes all users with the autopatrol flag, like patrollers) If your support depends on it being raised no higher than some number, include that number in your vote.
Increase the maximum number of files in UploadWizard for autoconfirmed users: votes
Increase the maximum number of files in UploadWizard for autoconfirmed users. If your support depends on it being raised no higher than some number, include that number in your vote.
Increase the maximum number of files in UploadWizard for all other users: votes
Increase the maximum number of files in UploadWizard for all other users. If your support depends on it being raised no higher than some number, include that number in your vote.
Oppose unless evidence is provided, such as new users reaching this limit or using workarounds described. 50 is plenty.--BevinKacon (talk) 21:45, 10 June 2019 (UTC)
Increase the maximum number of files in UploadWizard: discussion
Correction, Flickr2Commons can only upload based on a ratelimit, I believe 700 (seven-hundred) images for non-admins, or maybe less, I remember trying to upload large batches from a single museum and having to run the entire batch again after 30 (thirty) minutes because of a ratelimit. Thess rate limits will probably also have to be adjusted if this/these proposal(s) are adopted by the community. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:05, 8 June 2019 (UTC)
Sorry if this is a stupid question but inregards to the second !vote - when we say "other users" do we mean just like passers by/non-tool editors ?, Thanks, –Davey2010Talk23:00, 8 June 2019 (UTC)
@Davey2010: you mean the third? If you are logged in with an account that was registered less than 4 days ago, you are not autoconfirmed yet. This group doesn't really have a name, afaik. - Alexis Jazzping plz23:26, 8 June 2019 (UTC)
There should be a finite limit to prevent the wizard/webpage from crashing or other technical problems. The limit shall be left to the developers to decide.--Roy17 (talk) 17:21, 11 June 2019 (UTC)
@Roy17: that's also my vote: no artificial limit needed. Technical limits, for example to guarantee stability, are fine. I'm not sure what the limit (if any) for admins and license reviewers is. (what's your limit?) - Alexis Jazzping plz23:10, 11 June 2019 (UTC)
I remember that UploadWizard did some ugly things (actually plenty of them) but considering performance, it set one interval per file (JavaScript setInterval) and whenever the timer reached the interval, it did some checking. With older clients, it was very easy to get an unresponsive website experience. Maybe this issue is obsolete but please make sure you do not allow more files at once than most clients are able to cope with, regarding to memory and CPU. In theory, you could program the wizard that way that it would allow an almost unlimited number of files, but for that, a lot of engineering efforts will have to be made, which is costly. -- Rillke(q?)19:36, 17 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 09:49, 21 June 2019 (UTC)
This version, which is too similar to the English Wikipedia policy page, is not going to make it on Commons. Most users believe that if a civility policty is needed, that shoud be home-brewed. Further discussion should take place at Commons talk:Civility. 4nn1l2 (talk) 12:41, 23 June 2019 (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.
Oppose. Sorry, but I don’t like a kind of “civility” where routine conflicts from Commons and Wikipedia are exported to Meta-wiki, being converted to an obvious harassment. I don’t like “civility” whose proponents refer to my postings as to “usual nonsense” meanwhile demanding from me to be “civil”. Long live civility without enforcers of civility. Incnis Mrsi (talk) 05:33, 5 June 2019 (UTC)
Oppose This is a rather unnecessarily rambling single user essay, cut & paste last month with very few changes from Wikipedia, that fails to build on any solid foundations, such as our Scope, PRP, BP, IDENT, L policies, all of which are relevant in different ways to an understanding of how being mellow (or "civil") works on Commons, or how challenging an upload based on copyright, or putting a file up for deletion review, may be contentious but rarely uncivil. Key evidence that the essay is nowhere near ready to be a Commons policy is that it is literally stuffed with cross-references to English Wikipedia and Meta policies and guidelines rather than Commons, even the handful of footnotes. Completely absent is the concept that Commons is multilingual (which the English Wikipedia is not) and so what might appear not mellow or insulting in one language and national culture might feel fine if being translated from another; this absence is a massive hole in this essay as on many occasions misunderstandings do arise from basic cultural and lingual differences and to stay mellow any Commons regular contributor must keep in mind that this project is not an English project even though at the current time most contributions are in that language. --Fæ (talk) 10:04, 5 June 2019 (UTC)
Oppose First I thank you for taking this step but really the creation of a new policy is likely to take months. So a copy/paste from English Wikipedia and trim is insufficient for us to open voting. Please please can you close this poll as it will snowball fail. Instead you should publish to the VPs to alert people to the new proposed policy/guideline and encourage editing by the community. I would then expect talk page discussions on the policy to allow editors to discuss changes, etc, and then this to reach a level of maturity and consensus that it is ready for a vote. Only vote after you think you have consensus, please stop opening polls on a novel topic where you are unaware of community consensus. In addition to the multilingual/cultural aspects noted by Fae, the policy is hindered by the absence of related policy/guideline on:
Without these, the definition of civility is incomplete. Many editors and admins are quite clueless about what actually constitutes a personal attack (it is not merely expressing a negative opinion about another person). Further the term "harassment" is used on Commons far too casually. We saw the other day, one admin claiming "harassment" when a user had merely opened a DR (which has merit). Our policy on that term (unless we can find a better alternative word) needs to consider that "online harassment" is actually a criminal offence in the UK. Online harassment, combined with a personal attack (such as on the person's gender, sexuality, religion, etc) is also defined as a hate crime in the UK. These are really serious offences, which also makes gratuitous baseless claims of harassment/personal-attack a serious offence.
While Wikipedia has disputes about articles, which have similarities to disputes about file description pages, categories, forums and galleries, etc, we also have disputes about media and with external users (photographers, agents, companies, subjects, etc). Any policy needs to consider how those are different. For example, we need to deal with complaints made by external users (who may merely have registered an account in order to communicate) with professionalism and respect, rather than the hostility for breaching polices or not understanding how deletion works. We don't handle the "angry customer" situation well at all. -- Colin (talk) 10:34, 5 June 2019 (UTC)
Oppose unless you are planning to provide everyone with free unlimited Xanax. (and that would be a policy violation right there I guess) I'll explain my view further below. - Alexis Jazzping plz11:18, 5 June 2019 (UTC)
Oppose Pretty much per above; this sort of mission creep eventually leads to Wikilawyering in my experience, and I don't think we need it set in stone. Rodhullandemu (talk) 11:34, 5 June 2019 (UTC)
Oppose - Generally speaking CIVILTY isn't really enforced on EN and given this is a multilingual project non-English people could see things differently. –Davey2010Talk22:58, 8 June 2019 (UTC)
Oppose I cannot see it ever being applied to a more powerful party that is attacking somebody less powerful or popular. I would think that something like this can be attached to guidelines to some positions of power (admins, licence reviewers, etc) with a note that it is their requirement to remain civil when dealing with somebody less powerful then they are. As such it can be used to supplement AGF. Thus everybody would have to assume good faith, but if it is an interaction between somebody with more potential to hurt another individual, then a more powerful party should also remain civil. However, even that is unenforceable, since a more powerful individual is going to be able to just shrug it off. ℺ Gone Postal (〠✉ • ✍⏿) 04:12, 22 June 2019 (UTC)
Discussion (Civility)
First of all, thanks for the effort! But I really wish we would have an obligatory round of feedback before we vote on this kind of thing. After all, changing a policy after it has been formally established can be difficult. After the first read I have two points:
The way this whole thing is written feels more like a Guideline to me. It would nicely fit into behavioral guidelines section at Commons:Policies and guidelines, right next to things like COM:AGF.
Since this is pretty much a copy of the policy at en.wikipedia I'm wondering which points that are unique to Commons are missing. One would certainly be acknowledging that Commons being a multi-lingual project that is nevertheless predominantly run in English is a major source of misunderstanding and avoidable conflict …
@El Grafo: Changing language of filenames and categories is already covered at COM:FR and COM:C, but I am open to adding specific text about such changes to the subject page. If you wanted to make a subsection for !voting about it being a guideline instead, I would support that. — Jeff G. ツ please ping or talk to me08:46, 5 June 2019 (UTC)
@Jeff G.: I'm not talking about file names and categories, I'm talking about communication issues – Basically what Fæ wrote in the vote above. And I'm not going to bother setting up another vote because the whole thing is not fit for a vote yet. The Wikipedia policy is a possible starting point, but there is still a lot of work to be done, as indicated above by Fæ and Colin. You've got the attention now, propose to use the momentum, abort the vote here and start a project of interested users shaping a guideline that is specifically tailored for Commons. --El Grafo (talk) 08:15, 6 June 2019 (UTC)
"Commons' code of conduct" is compared to en.wp's Five Pillars? Could someone provide a link to the code of conduct please? --Fæ (talk) 09:52, 5 June 2019 (UTC)
I think this is a terrible idea. First of all: harassment is already grounds for blocking users. So are edit-warring and other forms of disruption. Debates get heated, and that's fine. Saying "this is a dumb idea" is fine. In fact, saying "this is a fucking stupid idea" is fine. Ad hominem attacks ("you are dumb", "you are fucking stupid") are not fine. This proposed "civility" policy is basically just saying any heated debate is off the table, more or less killing all meaningful debate. I'll pass. Anger is a human emotion and shouldn't be banned from Commons. That doesn't mean you are free to attack anyone, but you are free to attack anyone's arguments. I oppose any "civility" policy, I'll consider a "decency" policy. (but such a policy may end up being redundant as we already have harassment and disruption policies) - Alexis Jazzping plz11:18, 5 June 2019 (UTC)
(WMF's statement after banning Fram basically for saying fuck, wheel warring with Floquenbeam and desysopping Floquenbeam for a month)
This is why we should never fucking ever implement any sort of policy even goddamn remotely like this. It'd just be inviting that WMF shitstorm over here. Also, we need to swear more. They can't ban us all. - Alexis Jazzping plz00:56, 15 June 2019 (UTC)
@Alexis Jazz: Not convinced. I am not fully aware of this enwiki incident and do not know this enwiki user "Fram", but they have been uncivil towards ArbCom, i.e. a group of users, and that personal attack makes their block/ban justified if enforced/imposed by the community (No idea about the WMF action though). My understanding is that one is free to use the F-word as they wish, even directing it towards real people in the real world, but not towards Wikimedia users who are our red line. See also Special:Diff/330796896. I support civility. 4nn1l2 (talk) 05:08, 15 June 2019 (UTC)
@4nn1l2: WMF blocked Fram out of the blue, no community discussion. The community is overwhelmingly against this and admin Floquenbeam unblocks Fram. In response, WMF reblocks Fram and desysops Floquenbeam for a month because iron fist. Now admin Bishonen unblocks Fram. Floquenbeam, trying to see if this is indeed a case of iron fist, requests a resysop. Which is granted!! by bureaucrat WJBscribe. WMF states that even though Fram is now unblocked, if Fram makes as much as one edit on enwiki they will be globally banned/locked. To be continued? Shitstorm I tell ya. - Alexis Jazzping plz05:55, 15 June 2019 (UTC)
@Alexis Jazz: As far as I understand, the WMF is trying to enforce Terms of Use, not civility policy on the English Wikipedia, and the banned user does not seem that innocent to me, although I understand the user's and the community's frustration.
That being said, I guess the timing is not good for proposing a new civility policy on Commons now in the light of the English Wikipedia incident; many users will probably be on the defensive. Maybe one year later... 4nn1l2 (talk) 06:52, 15 June 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 12:41, 23 June 2019 (UTC)
I suspect that the above was edited in a manner that turns it into nonsense: the argument seems to be between A and A. - Jmabel ! talk01:11, 21 June 2019 (UTC)
"Galleries without media are not galleries at all. They are considered out of the project scope and meet the criteria for speedy deletion."
with:
"A "gallery" with less than two files is not a gallery at all. Contributions consisting solely of text can be made in descriptions, captions, Wikipedia, Wiktionary and other projects. Pages that are created as galleries but have less than two media files are considered out of the project scope and meet the criteria for speedy deletion."
"Mainspace pages (galleries) that are empty or contain no useful content, such as pages that contain text but no images or other media."
with
"Mainspace pages that contain no conceivably useful content, such as empty pages or a gallery for a subject that contains text but never had more than one image or other media. If the gallery contains less than two files because the media was deleted, the gallery should be repopulated or a DR should be started."
In case you're wondering "what's the difference?", well, the difference is not that huge. But some admins (plural) are interpreting the current text to mean any page in gallery (main) namespace that isn't a gallery should be speedily deleted. This despite the policy already saying "or contain no useful content". Content that is useful but not a gallery shouldn't be deleted, at the very least not speedily. If needed, we can propose additional policy to define what is and isn't desirable in the main namespace. - Alexis Jazzping plz19:00, 25 June 2019 (UTC)
I'm not sure what the effects would be of such a change. Enshrining a threshold of "two" might give legitimacy to such micro-galleries. Stressing that text should be elsewhere seems to be a way to say that it's fine to remove or even delete any textual content from galleries if it could theoretically go elsewhere (although your stated goal is the opposite, as far as I understand). I don't see a big problem with having some flexibility in textual content of galleries and categories, while I have no idea why we should allow main namespace pages on Commons which are not galleries. Nemo19:18, 25 June 2019 (UTC)
@Nemo bis: The limit of two is already enshrined in the canned edit summaries for speedy deletions: "Gallery without at least two images or other media files". Wasn't my idea. Used 157 times past month. The current policy wording says "without media", implying a gallery with one image is acceptable. I made a minor change to the text to clarify text contributions means "galleries" with only text contributions.
As for "why", well first I think it's good to have the flexibility to use the main namespace in useful ways, and only ban things that are abused or that the community doesn't want. There has been a war over disambiguation pages the last couple of years. The admins won, obviously. I don't care if the community, in a vote, decides to ban disambiguation pages in main namespace. You might argue I could instead create a proposal to allow disambiguation pages, but the current policy seems to already allow them so that makes no sense, yet they are routinely deleted. - Alexis Jazzping plz19:44, 25 June 2019 (UTC)
Add Speed controls in native Wikimedia video player and change the interface to look like YouTube/Vimeo ?
Hello,
Did you ever noticed any difference while playing videos on Commons and on YouTube/Vimeo ? If not try playing File:LE PAYS BASQUE ( Biarritz, Bayonne, St Jean de Luz...) - FRANCE.webm on commons and here on YouTube. There is not speed control option on commons and the interface looks decades old. Take a look at https://plyr.io/ (SOURCE) it's open-source, can be used by Commons and its interface is way better than ours. I doubt this ancient video player is one of the reason we don't have many videos. Check the difference in number of CC and PD of videos on commons and YouTube, you will be surprised. Please discuss this issue and support the option that you like.-- Eatcha (talk) 10:27, 18 June 2019 (UTC)
Tips for now: when playing videos, right click on the player and you should be able to choose between 0.25x and 2x. Or use an extension/add-on. I do support revamp of the media player though.--Roy17 (talk) 19:02, 18 June 2019 (UTC)
I am curious what you use playback speed controls for though.. Personally I've never used these for anything other than podcasts and watching content over 30minutes long.. —TheDJ (talk • contribs) 15:13, 21 June 2019 (UTC)
Update the entire interface, similar to YouTube using open-source players E.g. plyr.io
While I like the new player in beta, you have to know how to use your context menu in order to set playback speed. Also Plyr's menu look and feel is lovely and it offers timeline preview images :) -- Rillke(q?)22:48, 20 July 2019 (UTC)
Geograph 2?
Commons has plenty of images of the British Isles thanks to imports from Geograph. As most of these uploads were done long ago, it might be worth doing another bulk upload. Jura1 (talk) 23:02, 20 June 2019 (UTC)
Absolutely not, unless they are significantly better than their previous standards. People standing in front of buildings does not constitute a picture of a building. Churches are not generally angled at about 5 degrees off the vertical. The British Isles has, occasionally, some daylight, so it should be possible to see the subject, and in focus. Unless we can get resolution somewhere above at least 5MP, and uploads are filtered for quality, it just makes work for us to do later. Rodhullandemu (talk) 00:00, 21 June 2019 (UTC)
The category has currently 12 images: 1 from Panoramio, 1 from the NLW, 2 direct uploads and 8 from geograph.org.uk.
Except maybe for 2 or 3 similar pictures, from a mere user perspective, the group together gives a good impression of the topic. If we didn't have the geograph ones, this wouldn't be so.
Obviously, a series of featured pictures to showcase and possibly print poster-size would enhance it further, but at least we have a good basis to illustrate the topic.
It's somewhat regrettable that there are no people in any of the pictures as otherwise one could get a better sense of the size of the building.
A non-minor problem of Category:Twr Mawr Llanddwyn Lighthouse is that the most recent picture is from 2010. One could get the impression that the lighthouse remains stuck in the last decade.
As digital photograph evolved since the last decade, I think the resolution of recent geograph images is higher. Jura1 (talk) 10:43, 21 June 2019 (UTC)
I would dearly love to get more recent Geograph pictures into Commons, but I think a bulk import of the 4 million missing pictures would probably be unwise. In addition to the quality issues mentioned by Rodhullandemu (which I think will be less for newer pictures), there's the simple matter that a fair proportion even of technically good pictures will be out of scope: there are only so many pictures of oilseed rape fields in East Anglia that Commons needs. Another problem is categorisation: it's only within the last year that the last of the 2010/11 batch was categorised, and plenty still need review. On the other hand, relying on individual uploads means we miss an awful lot of worthwhile pictures: Commons users are uploading images from Geograph at a little over 1% the rate that Geograph is gaining them (60-odd over the past week vs 6000-odd). The other 99% can't all be bad. --bjh21 (talk) 11:08, 21 June 2019 (UTC)
Support a bulk upload. These are useful photos to have here, even if it would be better to have higher resolution versions. Targeting pictures to upload would miss out quite a few photos that turn out to be useful a while after they have been uploaded, and wouldn't have otherwise been spotted/used. The particularly good thing with this set of photos is that they all come with coordinates, so they can be put into the category tree by location right from the start, and then be migrated into the more specific categories. Thanks. Mike Peel (talk) 17:15, 21 June 2019 (UTC)
Oh My! "They all come with coordinates!" better, "some come with correct coordinates". You wouldn't believe some of the howlers I've seen in and around Liverpool Geograph images of late. They'd have been better sticking a pin in a map. It's not helped that {{Geogroup}} has been changed to only show the top-level, and its developer isn't talking to anyone. Rodhullandemu (talk) 17:32, 21 June 2019 (UTC)
I agree that the Geograph import has been a clear net positive for our coverage and quality, as I keep bumping into topics which would be very poorly illustrated without it. It would be nice if someone could achieve a new import, maybe with some heuristics to avoid uploading photos of areas which might already be "crowded". Nemo19:22, 25 June 2019 (UTC)
Support, bulk uploads will always be added to a maintenance category and while most images will be high quality educational images a few images will be nominated for deletion by those doing the maintenance, the benefits of hosting those images largely outweigh any negatives from them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:41, 28 June 2019 (UTC)
It's been a while since I ran GeographBot. I think I uploaded (the first) 1.8 million images and they currently have over 6 million images. The categorizatin would need attention when the remaining are imported. When I did the import we didn't have Wikidata so now it should be easier. Fort the new files, we could add some structured data right away. I would first start with setting up an incremental bot that just uploads everything from Geograph, but lags behind say 3 months (to prevent junk to be instantly mirrored here). When that's working fine, it can do the bulk. What is the quality of reverse geocoding these days for the UK? The flow would be coordinate -> reverse geocoding -> Geonames or similar id -> Wikidata item -> Commons category. Multichill (talk) 21:54, 20 July 2019 (UTC)
England, at least, now has very good Commons categories corresponding to UK parishes, matched to Wikidata. It's easy enough to get coordinate outlines for these, via their GSS code (2011) (P836) and then OSM or the ONS or the Ordnance Survey TOID (P3120), which can then be used to place image coordinates reasonably well. One can also look up on Wikidata to see if there are any point coordinates near the location, which may suggest a specific item / category. Manual review is still needed (together with addition of any further thematic categories), but one can get a long way from the coordinates. Per Mike Peel above, the usefulness of photos can sometimes be quite unexpected and unpredicable -- eg two images that I found were just what I needed for en:Mairi Hedderwick, a bio I wrote a few years ago. Jheald (talk) 18:11, 27 July 2019 (UTC)
Support Newer images on Geograph may be of significantly higher resolution -- and many will not be identical to subjects we already have. Jheald (talk) 18:11, 27 July 2019 (UTC)
Support Many high quality images were in my line of sight from the previous upload. If some had problems, it is better than not to have good images. ℺ Gone Postal (〠✉ • ✍⏿) 06:25, 31 July 2019 (UTC)
Support all of the parishes (apart from 1 that doesn't have any images) have categories that are categorized by district so the bot can work out which category to put them in. Crouch, Swale (talk) 07:57, 31 July 2019 (UTC)
Close inactive non-English village pumps
Inactive VP are like ghost towns. Posts on those don't get answered in time. We may consequently miss out issues or lose the minority users. Therefore, I would like to make three proposals:
Close inactive non-English village pumps. (As part of the process, resolve any unanswered requests or move them to major VP.)
Merge all non-English help desks into their respective VP.
If a certain language version were to be revived or created anew, it must receive community concensus first.
And some technical suggestions:
Remaining ones should be opted out of message delivery, unless the community agrees to opt in. The messages are more like spam that make real discussions harder to find.
Archives to be done on request only (by inserting {{Section resolved}}) or automatically after no response for min. 2-3 months. Archives should be set up per year (preferably) or per 250K+ bytes. (Prompted by the Commons:Köy çeşmesi, archived automatically for 7-day-old posts and set up per month... ridiculous settings for a minor forum.)
Mea culpa — I just added to my watchlist all those VPs whose languages I can contribute in adn might need a helping hand (so, not fr and es). -- Tuválkin✉✇23:15, 25 June 2019 (UTC)
Adding to the top, IMHO, the main VP and help desk are not reserved for English but they serve as centralised noticeboards. Only if threads in a certain language overwhelm the primarily Engish VP, should the language have its separate place. It's not the other way around, that each language automatically deserves a place, and now I am being Anglocentric and killing them. VP and HD are meant for reporting issues and solving problems but not general Internet forums.
Another reason to open a minority VP could be using it like classified ads, but I doubt how effective this is. Rather than posting here, users should take the matter to the more popular local wikis.--Roy17 (talk) 17:23, 28 June 2019 (UTC)
No opinion on the matter in general, but existence of two separate Serbian boards Commons:Трг and Commons:Trg is a patent absurd; let alone both are inactive. Merge all such stuff into one Serbo-Croatian (or Croato-Serbian, if one likes it more) village pump. Incnis Mrsi (talk) 09:17, 29 June 2019 (UTC)
The ones to keep
I think the following languages can be kept: the six working languages of UN, German, Japanese, Portuguese, Italian, Dutch, Persian.
Borderline (some activity, but not all posts get answered, and some of their population is relatively small): Czech, Hungarian, Polish, Finnish, Ukrainian, Bengali, Hebrew.--Roy17 (talk) 20:39, 25 June 2019 (UTC) +Korean, Turkish.--10:51, 27 June 2019 (UTC)
Support the general proposal. However, I would like to be more permissive.
Keep the rest. Turkish and Korean are potential languages with many speakers. Currently, their VPs may not be as active as before, but there is a good chance that they will be more active again soon (For example, Wikipedia is blocked in Turkey now).
Protect {{Lang-VP}} fully. New language editions of VP should be added only after consulting with the wider community. Most VPs should be opted out of automatic messages. Most VPs should be archived annually. 4nn1l2 (talk) 09:43, 26 June 2019 (UTC)
In my opinion, whether a forum is active or useful, does not depend only on the number of new posts, but also on whether experienced users are present to help. If not enough native speakers monitor the forums, it's better for newbies to ask on the main help desk/VP. A solution is, interested users can sign up to monitor a forum and be listed at the top of the page. If issues are not answered in time, newbies could go directly to those users' talk pages. The Commons community also knows whether a forum is actively maintained by experienced users. (This list is redundant for languages that obviously have large active userbases, e.g. Dutch.)
Btw, there are no signs of native speakers' activity on the Greek Commons:Αγορά and the Thai Commons:สภากาแฟ, even though these languages have hugh population. Everything is bots' spam or non-Native speakers' appeal for help. I'd say Close.--Roy17 (talk) 10:51, 27 June 2019 (UTC)
Keep ALL of them, there is a chance that these village pumps will become active in the future and for speakers of these languages these village pumps might be their only gateway to help, even if interaction is sparse (to put it at best). We should fight the Anglocentrism of Wikimedia Commons, not enforce it. A common problem many people have is that if they don't speak English then they won't be able to contribute here. It is better to editprotect largely inactive village pumps until a speaker requests access than to outright delete it, I just don't see the benefits of deleting any village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:45, 28 June 2019 (UTC)
Addendum, and as usual, the conversation regarding the fate of many non-English speaking communities is wholly conducted in English excluding the people whom this proposal concerns, this only shows the extend of the current Anglocentrism of Wikimedia Commons and Wikidata. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:48, 28 June 2019 (UTC)
When there is no native speaker (especially experienced ones) around, it makes no difference if you reply to them on their version or on the main VP in English or anything but their mother tongue, but it does make a difference for them not to be guided to a ghost town, and have their messages discovered months or years later by wandering scavengers like me. The main VP and help desk are not reserved for English either.--Roy17 (talk) 17:05, 28 June 2019 (UTC)
Keep ALL of them per Donald, and encourage knowledgeable native speakers of languages other than English to contribute to, or at least watchlist, the village pumps of their native languages. — Jeff G. ツ please ping or talk to me18:43, 28 June 2019 (UTC)
Keep. If you're concerned about people posting to these pages not getting answers, put them on your watchlist and answer them. Forcing non-English speakers to negotiate the English Village Pump to get a response is backwards.--Prosfilaes (talk) 04:09, 29 June 2019 (UTC)
Keep ALL of them per Donald. Move the VP to the major ones? So, you think people can just move to Spanish or English VP? Most part of the world do not speak English. Better keep those VP than force people move to a VP in a language they do not understand. --Sahaquiel - Hast du eine Frage?22:28, 30 June 2019 (UTC)
I saw it, while I cannot endorse it's creation in its current form I do think that such village pumps have potential, it should best be improved to match this page and some basic copy-pasting might suffice. I think that these village pumps largely suffer from a lack of communication between Wikimedia Commons and their respective Wikipedia's, there isn't that much cross-wiki communication. For example "Commons:De Kroeg" links to this page (current version) but not vice versa. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:35, 29 June 2019 (UTC)
Please don't ping me on general boards like this. When you propose 50+ pages for deletion, you can't expect people to look at every one; expect responses to the general principle. I watch one of the pages you propose for deletion, and see no reason at all to deprive Esperanto speakers of a page to communicate on Commons.--Prosfilaes (talk) 18:48, 29 June 2019 (UTC)
@Prosfilaes: I proposed Closing, not deletion. The general principle would be marking pages with {{Historical}}. And out of 50+ VP, my stand is 21 of them can be kept, so I did not propose 50+ pages for deletion. Not 50+, not deletion! I always expect thoughtful discussions.
Esperanto VP had seven threads in 10 years. Only two of them are not massive news delivery. I dont seem to see your effort at maintaining the VP either.
The distinction between "closing" and "deleting" here is uninteresting; either way you make an interactive page unusable. The distinction between 50+ and 29+ is rarely interesting.
People who argue against the death penalty don't get into the details of what w:Bobby Joe Long did, so no, I refuse to be drawn in on a discussion of specific Village Pumps. I believe there's value in having a page where people who don't speak English can feel comfortable posting on instead of demanding they go to the Village Pump. If by thoughtful discussion you mean discussion that starts with the same assumptions as you, you're going to be oft disappointed and oft unfair.--Prosfilaes (talk) 03:55, 1 July 2019 (UTC)
Roy17, you may ask for a confirmation, and that is now given. Your gotcha question is noted and dismissed, as this is a matter of principle. What all these pages need is a few active Commoners who are fluent speakers of their languages to watchlist them, making sure that any enquiry is replied to. Considerations about the number of such enquiries are irrelevant (and, frankly, feels somewhat meanspirited); this is not costing anyone anything, so lets just make it work. -- Tuválkin✉✇05:17, 2 July 2019 (UTC)
@Tuvalkin: Those were honest questions, but you answered only the first one. I am sorry that you chose to interpret them in a negative way. Commons:Čaršija is subject to speedy deletion per G1, but since some users confirm they support keeping it, a DR will be necessary. I am looking forward to your opinions in DR.--Roy17 (talk) 10:15, 2 July 2019 (UTC)
Now two weeks after the keep all votes, what has the users enthusiastic about linguistic diversity done to help resolve the cold cases on each board? Btw, which is worse, replying on their local boards in foreign languages, or asking them to post on COM:VP in their native languages?--Roy17 (talk) 17:21, 13 July 2019 (UTC)
I think Chinese is the worlds most spoken language, so we should close all other boards including the English version and communicate on the Chinese board. The editors of the board are likely to accept postings in other languages as well, so there is no need to be worried about other languages.--Giftzwerg 88 (talk) 21:53, 14 September 2019 (UTC)
Help desks
I'm splitting off the suggestion about help desks. {{Lang-HD}} is a bit misleading: most languages just redirect to their respective VP, while only English, French, Japanese, and Mirandese(nope, Mirandese redirects to the Portuguese VP) have separate Help Desk pages. --HyperGaruda (talk) 07:06, 29 June 2019 (UTC)
Mirandese should either have its own VP, or redirect to Asturian VP. (Just like a link to, say, a non-existent Flemish VP should redirect to Dutch VP, not to French VP.) -- Tuválkin✉✇14:34, 29 June 2019 (UTC)
Action plan
The following should be carried out step by step regardless how users above want to keep the talking shops:
opt all forums out of automatic message delivery, unless speakers of that language explicitly approve of opt-in.
answer all current cold cases in their languages, English, or any appropriate lingua franca.
one-off archival of everything.
set up automatic archiving (by year) for future posts.
This section is resolved and can be archived. If you disagree, replace this template with your comment. Roy17 (talk) 15:51, 19 September 2019 (UTC)
Proposal typing aid
When somebody uses e.g. the de:WP it should be well known that there are many 'search' abbreviations; as an example, H:T will make some suggested expansions, like Hilfe:Tabellen, or H:V like Hilfe:Vorlagen. That simplifies the access to many pages - not only to Help pages.
Spoiled by such comfort, I am missing a comparable service in the commons, where I am doing a lot. On busy days I type hundreds times the long namespaces Template: or Category:, wishing it would as well be possible with only T: or C:. To install such a possibility could not be a problem to the relevant people!
In the English language, many terms are pleasantly short (Help, File, User); really longs things are abbreviated (i18n); I just miss the mentioned cases - therefore I ask the community about that idea. -- sarang♥사랑15:07, 16 June 2019 (UTC)
@Sarang: C: is not desirable because this is the recommended interwiki code for Commons. We have COM:, templates can be linked with {{Tl}} and when using templates you don't usually need to enter Template:. See also COM:Shortcuts. - Alexis Jazzping plz16:20, 16 June 2019 (UTC)
Thank you. Ok, C: is not desirable, I understand that it is the wrong example. But when I want to enter a special template, or category, I always have to type the full namspace: first. I know that we have short-named templates, like {{C}}, {{F}}, {{T}}, {{U}}. But that's only for using/linking them - not for searching. -- sarang♥사랑16:41, 16 June 2019 (UTC)
@Alexis Jazz: I guess that is the problem of future, not now. In my opinion, WMF already hosts too many projects, and new projects should not be added too easily, and I guess we have not had a new project for many years (excluding Wikidata). 4nn1l2 (talk) 20:42, 16 June 2019 (UTC)
Support the aliases mentioned by @4nn1l2, plus U for User, F for File, and T suffixes for associated talk namespaces (UT for User Talk, GT for Gallery Talk due to conflict with Template). — Jeff G. ツ please ping or talk to me20:33, 16 June 2019 (UTC)
I only support t for template and cat for category. Inclined to oppose the others. Use shorthands only for the most frequent words.--Roy17 (talk) 19:02, 18 June 2019 (UTC)
Strong support I think we have pretty much consensus here. This proposal has been proposed since June. Would someone close it and open a phab ticket? Masum Reza📞21:31, 21 September 2019 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. 4nn1l2 (talk) 09:03, 21 June 2019 (UTC)
Support marking own work FPs as QIs automatically. — Jeff G. ツ please ping or talk to me 05:42, 11 April 2019 (UTC)
Oppose FP and QI guidelines are not identical. --Smial (talk) 10:46, 11 April 2019 (UTC)
Comment I just found out many Picture of the Year winners are not QI. A small list out of these non QI POTY is here. -- 🇪🅰〒©🇭🅰- 💬 14:39, 11 April 2019 (UTC)
later I like the idea, but let's first make sure that these two projects actually take off. --El Grafo (talk) 08:05, 14 May 2019 (UTC)
Info Please also note, that the generator only works for CC-licenses. Habitator terrae 🌍 09:47, 2 June 2019 (UTC)
Weak support It's necessary but there may be adjustments. Millennium bug (talk) 06:29, 8 June 2019 (UTC)
Keep ALL of them, there is a chance that these village pumps will become active in the future and for speakers of these languages these village pumps might be their only gateway to help, even if interaction is sparse (to put it at best). We should fight the Anglocentrism of Wikimedia Commons, not enforce it. A common problem many people have is that if they don't speak English then they won't be able to contribute here. It is better to editprotect largely inactive village pumps until a speaker requests access than to outright delete it, I just don't see the benefits of deleting any village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:45, 28 June 2019 (UTC)
22:28, 30 June 2019 (UTC)
Strong support. --予弦 06:14, 25 August 2019 (UTC)