2-Guides/review-guide.md

+# Welcome to community-based assessment of open source hardware!
+
+**You, the reviewer**, 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 your review you'll assess whether a certain piece of hardware qualifies as open source hardware according to [DIN SPEC 3105-1](https://osegermany.gitlab.io/OHS/din/DIN_SPEC_3105-1.pdf). See [CAB overview](/Documentation/CAB.md) or [DIN SPEC 3105-1](https://osegermany.gitlab.io/OHS/din/DIN_SPEC_3105-1.pdf) for more general information.
+
+# The Procedure
+
+## Overview
+
+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
+
+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.
+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](/Documentation/application-guide.md) 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
+
+## 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.
+
+**In short:**
+
+- license must be compliant to the [OSHWA definition](https://www.oshwa.org/definition)
+  - we maintain a [list of compliant licenses](osh-licenses.md); 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
+
+**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
+
+# FAQ
+
+## Does it qualify, when…
+
+### all information is there, but native CAD files are missing?
+
+**No.** Native CAD files are necessary to edit the design without the need of partly re-engineering it. It's an essential property of OSH to enable others to develop it further. OSH ≠ DIY.
+
+### technical drawings are missing, but STEP exports are available?
+
+**Yes.** **IF** the STEP files contain all necessary information (which can be critical when e.g. essential tolerances are needed). Technical drawings are highly recommended (for mechanical hardware), but currently not mandatory, when there's another suitable export available, e.g. STEP.
+
+### a non-commerial license is used?
+
+**No.** (and we are getting this question way to often).\
+See [this resource](https://mifactori.de/non-commercial-is-not-open-source/) for details.
+
+## During Review
+
+### What if I have feedback not related to DIN SPEC 3105-2?
+
+…e.g. technical feedback like "this part could much easier be 3D printed instead of being casted" or relevant, but optional feedback on the documentation like "measure XY is missing in drawing", when there's a STEP export making the information already accessible.
+
+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.