This issue is to propose an approach to managing the project source code & documentation for building the sgvhak-rover project.
Scope
Project source code includes hardware designs (s.a., 3D CAD models or PCB designs) and/or software source code (s.a., C/C++ code compiled to binaries for running on an onboard computer).
Documentation includes content needed to assemble/build the sgvhak-rover (s.a., parts lists, tools lists, assembly instructions, and/or supporting documentation - drawings, diagrams, etc.).
Proposed approach
1) Project source code and documentation should be published under permissive licenses (s.a., CERN-OHL-P for hardware, MIT for software, CC-BY-4.0 for documentation), in accordance with the Open-Source Hardware Definition, as to allow for modification and/or redistribution by contributors of the open source community with minimal restriction.^1
2) Documentation's authoritative-source-of-truth should persist in a docs-as-code format (i.e., plain ascii text, albeit using a markup or modeling language) as to be human and machine-readable, future-proof, and compatible with modern version control tools (s.a., git) for versioning documentation alongside source code on the local filesystem - by extension, doctools (s.a., static site generators), can be utilized using a docs-as-code format for producing documentation in multiple formats (s.a., HTML or PDF) that can be integrated with continuous delivery (CD) pipeline for auto-generating and publishing documentation to a static site page.^2
3) Project and repo name should be lower-cased & dash-separated (e.g., sgvhak-rover), as per the naming convention defined in the package.json specification - by extension, project metadata can be described using the package.json schema as to allow for modularity and package management of the project, including its sub-components.^3
Purpose
This issue is to propose an approach to managing the project source code & documentation for building the
sgvhak-rover
project.Scope
sgvhak-rover
(s.a., parts lists, tools lists, assembly instructions, and/or supporting documentation - drawings, diagrams, etc.).Proposed approach
1) Project source code and documentation should be published under permissive licenses (s.a., CERN-OHL-P for hardware, MIT for software, CC-BY-4.0 for documentation), in accordance with the Open-Source Hardware Definition, as to allow for modification and/or redistribution by contributors of the open source community with minimal restriction.^1 2) Documentation's authoritative-source-of-truth should persist in a docs-as-code format (i.e., plain ascii text, albeit using a markup or modeling language) as to be human and machine-readable, future-proof, and compatible with modern version control tools (s.a., git) for versioning documentation alongside source code on the local filesystem - by extension, doctools (s.a., static site generators), can be utilized using a docs-as-code format for producing documentation in multiple formats (s.a., HTML or PDF) that can be integrated with continuous delivery (CD) pipeline for auto-generating and publishing documentation to a static site page.^2 3) Project and repo name should be lower-cased & dash-separated (e.g.,
sgvhak-rover
), as per the naming convention defined in thepackage.json
specification - by extension, project metadata can be described using thepackage.json
schema as to allow for modularity and package management of the project, including its sub-components.^3Notes
The aforementioned approach can be facilitated using the distributed open-source hardware framework (DOF).