Top 300 Contributor Leaderboard for January 2022

@Will​  Thanks Will and thanks for running this program. 

I did better than expected, mostly via cast lists and plot keywords for movies I watched at the (virtual) Sundance Film Festival (normally I am big IMDb Answers contributor). 

Thanks Col for the support! Sundance to the rescue ;)

@Will​ Thanks for your updates. Always a good time reading the leaderboards.

@don_30lej8zccspy3​ Don't stop believing, and keep up the good work!

@adrian​ I did. I was using a crawler script to download all images for a series from an Arabic database similar to IMDB, and another script to batch upload them on the series' page on IMDB.
But it freezes my pc when the script is running so I stopped using it.
There are tons of data on Arabic/Indian/East-Asian sites that are missing on IMDB so automating the process may be useful to catch up with regional databases!

@DayoEnor​ 

The problem is that no one checks the accuracy of this data before (or likely after) it is entered.

@adrian​ Me too, but it wasn't the drop that bothered me as much as everything I submitted went into pending for a week or longer and I ended up having to stop contributing for over a week as I couldn't continue due to that so IMDb lost around 1500 contributions I would've made. I've no real problem with people that are doing it right now but my worry with the bots is two fold, one what will happen when bad actors get into the game and flood the site with nonsense, and also is this mass submitting what's clogging up the system, I've never seen as many pending submissions on the site as I have this year so far and I've never had to wait an entire week for the casts of mainstream US shows to be approved before, if this is the case, I hope IMDb is doing everything they can mitigate it.
I always believed one day in the future, IMDb would use it's own bots to fill out everything without need for contributors, so I'm not against bots or any users but if it's knackering or damaging to IMDb then I'm not happy about it.
I hope somebody on staff can put my mind to rest on the situation.

@adrian​ 

@Col_Needham 😀

??

Why don't TV & Movie Producers
send IMDb Staff an official, accurate, and complete list
of who's who for latest project
Paid staff can add this
or have some studio secretary add the data directly as a non paid contributor

These Producers must be looking for information here for future projects ??

.

@muzili​ The reason one person can make that many contributions is that we use automated scripts that uploads vast amounts of data at once. Instead of doing it all manually. I use API's to gather data on podcasts, series and episodes. Then upload it, this process is much faster that doing it manually and makes me able to contribute such large numbers. (Approx 216.000 /12h, if I let it run consecutively and have unuploaded data) I hope that answered your question, don't be a stranger if you have any other questions.

Yep, I assumed it but how trustable uploading non-processed data? And this case why we are on the same leaderboard race, I mean isn't it supposed to be a separate leaderboard? Otherwise, the leaderboard loses the purpose of a friendly race concept.

@muzili​ The data is trustable in the sense that it is directly from the source. An example of this is me using the NRK api (Norwegian State Television) and upload their series, episodes and podcasts. All the data provided in the API is 100% correct, and more accurate than what a user would be able to fetch manually. I started out doing it all manually, but found myself doing things wrongly from time to time, causing issues for myself and others. The percentage of mistakes is lowered to almost zero. And it is done automatically. I would also like to point out that making my program has taken a lot of hours, and that people automating contributions also put in the hours to get things on the road. However, once the program is done the efficiency is extremely high.

(Upfront work high, but once you complete the program it lives its own life. Example: If I stopped lifting a finger from this day on I could expect to contribute between 90.000-120.000 each month. This figure would drop as time went past and the series and podcasts I track die out, but still a sizeable amount)

Sounds like good resource and good api :D

@EvanD71​ i agree with you. The guy who at #1(Nomissimon10) is already guaranteed 2022's top #1-5 contributor for the year 2022. And it's only January. How are we supposed to friendly race? I mean it's something like we're on a running race and he is using a motorbike or jet fighter.

@EvanD71​ This could be a good idea, only issue is that it could be hard to differentiate between someone who is contributing automatically from someone who is doing it manually. And if you would want to find out IMDb staff would either have to spend a lot of time sending out mails and queries finding out who did do it automatically and who did not, and who is to say that my profile is used by a collective uploading on one account to get a joint recognition every month? I personally don't hide the fact that I am doing it with an automation script I have made, and would have no issue being placed on a different leaderboard in the same post. However, it could become more of a hassle for the IMDb staff than what good it does.

I hope I got my point across, and once again underlining that I would have no issue being put in a different leaderboard for people using automation. And I completely understand your questioning of why it is not done, all people that end up on the leaderboard deserve a callout for the great work they all put in. And I am sure there are many people just on the edge of getting recognition that put in a lot of time just like the rest of the 300 top contributors.

@Nomissimon10​ yep, we don't have a problem either. And about noticing who uses automation I think IMDb can detect it by using cookies. Who uses API or they auto-calculate the average contribution per minute.

@Nomissimon10​ I also have no issue with automated contributions. As long as the data gets uploaded, we are achieving the same end result. :-)

Obviously a manual contribution is both tedious and time-consuming (pause a recording... or sneakily take a photo of the credits in a cinema..., type each name and character, etc) and deserves its own recognition.

@EvanD71​ yes kinda but this is a thing IMDb stuff should think and decide. Even if we have positive agree or negative agree it's nothing but a dead end.

@EvanD71​ @muzili Yeah, I completely get it. (That you don't have a problem with me, but the fact that it could come off as unfair) And contributing manually definitely is a tideous process. I have been there myself, and found myself in the situation where I spent a lot of time contributing manually. The thing is that we programmers are lazy, and if there is a repeating process we can make it go automatically.

@muzili​ Also, no, cookies can't be used. The programmer can just set the version of browser, type of browser, cookies and other things that would obfuscate that. A calculation of contributions per minute might also not favour collectives of people contributing because they would be multiple people doing stuff at the same time. And a rate of uploads can just be set by the contributor.

Just to note, some of the cookies directly pertain to being logged into the system, and there is no access privilege to the submission form for client hosts that represent unregistered or logged-out persons. Thus the matter of the cookies being used for tracking purposes is a given, an irrelevant given. On the server-side, it will always be clear how many submissions are derived form a particular IMDb user account, and how quickly, but it won't necessarily be easy to determine whether automation has been involved, multiple human beings using the same account or neither. Although, some of the cookies IMDb assigns are "tab-related" for lack of a better description, as they change values with every page visit, so there might be a way to tell if two separate computer systems are simultaneously logged into the same account.