Best Of

@EvanReese
This is a very helpful explanation for a lot of people and small teams. I plan on sharing this with my team.

Onshape training needs to have more stuff based on real world projects/products. There are too many toy examples which don't have the complexities or constraints of actual development engineering. Hopefully in your new role you'll be able to collect more examples and learnings from multiple industries.

One thing that is important to understand about larger projects and/or teams is that a document is a unit of branching, merging and history. You rightly started splitting things into more documents as complexity grew in the projects. The reasons for that are not just performance, but also the ability for the story of a document to make sense. One of the many reasons for OTS parts to be in their own document(s) is that they are mostly going to come from imports and need a little clean up and metadata at most. OTS stuff is unlikely to branch and merge. OTS stuff is also more likely to get reused in future products/projects. It's awkward for it to be in the same document as all the custom parts which are related to a particular project.

For complex projects, subsystems often need their own document because their development path is not identical to the main product or ID. Early in development, those subsystems may be bench tested and iterated on with different concepts where branching and merging the entire project doesn't make sense.

I'm a little confused about the mentions about Super Derive and variables. Now that we have Variable studios, is Super Derive still useful and necessary for distributing variables? I'm also curious what your take is on @GregBrown 's Publish feature?

Another way I would look at this document structure topic is to review some of the things that don't work as well and why. For example, there are occasionally people that will say that every part should be its own document. For me that's completely missing the point of top-down design and collaboration possibilities, but it seems to have grown out of a fear of how release management works and how to find things. It's coming from people used to file-based CAD that haven't really understood Onshape.

Document structures also evolve over the course of a project. Early on, most/all of the project may be in a single document where rapid iterations with live workspace references are essential. As maturity and complexity grows, it makes sense for a bunch of reasons to split into multiple documents where, by definition you have to use version references. Even within the same document, there are phases of development. As things become more real and release management is essential, references need to switch from workspaces to versions/revisions.

@S1mon Lots of excellent points and comments here. My replies below

• Documents are a unit of branch, merge and history - I agree here, though if the team knows how to use them well, (and now that you can do partial merges, instead of merging everything) it doesn't matter so much IMO. I think either way a single branch should be done with a single change in mind, and not mixed in with unrelated changes. I'd prefer to have 3 concurrent branches (even if i'm working solo) for 3 changes/explorations that don't interact much.
• Project structures need to evolve - I suppose I left some things unsaid about this in the video, but I very much agree. These were the mature structures of the projects at the state that parts were ready for initial release and ordering, so they don't represent early development (when fewer documents may be in use) or later ongoing maintenance (when you may want even more document splitting). These are also only representations of structures for the production models, which assumes all of the concept refinement is already done and the Design Vision is clear enough to just execute. In addition to all of this there would be many mechanical prototypes, proofs of concepts, ID explorations, and so on. For simple tests they can be pretty loose and sloppy because they don't need to be maintained (i.e. "I'm doing a quick feasability check on a mechanism, or quick 3D print for ergonomics"), or for more involved benchtop tests you may want to have a multi-document structure more like this, even if all of that CAD is in pursuit of a prototype and won't make it to the production model.
• Super derive - This is still the only way to get measured variables downstream, or complex variables created by custom features like Variable Hole. I like creating a lot of measured vars off of key geometry in the master model if those vars are hard to calculate with straight math, or if it makes it clearer what they are. Sometimes it's just more understandable than a long equation.
• Publish feature - I've not had a chance to use it on a full project but I think it's going to be the way to go. I love it!