Critical Collaborative Literacy: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 9: | Line 9: | ||
#'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build. | #'''Use modularity of documentation.''' That means any hardware build is treated as a fork - see [[Every Build is a Fork]]. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build. | ||
#'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets. | #'''Use proper Open Source Product Development taxonomy'''. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets. | ||
#'''Upload as soon as you have something.''' The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help. |
Revision as of 19:06, 8 August 2021
These are principles of how to collaborate as large, open teams. This is a critical set of principles that enable a transition to the open source economy - an economy that optimizes for both production - and distribution. This is consistent with Distributive Enterprise.
What are open teams? Those are any teams that work on Open Source Product Development based on associated best practices of collaboration.
The principles are simple and basic, but they require coordination according to principles that solo and proprietary work do not follow. Thus, this is a significant cultural barrier to 99% of the population.
The principles are:
- Use modularity of documentation. That means any hardware build is treated as a fork - see Every Build is a Fork. This means that information is never mixed up between different versions. This is why centralized management via Git is not relevant for an overall project - though it is relevant for every single build.
- Use proper Open Source Product Development taxonomy. The process of product development is well-defined. Open source product development follows this pattern, with the only distinction that it keeps all knowhow open source. The process taxonomy must be used, so that any product developer can orient themselves readily within all the development assets.
- Upload as soon as you have something. The mainstream way is to publish after you have a product. The open source, collaborative way is to publish as soon as you start. Even a placeholder is a contribution to meaningful product development - as it informs the developer community that something is moving. Do not wait to finish. The advantage is that someone can provide in-process feedback - and at best - do the work for you so you don't have to do it yourself. The key is collaborative design. Use it! By publishing so others can help.