User:Alexis Jazz/Proposal incubator/Proposed

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Currently open proposals: Requests for adminship: Requests for license reviewer:
  • Roy17
  • Was already promoted
  • This is just filler
 Projects that need your help: Ex-proposals:

Create a list for Flickr accounts that require an additional human review

[edit]

Flickr is a rich source of images for us. Because some Flickr users are known for license laundering or have other issues that can't be overcome, Commons created Commons:Questionable Flickr images. Once on this list, tools downright refuse to upload anything from these photographers.

Unfortunately, this list grew to also include many accounts that accidentally uploaded something that doesn't adhere to our rules or that in general make some mistakes while also having good, properly licensed own work within our scope. For an example, look at https://www.flickr.com/photos/numberstumper/291229304/. A perfectly usable and correctly licensed photo of the town hall in Bradford. Can't upload it with any tool, because Paul Stumpr has also taken photos of magazines and a cardboard Fred Flintstone. If this proposal passes, tools should ignore the new list or merely warn the uploader without blocking the upload. FlickreviewR should tag the images for human review while also still providing its own review. (in case the license changes before the human reviewer gets to it) For the accounts that are placed on this list, the admin that adds the account should also provide a description of what the license reviewer needs to look out for with that particular Flickr account. - Alexis Jazz ping plz 23:38, 9 February 2019 (UTC)

Create a list for Flickr accounts that require an additional human review: votes

[edit]

Create a list, independent from Commons:Questionable Flickr images for Flickr accounts that do have properly licensed images that are within our scope but require a human review.

Create a list for Flickr accounts that require an additional human review: discussion

[edit]

Discuss details for this proposal here.

