Skip to content

Minutes 14 Sep 2023

Jump to bottom
Paul Albertella edited this page Oct 4, 2023 · 1 revision

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Dana Vede, Daniel Krippner, Elana Copperman, Sebastian Hetze, Gabriele Paoloni

Agenda

  • Agree process/workflow for drafting and reviewing documentation
    • Draft as Markdown in Wiki
    • Informal review in weekly meetings or on mailing list
    • Use Pull Request for formal submission and review when ready
    • Grant participants access to OSEP GitHub repo and Wiki
  • Documenting "Quantitative and probabilistic methods summary"
  • Documenting models describing ways in which Linux may be involved in a safety-critical system

Discussion

  • Publishing documents - which licences should we use?
    • Creative Commons is standard choice in ELISA
    • If contributors are publishing something in their own name, there may be implications for others reusing or changing their work in other contexts
  • Drafting / publishing
    • How do we publish things with a level of ‘authority’ ?
    • Sebastian: Can use PRs to have an open process with clear evidence of review
    • Authority is required to give write access, approval and merge of contributions
    • What qualifications do we need to publish documents that make safety claims?
    • We should not make safety claims, but we might describe how claims might be constructed and supported with respect to Linux
  • Gab: Authority here is about choosing to publish something meaningful and correct
    • Maintainer (e.g. WG chair for the WG repos) of repo has this authority
    • Might have different maintainers for other repos (e.g. ks-nav tool)
  • Igor: Choosing to do things in a particular way implies competency
  • Pete: There is a software engineering competency model (SWECOM)
  • Daniel: Do we need this when we don’t have any results?
  • If we don’t document our assumptions and how we arrived at and checked our results, then how can we have confidence in the results?
  • Sebastian: Should have a disclaimer regarding our published results
    • May be useful to have a route for escalating questions to someone with relevant expertise
  • Need to start by describing the expectations about what we are producing, in a way that our potential audience can understand:
    • This means at least a ‘safety’ audience and a ‘Linux’ audience
  • Expectations for what we do: https://github.com/elisa-tech/wg-osep/wiki/Process-for-ELISA-working-group-activities
  • What do we want from a record / statement about competence?
    • Why can we trust what you are saying, or that you are able to effectively review material?
    • Pete gave a talk about this at a previous ELISA workshop
  • Sebastian: ‘Competence’ should not be a barrier to contribution
    • Pete: However, the competencies of a contributor or reviewer are important criteria
    • Sebastian: Because this is public, anyone who does believe that they are competent to review and critique what we are saying should be free to do so
    • Daniel: We use PR to control quality
      • Paul: Quality criteria that are used by an open source project may not be considered sufficient for a safety-relevant project
    • Paul: Competence is relevant for maintainers of repos (who can approve and merge)
    • Gab: we should not over-engineer the rules that we use to decide what to publish
      • We can always correct flaws or gaps in what we publish, but if we never publish them then other potential contributors are able to identify these
  • Igor: Perhaps better to focus on reasons for rejection: this is how competent people can add value - by explaining why a contribution is not fit for purpose, and perhaps point to external documentation that can help with this
  • Igor: Items to discuss in Munich? Should we discuss the memory integrity issue?
    • Paul: Happy to raise this for discussion
  • Pete: Linux Foundation class on SWEBOK may help
Clone this wiki locally