|
|
|
**Welcome to community-based assessment of open source hardware!**
|
|
|
|
|
|
|
|
**You, the applicant**, are part of this pilot of decentralised, transparent and community-driven quality control of documentation for open source hardware (OSH). We believe that this procedure (standardised by [DIN SPEC 3105-2](https://din.one/pages/viewpage.action?pageId=36603181)) contributes to the overall trustworthiness and applicability of open source hardware. As a side effect we hope this helps OSH projects to interconnect to each other.
|
|
|
|
|
|
|
|
Thanks for donating your time and brain capacity for this. Highly appreciated.
|
|
|
|
|
|
|
|
# The Scope
|
|
|
|
|
|
|
|
By being part of the process with your project we will check and approve the quality, by means of reproducability, of your piece of hardware according to [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169). See [CAB overview](/3-Further-Information/CAB) or [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169) for more general information.
|
|
|
|
|
|
|
|
# The Procedure
|
|
|
|
|
|
|
|
## Application Requirements
|
|
|
|
|
|
|
|
To get your project into the assessment it has to fullfill the following criteria:
|
|
|
|
|
|
|
|
* correct licenses
|
|
|
|
* You'll need three different licenses for the Hardware itself, the documentation and eventually the software. A common choice is:
|
|
|
|
* Cern Open Hardware Licence Version 2 - Permissive (For Hardware)
|
|
|
|
* GNU General Public License v3.0 or later (For Software)
|
|
|
|
* Creative Commons Attribution 4.0 International (For the Documentation)
|
|
|
|
* All source files (The files you used to create the hardware): CAD - Files, PCB-Layout, Software, etc....
|
|
|
|
* A part from the source files there needs to be an exported file than can be read or used more software independant, such as: .stl-files (3D-printing), technical drawings, wiring schemes.
|
|
|
|
* Bill of Materials - A list including all parts to build the hardware.
|
|
|
|
* Assembly instructions
|
|
|
|
|
|
|
|
The CAB-admins will, during application, only check if everything is provided. The investigation of the content is then part of the review process.
|
|
|
|
|
|
|
|
Find information on all accepted licenses in the [license overview](/3-Further-Information/OSH-licenses).
|
|
|
|
|
|
|
|
## Get ready for the application
|
|
|
|
|
|
|
|
To apply for the assessment:
|
|
|
|
|
|
|
|
* Get and account at https://gitlab.opensourceecology.de
|
|
|
|
* contact us via [cab@ose-germany.de](mailto:cab@ose-germany.de) or in our [telegram welcome group](https://t.me/OSEGWelcome)
|
|
|
|
* Inform the CAB administration that you want your project to be reviewed
|
|
|
|
* Use GitLab Functions or [cab@ose-germany.de](mailto:cab@ose-germany.de)
|
|
|
|
* Provide the place where we can download your project from
|
|
|
|
* Provide your username at https://gitlab.opensourceecology.de
|
|
|
|
|
|
|
|
Subsequently the CAB administration will clone your project to https://gitlab.opensourceecology.de/verein/projekte/cab and list it in the [OSEG CAB assessment list](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/blob/main/archive/assessments.md). Once it was doublechecked for the requirements the project will be prepared for the assessment and suitable reviewers for the assessment will be searched and assigned.
|
|
|
|
|
|
|
|
## Reviewing
|
|
|
|
|
|
|
|
The CAB administration will create issues for the review process in the cloned project. Commonly next to the **main** issue there would be one issue for all **standard**-parts, one for all **buy**-parts and one issue for each **self-designed-part**. If all requirements for the single parts are fulfilled the reviewers (at least two per part) will approve and close the issue. If there is something to complain they will leave a comment.
|
|
|
|
|
|
|
|
The detailled reviewing process is described in the [reviewing guide](/2-Guides/review-guide).
|
|
|
|
|
|
|
|
## Bugfixing and project updates
|
|
|
|
|
|
|
|
To fix the problems pointed out by the reviewers:
|
|
|
|
- For bigger changes: Start a new branch
|
|
|
|
- Ideally edit only one part per commit
|
|
|
|
- Apply the changes and commit them as **merge request** into the **review branch!**
|
|
|
|
- **When commiting tag the relevant issue you fixed!!!**
|
|
|
|
- This is very important, so reviewers and CAB-admin can comprehend the change history
|
|
|
|
- The reviewers will check the merge request and update the relevant issues
|
|
|
|
|
|
|
|
In some cases Reviewers might also directly apply changes fixing their complain. In this case they should follow the same guidelines but the changes should be approved by the applicants, respectively the project developers.
|
|
|
|
|
|
|
|
## Finishing
|
|
|
|
|
|
|
|
Once all parts are approved the assessment will be finished and the project will receive the community conformity by means of a specially tagged version. The project will be listed in the assessment overview as approved and the review branch
|
|
|
|
|
|
|
|
# Feedback
|
|
|
|
The workflow is still under development. Frankly speaking, since it is open source, it will always be an evolutional process, which is one of the strengths of the community driven design.
|
|
|
|
|
|
|
|
Therefore we invite you to contribute in our development. First of all we would highly appreciate your feedback on all your workflow experiences. Please feel free to create as many issues as you like inside here: [CAB Feedback](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/milestones/4)-Area.
|
|
|
|
- What was your experience?
|
|
|
|
- What difficulties did you face?
|
|
|
|
- How did you solve them?
|
|
|
|
- Was the information provied helpfull?
|
|
|
|
- What did you miss and how would you have wished it to be?\
|
|
|
|
# Scope
|
|
|
|
This guide describes the application process for projects in the OSEGeV Conformity Assessment Body.
|
|
|
|
|
|
|
|
|
|
|
|
----
|
|
|
|
|
|
|
|
in rework
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
By being part of the process with your project we will check and approve the quality, by means of reproducability, of your piece of hardware according to [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169). See [CAB overview](/3-Further-Information/CAB) or [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169) for more general information.
|
|
|
|
|
|
|
|
# The application workflow
|
|
|
|
|
|
|
|
## Application Requirements
|
|
|
|
|
|
|
|
To get your project into the assessment it has to fulfill the following criteria:
|
|
|
|
|
|
|
|
* correct licenses
|
|
|
|
* You'll need three different licenses for the Hardware itself, the documentation and eventually the software. A common choice is:
|
|
|
|
* Cern Open Hardware Licence Version 2 - Permissive (For Hardware)
|
|
|
|
* GNU General Public License v3.0 or later (For Software)
|
|
|
|
* Creative Commons Attribution 4.0 International (For the Documentation)
|
|
|
|
* All source files (The files you used to create the hardware): CAD - Files, PCB-Layout, Software, etc....
|
|
|
|
* A part from the source files there needs to be an exported file than can be read or used more software independant, such as: .stl-files (3D-printing), technical drawings, wiring schemes.
|
|
|
|
* Bill of Materials - A list including all parts to build the hardware.
|
|
|
|
* Assembly instructions
|
|
|
|
|
|
|
|
The CAB-admins will, during application, only check if everything is provided. The investigation of the content is then part of the review process.
|
|
|
|
|
|
|
|
Find information on all accepted licenses in the [license overview](/3-Further-Information/OSH-licenses).
|
|
|
|
|
|
|
|
## Get ready for the application
|
|
|
|
|
|
|
|
To apply for the assessment:
|
|
|
|
|
|
|
|
* Get and account at https://gitlab.opensourceecology.de
|
|
|
|
* contact us via [cab@ose-germany.de](mailto:cab@ose-germany.de) or in our [telegram welcome group](https://t.me/OSEGWelcome)
|
|
|
|
* Inform the CAB administration that you want your project to be reviewed
|
|
|
|
* Use GitLab Functions or [cab@ose-germany.de](mailto:cab@ose-germany.de)
|
|
|
|
* Provide the place where we can download your project from
|
|
|
|
* Provide your username at https://gitlab.opensourceecology.de
|
|
|
|
|
|
|
|
Subsequently the CAB administration will clone your project to https://gitlab.opensourceecology.de/verein/projekte/cab and list it in the [OSEG CAB assessment list](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/blob/main/archive/assessments.md). Once it was doublechecked for the requirements the project will be prepared for the assessment and suitable reviewers for the assessment will be searched and assigned.
|
|
|
|
|
|
|
|
## Reviewing
|
|
|
|
|
|
|
|
The CAB administration will create issues for the review process in the cloned project. Commonly next to the **main** issue there would be one issue for all **standard**-parts, one for all **buy**-parts and one issue for each **self-designed-part**. If all requirements for the single parts are fulfilled the reviewers (at least two per part) will approve and close the issue. If there is something to complain they will leave a comment.
|
|
|
|
|
|
|
|
The detailled reviewing process is described in the [reviewing guide](/2-Guides/review-guide).
|
|
|
|
|
|
|
|
## Bugfixing and project updates
|
|
|
|
|
|
|
|
To fix the problems pointed out by the reviewers:
|
|
|
|
- For bigger changes: Start a new branch
|
|
|
|
- Ideally edit only one part per commit
|
|
|
|
- Apply the changes and commit them as **merge request** into the **review branch!**
|
|
|
|
- **When commiting tag the relevant issue you fixed!!!**
|
|
|
|
- This is very important, so reviewers and CAB-admin can comprehend the change history
|
|
|
|
- The reviewers will check the merge request and update the relevant issues
|
|
|
|
|
|
|
|
In some cases Reviewers might also directly apply changes fixing their complain. In this case they should follow the same guidelines but the changes should be approved by the applicants, respectively the project developers.
|
|
|
|
|
|
|
|
## Finishing
|
|
|
|
|
|
|
|
Once all parts are approved the assessment will be finished and the project will receive the community conformity by means of a specially tagged version. The project will be listed in the assessment overview as approved and the review branch
|
|
|
|
|
|
|
|
# Feedback
|
|
|
|
The workflow is still under development. Frankly speaking, since it is open source, it will always be an evolutional process, which is one of the strengths of the community driven design.
|
|
|
|
|
|
|
|
Therefore we invite you to contribute in our development. First of all we would highly appreciate your feedback on all your workflow experiences. Please feel free to create as many issues as you like inside here: [CAB Feedback](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/milestones/4)-Area.
|
|
|
|
- What was your experience?
|
|
|
|
- What difficulties did you face?
|
|
|
|
- How did you solve them?
|
|
|
|
- Was the information provied helpfull?
|
|
|
|
- What did you miss and how would you have wished it to be?\
|
|
|
|
Be free. Be creative. We are counting on you :star: |
|
|
\ No newline at end of file |