Pinging @Donald Trung, GreenMeansGo, Roy17 whatcha think? - Alexis Jazz ping plz 23:45, 9 February 2019 (UTC)
  • I would  Support this as blacklisting should be a last resort and not a first resort (like Wikipedia's already do with "spam" websites which are useful and educational but get blacklisted because of one assumption of bad faith or incident. A lot of Flickr accounts have thousands of good images with hundreds of bad ones, most importers won't check the blacklist first and excluding good content over trivial reasons that could be handled by a handful of volunteers should not be an option. Post Script: You could copy this comment and any other comment I make to the actual proposals village pump when you're going to present your ideas as I'd rather not "vote" twice. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:46, 10 February 2019 (UTC)
  • Well, we could do a 360 on our recent proposal, and actually re-implement the extended uploader right, but give it the ability to basically override all warnings and errors. It may be the case that even accounts with a long-term problematic history of uploading inappropriate images to Flickr will still upload occasional good images. Even a broken clock is right twice a day. So the solutions wouldn't be to remove them from the list, but to empower experienced users to evaluate images individually. GMGtalk 14:24, 10 February 2019 (UTC)
    • @GreenMeansGo: I'm not convinced that's the best solution. We could allow license reviewers to override the blacklist as those are realistically the only group that could be trusted with this.. But then, why not allow anyone to upload (possibly warn them) and tag the uploads for human license review? In addition.. Even administrators and license reviewers get it wrong every once in a while. Images from Marco Verch seem fine, but they're not, because the community decided they're not. If you are not aware of that discussion you can't detect that, and I've seen some admins and reviewers greenlighting those images after FlickreviewR tagged them as "bad author". Marco Verch needs to be on the blacklist so nobody can accidentically upload his shit. - Alexis Jazz ping plz 17:39, 10 February 2019 (UTC)


Commons:Village pump/Proposals#Allow operation of bots without a permit subject to a set of rules

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

[edit]

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.

- Alexis Jazz ping plz 00:48, 13 February 2019 (UTC)

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

[edit]

Discuss details for this proposal here.

Increase the maximum number of files in UploadWizard

[edit]

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, or even upload to Flickr first and import with Flickr2Commons afterwards, which has no such limit. - Alexis Jazz ping plz 16:33, 5 June 2019 (UTC)

Increase the maximum number of files in UploadWizard for autopatrolled users: votes

[edit]

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.

  •  Support as proposer, no artificial limit needed. - Alexis Jazz ping plz 22:50, 5 June 2019 (UTC)

Increase the maximum number of files in UploadWizard for autoconfirmed users: votes

[edit]

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.

  •  Support as proposer, limit to 200. - Alexis Jazz ping plz 22:50, 5 June 2019 (UTC)

Increase the maximum number of files in UploadWizard for all other users: votes

[edit]

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.

  •  Support as proposer, limit to 200. - Alexis Jazz ping plz 22:50, 5 June 2019 (UTC)

Increase the maximum number of files in UploadWizard: discussion

[edit]

Discuss details for this proposal here.

Create user group 'general maintainer'

[edit]

Some Commons users do a lot of maintenance and other work here, but they may not be interested in becoming an administrator or not deemed suitable by the community.

When it comes to administrators, there are two reasons we can't promote everyone to be an administrator: the community doesn't trust everyone with the mop and for the WMF administrators (to be precise: anyone who can view deleted content) are a legal liability. Being an administrator on a Wikimedia project also carries some legal risk for the administrators themselves because of that.

A general maintainer wouldn't quite be an administrator, but would be given access to various tools. They need to be users who can be trusted not to abuse their tools (similar to, for example, rollbackers), but don't need overly extensive copyright knowledge (like a license reviewer) and the community doesn't need to trust them with sanctioning other users. General maintainer can be a step towards adminship, but doesn't have to be. You also won't have to be a GM to apply for adminship.

A general maintainer could:

  • Move files
  • Delete their own files and revisions (very handy for mass-uploaders who spot a bad file after uploading and map makers who need to delete inaccurate old revisions of maps)
  • Speedy delete abusive uploads (these deletions would always be accompanied by a report on COM:ANB)
  • Hide abusive page revisions (vandalism)
  • Handle G7 requests that fully meet the G7 criteria. (original author or uploader requests deletion of recently created (<7 days) unused content)
  • More easily close-keep DRs as they have DelReqHandler, but by default they should only close DRs that any user would be allowed to close: "Non-admins may close a deletion request as keep if they have a good understanding of the process, and provided the closure is not controversial." (but read more below)
  • Mark others' edits as patrolled (patrol)
  • Not be affected by rate limits for edits, moves, uploads, rollbacks, purges and thumbnail rendering (depending on developer preferences, they may get noratelimit instead, but deletions will be limited to 10 per minute)
  • Not create redirects from source pages when moving pages (suppressredirect)
  • Enable 2FA
  • Edit protected templates (templateeditor)
  • Override the title or username blacklist (tboverride)

Unlike an administrator, a general maintainer can't:

  • Delete more than 10 files per minute
  • Do license reviews (unless they also apply to be a license reviewer)
  • Block users
  • Restore files (undelete)
  • Deal with DRs and copyvios (but read more below)
  • Perform history merging and splitting (this requires undelete)
  • Edit pages protected as "Allow only administrators" (editprotected) and fulfill edit requests
  • Change protection levels and edit cascade-protected pages (protect)
  • Configure Upload Wizard campaigns (upwizcampaigns)
  • Work on abuse filters

Requests to become a general maintainer should be made at Commons:Requests for rights and granting this right to candidates is at the discretion of admins. Obviously, only properly experienced users should be made general maintainers.

To prevent an endless accumulation of GM accounts as people often naturally move on as years pass by, to retain GM status the user should make at least 1 edit per year.

Community approved general maintainer

If a general maintainer also wants to engage in dealing with DRs (including close-deleting them), copyvios, etc (which technically they can), they need a community mandate very much like an RFA. For the community, the bar to support such a request will be lower than the bar to support adminship.

A general maintainer with community approval could, in addition to everything a GM is capable of:

  • Delete more than 10 files per minute
  • Deal with DRs and copyvios
  • Edit pages protected as "Allow only administrators" (editprotected) and fulfill edit requests
  • Change protection levels and edit cascade-protected pages (protect)

- Alexis Jazz ping plz 11:18, 31 January 2019 (UTC)

Create user group 'general maintainer': votes

[edit]
  •  Support as proposer. - Alexis Jazz ping plz 12:01, 11 June 2019 (UTC)

Create user group 'CA general maintainer': votes

[edit]

(we might think of a better name for community approved general maintainers, but that's not really the point)

  •  Support as proposer. - Alexis Jazz ping plz 12:01, 11 June 2019 (UTC)

General maintainers: discussion

[edit]

Discuss details for this proposal here.

  • WIP. The list is too long. Must be simplified. - Alexis Jazz ping plz 11:19, 31 January 2019 (UTC)
  • @GreenMeansGo: now that I think about it, the delete-self proposal above (which should be technically possible, the "reupload-own" right already exists which allows users to overwrite only their own files) may be replaceable by general maintainer. - Alexis Jazz ping plz 14:04, 31 January 2019 (UTC)
  • Commons:Village pump#General maintainers - Alexis Jazz ping plz 21:34, 7 June 2019 (UTC)
  • @4nn1l2: I think this proposal is about ready to go now, it's been reformed a few times. It also includes template editor now, and I stole a line of you somewhere. Do you want me to wait until voting on your proposal has finished or do you think it won't interfere? - Alexis Jazz ping plz 12:01, 11 June 2019 (UTC)
    @Alexis Jazz: I don't think they interfere. At Persian Wikipedia, we have both of them: template editors (of which I am a member) and eliminators [1] (actually 'junior admins' with the official name of Wiki-maintainers!). Eliminators are elected for one year and they have apparently been a boon to admins for clearing backlogs. However, I am not very fond of them, because I believe they could be admins themselves, but the community has been very selective in promoting new admins. 4nn1l2 (talk) 17:57, 11 June 2019 (UTC)
    @4nn1l2: I avoided a name like "junior admin" so nobody would say anything like "oh, you're just a JUNIOR admin". Maintainers maintain, admins block. It's a different thing. I think general maintainer can be a step towards adminship in some cases. Don't forget though, not everybody wants to be an administrator. - Alexis Jazz ping plz 18:36, 11 June 2019 (UTC)
  • Proposed: Commons:Village pump/Proposals#Create user group 'general maintainer' - Alexis Jazz ping plz 18:36, 11 June 2019 (UTC)

WMF-community trust person

[edit]

Following Commons:Village pump#WMF partial bans and Wikimedia Commons and the ban of Fram on enwiki, here's a proposal.

The community will select one or more candidates for this position. Candidates should:

  • Be known to respect privacy
  • Be a highly trusted community member
  • In general preferably not an admin, as admins are more likely to be involved
  • Be reasonably skeptical of the WMF
  • But not outright hate the WMF
  • Not be on WMF's payroll (well doh!!)

The community is allowed to revoke their trust in any candidate at any time.

From the candidates put forward, the WMF selects one. If they select more than one, any additional trust persons will only be used when the primary trust person is unavailable or the primary trust person is involved in the conflict. (this avoids cherry-picking) WMF selected candidates:

  • Are appointed for life. They will have no fear of being "fired" if they say the WMF did something unreasonable.
  • Will not share any identifying information about the accuser.
  • Will be given all the diffs and other reasons that resulted in the ban of a community member.
  • Doesn't have to be told who the accuser(s) are, but this information may or may not be inseparable from the ban rationale.

Note that a NDA may not be desirable, or even legally sufficient. If the accuser(s) agree to have the required information shared with the WMF-community trust person, there will be no legal issues. The accuser should be very motivated to agree to this, because if they don't the WMF will ban someone for seemingly no reason which, as we've seen with Fram, may well result in a pitchfork-wielding mob.

Procedure:

  • The accuser(s) will be asked to agree to the sharing of necessary information with the WMF-community trust person. If they don't, well, pitchfork-wielding mob.
  • The WMF shares the full ban rationale with the WMF-community trust person.
  • This person drafts a statement.
  • The WMF reviews this statement and redacts identifying information if needed.
  • If the statement is redacted, the WMF-community trust person will be given an opportunity to alter the statement. This may go back-and-forth between the trust person and the WMF a few times times if needed.
  • If no agreement can be reached or the WMF-community trust person agrees to the redacting of the statement, the redacted statement will be used. The redacting must be visible, for example: "This is when *REDACTED* contacted the.."
  • Along with the ban notice (unless time does not allow that, in which case the statement will be released later), the WMF releases the statement on-wiki. WMF also states the number of accusers that were involved and the number that agreed to share information with the WMF-community trust person.
  • The WMF-community trust person confirms this was their statement and no non-identifying information has been redacted.

In addition:

  • If all the accusers agreed to have information shared with the WMF-community trust person and after the statement has been published some community members still start to speculate about the identity of the accusers, those users will be warned (if they were plausibly unaware such speculation is not allowed) or locally blocked for up to one month by a local admin. If overlooked, the WMF will report the user to the local admins.

Please comment. - Alexis Jazz ping plz 20:47, 21 June 2019 (UTC)

WMF-community trust person: discussion

[edit]

Discuss details for this proposal here.

  • @Donald Trung: quick draft. - Alexis Jazz ping plz 20:49, 21 June 2019 (UTC)
    • @Alexis Jazz: I like it, however I must say that in my original post (which was poorly worded due to my general lack of time (and sleep) lately) I wished to placed some certain responsibilities on the WMF Office to notify the community in the village pump and make a list on the users they've banned. A middle (wo)man in this regard can share to the community why the ban was made and while I must admit that the Wikimedia Foundation has a huge issue with communicating.
    • generally speaking I think that WMF partial bans (if not indefinite) are a good alternative to the permanent WMF global bans, but we should impose scrutiny and the ability to scrutinise the Wikimedia Foundation on it. A more specific reaction to this proposal is that community trust can be taken away, which is a must, but it also opens up "mob justice", let's say that Fæ would get WMF partial banned today for unknown reasons (I am using them as an example because they are openly critical of the WMF's office actions and is the most active Commonswiki contributor) and the WMF-community trust person will just forward what the WMF told them, they could be "crucified" by the mob because they want a better outcome, or the WMF-community trust person could become the target of community outrage rather than the WMF themselves. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:45, 21 June 2019 (UTC)
  • Not really proposed but whatever: m:Requests for comment/WMF-community trust person. - Alexis Jazz ping plz 22:43, 22 June 2019 (UTC)

Enable Flickr uploads (upload_by_url) for more users

[edit]

Following the previous proposal, let's see if there is support to allow additional user groups to use the Flickr upload feature in UploadWizard. Currently, users who are not autopatrolled either use Flickr2Commons or they cause problems when trying to upload by hand. Copy-pasting the wrong source link, accidentally upload thumbnails, directly uploading crops without the originals, things like that. License reviewers are left to clean up the mess. UploadWizard can take care of many of these issues as it automatically inserts the correct information. - Alexis Jazz ping plz 16:14, 5 June 2019 (UTC)

Enable Flickr uploads (upload_by_url) for autoconfirmed users: votes

[edit]

Enable upload_by_url for autoconfirmed users. If your support depends on ratelimiting this group, include the maximum number of uploads per minute for your support.

  •  Support as proposer. - Alexis Jazz ping plz 16:17, 5 June 2019 (UTC)
  •  Support, the democratisation of Wikimedia Commons is here! We should place functionality front and centre and not hide it behind user rights. Someone who mostly edits Wikipedia and finds an amazing photoshoot in a museum on Flickr released with a compatible license who doesn't know that Flickr2Commons exists and doesn't look at Wikimedia Commons beyond the MediaWiki Upload Wizard and the images they published will never upload it. We should work to maximise content creation and the MWUW already knows how to prevent Flickr uploads with incompatible licenses. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:33, 10 June 2019 (UTC)

Enable Flickr uploads (upload_by_url) for all users: votes

[edit]

Enable upload_by_url for all users. (see "(all)" on Special:ListGroupRights) If your support depends on ratelimiting this group, include the maximum number of uploads per minute for your support.

  •  Support as proposer, ratelimited to 4 uploads per minute. Enough for a user who only comes here to upload or import a few images for an article. - Alexis Jazz ping plz 16:17, 5 June 2019 (UTC)
  •  Support, see comment above. Most Wikipedians don't care about Wikimedia Commons and its intricacies, they just want to upload high quality images to place inside of their articles and we should help them be more productive. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:35, 10 June 2019 (UTC)

Enable Flickr uploads (upload_by_url) for more users: discussion

[edit]

Discuss details for this proposal here.

Acceptance of files from external sources without a license review

[edit]

We have an endless number of files from external sources without a license review. Many have been around for many years, many of the links died. Thanks to Donald Trung's proposal to archive all external links, this shouldn't be a common sight anymore from now on. But we still have all those old files that were never reviewed. Deleting everything makes no sense. Pretending license reviews are not needed makes no sense. This proposal does not apply to files without a source, a source that still works or a source that can be checked through archive.org or similar means.

Proposal to keep files with a source that is no longer available and that:

was uploaded by a former or current license reviewer, administrator or OTRS-member

or

matches all of the following:
  • Has a similar or identical source to files with a license review or uploaded by the groups above (for "example.com/gallery1", "example.com/gallery2" would be similar)
  • Matches the general style of those files. Locations, subjects, time period, photography/art style, EXIF if present, watermarks. Not every single thing needs to match, but we should be convinced the work is from the same source.
  • Comes from a source with a general waiver or license (no exclusion of specific files, or only exclusion based on criteria that we can tell without having the source available, for example: "the license only applies to photos taken in Italy")
  • Uploaded by a user who is not known for copyfraud.

These files will be marked as "This file was uploaded by a trusted user" and won't require a license review. - Alexis Jazz ping plz 17:41, 13 February 2019 (UTC)

Acceptance of files from external sources without a license review: discussion

[edit]

Discuss details for this proposal here.

@Fæ: I know you made a similar proposal not too long ago. Any comment? - Alexis Jazz ping plz 17:45, 13 February 2019 (UTC)
I've been following File:31i-US-2 (警察との共同訓練（緊急輸送訓練）) R 教育訓練等 53.jpg. It's too difficult or simply impossible to verify old linkrots like this. I will support a resolution to relax a bit on linkrot files that meet the following criteria: 1. well-known/large-scale linkrot like picasa, lasvegasvegas, farsnews, etc.; 2. uploaded a long time (3 years?) ago. Such files should not be deleted for the vague no source/no permission/... Only credible claims of copyright issues (the photographer can be identified, an external copy can be found, or a complaint is made...) can lead to deletion by DR.--Roy17 (talk) 14:07, 17 February 2019 (UTC)
@Roy17: Category:Chama Ice Cave from farsnews was uploaded in December 2018. For that reason, I didn't include a fixed time period like 3 years because nobody can predict linkrot. - Alexis Jazz ping plz 17:20, 17 February 2019 (UTC)
  • I would  Support this as I had supported the original proposal by Fæ, if my proposal gets accepted this proposal will probably not be needed for newer files as they'll have archived external links, but as this practice hasn't been adopted yet many links have become useless. Though all these users most certainly aren't perfect, it beats deletion. I still think that we should've utilised the Internet Archive Bot years ago. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:42, 17 February 2019 (UTC)
    • @Donald Trung: Good point, that's why I have an incubator. I'm going to wait for your proposal to pass. After that, this will be more of a "grandfathering" proposal, which I think is more likely to be accepted. Fæ's proposal was too specific and not really worked out. Fæ said to "vote on the principle", but that's generally not what VPP is for. - Alexis Jazz ping plz 21:02, 17 February 2019 (UTC)
  • This looks reasonable. Yann (talk) 04:21, 22 February 2019 (UTC)

Acceptance of files from external sources without a license review

[edit]

proposed

Rehash of this one-year old proposal with changes made to ease the opposition.

We have an endless number of files from external sources without a license review. Many have been around for many years, many of the links died. Thanks to Donald Trung's proposal to archive all external links, this shouldn't be a common sight anymore from now on. But we still have all those old files that were never reviewed. Deleting everything makes no sense. Pretending license reviews are not needed makes no sense. This proposal does not apply to files without a source. Applying it to files with a source that still works, can be fixed or a source that can be checked through archive.org or similar means is discouraged. When such files are found they should be upgraded to a license review.

Proposal to keep files with a source that is no longer available and that:

was uploaded by a former or current license reviewer, administrator or OTRS-member and there is no indication that the file did not originate from the indicated source and there is no reason to suspect that the file is not properly licensed.

or

matches all of the following:
  • Has a similar or identical source to files with a license review or uploaded by the groups above (for "example.com/gallery1", "example.com/gallery2" would be similar)
  • Matches the general style of those files. Locations, subjects, time period, photography/art style, EXIF if present, watermarks. Not every single thing needs to match, but we should be convinced the work is from the same source.
  • There is no indication that the file did not originate from the indicated source and there is no reason to suspect that the file is not properly licensed.
  • Comes from a source with a general waiver/license (no exclusion of specific files, or only exclusion based on criteria that we can tell without having the source available, for example: "the license only applies to photos taken in Italy") or the license is embedded in the file (for example in the end credits of a video or EXIF)
  • Uploaded by a human user (not bot) who was not known for engaging in copyfraud in the time period of the upload.

or (fallback in case the conditions above can't technically be met)

the community is convinced the file in question came from the indicated source and is properly licensed

These files will be marked as "This file was uploaded from a trusted source" (or similar), won't require a license review and any "no source" tagging on these is automatically invalid. This proposal does not override COM:PRP, COM:SCOPE and similar relevant policies.

Examples of general waivers/licenses:

  • A weblog with a license that applies to the whole weblog, for example lasvegasvegas.com. (now defunct)
  • A website with a license that applies to all users, for example Skitterphoto.
  • An account (where the account can be told from the source url) where a license tag applies to all files from that account. For example {{PD-CAGov}} for https://www.flickr.com/photos/californiadfg/ or a Flickr account that states on its "about" page that all their photos are freely licensed.

Which means no:

  • Flickr and YouTube accounts for which there is no license tag that could be applied to all files from that account. Even if the account is generally known to tag all their files as Creative Commons: it is possible (and it happens) that an account will omit some files for whatever reason.

Main changes that were made compared to the previous proposal:

  • This type of tagging is merely discouraged instead of forbidden for uploads that do have a valid source. It may be impractical to check thousands of files just in case archive.org catched 1 or 2 of them. When found, such files should be "upgraded" to a regular license review.
  • Bot uploads are not (automatically) covered. (this was added for BevinKacon) This may still be used as a guideline when judging such uploads, but the community has to discuss this on a case-by-case basis.
  • "not known for copyfraud" changed to "who was not known for engaging in copyfraud in the time period of the upload". If a user engages in copyfraud later this doesn't affect the status.
  • Source examples added.
  • Also allow files with embedded license from sites without a general waiver.
  • Fallback added.

Hopefully more luck this time. - Alexis Jazz ping plz 19:15, 21 February 2020 (UTC)

Comments

[edit]
I think it looks good. I suggest we add:
"and there is no indication that the file(s) in question did not from the indicated source and there is no reason to suspect that the file is not properly licensed."
to grey box 1 and 2. It should be obvious but it is to make it very clear that the template should not be added if reviewer think that something looks wrong.
Also we could add that the template does not prevent deletions of files that are out of scope.
As a last comment we could add in the intro that it is not meant for sources where the link works "or can be fixed" or ... --MGA73 (talk) 20:30, 21 February 2020 (UTC)
Done. - Alexis Jazz ping plz 20:54, 21 February 2020 (UTC)
I found this DR today Commons:Deletion requests/File:Tirumala natural stone arch.jpg. --MGA73 (talk) 21:56, 22 February 2020 (UTC)
@MGA73: that's about grandfathering. The proposal above is actually not a grandfathering proposal, there's no time limit. Because you never know when linkrot may occur. The files from Category:Chama Ice Cave became unavailable after just 2 months or so. (only saved after some digging at Commons:Village pump/Archive/2019/02#License reviewers and admins help is needed ASAP) - Alexis Jazz ping plz 01:18, 23 February 2020 (UTC)
@Alexis Jazz: I think it is partly a grandfathering proposal. Because if someone upload a file and a reviewer tries to review it 1 hr or 1 day later and find that the link does not work then we add a no source and if the license is unfree we add a no permission. But if a reviewer tries to review a 5 yr old file then no source and no permission is not a good solution. Anyway what we are discussing is if there are cases where we should keep a file where we can't verify the source and license for some reasons. The link I provided is an example of a file where a DR ended as keep. I just thought it could be handy to mention that as an example of a file where the template could perhaps be added. --MGA73 (talk) 09:35, 23 February 2020 (UTC)
@MGA73: ah, yes. But actually it could apply to your 1 hour case, but it wouldn't be a common sight. If someone uploaded a photo from Tasnim and 1 hour later Tasnim as a whole is shut down and those specific photos weren't archived on archive.org, this proposal could apply. It's unlikely (the chances of archive.org having it are bigger now and Google/Bing/Yandex cache may also have it after such a short time) but technically it could happen. - Alexis Jazz ping plz 18:00, 23 February 2020 (UTC)
@Alexis Jazz: Yes it could apply but I think we would need strong supporting evidence to keep files after just 1 hr. I think most reviewers would add a no source or no permission it those cases. If we suggest that the template should also be used after 1 hr then I think many users would oppose. --MGA73 (talk) 18:07, 23 February 2020 (UTC)
@MGA73: it would be rare: there would have to be reason to believe the link was actually working an hour ago and it wasn't taken down because of licensing issues. And it would have to be an upload by a license reviewer/admin/etc. or match all the stuff from the second box. It would be very, very uncommon. - Alexis Jazz ping plz 18:35, 23 February 2020 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=User:Alexis_Jazz/Proposal_incubator/Proposed&oldid=400055132"