Minutes 13 Mar 2025

Host: Paul Albertella

Participants: Florian Wuehr, Pete Brink, Gabriele Paoloni, Stephen Oresanya, Igor Stoppa, Daniel Krippner

Agenda

• Updates on documents
• Trustable Software Framework

Discussion

Updates on documents

Pete shared set of criteria for document review (branch)

• Superset of criteria that we could apply
• Some of the document metadata may be superfluous if we are using git, but there can be value in e.g. document version numbering if we have a review workflow that is independent of the PR process
• Danger that documents can languish at a ‘draft’ level - would be useful to have a push towards making something useable

Gab: Would be useful to make the criteria specific for ELISA

Paul: Yes, idea is that we share the generic criteria and then specify which we apply for ELISA

Change control criteria should describe the objectives, rather than the mechanism

• Then we can describe how we achieve this for ELISA (using GitHub)

Reviewer competencies

• Daniel: As an open source project, shouldn’t we allow anybody to provide feedback?
• Pete: Yes, but how do we determine whether it is valid?
• Daniel: We can use a project-managed set of ‘approved’ reviewers
• Igor: Implies a ‘trust’ component in the review. Better criteria would be to have appeal to ‘indisputable facts’.
• Pete: There are problems of relevance or scope, even if facts are well established
• Author(s) should have final say about scope; maintainer(s) should have the final say over what is merged
• Some method of conflict resolution should be included, but we don’t necessarily have to have a procedure for that
  • Could have a ‘disputed’ section that is highlighted
• Pete: We can also use categorisation of feedback / violations to help with this:
  • e.g. Critical, Severe, Minor, Question
• Exit conditions: When are we ready to proceed? Where proceed might be ‘publish as draft’ or ‘request for comment’.
• Might be worth looking at the RFC process

Trustable Software Framework

Paul talked about how to apply the TSF in practice, using examples from the Safety Monitor project.

• Examples of Statements that are linked to TA, to:
  • explain (part of) how the project satisfies one or more of of the TA (Assertions)
  • provide evidence to support this, by referencing an artifact (e.g. file in the repo or result from a CI job)
• Nice example of how the project is addressing one of the TA
  • Using the rust's cargo-deny to verify that a dependency is still actively maintained
  • Daniel K: Using similar techniques with rust in this project