|
|
|
# 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://osegermany.gitlab.io/OHS/din/DIN_SPEC_3105-2.pdf)) 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://osegermany.gitlab.io/OHS/din/DIN_SPEC_3105-1.pdf). See [CAB overview](/3-Further-Information/CAB.md) or [DIN SPEC 3105-1](https://osegermany.gitlab.io/OHS/din/DIN_SPEC_3105-1.pdf) 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 CAD - Files, Software are there.
|
|
|
|
* For special parts there should be technical drawings provided.
|
|
|
|
* Bill of Materials - A list including all parts to build the hardware.
|
|
|
|
* Assembly instructions
|
|
|
|
|
|
|
|
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 [verein@ose-germany.de](mailto:verein@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
|
|
|
|
* For now: [lukas.schattenhofer@ose-germany.de](mailto:lukas.schattenhofer@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 |
