Wiki Taxonomy
Introduction
The development of the 50 GVCS tools and other focused open hardware projects follows a taxonomy - a nomenclature that allows any of the numerous pieces of information required to design and build any of the artifacts. If you understand this taxonomy, then you can in principle find any of the 250,000 wiki pages that will exist for documenting the GVCS in its entirety. When you think about this - this is extremely powerful - to essentially augment your abilities via the capacity to pull up any information to your fingertips - without having to look for it or without wading through endless pages of content. This taxonomy is designed such that the diligent student can find out anything required to build a civilization from scratch - within seconds. Thus - it is important to understand this taxonomy.
The Module Based Design indicates that we are tracking about a quarter million development items for the project! To find any of the quarter million pages, you need to understand: Module Based Design, Machine Naming Convention; List of GVCS Modules; Versioning; and Development Spreadsheet. To orient between all the versions done - know that there is a list of all Genealogies and that each project should have its own genealogy. Understanding HOW we design our products would also be useful if you actually want to assess the quality of the content on this wiki as it relates to the completion of the Global Village Construction Set. To understand HOW we design, you would need to understand the OSE Specifications that determine our human-centric, collaborative design for a transparent and inclusive economy of abundance.
- Module Based Design - the key to massive parallel development is breakdown into bitesize chunks.
- Machine Naming Convention - all GVCS machines have a unique name. Use that exact name.
- List of GVCS Modules - each machine is broken into modules. You need to understand what those modules are, which is listed and should be refined continuously.
- Versioning - Most Important - otherwise the project collapses in confusion as it is not clear which version is which. Version numbers allow for unique naming - across the dimension of time. This is critical for a long-term project. Using Git does not solve this - as not all of our documentation lends itself to Git-based repositories. See also this discussion on The Case for Using Wiki Version History
- Development Spreadsheet - this is the ultimate breakdown of modules into their 20 development steps at the technology level, and more steps at the enterprise level. OSE is developing both open hardware products, and enterprises around those products.
