Merge Workflow
Contents
Summary
General
Merge Workflow is a technique where, without locking down design files, collaboration can occur on a single CAD design with an unlimited number of people.
This concept is general: it refers to any process where people can work independently with zero barriers to entry and without reconciliation of contributions until the very end, as in the 'excessive prototyping' concept of the Second Toyota Paradox. This allows for casting a wide net for contributions from many people, without the time-intensive reconciliation process (commits). In this way, relevant contributions can be collected - under the assumption that any work of genius is 1% inspiration, and 99% perspiration. To refine the contributions, various mechanisms can be implemented. These mechanisms must involve Subject Matter Experts, Artificial Intelligence, or another process which evaluates and refines the contributions into products.
The Swarm Build technique pioneered by OSE for developing and building products involves modular design for large-scale, parallel builds - where the modules are 'assembled rapidly into place' at the end - allowing for rapid build timeframes of Extreme Manufacturing. This 'rapid assembly' process is one specific instance of 'merge workflow.'
FreeCAD Case
The workflow relies on merging parts into working documents, and files can also be joined in positionally-correct locations. This does not require the more advanced functionality of using constrains in the Assembly workbench, nor Git as version control. Version control is done using the wiki, just as Wikipedia has scaled to become the largest information project in the world. OSE's Public Development may be compared to Wikipedia more than to Linux in terms of how it manages information. We use Set-Based Concurrent Engineering with design reconciliation / integration / quality control as late in the process as possible in order to maximize the number of prototypes that feed into any hardware build. We consider that Every Hardware Build is a Fork, for which reason a Git-based workflow is not adequate.
Part location is an important topic, but this workflow does not require positionally-correct files - parts can be moved into the correct position iterativelly.
For positional-correctness of inserted parts - to address the issue or correct part location, part placeholders are started in an assembly document - in a positionally correct location. These parts can subsequently be edited in separate documents. Source files are uploaded on an ongoing basis. For onboarding of additional designers, uplaods incude Visual Version History, and live-editable Working Docs support the design process. Because nothing is locked down and ongoing communication between developers occurs via video in realtime or via work docs asynchronously, this process can leverage the input of large teams, using common off-the-shelf software, FreeCAD.
Philosophical Point
MJ sez: Constraints are misleading. It makes teh CAD artist shun further responsibility of buildability. Because no 2 parts are ever perfectly aligned in real life (if you dig deep enough). So why design perfect alignment in CAD? Approximating alignment by manual placement provides a reality check regarding actual build conditions. It makes the CAD artist consider buildability because it forces the designer to move things, and while moving things, part interference can be observed. In our view, constraintless design has merits of accountability. Constraints mislead the author into a feeling of absolute power and control over their design - "it's a perfect design". Wake up Neo, swallow a whole packet of red tablets. The reality is never as perfect. Thus, no need to create a perfect design (in most cases). It is important to understand what level of detail is important in real life. The practical advantage at OSE is not requiring the CAD artist to use Assembly workflows - moving and rotating things is simpler conceptually - and novices can learn move-rotate immediately. Move-rotate corresponds to real life - so it's a good reality check for buildability. Maybe there are so many unreachable bolts in engines because the designers used Assembly workflows to create the designs?
Intro
Hint: This is one of core OSE collaborative, open development protocols. You are welcome to improve this page by editing mercilessly.
The key to successful management of large scale, global, open development collaboration - hardware or software - is Modular Breakdown of complex projects into small parts.
For the case of hardware designs - modular breakdown means that we break machines and product systems down to their smallest components.
Tracking any development effectively, and collaborating on a large scale - requires that each component is distinguished from the overall product - such that it can be developed independently and in parallel with many other components.
Scalable parallel development can exist on the level of an overall product, its module, and its sub-modules or components.
To document products and components, we use Part Libraries. Part libraries are also convenient in terms of how they can be modified using FreeCAD. A developer or user should be able to download parts and overall products from part libraries. To understand how part libraries relate to FreeCAD and large-scale parallel development - we must understand the Merge Workflow in FreeCAD:
- FreeCAD has a Merge Workflow option. Go to File->Merge project... to access this workflow.
- Proper use of this workflow allows files on the wiki - parts - to be merged into the same document.
- To use this workflow - files must be saved in a positionally correct location. This means, that when a second part it merged with a first part - it appears in a location like in the final product.
- One can start by downloading any single part, and merge new parts into the same working document as needed
- This way of handling parts allows full modular breakdown. Each file or part is accessible.
- Anyone can work on any part, and uplaod changes to the wiki on a granular basis.
- The wiki keeps old versions, so that we can work with older versions if needed at any time. The wiki thus has a full ability to do version history. It is useful to annotate older versions (either in file comments or on the wiki page for the versioned file) so other developers can see what the version contains.
- The main point of this is allowing many people to work in parallel on the same CAD design.
- Another advantage is retaining full versioning control on parts, not only on overall assembly.
- Another advantage is file size management: instead of uploading complete files, it takes much less disk space to upload only the changing parts. This becomes increasingly important with growing project size/complexity.
The above summarizes how to work using the Merge Workflow. This can be used in conjuntion with more advanced workflows such as using the Asembly 2 Workbench.
More Notes on the Merge Workflow
- It is useful to include a Visual Version History in the part library - which simply means pictures of snapshots of the file as it evolves in time. New snapshots are included for visual reference - to save time in assessing the content of files. This is an antidote to Git or other drop-box like platform - where a wall of filenames of parts takes time to parse for content. Git does not allow versioning at a granular level (new uploads over an existing individual files), only at a repository level. This does not work well for open hardware development because 2 component CAD files cannot be compared side by side.
- For solo work, it's acceptable to use git or other 'whole project versioning'
- Note that 'whole project versioning' at the level of CAD does not work well for large, collaborative open hardware, as CAD and software are only a small portion of an overall project. Thus, a wiki is still required to manage many other data formats while allowing for powerful organizational, taxonomy, or semantic organization aspects.
- The power of a wiki is the reason why OSE uses the wiki-based Development Template, which is cloned in full for the next iteration. Parts of the Development Template are updated as needed, while keeping the whole project version intact.
Example
This example applies to using FreeCAD workflows to design a large and complex project with a large number of people (1000 or so) working in a Window of Opportunity framework - in a short, 1 day period. This is an expected scenario that OSE is working on - through its STEAM Camps program, Summer of Extreme Design-Build, Extreme Manufacturing Workshops, and Incentive Challenges.
The two options are using the Merge Workflow vs Assembly Workbench workflow.
Take an example of 1000 people design a rocket ship in one day by splitting the project into 1000 parts, by defining interfaces, and saving the files in positionally correct locations defined by the interfaces. This allows realtime, rapid development that is not possible in a FreeCAD assembly workbench workflow, because only one person can work on an assembly without running into merge conflicts. The most granular development method is thus afforded more effectively using the merge workflow.
