Why does Robert Minkoff's filmography consist of playing the same uncredited character of Bit in everything?

On a side note, I'm disappointed by how often the IMDb company declines to provide reasons for anything pertaining to the IMDb website. A lot of times, it is not necessarily that hard to provide an explanation. Now, if only we could be provided an analysis as to why the approved new genres cannot be implemented, that would be great and reasonable.

The Wayback Machine shows Robert Minkoff's uncredited credits were added around ten years ago (his page May 2010). I don't think the uncredited guidelines were very different then. Here they are from January 2011, with the same note as today: "Submissions with an empty character field or with descriptions like "lead", "supporting", "featured", "background", "extra" or "bit-part" will automatically be discarded."

I found that he is also not credited in Four Friends (1981) and added the uncredited attribute. I could probably have deleted the credit, but I'll see if there is a conclusion to this thread.

Wow, Peter. Well, that sure is cause to believe that the vague character descriptions submissions slipped through somehow, but from a pedantic standpoint, it is within the realm of possibility that "bit" was interpreted as being different from "bit part", despite carrying the same meaning.

@jeorj_euler  I agree that we could do better here. The reasons for not providing reasons (!!) are a combination of factors, including: there are plans in progress to address the issue so we would rather spend the time fixing it than explaining it; the reported issue is a surprise to us and we need to think about how / whether to fix it in the future; the issue is contained within a software component which is scheduled to be replaced or retired so it will disappear soon enough; the issue is small enough / rare enough that we do not consider it worth addressing; or the issue is much more complex below the surface than customers might expect, so addressing it is going to take significant time or larger changes before it can be fixed.  This all leads to the bigger picture which experience has taught us — not to pre-announce or promise too much in specific timing because customer needs, or the world, or our plans, or the technology can change before we get to delivering the promised solution. 

As to new genres ... first, yes, this is indeed embarrassing and I wish it had been simpler to deploy them.  Between the first genre expansion and the second, technology changed and complexity increased.  It is not as easy to launch new genres as it should be because of entanglements between different IMDb systems.  Originally we could update a couple of systems in/behind the www.imdb.com site and we would be done. Now we have the main site, the mobile site, the iPhone app, the iPad app, the Android app, the IMDbPro site, the IMDbPro mobile site, the IMDbPro mobile app, multiple language translations behind all of the above, the systems used for our licensing business, the data we share with Amazon systems which drive experiences on Amazon, on Fire TV and on Alexa and more.  Some of those are shared systems, but not all of them are, and the effects of a change cannot always be known in advance due to the distance between where the data is stored vs. where it is presented to customers. For example, if a data change (like a new genre) is made in IMDb’s core data store and we discover a week later that this change is causing Android app crashes for customers in Portugal, then getting a new version approved and distributed to those customers is not just not as easy as instantly changing the config of one web site back in 2009.  We are addressing this behind-the-scenes with new technology, simplifications and cleaner APIs and we are improving week by week, but it is still a long journey.  For example, the new IMDb title pages which are currently in beta are based on a new technology platform which eliminates the need for a separate mobile site and has components already being used by our mobile apps, and with a much cleaner API.  We are heading back to a world in which a new genre is one config change (and a few language translations). 

The other issue with new genres is that we already have a very flexible plot keywords system which is always easy to extend.  There are few things that genres can do which are not already covered by plot-keywords; maybe not quite as visible / convenient, but equally not (yet) worth the effort and risk of turning some of them into genres for the reasons explained above. 

Hope this helps. 

Alright, Col Needham. I'm glad to hear from you, and I appreciate you taking the time to provide more analysis. Thank you.

I also appreciate the very thorough explanation.  Some of us (definitely myself) lose sight of just how many platforms IMDb runs on and that many of these changes/improvements are not nearly as easy to implement as we think they are.  I personally loathe the IMDb app on Android and would love an easier & cleaner API. Looking forward to what the future holds. 

Thanks a bunch for your reply Col! It's appreciated.

That being said, it's a very common frustration among contributors that there's a lack of communication. I think this has been a problem ever since Jon Reeves left, about ten years ago. Anyway, since you mentioned the new genres, I think this post shows that quite some people would like some more background/response on matters: https://community-imdb.sprinklr.com/conversations/data-issues-policy-discussions/implementation-of-new-genres/5f4a7a638815453dbaa6da98

Apart from that, IMDb doesn't read all messages of their contributors and doesn't respond to everything (a fact that would probably get me fired from my job if I'd do that). On several occasions I've had to create a second post because the first one didn't get a reply. This thread might be of interest here: https://community-imdb.sprinklr.com/conversations/data-issues-policy-discussions/i-dont-know-any-jokes-about-respect/600dd1eb90c13179fb16fec1

Posts like these of yours are really appreciated, but it always seems like a bit of a clean-up after the fact: too little too late so to speak. I personally feel like every post I make is hit or miss when it comes to getting a response from IMDb. I should not feel that way, but yet I do. It obviously doesn't help that I've bumped over a hundred posts over the years...

Thanks @marco 

I have reposted my comments on new genres on the other thread as suggested, thanks.

I will share your note with the appropriate team members on Monday to see what can be done. We certainly intend to read all messages and act upon them wherever appropriate, however, there are a few things which might be behind the valid issues you raised here.  Whatever those reasons, the end result you have described should not be the case and we need to do better. 

Thanks @Col_Needham for reposting your comment in the other thread. And of course thanks for discussing this. That said, I *think* what is needed is a function kinda like Jon Reeves had. That way, both IMDb staff members as well as contributors know that there is someone who reads everything and responds to issues and, every now and again, shares a little background information.

Last but not least, I want to make clear (as I did here https://community-imdb.sprinklr.com/conversations/data-issues-policy-discussions/i-dont-know-any-jokes-about-respect/600dd1eb90c13179fb16fec1?commentId=6011a5e3f17c3c28b43c9c2a&replyId=6019c90ba60d18737248637d ) that I think all contributors know you guys have a lot of work on your plate so things can't always be done as fast as we (or you!)'d like, but updates, responses and more background on why things have been done or can't be done (at a certain point in time) would be very much appreciated.

@ACT_1  why. is. that. ?