The character came to be during a brainstorm session with the whole team. At that time it was a character that would celebrate all things in life, the good and bad. From there on out I drew character designs and wrote out this film (and some others) and eventually directed the film. So in a way you can blame me and the whole team. 
We extract the shading groups (and other sets) into a .ma file along with a relationships table stored in a .json file format. All our models get a unique identifier assigned so at all times (no matter where the mesh is) we can identify it for example as the leg of Bjorn. We can lookdev Bjorn and publish his shaders and their relationships, so basically it knows to assign the legs shader to the legs mesh.
Additionally a single asset can have shader variations (e.g. a healthy condition of his outfit, a worn down variation or just a different colored one). This is especially useful for background props (e.g. having many variations on books, etc.)
Because of the asset ids being on the mesh the shaders could theoretically be created anywhere (not necessarily in the workspace of the asset itself) and it would know the relationships belong to the Asset (e.g. Bjorn). In usual production we recommend to work in the asset itself but it has happened that we would lookdev a whole scene (consisting of many assets) in one go and combined and publish it from there.
With this we’re not yet where we want to be because preferably it would be a one-click solution. Usually rig updating isn’t a major dealbreaker at this point since meshes usually maintain their ids and all we do is transfer the deformer relationships from the old to the new meshes. (We don’t have referenced meshes in the rig, they are imported there.)
So far this has worked fine and usually takes around 10-20 minutes for a character depending on the complexity of the rig. Only with a lot of blendshapes things get increasingly complex.
I must say, yes. At least, over time, they grow comfortable with some of it. Especially instance is something they know what it is because we specifically identify in the scene what needs to be published by putting it in sets that we call instance sets.
I don’t think they use the terminology of Pyblish (they don’t really need to) of plugins and instances. I never heard them say plugin for example, they would usually say “This mesh check here is giving me this error. What’s up?” or “The model publish isn’t working here and I can’t seem to find what went wrong?” These are things you usually hear when a Validator started acting out (bug in the code that results in wrong behavior in specific situations) or just plain Maya crashes during certain extractions (which is when we debug it all and resolve it for the future, potentially adding extra validators or improving the extractor).
I think it’s mostly in the UI at this point. The backbone is there and should just get some good use over time to really figure out what else is needed but I believe the foundation that’s there is strong. We use the QML version but are looking to switch to Lite for stability and speed purposes. The UI suffices for most of the general use cases but large and heavy scenes would benefit from simplified overviews that are more artist friendly.
Aside from that I would love to see the community growing into such a direction that ideas, techniques and preferably even plugins & pipelines start to open up and get shared. Collaboration is a keyword there, so I believe, and it will help us all to increase production quality much more than we would be able to do alone. The fact that Pyblish exists and is maintained is just the beginning. The first step is there, from here on out giant leaps should be taken by everyone to really reap the benefits.
