Open main menu
Community portal
introduction
Help deskVillage pump
copyrightproposalstechnical
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

COMMONS DISCUSSION PAGES (index)


Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 

Proposal to run a bot to archive every external link using the Internet Archive on Wikimedia CommonsEdit

(Prior discussion Commons:Bots/Work requests#Internet Archive preservation of external links.)

The Wayback machine already works on most major Wikimedia websites.

Dear fellow contributors,

I am proposing to let a bot run on every file on Wikimedia Commons and other relevant pages which utilise external links and archive these links using the Internet Archive for future reference in the same way it is currently done on many other Wikimedia websites. This will allow for license reviewers and re-users to have a point of reference files from external sources as linkrot may obfuscate their original licenses and make it harder to verify them.

For a good (current) example where a changed source page is affecting the license of formerly free files please see "User:Alexis Jazz/DWDD archief". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 5 February 2019 (UTC)

Votes (archiving external links)Edit

  1. Symbol support vote.svg Support, obviously as the proposing agent. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 5 February 2019 (UTC)
  2. Symbol support vote.svg Support This seems useful. --Yann (talk) 11:39, 5 February 2019 (UTC)
  3. Symbol support vote.svg Support Good idea. - Alexis Jazz ping plz 11:54, 5 February 2019 (UTC)
  4. Symbol support vote.svg Support, I hope they can handle the traffic.   — Jeff G. please ping or talk to me 12:27, 5 February 2019 (UTC)
  5. Symbol support vote.svg Support - Sounds like a great idea!, Although somewhat unrelated I run this tool all the time at EN (which can replace all dead and alive links with WebArchive) - As noted above given licences can and do change I would support this little gem. –Davey2010Talk 20:34, 5 February 2019 (UTC)
  6. Symbol support vote.svg Support. Archive should be done within minutes. This is also useful for Iranian websites which publish content, but occasionally remove them within hours (sometimes at the behest of "censorship office"). For example see File:Pir Shalyar 20190202 06.jpg which no longer can be license-reviewed. Neither Google cache [1] nor Bing cache [2] nor Internet Archive [3] could save the work in time. File:Mahnaz Afshar 20190201 01.jpg is another example which was fortunately saved using Google cache. In this case the problem was apparently violation of dress code. 4nn1l2 (talk) 08:43, 6 February 2019 (UTC)
  7. Symbol support vote.svg Support Common sense idea. This also will help prevent DRs and "no source" tagging. Abzeronow (talk) 14:52, 6 February 2019 (UTC)
  8. Symbol support vote.svg Support This consensus helps to ensure that later housekeeping or bot maintainers can more easily handle complaints, related to what is likely to affect millions of files. Where there are specialized issues, such as "hot" websites where the quoted source is at risk of being taken down, these may need bot tasks negotiated that periodically rerun. For very large stable collections, like Geograph or the British Library, these can run relatively slowly as background maintenance, and it hardly matters whether a new upload waits to have its links added to WBM for a few months. -- (talk) 12:03, 9 February 2019 (UTC)
  9. Symbol strong support vote.svg Strong support yes please. --Jarekt (talk) 12:59, 12 February 2019 (UTC)
  10. Symbol support vote.svg Support and for robots sites [4] go to archive.is -- Slowking4 § Sander.v.Ginkel's revenge 14:12, 12 February 2019 (UTC)
  11. Symbol support vote.svg Support This would be a good prevention of linkrot. De728631 (talk) 20:53, 12 February 2019 (UTC)
  12. Symbol support vote.svg Support Platonides (talk) 23:59, 17 February 2019 (UTC)
  13. Symbol support vote.svg Support Blue Elf (talk) 23:10, 22 February 2019 (UTC)
  14. Symbol support vote.svg Support Bj.schoenmakers I'm already using this to preserve copyright information on sites where people can adjust their own copyright on images. My upload-bot will post the url to waybackmachine/archive.org first and use the returned date in my template in the commons upload: for example {{Archive.orgTimeStamp|20190303145847|https://world.observation.org/foto/view/19508795}} —Preceding comment was added at 00:10, 4 March 2019 (UTC)
  15. Symbol strong support vote.svg Strong support Very good idea Vulphere 15:13, 24 March 2019 (UTC)
  16. Symbol support vote.svg Support IMO very good Proposal -- Eatcha (Talk-Page ) 18:15, 12 May 2019 (UTC)
  17. Symbol strong support vote.svg Strong support --oSeveno (User talk) 15:35, 15 May 2019 (UTC)
  18. Symbol support vote.svg Support but see my comment below. Ankry (talk) 11:10, 21 May 2019 (UTC)

Discussion (archiving external links)Edit

How should this best be implemented? Is the page "User:Fæ/Wayback" developed by a good model? Personally I propose "[EXTERNAL LINK] (ARCHIVE, retrieved: DD-MM-YYYY)". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 5 February 2019 (UTC)

@Donald Trung: "{{Wayback|url=http%3A//trainpix.org/photo/122696/|date=20150316101047}}" (implemented as "archive copy at the Wayback Machine (archived on 16 March 2015)" on File:143, Sverige, Stockholm, Roslagsbanans depå (Trainpix 122696).jpg) is standardized and looks nicer, you can discuss on Template talk:Wayback if you disagree.   — Jeff G. please ping or talk to me 12:38, 5 February 2019 (UTC)
@Jeff G.: indeed, that looks way better, and having a standard template for Internet Archive Wayback Machine links would also make it easier to be consistent. Face-smile.svg I honestly wasn't aware of the existence of "{{Wayback}}", this would make implementing the above proposal easier as well. Face-grin.svg --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) ill have (Articles 📚) 12:48, 5 February 2019 (UTC)
Though some earlier wayback additions were the links only, and others like Fortepan have the WBM link added as part of a specialized collection template, the largest collection so far, the Portable Antiquities Scheme uploads are using the preexisting wayback template. See File:BUCKLE_(FindID_187883).jpg or File:Cavalry Soldiers rehearse live-fire exercises with Lithuanian partners 141118-A-QS211-838.jpg for examples of how this looks. -- (talk) 11:57, 9 February 2019 (UTC)

I do not understand the proposal. Are we voting on something that will be done on the Wayback-homepage? --Schlurcher (talk) 12:47, 10 February 2019 (UTC)

@Schlurcher:, this proposal is so that all external links could be backed up using the Wayback Machine using a bot, this would create a snapshot of the external website which future people could use to confirm the licenses of files. For example I import a photograph from Amazingfreepictures.fr (example website) but then this website disappears a year later, a license reviewer then tries to confirm the license but can't, now this image will have to be deleted because its free license can’t be confirmed (see “COM:PCP”), now if this external website was backed up using the Internet Archive this file would not have to be deleted. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:04, 10 February 2019 (UTC)
@Donald Trung: or you could use some examples that actually happened: Commons:Village pump#License reviewers and admins help is needed ASAP (we got lucky with that one and everything could be reviewed in time), Category:Images from lasvegasvegas.com and Category:Photographs by Agencia Brasil. - Alexis Jazz ping plz 21:36, 10 February 2019 (UTC)

I'm not sure why this is still being discussed, but Internet Archive is already doing this and we have stats that nearly all the links we have in file descriptions are already archived. Nemo 08:59, 8 April 2019 (UTC)

Could you provide a link to the stats, or a link to where someone has confirmed that the tool is crawling Wikimedia Commons, not just Wikipedia? Seconds before I write this, this WBM link is being added to a DoD photograph uploaded in 2016, it was not on the IA until I added it today. The majority of the Commons images I am adding WBM links for are not already on the IA. You may be confusing the undocumented exercise to add all Featured Pictures to the WBM with doing it for everything else. As a quick test using a sample of 1,000 files, the ratio of 'already on IA' to 'not on IA' for the DoD project is 42%, and most have been hosted on Commons for several years; in that time quite a large number have suffered with linkrot (for non-DVIDs sources), so are already too late for the WBM. -- (talk) 09:16, 8 April 2019 (UTC)

@Nemo bis: I just saw your comments, is this already true for Wikimedia Commons? Because I imported a couple of hundred files from a University which just completely changed how its URL's work and now all of the old URL's don't function anymore, would the InternetArchiveBot immediately recognise them in the Internet Archive? Or aren't these links archived yet? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:34, 3 May 2019 (UTC)

While I generally support the idea, I am a bit afraid that IA ban us when we try to archive large bunch of external webpages. Especially if a user intentionally adds a bunch of links (not necessarily related to the uploaded file) in the file description page. IMO, the better solution would be to archive the links somewhere in Wikimedia (and not necessarily make them available to the whole public). Ankry (talk) 11:09, 21 May 2019 (UTC)

I created over 400,000 links on IA over a couple of weeks as part of housekeeping my Commons upload projects, if their interface is being used correctly, I doubt anyone would get access blocked. As for using Wikimedia, it was confirmed on the Wikimedia-l email list that there are no plans or strategy in place by the WMF to maintain any public archives, ever. If Wikimedia Commons went offline next month, there is zero guarantee that the WMF would give public access to an archive, while the Internet Archive explicitly guarantees it, with a strategy behind it for 100 years. -- (talk) 11:44, 21 May 2019 (UTC)

Proposal to shorten the warning shown to logged-out usersEdit

With the addition of structured data on Commons, there are multiple new input points where logged-out users can see the usual “You’re not logged in, your IP address is visible” warning; it's no longer only the edit box window. The development team would like to update the default message on Commons to be more similar to the rest of the Wikimedia wikis, which will fit better with new inputs. For sake of comparison I'm using English-language editions of wikis, but other languages have messages of similar brevity.

  • Commons today: You are not currently logged in. While you are free to edit without logging in, your IP address (viewable on your talkpage, where you can check messages sent to your IP) will be recorded in this page's edit history. Creating an account will conceal your IP address and provide you with many other benefits. Please do not save test edits. If you want to experiment, please use the Sandbox.

...as compared to...

  • Wikidata today: Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a user name, among other benefits.
  • English Wikipedia today: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a user name, among other benefits.
  • English Wikivoyage today: You are not logged in. Your IP address will be publicly visible when you save an edit. To have your edit associated with a user name instead (among other benefits), log in or sign up.

The proposed new text for Commons:

  • You are not logged in and your IP address will be publicly visible if you make any edits. Logging in or creating an account will conceal your IP address and provide you with many other benefits. Please do not save test edits. If you want to experiment, please use the Sandbox.

What do y'all think? Keegan (WMF) (talk) 19:15, 3 April 2019 (UTC)

  • +1. While we're at it, however, better link mw:Help:Logging in rather than a monolingual page. Similarly, rather than a technical page which most people won't understand it's better to have "your IP address" link special:Mypage. These are both changes which could be made in the MediaWiki default as well, which I currently consider superior. Nemo 19:45, 3 April 2019 (UTC)
Great suggestion, thank you. Keegan (WMF) (talk) 20:21, 3 April 2019 (UTC)
  • +1. As Nemo says, multilingual link would be better for Commons since this is not a monolingual project. Abzeronow (talk) 19:49, 3 April 2019 (UTC)
  • +1 per Nemo.   — Jeff G. please ping or talk to me 22:52, 3 April 2019 (UTC)
  • +1. Good idea, no one reads warnings if they are longer than a couple sentences. Kaldari (talk) 18:56, 13 April 2019 (UTC)
  • +1 per Nemo and Kaldari. Green Giant (talk) 04:44, 15 April 2019 (UTC)
  • +1. Vulphere 13:42, 11 May 2019 (UTC)
  • +1.per supports above -- Eatcha (Talk-Page ) 18:59, 12 May 2019 (UTC)

Featured picture which is work of a user should automatically get the QI TagEdit

  • 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)
  • Symbol support vote.svg Support marking own work FPs as QIs automatically.   — Jeff G. please ping or talk to me 05:42, 11 April 2019 (UTC)
  • Symbol support vote.svg Support, this makes a lot of sense. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:39, 11 April 2019 (UTC)
  • Strong Symbol oppose vote.svg Oppose FP and QI guidelines are not identical. --Smial (talk) 10:46, 11 April 2019 (UTC)
  • Symbol oppose vote.svg Oppose There are cases where featured pictured are not QI. Regards, Yann (talk) 11:08, 11 April 2019 (UTC)
  • Symbol support vote.svg Support - support as proposer, please look at obvious QIs like these 1, 2, 3, 4 and many more. Why we need to nominate these at QIC ? -- 🇪🅰〒©🇭🅰- 💬 14:01, 11 April 2019 (UTC)
  • Pictogram voting comment.svg 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)
  • 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)
  • Okay, I struck those 2 non common user works. That means 11 non QI FIs are still left that too only from POTYs. If some of user are against this automatic marking proposal , how about If no user is against marking an Image as QI at the FI nomination Page, then Mark it with the QI stamp ? -- 🇪🅰〒©🇭🅰- 💬 03:39, 12 April 2019 (UTC)
  • We don't need a new rule for that. Just nominate them for QI. Regards, Yann (talk) 07:23, 12 April 2019 (UTC)
    @Yann, what about others work ? can I nominate their works without consulting them and is it considered civil ? -- 🇪🅰〒©🇭🅰- 💬 14:25, 12 April 2019 (UTC)
  • I mean what if I nominated their work and it does get rejected ? -- 🇪🅰〒©🇭🅰- 💬 14:28, 12 April 2019 (UTC)
  • You don't need the permission from the authors, but sending them a message would be nice. Regards, Yann (talk) 14:32, 12 April 2019 (UTC)
  • Thanks, I am nominating 5 out of these 11 POTYs -- 🇪🅰〒©🇭🅰- 💬 16:09, 12 April 2019 (UTC)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg 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)

