Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • OSEGeV Conformity Assessment Body OSEGeV Conformity Assessment Body
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 40
    • Issues 40
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OSE Germany e.V.
  • Projekte
  • CAB
  • OSEGeV Conformity Assessment BodyOSEGeV Conformity Assessment Body
  • Issues
  • #59

Closed
Open
Created Jun 07, 2021 by Nils Weiher@nilesOwner

CAB Assessment-Procedure

Learnings from the CAB-Administration

Administration

  • currently gathering experience in how projects work and how to create the workflow around them
  • Still a lot of handwork (Uploading, create issues)
  • Time consuming and eventually time blocker during the assessment
  • Structure
    • BOMs are usually in a very very different structure
    • Therefore individual solutions required for structuring the assembly groups!
    • Not any project uses version numbers

Questions

  • How to make sure that issues related to changed components are "notified"?
    • Current Procedure: Applicants and reviewers communicating in the issues
  • How to deal with changes that effect already reviewed components?
    • strictly viewed the component must at least be quickly re-evaluated
    • Current Procedure: Applicants and reviewers communicating in the issues
  • Should the REVIEW branch be a SNAPSHOT
    • can not be changed by applicants / reviewers
    • AND: Do we at all need a review branch?
  • Should applicants commit the changes on their own into the assessment repo?
    • Could make sense to reduce this action to CAB-admins
      • More control
      • But also more work!

Guide

  • Communicate the desired workflow with the projects applicant
    • Make sure the "rules" are clear

Application

  • Still a bit unclear WHO is uploading / committing WHAT and WHERE
  • Difficult to adjust product development to the review process

Questions

  • Who are the TARGETS of the designs? In other words - which knowledge can be assumed?
  • What are the exact requirements for the review? How to deal with unclarities? Unless they are unclear the discusscion might become endless...

Guide

  • Communicate your changes
  • Ideally apply 1 change per commit
  • Mark the relevant issues in your commit!!!

Review

  • A lot of questions are still open
    • to which depth the technology should be checked?
    • Complex technologies require detailed information for tolerances?
  • Communication could be more active

Guide

Ideas

  • Levels of Assessment
    • Eventually we will need different levels of assessments, to show if a technology is more DIY (low-tech, low demand for details) or or professional (complex, high demand for tolerances)
  • Organise meetings with reviewers and applicants for an exchange
Edited Jun 08, 2021 by Nils Weiher
Assignee
Assign to
Time tracking