|
|
|
# Who cares?
|
|
|
|
|
|
|
|
CAB-Admins and eventually reviewers.
|
|
|
|
|
|
|
|
Issues on a GitLab instance are currently the most convenient way to run an assessment process yet compliant to _all_ operational requirements of DIN SPEC 3105-2.\
|
|
|
|
And this guide will show you a very time-efficient way to set things up for your next assessment using our ready-made templates :sparkles:
|
|
|
|
|
|
|
|
# The Procedure
|
|
|
|
|
|
|
|
…after having cloned the project and having all assignments and access rights clear (following [this guide](/Documentation/cab-admin-guide.md)):
|
|
|
|
|
|
|
|
1. Open the main issue `[assessment][main]`
|
|
|
|
2. Open all subissues e.g. `[assessment][STD]` and `[assessment][3D-printed]`
|
|
|
|
3. Link subissues in main issue
|
|
|
|
4. Rock'n'Roll. Let the review happen, close issues.
|
|
|
|
1. Reviewers will give approvals by their checkboxes; GitLab automatically comments this in the discussion history.
|
|
|
|
2. Once an issue is fully approved and closed by reviewers, double-check if reviewers did a responsible job and all relevant questions have been resolved → if so, tick the corresponding checkbox in the main issue.
|
|
|
|
3. Once all issues are closed by reviewers and double-checked by you (hence all checkboxes are ticked), close the main issue.
|
|
|
|
5. Issue the attestation :tada: following [this guide](/Documentation/cab-adminreview-guide.md).
|
|
|
|
|
|
|
|
## Main Issue
|
|
|
|
|
|
|
|
[main issue template](/Templates/[assessment][main].md)
|
|
|
|
|
|
|
|
In this issue you (and the reviewers) will keep the overview of what's happening.
|
|
|
|
|
|
|
|
- use `[assessment][main]` as issue title (those tags help distinguishing the issue categories)
|
|
|
|
- put the project name in the headline
|
|
|
|
- divide the assessment into reasonable subissues and assign min. 2 reviewers to each by putting their name tag next to the issue in the list (e.g. `@moedn`); as a rule of thumb one subissue each for:
|
|
|
|
- assembly
|
|
|
|
- standard components
|
|
|
|
- proprietary components
|
|
|
|
- parts of a certain kind so that 2…3 reviewers would be capable to resolve this subissue together
|
|
|
|
- place a copy of the bill of materials (BoM) for overview reasons
|
|
|
|
- the template includes a sample
|
|
|
|
- if a BoM copy doesn't make sense or would take too much effor to create, you can alternatively just link the BoM (e.g. by a relative link: `[BoM](/path-to-BoM.csv)`).
|
|
|
|
- link subissues by their ID (e.g. #2) once subissues have been openned
|
|
|
|
|
|
|
|
## Subissues
|
|
|
|
|
|
|
|
[Template folder](https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/tree/main/Templates)
|
|
|
|
|
|
|
|
### for Assembly
|
|
|
|
|
|
|
|
[assembly subissue template](/Templates/[assessment][ASM].md)
|
|
|
|
|
|
|
|
- use `[assessment][ASM]` as issue title (those tags help distinguishing the issue categories)
|
|
|
|
- update the headline (with real project title etc.)
|
|
|
|
- replace sample name tags (next to the checkboxes) by the ones of your assigned reviewers
|
|
|
|
- link all assembly-related documents either directly or the directory where they are located; e.g. assembly instruction, rationale, CAD model, assembly drawing in source (e.g. SCAD) and export format (e.g. STP, PDF)
|
|
|
|
|
|
|
|
### for Parts
|
|
|
|
|
|
|
|
[parts subissue template](/Templates/[assessment][someParts].md)
|
|
|
|
|
|
|
|
- use `[assessment][your-category]` as issue title (those tags help distinguishing the issue categories)
|
|
|
|
- update the headline (with real project title etc.)
|
|
|
|
- replace sample name tags (next to the checkboxes) by the ones of your assigned reviewers; _reviewers will need check each part individually_
|
|
|
|
- link all related documents per part either directly or the directory where they are located; e.g. rationales, schematics, 3D models, technical drawings in source (e.g. SCAD) and export format (e.g. STP, PDF)
|
|
|
|
- it is highly recommended to use one issue per part, to have a good overview. Of cause if it makes sense to put things together for review feel free to do so!
|
|
|
|
|
|
|
|
### for a Set of Parts
|
|
|
|
|
|
|
|
[parts subissue template](/Templates/[assessment][STD].md)
|
|
|
|
|
|
|
|
_specifically standard components or proprietary parts_
|
|
|
|
|
|
|
|
For those it usually makes sense to approve the whole set of parts
|
|
|
|
instead of approving every single screw.\
|
|
|
|
Thus the template includes just one checkbox per reviewer and
|
|
|
|
a BoM copy of all relevant parts and their references.\
|
|
|
|
Reviewers will only check those references.\
|
|
|
|
If a BoM copy makes no sense in the issue or
|
|
|
|
would take too much effort to create,
|
|
|
|
you can alternatively just link the BoM
|
|
|
|
(e.g. by a relative link: `[BoM](/path-to-BoM.csv)`).
|
|
|
|
|
|
|
|
- use `[assessment][ASM]` as issue title (those tags help distinguishing the issue categories)
|
|
|
|
- update the headline (with real project title etc.)
|
|
|
|
- replace sample name tags (next to the checkboxes) by the ones of your assigned reviewers |