Collaborative waste is any waste that arises from large groups of people working together. There may be many sources of such waste: coordination losses, people not producing documentation, the sheer effort to produce documentation (which is not a waste if this helps future generations), etc.
However, in the digital age, there are tools to manage effective collaboration between large groups:
- Modular breakdown - breakdown of complex problems into small parts is a critical tool for solving large problems with many people
- Role definition - defining clear roles, tasks, and skill sets required to work on tasks
- Upvoting platforms for distilling content so content transforms from cacophony to distilled wisdom
- Wikis - to manage large amounts of data collaboratively
- Live editable documents - such as Google Presentation/Colab - for large realtime design effort
- Part libraries and open source CAD - with clear submission and file format guidelines, large part libraries can be managed effectively for large scale collaboration where many people work on different modules
- Realtime Documentation - involving remote teams in documentation and video production at the same time that a design/build occurs
Collaborative Waste of Documentation
Anyone who has worked on open source projects recognizes the vast effort required to document everything. For this reason, documentation is typically lacking. However, we emphasize that documentation is the only way that a project can scale. Writing has been developed 10,000 years ago, which allowed Time Binding to occur. In the 1990s, the wiki was developed. In the 2000s, live editable docs became a reality. Thus, in the digital age, we are not short of adequate tools for distributed documentation. The benefit of documentation outweighs the cost.
However, there must be clear standards for how to document: tools used, file formats accepted, best practices.
- By  - 12 issues of open source - https://opensource.com/life/14/6/12-challenges-open-source-projects
- Establishing a standard for code submissions
- requiring acceptance of a common license
- implementing peer review are three ways in which good open source projects help to mitigate the risk of problematic code.
- For HeroX - update videos for contributions. Rewarding your contributions. You MUST inform people of your work, and allow them to contribute
- Modular breakdown to as many small pieces as possible
- Doing critical contributions only, not derivative ones, and phasing progress. For ex, CAD is king as the deliverable; an exploded part diagram may be in a subsequent phase (User Manual Phase).
- Build it and show us the data puts a quick resulution of design debate
- Judging and peer review can be combined. You get rewarded for working on winning versions. This forces you to contribute to something that you deem worthy - which is a form of peer review. If you work on a dead end, sorry but no cigar.