Sort licence review requests chronologicallyEdit

The queues of licence review requests are perennially long. In particular Category:License review needed (video) is near 10,000. Yay!

I propose sorting the requests chronologically so that old ones can be reviewed first. Age of a file does matter, because the longer it waits, the more likely its source disappears.

Another advantage is, files uploaded around the same time but starting with different alphabet will be put together. This is helpful for batch uploads.

A disadvantage is, reviewers wont be able to find a particular topic by picking alphabet. (I often jump to U... files because they are mostly related to US and easy for me to review.)

I've proposed this before (Commons:Village_pump/Archive/2019/01#sort_files_pending_review_by_timestamp and Template_talk:LicenseReview/layout-reviewme), but so far only @Ghouston, Jeff G.: were interested to discuss this, so now I make a formal proposal. Do you support sorting by REVISIONTIMESTAMP, or by PAGEID; oppose; or have other suggestions? (You can find the single line of code that implements this proposal at Template_talk:LicenseReview/layout-reviewme.)--Roy17 (talk) 18:30, 9 May 2019 (UTC)

Symbol support vote.svg Support PAGEID. If sorted by timestamp, an edit will send the file to the end of such long queues (thousands of files, i.e. tens of pages of 200 each). However, if queues can be kept short (below 1000), it wont make much difference because even the end of the queue will get reviewed soon enough. (Btw, I dont think padding is essential, since LRR queue is meant to be dealt with shortly, it wont take long for all queuing files to have the same length of PAGEID. Page#9999999 was created in 2010. Right now we are around #78830000. In a few years it will be 9 digits.)--Roy17 (talk) 18:30, 9 May 2019 (UTC)
PAGEID does seem best. Sometimes an old file will be added to the license review queue, and you wouldn't want it to stay at the back forever because it starts with a "9". --ghouston (talk) 02:51, 10 May 2019 (UTC)
Symbol support vote.svg Support PAGEID per nom and ghouston.   — Jeff G. please ping or talk to me 11:28, 10 May 2019 (UTC)
Symbol support vote.svg Support PAGEID as mentioned above. --Yann (talk) 04:58, 12 May 2019 (UTC)
Symbol support vote.svg Support PAGEID as above -- Eatcha (Talk-Page ) 18:53, 12 May 2019 (UTC)
Symbol support vote.svg Support, more things should be organised chronologically, the older the video the larger the chance is that it has been affected by linkrot or a license change. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:12, 12 May 2019 (UTC)
Symbol support vote.svg Support PAGEID. Vulphere 10:16, 16 May 2019 (UTC)

Allow operation of bots without a permit subject to a set of rulesEdit

Proposal withdrawn, no more votes please. Discussion may continue below.

To stimulate the creation of bots, I propose to reduce the bureaucracy needed to operate one. This will also be useful for users who want to test bots before applying for a permit.

For the purposes of this proposal, a bot is defined as a computer program that will continue editing a wiki without human intervention until the program is halted. So Cat-a-lot and VFC are not bots.

To operate a bot without a permit, it is required to comply with the following:

Account:

  1. The bot must use an account, and the account must have the word "bot" or "robot" in the username. For example: "BotAdventures", "ArchiverBot", "Rotatebot", "Robot power" or "Mike's bot".
  2. The user page of the bot must have the {{Bot}} template at the top and should explain what the bot does.
  3. One bot is not allowed to use multiple accounts.

Requirements:

  1. The edit summary for every edit the bot makes must begin with "Bot: " and contain an informative summary in English. If your bot performs a task aimed at a specific language, the summary is allowed to be in that language instead.
  2. By default, your bot should not mark edits as minor. If an admin requests so, you have to configure your bot to mark edits as minor.
  3. Your bot must have a check to avoid reverting other users within 24 hours if they have reverted your bot. If required to avoid an edit warring bot, you will have to create an internal blacklist for your bot with pages it shouldn't edit. If your bot fights vandalism and reverts edits on purpose, it should perform no more than one revert every five minutes on the same page and never revert an autopatrolled user.
  4. The bot must be internally limited to no more than one edit every 5 seconds per namespace. So one edit in the "User talk" namespace and one in the "File" namespace within 5 seconds would be allowed, but two edits in the "File" namespace within 5 seconds is not allowed. Any administrator is allowed to enforce that with a ratelimit.

Limitations:

  1. Your bot should only make non-controversial edits. If you want to use your bot for potentially controversial edits, you need to seek community consensus first. If you receive any serious complaint, you must pause your bot and discuss. Any admin may temporarily block your bot if concerns are raised.
  2. You are allowed to combine multiple functions or bots in one account, but the account is still not allowed to exceed one edit every 5 seconds. In addition, the edit summary needs to clarify which function or bot made the edit in this case.
  3. You are allowed to operate multiple bots that each have their own account, but only if they are not interconnected or coded similarly in a way that may cause them to fail and start producing bad edits simultaneously.
  4. If your bot messes up, you are expected to repair the damage. How you do this (by hand, using your bot, with VFC, etc) is up to you. Any admin may block your bot as long as it misbehaves.
  5. When you implement a new function in your bot, you are expected to test it before you let it run automatically. If a test run messes anything up, the previous rule applies.

This would be added to Commons:Bots with a new header "Running a bot without permission". - Alexis Jazz ping plz 20:30, 10 May 2019 (UTC)

Allow operation of bots without a permit subject to a set of rules: votesEdit

Proposal withdrawn, no more votes please. Discussion may continue below.

  • Symbol support vote.svg Support, a lower threshold for bot-accounts would probably invite more users to create one, everything above seems sensible. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:07, 13 February 2019 (UTC)
  • Symbol support vote.svg Support as proposer. Donald Trung's vote copied per his request. - Alexis Jazz ping plz 20:30, 10 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose The whole point of a bot flag is to avoid flooding people's watchlists when an authorized bot makes thousands and thousands of edits. If you want to test a bot you can do so in your userspace, no questions asked. Sorry, but allowing unauthorized bots, rules or not, is a horrible idea in my opinion. How exactly are we supposed to rate limit accounts anyways? The only way to stop an account from editing is with a block or an edit filter the latter of which would cause an unnecessary strain on resources. This is an extreme solution to a small problem of "lack of bots" of which was not actually explained. What bot are we specifically lacking that has been requested and not taken up? --Majora (talk) 20:53, 10 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose The proposal actually introduces stuff that are not actually "rules" at the moment, e.g. not marking trivial housekeeping edits as minor (why?), no multiple functions or bots in one account (huh, that's unnecessary). The benefits are unclear as there is nothing to stop a user doing most of this stuff already if they want to. Set up and account and get on with it is the basic rule, then apply for a bot flag if that's really necessary, like making 100,000 edits in a project. We do not need people to ask for bot flags for simple things like having an account devoted to an upload project, or small scale maintenance stuff equivalent to running VFC on a couple of thousand files that nobody will care about. Want to set up User:AJ_bot and experiment with doing some helpful automated maintenance, nothing stopping you. What we should do is take All bots running on Wikimedia Commons must have advance permission to do so out of the bots policy, it's not the actual norm. -- (talk) 21:32, 10 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Majora. Bad enough when the watchlist is flooded by semi-automated tools (yes, I use these and can understand people's frustration when the watchlist is flooded with category moves for example) but to allow bots without going through the process of getting the bot flag, where we know it isn't unstable (making incorrect moves, removing important information). Bidgee (talk) 01:27, 11 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Majora and Fæ. COM:BOTS exists for a reason; flooded recent changes is not fun.   — Jeff G. please ping or talk to me 09:24, 11 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose no evidence has been provided that reducing bureaucracy would encourage bot creation.--BevinKacon (talk) 11:45, 11 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose per Majora and Fæ. Vulphere 13:41, 11 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose More likely to create problems than reduce supposed bureaucracy. Ammarpad (talk) 18:14, 11 May 2019 (UTC)

Proposal withdrawn, no more votes please. Discussion may continue below.

Allow operation of bots without a permit subject to a set of rules: discussionEdit

@Majora: a ratelimit could be implemented with a new user group. This enforcement doesn't have to be implemented, but if anyone feels it's needed, it could be. You would deal with them the same as users: if they behave well, autopatrol them. Testing bots in userspace is not realistic for many bots, because the File: namespace behaves differently. Your last question: there are many tasks here that could be automated, but it doesn't happen. FlickreviewR for other sites? Dealing with archive.org? In general, many requests at Commons:Bots/Work requests seem to go unanswered if they can't be done with cat-a-lot or VFC. - Alexis Jazz ping plz 21:10, 10 May 2019 (UTC)

The only thing I see on the work requests page that has no responses was posted April 30th. It is the last section on that page. Knowing a little bit about programming and the difficulty of image recognition for computers I'm not sure how feasible that last section even is. As to the suggestion that we would create a new group wouldn't that defeat the purpose of this proposal? And for testing there is the beta cluster or the test server. Two great resources for programmers looking to test things without having to use production. --Majora (talk) 01:07, 11 May 2019 (UTC)
There's more in the archives. The purpose of the proposal is to make it possible for people to create bots without asking for permission when respecting some restrictions. When you must ask for permission, it creates a barrier. You don't need permission to create an account and use VFC or Flickr2Commons.. but if you create a bot that makes 10 edits per day, it may get blocked because the policy says so. The beta cluster, yes, that's a better option. Not everyone knows it exists, but if you do, it's a good option for testing. - Alexis Jazz ping plz 02:15, 11 May 2019 (UTC)

@: "e.g. not marking trivial housekeeping edits as minor (why?)" Because it's a bot, I suggest not marking anything as minor initially. As soon as an admin sees it and determines it's fine, the admin can ask the bot operator to switch to minor and/or grant the bot autopatrol status.

"no multiple functions or bots in one account (huh, that's unnecessary)" Actually that's specifically allowed?

"Set up and account and get on with it is the basic rule, then apply for a bot flag if that's really necessary, like making 100,000 edits in a project." The basic rule is "set up an account for your bot, get blocked for no reason". Actually VysotskyBot got blocked because "The bot in question is not flaged and therefore flooding the RC with unpatrolled edits." Well, if VysotskyBot misbehaved they should have been blocked for that and otherwise they should have been granted autopatrol. I suppose in this particular case VysotskyBot could have been blocked for having a misleading username or something, but that was not the reason for the block. I agree that "All bots running on Wikimedia Commons must have advance permission to do so" should be removed from the policy. There doesn't seem to be clear support to simply drop that part, so this proposal is an attempt to regulate bots without a permit instead of some wild west scenario. - Alexis Jazz ping plz 23:01, 10 May 2019 (UTC)

The key to these questions is 'non-contentious'. If you set up a general housekeeping account for your projects, it can legitimately do lots of automated and semi-automated things, most of which will be variations of what we do with cat-a-lot or VFC without anyone worrying. This stuff only becomes 'contentious' when categories are flooded, when the automation is very fast and edits are filling recentchanges, or where what is being done causes confusion for others and ought to really have a reasonable amount of community discussion before carrying on.
Over a year there are several rather pointless requests for bot accounts flags where all the user wants to do is some limited housekeeping like uploading 1,000 images or renaming a few thousand files. As a community we should get more in to the habit of encouraging folks to experiment with that type of automation, whether using a legit alternative "bot" account or not, just as if the user were doing the changes using AWB.
Now, rather than worrying about the minor flag, if you think changes need a review, then one can ask on the VP, bots/work or at AN for feedback, or for larger experiments one should consider creating an on-wiki project page to document the project. If these changes are thought by others to be significant automation, then that's a good time to think about creating a long term special bot account for it.
As for the 'one account' question, no there are many, many examples of bot accounts that are generalized and the operator routinely chucks new housekeeping jobs under the same account. There is no need for limited housekeeping jobs to spawn endless new bot accounts. There can and should remain room for common sense.
Naturally, lots of people bang on about regulating bots as if we are under attack by spammers and hackers. This does happen, but making extra bureaucracy for volunteers who want to play around with legitimate automation does absolutely nothing to discourage the fringe black hats and those that get their kick from being annoying. -- (talk) 11:42, 11 May 2019 (UTC)
As for the 'one account' question, no there are many, many examples of bot accounts that are generalized and the operator routinely chucks new housekeeping jobs under the same account. There is no need for limited housekeeping jobs to spawn endless new bot accounts. There can and should remain room for common sense.
Yes, and my rules specifically allowed this, so I don't see the conflict here? I think in general we agree, but somehow we can't figure out the right wording for the policy. - Alexis Jazz ping plz 06:24, 12 May 2019 (UTC)

Parameter to hide non-US warning on {{PD-US-expired}}Edit

{{PD-US-expired}} has a static warning message that warns "If the work is not a U.S. work, the file must have an additional copyright tag indicating the copyright status in the source country." The message comes with a red warning icon and, in my opinion, always makes it look like something is wrong, even though the warning does not apply if the work was published in the U.S.

Proposal:

  • Add a publication country parameter to the template. If the parameter is provided and set to 'US' or 'USA' (the ISO-3166 country codes for the United States), omit the warning message.

This was also suggested by Xover (talk · contribs) ages ago on the template talk page. BMacZero (talk) 17:48, 11 May 2019 (UTC)

Definitely support this. As well as, I think, some combination of PD-old-*-auto (or is it PD-scan?) that combines US and source country (UK, say), where it still gives that warning even though the non-US license tag is right there; in, from the user's perspective, the same template (I know that's technically not true, but that's what it looks like). And those templates together have both |deathyear= and |location= parameters already, that are just not used for this. --Xover (talk) 18:05, 11 May 2019 (UTC)
@Xover: Yes, I think it's also a good idea to find a way to suppress the warning when a valid license for the source country is provided. BMacZero (talk) 04:45, 13 May 2019 (UTC)
  • Symbol support vote.svg Support to allow hiding of the static warning messages in templates like {{PD-US-expired}} or {{PD-old-auto}}. However I would just add some true/false flag like |hide_warning= instead of using free text parameter like |publication country=. --Jarekt (talk) 03:20, 12 May 2019 (UTC)
  • @Jarekt: I see what you're getting at, but I think I prefer the country parameter because it requires the user adding it to specifically acknowledge the warning and explicitly specify why it doesn't apply. BMacZero (talk) 04:45, 13 May 2019 (UTC)
  1. many templates could use this parameter and all of them should use the same parameter,
  2. make parameter easy to remember - using | to turn of warnings is not intuitive and will likely require studying of documentation
  3. We might want to turn off warnings in {{PD-US-expired}} for other reasons than publication country being US, for example we already have non US template, like {{PD-Polishsymbol}}
--Jarekt (talk) 10:53, 13 May 2019 (UTC)
Is this perhaps an instance of doing both? To me the semantics of saying "disable this warning (reason unspecified)" and "This was published in country X" (which latter has a side effect of disabling the warning, just as it might, for example, populate a category or something) are different and both would be reasonable things to have. For some simple cases we can in effect compute licensing and copyright status based on date of death (|deathyear=) and place of publication and automatically disable some kinds of warnings (or even enable others). Or if we actually know that some kind of non-US license is provided we can automatically disable anything that is meant to encourage adding one. And then we need a static "Don't show the warning" param for all the cases where such cannot be safely determined automatically for whatever reason. --Xover (talk) 07:53, 14 May 2019 (UTC)
That sounds reasonable to me. BMacZero (talk) 17:44, 15 May 2019 (UTC)
  • Symbol support vote.svg Support I complained about this before. It's a stupid warning. If the work is from another country and that additional copyright tag has been provided, the warning also needs to go away. - Alexis Jazz ping plz 06:13, 12 May 2019 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 13:48, 12 May 2019 (UTC)
  • Symbol support vote.svg Support -- Eatcha (Talk-Page ) 18:51, 12 May 2019 (UTC)
  • Symbol support vote.svg Support, this is a good proposal to reduce user confusion. Vulphere 21:59, 12 May 2019 (UTC)
  • Symbol support vote.svg Support, the current situation could instil doubts in cases where the file already is in the public domain for the uploader, things like this may overwhelm newcomers. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:20, 12 May 2019 (UTC)

I've made the edit request at Template talk:PD-US-expired#Add_parameters_to_suppress_the_"U.S._work"_warning. – BMacZero (🗩) 03:55, 18 May 2019 (UTC)

(I intend to follow up with another change to allow a non-US license template to be passed, also suppressing the warning, when I have more time. I'm starting with two new parameters here: hide_us_warning and publication_country. – BMacZero (🗩) 04:04, 18 May 2019 (UTC)

Proposal to allow only Featured Media as Media of the dayEdit

Dear users,

Should we allow only media featured through Featured sound candidates and Featured video candidates as Media of the day ? I guess this will significantly improve the quality of Media of the day and encourage users/creators to focus on Quality and standards ? You please take a look at POTDs and MOTDs, did you noticed any difference ? I believe that this difference is due to the lack of platform like Commons:Featured picture candidates, a Picture of the day has to face our reviewers at the Featured picture candidates, but the same is not happening with the Media of the day. -- Eatcha (Talk-Page ) 18:47, 12 May 2019 (UTC)

Votes (allow only Featured Media as Media of the day)Edit

  • Symbol support vote.svg Support as proposer -- Eatcha (Talk-Page ) 18:56, 12 May 2019 (UTC)
  • Symbol oppose vote.svg Oppose for now. The featured video candidates project was only just started, so there are literally no featured videos at this moment. Once there is a decent collection to choose from, perhaps this will be sensible, but not now. - Alexis Jazz ping plz 12:46, 13 May 2019 (UTC)
  • Symbol oppose vote.svg 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)
  • Symbol oppose vote.svg Oppose May be later, when we have a stock of featured content. Regards, Yann (talk) 15:56, 13 May 2019 (UTC)
  • Time2wait.svg 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)
  • Symbol oppose vote.svg Oppose per Alexis Jazz. Vulphere 10:15, 16 May 2019 (UTC)

