Samsara
Before you delete media as identical, consider whether they have been altered. Usually, they will have "edit", "cropped", "enhanced" or similar in the filename and/or a {{Retouched}} tag. Either one of those should be a big hint to you.
Before you post about copyvio, consider whether I uploaded the original image or my image is a derivative work of another image uploaded to Commons. If the latter, go blame the original uploader for the copyvio, not me. Also, if I transferred the image from some other wiki, go find and blame the original uploader.
In a nutshell, think before you act. Thank you.
White Balancing
In the future, would you mind waiting to do white balancing and such until after the Flickr review bot has confirmed the license on the picture? Thanks, Elisfkc (talk) 18:21, 12 December 2016 (UTC)
- I don't understand the logic of this. If I upload with Flickr2Commons, which I assume rejects inappropriately licensed images, then where does the problem with confirming the license arise from? I'm fine waiting, but I find it rather puzzling that this should be necessary. Makes no sense to me. Samsara (talk) 18:33, 12 December 2016 (UTC)
- Samsara, as the bot is not human, it will complete the review only if the source and what uploaded here perfectly matches. Otherwise it will tag the file for a human review, which takes much time to complete. And chances that the human reviewer revert the edit and send it back to the bot for review. Usually the bot will process the review within hours; so worth to wait for it. Note that Flickr2Commons and Flickr review bot are different; only the latter is approved for a bot review. Jee 01:26, 13 December 2016 (UTC)
- I knew all that. I'm asking why. That's what doesn't make sense. The bot doesn't, in my opinion, work very well. If it's true that Flickr2Commons checks the license before upload, the bot must be updated to not balk at those uploads. Unfortunately, the bot page doesn't even state who runs it. Is that common practice? Samsara (talk) 07:37, 13 December 2016 (UTC)
- Now it is User:FlickreviewR 2 by Zhuyifei1999. Jee 08:08, 13 December 2016 (UTC)
- Thanks - I believe the above will serve a ping. Samsara (talk) 08:10, 13 December 2016 (UTC)
- Sorry but Flickr2Commons is a mostly client-side program, meaning the license checking is done on the user browser (list, check). Any random person with sufficient knowledge in front-end coding can cheat the system and upload any arbitrary image from flickr using the tool, whether the image is free or not, completely bypassing the point of Flickr reviewing. Therefore, FlickreviewR cannot just coded to trust Flick2Commons images blindly. (This is similar to the UploadWizard case, where the functionality is not given to any random user for the very same reason.) --Zhuyifei1999 (talk) 10:28, 13 December 2016 (UTC)
- Okay, I can see the problem with code manipulation on the client side. But I can also make the case that once an image is uploaded, I can upload any image over the top and it will not affect the license tag or FlickrReviewer certification. So why it should matter whether a retouched version is uploaded after or before FlickrReviewer visits is still a mystery to anyone who expects things to "just work". More to the point, what is the programming logic that makes it fail in the case alluded to by the OP? Samsara (talk) 10:48, 13 December 2016 (UTC)
- Well, I would hope everything should "just work", except "just work" usually difficult. The bot logic on this is quite simple: if the file is different from Flickr's in every single size, refuse to review it automatically, and put the file into manual review queue instead. By different I mean different binary-ly, as in any byte change in the file itself will make the file different --Zhuyifei1999 (talk) 14:10, 13 December 2016 (UTC)
- Right, so why can't it use the first version of the file that was uploaded for the comparison? Samsara (talk) 14:21, 13 December 2016 (UTC)
- More importantly, if you need to download the file all over again, why don't we have one tool that does both things? I mean, maybe we do? When I looked at the COM:Flickr page, it seemed to be heavily biased in favour of Flickr2Commons... Samsara (talk) 14:24, 13 December 2016 (UTC)
- Well, the current algorithm attempts to find the matching on flickr by comparing the image dimensions, then comparing the file size and finally the hash (which reflects the binary data) if necessary. If it have to do this for each one in file upload history, it'll make things more complex.
- Btw: I just read the code again. It doesn't even download the file from commons to get the information; instead, it simply get everything from the API. But some of these data simply does not exist for old versions, requiring the bot to download the files itself and making things much slower. (The bot is kind of overloaded already when batch uploader do their work)
- As for a unified tool, well, maybe I'm wrong, but I still find a tool and a bot different. A tool has an interface for users to ease the transfer of the files, but the bot does the post-processing of files from all kinds of sources. Perhaps the tool can do some of the work of the bot, but in the currently, it cannot, as explained above (code manipulation), unless it is written in some other ways in the future --Zhuyifei1999 (talk) 16:33, 13 December 2016 (UTC)
- Yes - a tool that does more things on the server side. It's just that I've realised over the last 24 hours that "waiting", as the OP suggested, doesn't work particularly well for me. I'd have to completely change my workflow and have a "waiting" folder on the desktop for my edits, and then hope I don't forget to upload those items. So I guess I do mind waiting, but if the result is that I'll be requested to wait, I guess I won't be uploading. It would be nice if people could be flexible and understand that some of us are trying to achieve a certain level of quality in our contributions, and that a poorly white balanced image is not acceptable and needs fixing, not waiting. In the end, I guess what I'm saying is that if I have to sacrifice quality or change my workflow to be slower, then I might prefer to spend my time in other ways. Samsara (talk) 17:02, 13 December 2016 (UTC)
- Well, I would hope everything should "just work", except "just work" usually difficult. The bot logic on this is quite simple: if the file is different from Flickr's in every single size, refuse to review it automatically, and put the file into manual review queue instead. By different I mean different binary-ly, as in any byte change in the file itself will make the file different --Zhuyifei1999 (talk) 14:10, 13 December 2016 (UTC)
- Okay, I can see the problem with code manipulation on the client side. But I can also make the case that once an image is uploaded, I can upload any image over the top and it will not affect the license tag or FlickrReviewer certification. So why it should matter whether a retouched version is uploaded after or before FlickrReviewer visits is still a mystery to anyone who expects things to "just work". More to the point, what is the programming logic that makes it fail in the case alluded to by the OP? Samsara (talk) 10:48, 13 December 2016 (UTC)
- Sorry but Flickr2Commons is a mostly client-side program, meaning the license checking is done on the user browser (list, check). Any random person with sufficient knowledge in front-end coding can cheat the system and upload any arbitrary image from flickr using the tool, whether the image is free or not, completely bypassing the point of Flickr reviewing. Therefore, FlickreviewR cannot just coded to trust Flick2Commons images blindly. (This is similar to the UploadWizard case, where the functionality is not given to any random user for the very same reason.) --Zhuyifei1999 (talk) 10:28, 13 December 2016 (UTC)
- Thanks - I believe the above will serve a ping. Samsara (talk) 08:10, 13 December 2016 (UTC)
- Now it is User:FlickreviewR 2 by Zhuyifei1999. Jee 08:08, 13 December 2016 (UTC)
- I knew all that. I'm asking why. That's what doesn't make sense. The bot doesn't, in my opinion, work very well. If it's true that Flickr2Commons checks the license before upload, the bot must be updated to not balk at those uploads. Unfortunately, the bot page doesn't even state who runs it. Is that common practice? Samsara (talk) 07:37, 13 December 2016 (UTC)
- Samsara, as the bot is not human, it will complete the review only if the source and what uploaded here perfectly matches. Otherwise it will tag the file for a human review, which takes much time to complete. And chances that the human reviewer revert the edit and send it back to the bot for review. Usually the bot will process the review within hours; so worth to wait for it. Note that Flickr2Commons and Flickr review bot are different; only the latter is approved for a bot review. Jee 01:26, 13 December 2016 (UTC)
- Samsara, another option for you is to apply for a license reviewer right. I think it is fine as you're an experience admin in EN and working on media too. A license reviewer can upload directly from the URL and I think it doesn't require a review. I may wrong as I don't remember it correctly. Jee 17:13, 13 December 2016 (UTC)
- Thanks, Jee. Upon your suggestion, I looked at that, and it seems that one is not meant to review one's own uploads: Please note that as of 21 February 2012, image-reviewers may not review their own uploads [...] Source: Commons:License review#Instructions for reviewers. It probably changed since you last looked at it. Regards, Samsara (talk) 17:40, 13 December 2016 (UTC)
- I know that it not that I'm talking about. upload directly from the URL is a special feature only available to admins and license reviewers. So they don't need to depend Flick2Commons for their uploads. Jee 02:28, 14 December 2016 (UTC)
- Thanks for clarifying. I added a request. We'll see what happens. Best regards, Samsara (talk) 10:01, 14 December 2016 (UTC)
- I know that it not that I'm talking about. upload directly from the URL is a special feature only available to admins and license reviewers. So they don't need to depend Flick2Commons for their uploads. Jee 02:28, 14 December 2016 (UTC)
- Thanks, Jee. Upon your suggestion, I looked at that, and it seems that one is not meant to review one's own uploads: Please note that as of 21 February 2012, image-reviewers may not review their own uploads [...] Source: Commons:License review#Instructions for reviewers. It probably changed since you last looked at it. Regards, Samsara (talk) 17:40, 13 December 2016 (UTC)
Autopatrol given
Hello. I just wanted to let you know that I have granted autopatrol rights to your account; the reason for this is that I believe you are sufficiently trustworthy and experienced to have your contributions automatically marked as "reviewed". This has no effect on your editing, it is simply intended to make it easier for users that are monitoring Recent changes or Recent uploads to find unproductive edits amidst the productive ones like yours. In addition, the Flickr upload feature and an increased number of batch-uploads in UploadWizard, uploading of freely licensed MP3 files, overwriting files uploaded by others and an increased limit for page renames per minute are now available to you. Thank you. Zhuyifei1999 (talk) 14:16, 13 December 2016 (UTC)
- Thank you. Samsara (talk) 16:57, 13 December 2016 (UTC)
Your talk page header
It was not my intent to 'misrepresent' your talk page header. Instead, take it as a strong hint that your intended meaning is easily misunderstood. You seem to be saying that you are not responsible for the actual copyright status of files that you transfer to Commons. If so, that is simply wrong. You are responsible for exercising due diligence when transferring files. Reventtalk 12:30, 14 December 2016 (UTC)