|
|
**Welcome to community-based assessment of open source hardware!**
|
|
# Scope
|
|
|
|
|
This guide describes the application process for projects in the OSEGeV Conformity Assessment Body.
|
|
|
**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
|
|
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 Procedure
|
|
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.
|
|
|
|
|
|
|
|
## Application Requirements
|
|
# The application workflow
|
|
|
|
|
|
|
|
To get your project into the assessment it has to fullfill the following criteria:
|
|
## Application Requirements
|
|
|
|
|
|
|
|
* correct licenses
|
|
To get your project into the assessment it has to fulfill the following criteria:
|
|
|
* 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)
|
|
* correct licenses
|
|
|
* GNU General Public License v3.0 or later (For Software)
|
|
* You'll need three different licenses for the Hardware itself, the documentation and eventually the software. A common choice is:
|
|
|
* Creative Commons Attribution 4.0 International (For the Documentation)
|
|
* Cern Open Hardware Licence Version 2 - Permissive (For Hardware)
|
|
|
* All source files (The files you used to create the hardware): CAD - Files, PCB-Layout, Software, etc....
|
|
* GNU General Public License v3.0 or later (For Software)
|
|
|
* 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.
|
|
* Creative Commons Attribution 4.0 International (For the Documentation)
|
|
|
* Bill of Materials - A list including all parts to build the hardware.
|
|
* All source files (The files you used to create the hardware): CAD - Files, PCB-Layout, Software, etc....
|
|
|
* Assembly instructions
|
|
* 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.
|
|
|
The CAB-admins will, during application, only check if everything is provided. The investigation of the content is then part of the review process.
|
|
* Assembly instructions
|
|
|
|
|
|
|
|
Find information on all accepted licenses in the [license overview](/3-Further-Information/OSH-licenses).
|
|
The CAB-admins will, during application, only check if everything is provided. The investigation of the content is then part of the review process.
|
|
|
|
|
|
|
|
## Get ready for the application
|
|
Find information on all accepted licenses in the [license overview](/3-Further-Information/OSH-licenses).
|
|
|
|
|
|
|
|
To apply for the assessment:
|
|
## Get ready for the application
|
|
|
|
|
|
|
|
* Get and account at https://gitlab.opensourceecology.de
|
|
To apply for the assessment:
|
|
|
* 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
|
|
* Get and account at https://gitlab.opensourceecology.de
|
|
|
* Use GitLab Functions or [cab@ose-germany.de](mailto:cab@ose-germany.de)
|
|
* contact us via [cab@ose-germany.de](mailto:cab@ose-germany.de) or in our [telegram welcome group](https://t.me/OSEGWelcome)
|
|
|
* Provide the place where we can download your project from
|
|
* Inform the CAB administration that you want your project to be reviewed
|
|
|
* Provide your username at https://gitlab.opensourceecology.de
|
|
* Use GitLab Functions or [cab@ose-germany.de](mailto:cab@ose-germany.de)
|
|
|
|
|
* Provide the place where we can download your project from
|
|
|
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.
|
|
* Provide your username at https://gitlab.opensourceecology.de
|
|
|
|
|
|
|
|
## Reviewing
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
## Reviewing
|
|
|
|
|
|
|
|
The detailled reviewing process is described in the [reviewing guide](/2-Guides/review-guide).
|
|
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.
|
|
|
|
|
|
|
|
## Bugfixing and project updates
|
|
The detailled reviewing process is described in the [reviewing guide](/2-Guides/review-guide).
|
|
|
|
|
|
|
|
To fix the problems pointed out by the reviewers:
|
|
## Bugfixing and project updates
|
|
|
- For bigger changes: Start a new branch
|
|
|
|
|
- Ideally edit only one part per commit
|
|
To fix the problems pointed out by the reviewers:
|
|
|
- Apply the changes and commit them as **merge request** into the **review branch!**
|
|
- For bigger changes: Start a new branch
|
|
|
- **When commiting tag the relevant issue you fixed!!!**
|
|
- Ideally edit only one part per commit
|
|
|
- This is very important, so reviewers and CAB-admin can comprehend the change history
|
|
- Apply the changes and commit them as **merge request** into the **review branch!**
|
|
|
- The reviewers will check the merge request and update the relevant issues
|
|
- **When commiting tag the relevant issue you fixed!!!**
|
|
|
|
|
- This is very important, so reviewers and CAB-admin can comprehend the change history
|
|
|
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.
|
|
- The reviewers will check the merge request and update the relevant issues
|
|
|
|
|
|
|
|
## Finishing
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
## Finishing
|
|
|
|
|
|
|
|
# Feedback
|
|
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
|
|
|
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.
|
|
|
|
|
|
|
# Feedback
|
|
|
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.
|
|
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.
|
|
|
- What was your experience?
|
|
|
|
|
- What difficulties did you face?
|
|
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.
|
|
|
- How did you solve them?
|
|
- What was your experience?
|
|
|
- Was the information provied helpfull?
|
|
- What difficulties did you face?
|
|
|
- What did you miss and how would you have wished it to be?\
|
|
- 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: |
|
Be free. Be creative. We are counting on you :star: |
|
|
|
\ No newline at end of file |