Comments (allow only Featured Media as Media of the day)Edit

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 Jazz ping plz 12:43, 13 May 2019 (UTC)
FWIF, the FS was nominated for deletion in 2010 but was kept ( SEE Commons:Deletion requests/Commons:Featured sounds ). At that time it was suggested to be merged with Featured pictures, but it was never done and I guess it can't be done ever. -- Eatcha (Talk-Page ) 14:44, 13 May 2019 (UTC)

Option to extract date from file name in Upload WizardEdit

the video I uploaded doesn't contain EXIF metadata to indicate the time of capturing. Instead it is presented in file name, i.e. XXX_20yymmdd_hhmmss.webm. It's a tedious thing to copy-paste them one by one when uploading. And as far as I can say, imaging equipment also uses similar naming scheme by default. So it might be useful to add such an option. Tomskyhaha (talk) 23:59, 18 May 2019 (UTC) p.s. For splitted video files, the last 3 or 2 characters need to be ignored. eg. yymmdd_hhmmss_01. I suddenly realized that, there are so many variations out there, one might just have to write a JavaScript to achieve such function. Tomskyhaha (talk) 00:04, 19 May 2019 (UTC)

Update the username policyEdit

Replace the section Usernames requiring identification with these paragraphs. It doesn't so much change the existing policy as that it clarifies it. - Alexis Jazz ping plz 14:15, 23 May 2019 (UTC)

Update the username policy: votesEdit

  • Symbol support vote.svg Support as proposer. - Alexis Jazz ping plz 14:15, 23 May 2019 (UTC)

Update the username policy: discussionEdit

Discuss details for this proposal here.