OSEGeV Conformity Assessment Body issueshttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues2021-11-29T12:00:31+01:00https://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/23Feedback Collection Helper2021-11-29T12:00:31+01:00Nils WeiherFeedback Collection HelperHelper to link comments for feedback.
Just add `CAB#23` to any issue (e.g. by answering a relevant comment) and the issue will automatically pop-up as a "mention" here, so we can harvest it for feedback later.
Brilliant, isn't it? :)Helper to link comments for feedback.
Just add `CAB#23` to any issue (e.g. by answering a relevant comment) and the issue will automatically pop-up as a "mention" here, so we can harvest it for feedback later.
Brilliant, isn't it? :)CAB Feedbackhttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/43CAB Assesssment Criteria2021-07-05T10:57:23+02:00Nils WeiherCAB Assesssment CriteriaWhat are the criteria for the assessment of a project:
- Reproducability
- e.g. Availability: Can the part currently be purchased in a shop **with international shipping**?
- Assessment
- What are the relevant criteria for the asses...What are the criteria for the assessment of a project:
- Reproducability
- e.g. Availability: Can the part currently be purchased in a shop **with international shipping**?
- Assessment
- What are the relevant criteria for the assessment instructions?
- BOM
- Parts
- TSDC Technology Specific Documentation Criteria
How to deal with unconfirmed Open Source Hardware
- distinguish Open Source Hardware according to DIN and OSH with self-assessment
- transparent communication in the issueCAB Feedbackhttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/49Review Documentation2022-03-17T10:41:14+01:00Nils WeiherReview DocumentationAdjust the review documentation with the experiences from the current review.Adjust the review documentation with the experiences from the current review.CAB Feedbackhttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/53Clear definition of requirements missing2021-06-28T17:49:03+02:00Leonard MöllerClear definition of requirements missing> engineers shall be enabled to fully understand, build and modify the design only by the given documentation
This is very broad and could depends very much on knowledge and experience.
some questions that came to me:
- Should the proj...> engineers shall be enabled to fully understand, build and modify the design only by the given documentation
This is very broad and could depends very much on knowledge and experience.
some questions that came to me:
- Should the project include assembly instructions?
- If it doesn't, how much time should it take to collect the information from the 3D-Model?
- If it does, should it always be 100% synchronized with the 3D-Model?
- What should be explained in the BOM? Should I be able to find a suitable part with those information only or do is it fine to have e.g. the suitable versions of an arduino board in the code section rather than the BOM?CAB Feedbackhttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/59CAB Assessment-Procedure2022-01-10T13:27:18+01:00Nils WeiherCAB 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 eventua...# 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 exchangeCAB Feedbackhttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/70Assessment level (DIY/Industry)2022-01-10T14:45:29+01:00Nils WeiherAssessment level (DIY/Industry)Here is some valuable insight to the idea of diverging prerequisites regarding the documentation:
> Hello Nils, Lukas, how are you?
>
> I still have to work on some little missing items in my documentation. I´ll keep you updated on tha...Here is some valuable insight to the idea of diverging prerequisites regarding the documentation:
> Hello Nils, Lukas, how are you?
>
> I still have to work on some little missing items in my documentation. I´ll keep you updated on that.
>
> Anyway, I wanted to share a thought that came to me following last week's online meeting. In reality, it's pretty much the same stuff I've been saying about my needs before, except better, I think.
>
> At the meeting you commented on an idea regarding the specs to be specified in 2 different levels: "DIY" or "industry". And that is closely related to what I´ve been dealing with on my project since the beginning.
> In my case, I want my documentation to be used by the industry, but it is not as detailed as it should be. Because of my lack of some technical specific knowledge, it looks more like DIY...
>
> So my thought is that it would be fantastic if manufacturers could take a DIY project documentation (not just my case, but any DIY level project) and upgrade it to industry standard. As a result, the company becomes a contributor/documenter/backer/co-author to that project.
> That option, I feel, might be a significant component of the OSH DIN standards program and should be actively pushed. Even as an invitation to the entire business to participate in and contribute to the Open Source Movement, not simply as users but as developers/contributors.
>
> As a result, the documentation improves because it is redacted by people who are well-versed in the field particular for each project. Furthermore, Open Source initiatives would reach the industry and, eventually, more end users.
>
> That's what I've been looking for with my project. I am certain that my innovations have the potential to benefit a large number of people and companies, but I have yet to reach them... And I'm guessing I'm not the only one in this situation.
>
> I hope you get my point, and that you find it relevant.
> Thanks again for your support!
>
> Happy New Year!
@isabbioni
We are definitely going to discuss this in the future!CAB Feedbackhttps://gitlab.opensourceecology.de/verein/projekte/cab/CAB/-/issues/71Review Feedback Collection2022-01-20T11:41:26+01:00Nils WeiherReview Feedback CollectionStatements given by reviewersStatements given by reviewersCAB Feedback