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!
- Could make sense to reduce this action to CAB-admins
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 by Nils Weiher