70 Messages
•
1.3K Points
Data correction rejected despite providing screen proof (On-screen credits verification)
Hi IMDb Team,
I am an experienced contributor (submitting data since 2009), and I have encountered a systemic issue where incorrect data, once approved in the database, becomes very difficult to correct through standard forms.
I recently attempted to correct inaccurate release/credit data on two instances, but my initial corrections were declined, and the incorrect information remained.
To resolve this, I have just submitted two new corrections, this time attaching official on-screen credit screenshots as undeniable proof. These submissions are currently pending.
Could an IMDb employee please manually review these pending contributions to ensure they are processed correctly this time?
Here are the pairs for comparison:
Case 1:
- Declined initial correction: Contribution ID: 261013-170505-921000
- New pending attempt with proof: Contribution ID: 261014-072149-121000
Case 2:
- Declined initial correction: Contribution ID: 261013-170541-782000
- New pending attempt with proof: Contribution ID: 261014-072523-069000
Thank you for your help in keeping IMDb data accurate.
DOS
70 Messages
•
1.3K Points
5 hours ago
I have a rhetorical question regarding the platform's verification policy. I have been a dedicated and active contributor since 2009. Over all these years, I have submitted thousands of accurate updates, yet it feels like my long-standing contribution history and reputation mean absolutely nothing to the automated system.
Why is it that when someone submits completely incorrect or unverified data onto an empty page, the system approves it instantly? But the moment an experienced user attempts to fix that obvious mistake, the system treats them with extreme suspicion, automatically declining the correction unless they provide bulletproof on-screen evidence for every single minor detail.
It is incredibly frustrating that trusted users have to jump through hoops and waste time on the forums just to fix bad data that should never have been approved in the first place.
Does IMDb have any plans to introduce a reputation-based trust system for veteran contributors, or are we expected to provide screenshots for the rest of our lives?
Thank you for your time.
0
0
DOS
70 Messages
•
1.3K Points
5 hours ago
https://contribute.imdb.com/contribution/261013-170615-469000 vs https://contribute.imdb.com/contribution/261014-074017-309000
https://contribute.imdb.com/contribution/261013-170709-659000 vs https://contribute.imdb.com/contribution/261014-074352-923000/
(edited)
0
0
DOS
70 Messages
•
1.3K Points
5 hours ago
I have another case of an incorrect data correction that is currently pending review.
Initially, I submitted a correction request, but realized I needed to back it up with official evidence. Therefore, I submitted a second, updated correction for the exact same data, this time attaching an on-screen credit screenshot as proof. Both are currently pending.
Could an IMDb employee please manually review these and approve the second submission (which contains the screenshot proof)?
Here are the contribution IDs for reference:
- Initial submission (pending): 261014-062803-482000
- Updated submission with screenshot proof (pending): 261014-075204-407000
Thank you for your help in keeping the database accurate!
UPADATE:
I recently submitted a credit correction, which was unfortunately declined with the reason "Duplicate" (Contribution ID: 261014-075204-407000).
This is an automated error by the system. The screenshot proof I provided for this submission was indeed used in another recent contribution, but that is because the on-screen credit image contains three different actors' names at once. It is the correct and official proof for all of them.
Since the automated filter flagged it as a duplicate file and declined it, could an IMDb employee please manually review Contribution ID: 261014-075204-407000?
You will see that the attached screenshot clearly verifies the data for this specific person as well.
Thank you for your time and for helping override this automated glitch.
(edited)
1
0