| ... | ... | @@ -6,7 +6,7 @@ Thanks for donating your time and brain capacity for this. Highly appreciated. |
|
|
|
|
|
|
|
# The Scope
|
|
|
|
|
|
|
|
By your review you'll assess whether a certain piece of hardware qualifies as open source hardware according to [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169). See [CAB overview](/2-Guides/CAB) or [DIN SPEC 3105-1](https://din.one/pages/viewpage.action?pageId=36603169) for more general information.
|
|
|
|
By your review you'll assess whether a certain piece of hardware qualifies as open source 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
|
|
|
|
|
| ... | ... | @@ -14,58 +14,58 @@ By your review you'll assess whether a certain piece of hardware qualifies as op |
|
|
|
|
|
|
|
Review happens in corresponding issues on the CAB's GitLab instance. They should be self-explanatory; essentially there 4 types of review issues:
|
|
|
|
|
|
|
|
- `[assessment][main] <project-name>`
|
|
|
|
- that's just for the overview; no need to do anything here; however, you're free to view and comment general things, especially to give recommendations for the project development beyond the requirements of the assessment.
|
|
|
|
- `[assessment][some-category]`
|
|
|
|
- self-designed parts of a certain category (e.g. 3D printed parts) so that reviewers with specific knowledge can be invited
|
|
|
|
- each one must be checked individually
|
|
|
|
- `[assessment][ASM]`
|
|
|
|
- review of the assembly
|
|
|
|
- `[assessment][STD]`/`[assessment][BUY]`
|
|
|
|
- squashed review for referenced parts; in most cases these are standard and proprietary components
|
|
|
|
* `[assessment][main] <project-name>`
|
|
|
|
* that's just for the overview; no need to do anything here; however, you're free to view and comment general things, especially to give recommendations for the project development beyond the requirements of the assessment.
|
|
|
|
* `[assessment][some-category]`
|
|
|
|
* self-designed parts of a certain category (e.g. 3D printed parts) so that reviewers with specific knowledge can be invited
|
|
|
|
* each one must be checked individually
|
|
|
|
* `[assessment][ASM]`
|
|
|
|
* review of the assembly
|
|
|
|
* `[assessment][STD]`/`[assessment][BUY]`
|
|
|
|
* squashed review for referenced parts; in most cases these are standard and proprietary components
|
|
|
|
|
|
|
|
All relevant discussions & decisions are directly documented in the issue as comments. The process goes like this:
|
|
|
|
|
|
|
|
1. Get assigned:
|
|
|
|
- to an OSH project to review and
|
|
|
|
- to specific review issues that meet your skills and knowledge.
|
|
|
|
* to an OSH project to review and
|
|
|
|
* to specific review issues that meet your skills and knowledge.
|
|
|
|
2. Perform review:
|
|
|
|
- Check if all mandatory information is there,
|
|
|
|
- state misalignments otherwise and
|
|
|
|
- wait until misalignments are fixed (most likely by developers of the applying OSH project) or quickly fix it yourself (please refer to the [application guide](/2-Guides/application-guide) before!).
|
|
|
|
* Check if all mandatory information is there,
|
|
|
|
* state misalignments otherwise and
|
|
|
|
* wait until misalignments are fixed (most likely by developers of the applying OSH project) or quickly fix it yourself (please refer to the [application guide](/2-Guides/application-guide) before!).
|
|
|
|
3. Check the update:
|
|
|
|
- Fixes by the applicants (applying project developers) in reply to your comments are commited as **merge requests**, ideally each one linked to the relevant issue.
|
|
|
|
- Check the merge request and see if all relevant issues are tagged,
|
|
|
|
- reset the review status for the relevant issues for another revision,
|
|
|
|
- then accept the merge request.
|
|
|
|
3. Approve items:
|
|
|
|
- Once all misalignments are resolved the items can be approved.
|
|
|
|
- Do so by ticking the checkbox assigned to you (`[ ] approved @reviewer_1` → `[x] approved @reviewer_1`).
|
|
|
|
4. Close issues (**not [main]**)
|
|
|
|
- Once all checkboxes for approval are ticked.
|
|
|
|
- Do not manipulate or close the **[main]** issue! This is for CAB Admins only.
|
|
|
|
5. Have fun\
|
|
|
|
- actually starts right after point 1
|
|
|
|
* Fixes by the applicants (applying project developers) in reply to your comments are commited as **merge requests**, ideally each one linked to the relevant issue.
|
|
|
|
* Check the merge request and see if all relevant issues are tagged,
|
|
|
|
* reset the review status for the relevant issues for another revision,
|
|
|
|
* then accept the merge request.
|
|
|
|
4. Approve items:
|
|
|
|
* Once all misalignments are resolved the items can be approved.
|
|
|
|
* Do so by ticking the checkbox assigned to you (`[ ] approved @reviewer_1` → `[x] approved @reviewer_1`).
|
|
|
|
5. Close issues (**not \[main\]**)
|
|
|
|
* Once all checkboxes for approval are ticked.
|
|
|
|
* Do not manipulate or close the **\[main\]** issue! This is for CAB Admins only.
|
|
|
|
6. Have fun\\
|
|
|
|
* actually starts right after point 1
|
|
|
|
|
|
|
|
## What to review?
|
|
|
|
|
|
|
|
**Intro:**
|
|
|
|
|
|
|
|
What makes open source hardware different from prorietary hardware is it's technical documentation. DIN SPEC 3105 is the first official standard defining concrete requirements (DIN SPEC 3105-1) and how to check them (DIN SPEC 3105-2). It is itself the first official open source standard. Hence, if you find some requirements overly demanding, too vague, missing etc. file an issue or merge request in the original repository (<https://gitlab.com/OSEGermany/OHS>) so we, the community, can take care of it.
|
|
|
|
What makes open source hardware different from prorietary hardware is it's technical documentation. DIN SPEC 3105 is the first official standard defining concrete requirements (DIN SPEC 3105-1) and how to check them (DIN SPEC 3105-2). It is itself the first official open source standard. Hence, if you find some requirements overly demanding, too vague, missing etc. file an issue or merge request in the original repository ([https://gitlab.com/OSEGermany/OHS](https://gitlab.com/OSEGermany/OHS)) so we, the community, can take care of it.
|
|
|
|
|
|
|
|
**In short:**
|
|
|
|
|
|
|
|
- license must be compliant to the [OSHWA definition](https://www.oshwa.org/definition)
|
|
|
|
- we maintain a [list of compliant licenses](3-Further-Information/OSH-licenses); ask a CAB Admin for help if needed
|
|
|
|
- documentation must be permanently and publicly accessible
|
|
|
|
- when you are seeing this OSH project on <https://gitlab.opensourceecology.de/> this is already the case
|
|
|
|
- engineers shall be enabled to fully understand, build and modify the design only by the given documentation
|
|
|
|
- hence design files must be provided in their original file format and a generally accessible export format so that users a) can modify the documentation and b) have a fair chance to access the information without special or expensive software
|
|
|
|
* license must be compliant to the [OSHWA definition](https://www.oshwa.org/definition)
|
|
|
|
* we maintain a [list of compliant licenses](3-Further-Information/OSH-licenses); ask a CAB Admin for help if needed
|
|
|
|
* documentation must be permanently and publicly accessible
|
|
|
|
* when you are seeing this OSH project on [https://gitlab.opensourceecology.de/](https://gitlab.opensourceecology.de/) this is already the case
|
|
|
|
* engineers shall be enabled to fully understand, build and modify the design only by the given documentation
|
|
|
|
* hence design files must be provided in their original file format and a generally accessible export format so that users a) can modify the documentation and b) have a fair chance to access the information without special or expensive software
|
|
|
|
|
|
|
|
**Even shorter:** Would you be able to build this hardware only by the given documentation?
|
|
|
|
|
|
|
|
- Yes → approve
|
|
|
|
- No → state misalignment so it can be fixed
|
|
|
|
* Yes → approve
|
|
|
|
* No → state misalignment so it can be fixed
|
|
|
|
|
|
|
|
# FAQ
|
|
|
|
|
| ... | ... | @@ -93,21 +93,24 @@ See [this resource](https://mifactori.de/non-commercial-is-not-open-source/) for |
|
|
|
Short answer: File upstream. You can comment that in the review (since this may relevant for other reviewers as well). More important is to report this in the original repository so the developers can take care of it. If you're struggling with it or don't find the time, CAB admins are always there to help you out.
|
|
|
|
|
|
|
|
# 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:
|
|
|
|
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 ⭐
|
|
|
|
|
|
|
|
Some specific questions for our reviewers:
|
|
|
|
- what aspects did you review?
|
|
|
|
- what details did you look at?
|
|
|
|
- was it your first review?
|
|
|
|
- was the process clear to you?
|
|
|
|
- did you know what to look at, what questions to answer?
|
|
|
|
- how much time did you take?
|
|
|
|
- what (technical) specification of the review process would you wish for as guidance? |
|
|
\ No newline at end of file |
|
|
|
|
|
|
|
* what aspects did you review?
|
|
|
|
* what details did you look at?
|
|
|
|
* was it your first review?
|
|
|
|
* was the process clear to you?
|
|
|
|
* did you know what to look at, what questions to answer?
|
|
|
|
* how much time did you take?
|
|
|
|
* what (technical) specification of the review process would you wish for as guidance? |
|
|
\ No newline at end of file |
