Help

Applicants

A complete application for inclusion in the evaluation process includes

1.Information about the applicant http://de.oho.wiki/wiki/Benutzer:xyz (xyz=username)
2.Creation of the project, if the project is not yet registered on OHO http://de.oho.wiki/wiki/Spezial:Mit_Formular_bearbeiten/Projekt
3.Details of the project more
4.Creation of the parts list (see https://de.oho.wiki/wiki/Parts_Lists)

*use simple (without assemblies) or structured parts list (with assemblies, improves comprehensibility)?
*Structured BOMs: use two or more levels (1.1 or 1.1.1 etc.)
*all components and assemblies are included?
*For all components and assemblies, the "Part number" is given (1, 1.1, 1.2 etc.)?
*In the case of structured parts lists, use as uniform an order as possible for the assemblies, e.g. (rack > drive unit > functional unit or similar)
*For all parts and assemblies, the number is given?

5.For all parts, the "Part Type" is given (not for assemblies) Upload the parts list
6.Upload the original CAD files in the original format of the software they were created with more info.
7.Upload of CAD files in STEP format more info
8.Upload technical drawings in PDF format or as graphic files (JPG, PNG, GIF), one drawing for each part, assembly, etc.
9.Linking of each production part or assembly of the parts list to the corresponding PDF files.

General notes regarding the upload of files:

1. Uploading graphics

*Search for file on local PC, make sure that file name is given with extension
*Fill in the "Destination filename" field:
*upload file
*The same files cannot be uploaded more than once, if a file has already been uploaded, it is sufficient to specify the file name with an extension in the "Destination filename" field

2. Check the box "Ignore any warnings", if necessary

Reviewer

A new comment is opened for each problem of a part in the part list, as a sign that a problem is solved, the reviewer writes "OK, FINISHED" at the end.

Following checks are performed by the reviewers: I.

Completeness of the part list through comparison with the drawings for the entire project and the assemblies
Completeness of the information on the technical drawings
Accuracy of the information on the technical drawings
Completeness/correctness of information for standard parts and buy parts
Enough dimensioning or quality of the parts concerning their functions (plausibility check, intuitive check)

Reviewer instructions:

To review a project, it's best practice to start with the assembly instructions: Please go through them thoroughly and make sure all the information to build the entire project is there. This includes:

Matching references to the components in the part list
The processes to build special parts or connect parts are describe well and are easy to follow.
And of course, please check if everything makes sense to you

Assembly The heart of the reviewing process is the part list. Every part of the project must be listed here with details that define the part precisely. You can make comments on every part of this list.

You should comment if:

1. The information provided is not enough for uniquely classifying the part.

* A link to a vendor is not enough, since links change!
* If you unable find the buy part on the internet with the information provided

2. Measurements or other specifications are missing in the drawings.
3. Specifications are there but do not make sense, concerning other parts, to the surroundings, etc.

*Note:If there is no specific field in the parts list, please add your comments.

Some specific requirements are depending on the type of part or assembly:

For each mechanical part, there must be at least a correct drawing in PDF and the original CAD-File. (This is to make sure that people can change the system by themselves. If they have the matching Software.)
3D-printed parts should come with a .stp file, besides the PDF-drawing and the CAD-File
PCBs (Printed Circuit Boards): directions of the parts.

*Note:If you have any difficulties in understanding or found mistakes please leave a friendly comment at the corresponding part. For issues regarding the whole project, there is an extra field in the part list, where you can leave your comments. After the issues are resolved please write a comment ending with: "OK, FINISHED"

Review co-ordinator

Review Coordinator first performs a pre-review, examines whether

1. All applicant data is complete
2. All project data are complete

*I.The parts list has been uploaded correctly, if necessary, as a 	structured part list (for example, if there are more than 10 or 20 	parts)
*Whether the structure of a structured part list is reasonable and 	consistent
*Each production part of the part list is linked to a PDF drawing
*PDF drawings are complete and correct (at first glance)
*Information on standard parts is suitable and correct
*Information about bought parts is adequate and correct
*An assembly instruction is available as required
*Other important data or files for the assessment process are 	completed.

3. If any data or files are missing, incomplete, or incorrect, the review supporter will work with the applicant to complete or correct them
4. If the existing CAD files are outdated, in unusual formats, or incomplete, it ensures that the CAD files are recreated
5. For interesting projects whose owners do not have time for the assessment process, the review supporter can also take over the function of the applicant, in which case the review supporter or the conformity assessment body and the owner are entered together as the applicant.

Conformity Assessment Body (CAB)

Confirmation form applicants and reviewers
Issue of the attestation of conformity.

Technology-specific Documentation Criteria (TsDC)

Contributing guide reviewer

Table of contents:

1. Thanks
2. Process steps

* Actual steps
* Documentation updates

3. General requirements to check
4. Technology-specific requirements to check.

Thanks

You just chose to join a group of essential supporters and fuel the global movement of open-source hardware with your professional expertise. By providing constructive feedback, you are not only supporting transparency and trustfulness of the term "open source hardware" but also improving the overall quality of technical documentation, the "source code" of open-source hardware. This document shall give you a quick and dirty introduction to the process. To look up details or to fulfill a strong desire for technical notation, please check the DIN SPEC 3105-2 (link) or get in touch with us (here ).

SCOPE

DIN SPEC 3105-1, DIN SPEC 3105-2, and the TsDC provide enforceable requirements for technical documentation of OSH. Developers may want to comply with them and someone else (the community) assesses that. A "conformity assessment body" moderates the whole process so

The procedure: community-based assessment
Roles & duties

The following terms are copied from DIN SPEC 3105-2 and needed to be aligned to definitions in international standards. Wording may appear weird in the context of OSH :

Client

Submits a stable documentation release to the CAB to get it reviewed and assessed according to DIN SPEC 3105-2
Point of contact for CAB and reviewers for questions and feedback regarding the submitted documentation

Reviewer

3rd party
Reviews are (almost) anonymous. The CAB can view the contact details of reviewers and may ask reviewers to make a public declaration on their conflicts of interest regarding the outcome of the assessment.

Conformity Assessment Body, CAB (e.g. OHO)

All actions in the assessment process are performed online and are publicly visible. This means that all information relative to the assessment process can be viewed online by anyone without any restricted access and is released under a free/open license.
which means that the CAB is "forkable" for anyone anytime

Process Step

Actual steps:

1.Client submits documentation release to CAB.
2.CAB

* checks some formalities and 
* opens the review process.
* CAB may invite selected reviewers to support the discussion

3.Reviewers

*1.	Check whether the document contains sufficient information so that users could effectively understand, reproduce, modify and operate the piece of hardware. Note that users/recipients are meant to be specialists in the corresponding field of technology (e.g. mechanical or electrical engineers). However, projects may define additional (probably larger) target groups.
*2.	Decide for each document they have checked:
  *"Approved" Document is good to go from your perspective.
  *"Approval subject to revision" You missed some important information or had serious issues understanding the document. → Please provide constructive feedback so the authors can fix this.

4.As soon as the whole documentation release has been approved at least twice, the CAB can issue an attestation stating the compliance with the DIN SPEC 3105-1. Reviewing is closed by then (but maybe reopened)

After the CAB has issued the attestation, anyone can submit complaints to the CAB. A complaint may, among others, be triggered in case:

The documentation release is not accessible anymore or parts of it disappeared,
he licensing terms have been changed and are not compliant anymore with the requirements of the DIN SPEC 3105-1 or
Any other relevant information has been changed or disappeared.

Considering the importance of submitted complaints, the CAB voids the attestation and reopens the documentation release again for reviewing.

Documentation updates Clients may submit updates of already attested documentation release. Identical, so already attested, hence approved, parts of the documentation keep their validity and don't need to be reviewed again.

General requirements to check

(for everyone) [DIN SPEC 3105-1]

1.It has been released under licensing terms complying with the OSHWA Definition 1.0 (e.g. CERN OHL v2)
2.In references of:

*its authors; 
*A functional description of the piece of OSH, e.g. what functions it 	is supposed to deliver, what is the problem it solves, for whom, 	etc.;

3.A mention of all applying technology-specific documentation criteria (see below);
4.All documents required by the mentioned technology-specific documentation criteria;
5.A name or working title is given to the piece of OSH

Technology-specific requirements to check (for everyone with adequate knowledge in the corresponding field of technology):TsDC