Thank you for sharing this @TiberiusB - this is a exciting direction that provides tangible, practical next steps.
Your document is getting a lot closer to where we need to go. The style/approach Instructables has for participatory community development of documentation is a great model; I have leaned heavily on their content in my former classrooms/lab;, both for builds and as a model for development of documentation internally.
It has been identified that there is a dearth of documentation across the board in our work, particularly in the finishing and assembly of component parts from bundled design files - as was once again affirmed during the DAPSI MVP dev and accompanying UX testing. In the report from DAPSI P2 (P2 focusing on design and documentation specifically), the following next steps were identified:
-
Dissemination of the research findings and prototype development, showcasing the utility
that the OKH-LD manifest, along with the tooling developed of this work, provides
specifically for file and data portability for maker projects. -
Recommendation to develop tooling for point-of-need OKH-LD manifest generation, such as
a browser extension. -
Continue the development of the OKH-LD ontology for hardware project metadata and align
all involved stakeholders in developing a shared vocabulary for data exchange. -
Encourage platforms to enable the automatic generation of OKH-LD manifests to allow for
easier sharing of project data and files. -
Enhance the functionality of the OKH Solid App and seek partnerships to develop new
applications based on the OKH-LD data standard within the Solid ecosystem.
I think the DIY document you’ve shared for the Organic Box 3V is a really interesting use case that could help us tackle some of those recommended next steps.
I think the must fruitful conversations would result from talking with @hoijui and @max_w (pls do chime in here, both) as they were the on the DAPSI P1-2, and @hoijui has been continuing some of that work.
And, your offer to have Sensorica serve as the testbed for providing feedback for iterative dev/improvement is just what we need - it is also potentially applicable to the ongoing GOSQAS discussion; a user journey could be developed as part of the testing for this use case, perhaps emphasizing QA, to help build out the (somewhat vague) “provenance in QRs/QA performed” process step. What do you think @max_w
RE: GOSQAS, there is an upcoming meeting - I will post the invitation for the meeting to discuss MVP planning to the forum momentarily.