Aug 12, 2024 ‐ 15:00 UTC

Host:

• Philipp Ahmann

Participants:

• Alfred Strauch
• Steven Carbno
• Karen Bennet
• Nicole Pappler

Regrets:

• ...

Attended Recently

• Guy Lunardi
• Andreas Bartelt
• Thomas Mittelstädt
• Stewart Hildebrand
• Kate Stewart
• Olivier Charrier
• Walt Miner
• Daniel Weingaertner
• Axel

Topics & Notes:

Check past action items

• ...

Project Proposal: Good Quality Practices in Open Source [cont.]

• Draft
• Conclusion from last meeting: Bring the "objective of proposal" forward so that it can form a base for "whatever kind of funding/financing".
• Related paper: Open source software development process: A systematic review
• Recent discussions inside ELISA
  • We should check which good practices regarding quality and OSS already exist.
  • We recent standards are under preparation for quality management of software (hardware or systems) taking into account CI/CD practices
  • Have a clear goal on what we want to achieve with "a new standard".
• Most QM systems are start with formal requirements where Open Source is different and also modern CI/CD driven SW development often starts with code.
  • Artifacts are hardly visible and the process is not fully formally described (mainly how-tos)
  • This also relates to the Safe Systems with Linux MC at Linux Plumbers
• In self driving car space they feed accident/incident reports and let AI prepare regression tests. Can this be something also for open source?
  • This may also need to create a requirement out of the reports.
• The issues for functional safety is essence of the discussion. How can you say something is good or sufficient?
• What is quality practices and what is quality? How is the relationship between safety and quality?
• Is there a way to define a threshold for good enough? At the end even the assessor is seeing numbers, but only has confidence and not a number saying "good enough".
• Can it be easier to say what is insufficient? This may be far easier to say: If you don't meet this threshold it is clearly insufficient.
• The impact also defines the rigour which need to be taken and judge sufficiency/insufficiency
• Components and interaction of components makes the process also more complicated and how does a continuous validation process look for a single and for a set of components.
  • This topic is explicitly interesting for product developers and integrators/distributors.
  • Distributed systems add another dimension to the complexity.
  • It can also be a moving target when phrasing a standard or best practices and measuring the "good enough" state.
• Above points can be integrated in the motivation to define a clear goal of the good practices standard.
• Karen may be able to share some references for papers also handling the topic.

AoB

• Karen Bennet: Works in automotive and with AI, brings interest with ISO & IEEE and where they do a lot of best practices.