OSHW Project Management User Stories

Preamble

Welcome to the How do you share your Open-Source Hardware project workshop summary report. During the workshop we worked with participants to identify what we can do as a community to make it easier to share, communicate, and collaborate on OSHW projects. The following content is the result of that work.

Desired Core Capabilities

From 1. Core Capabilities

Go to text →

These are the core needs of the OSHW community when sharing, communicating, and collaborating on OSHW projects

1. OSHW Definition

From 1. OSHW Definition

Go to text →

OSHW projects should be developed and shared in accordance to the OSHW Definition.¹

1: https://www.oshwa.org/definition/

2. OSHW Certification

From 2. OSHW Certification

Go to text →

OSHW projects should be developed and shared in accordance to the OSHW Certification process.¹

1: https://certification.oshwa.org/process.html

3. OSHW Should Be like OSS

From 3. OSHW Should Be like OSS

Go to text →

OSHW should be like Open Source Software (OSS) to the greatest degree possible (e.g. sharing, development, licensing).

4. OSHW Development Should Leverage Modern Software Development Techniques

From 4. OSHW Development Should Leverage Modern Software Development Techniques

Go to text →

OSHW development should leverage modern software development techniques to improve the OSHW developer experience.

examples

package management
DevOps (e.g., DevSecOps, DocOps)
mono-repos
design patterns (e.g., model-view-controller)
semantic versioning

Minimum Required Data Model

From 2. Pillars

Go to text →

Classes of data that need to be captured 1. Core Capabilities

1. BOM Data

From 1. BOM Data

Go to text →

Bill of Materials (BOM) data: list of components and counts covering all parts and tools which must be procured to build the project

2. Instructions

From 2. Instructions

Go to text →

Assembly Instructions: complete list of instructions to build the project from its procured parts
Operating Instructions: complete list of instructions to use the project safely and effectively

3. Supporting Data

From 3. Supporting Data

Go to text →

e.g. design files,

CAD models (e.g., Mechanical CAD files, PCB Gerbers files)
Specifications (e.g., operating temperature range)
Interface definitions (e.g., board pinout)
Schematics (e.g., Circuit boards)

User Stories

From User Stories List

Go to text →

From User Build an OSHW Project

Go to text →

As a OSHW User, I want to Build an OSHW Project, so that I can Reproduce the OSHW Project

related to 1. Core Capabilities: 1. OSHW Definition

notes

build using alternative components for (end-of-life) availability

From User Build an OSHW Project with Alternative Components

Go to text →

As a OSHW User, I want to Build an OSHW Project with Alternative Components, so that I can Address Issues with Component Availability

related to 1. Core Capabilities: 1. OSHW Definition

From Developer Ensure Unique Project Element Names

Go to text →

As a OSHW Developer, I want to Ensure Unique Project Element Names, so that I can Unambiguously Identify Every Instance of a Component in a Project

related to 1. Core Capabilities: 1. OSHW Definition

From Developer Organize Projects

Go to text →

As a OSHW Developer, I want to Organize OSHW Project, so that I can Conform to DRY Principle

related to 1. Core Capabilities: 4. OSHW Development Should Leverage Modern Software Development Techniques

notes

need for bridging knowledge gap between industry standard and open-source practices; no mentoring programs / methodology
- while the DOF team agrees this is a challenge within the OSHW community, it is outside the scope of DOF (packaging a OSHW project to be shareable/modifiable/reproducible)
lintable data structure
- interpret "lintable" to mean the content in the model is verifiable (no missing fields, orphan elements, etc.)
- LinkML "validate" capability implements these kinds of tests
- a.k.a., expose ability to validate content