Re: New WG proposal: Safety Engineering Process


Paul Albertella
 

Hi Lukas,

Thanks very much for your supportive words and thoughtful feedback!

Responses inline below.

On 14/09/2021 17:36, Lukas Bulwahn wrote:
My preference on naming, hence, would be on:
- Evidence WG
- Claims on Open-Source Software WG
- Open-Source Engineering Process WG
The name is important, just for newcomers and outsiders not to set the
wrong expectations.
Agreed!

The consensus in the last Dev Process WG meeting was that the name needed to have the word 'safety' in it (as with the Safety Architecture WG) to make it clear to participants that safety is explicitly in scope for our discussions!

Participants expressed a concern that 'Evidence' and 'Claims', while descriptive of the intended *approach* for the group, do not clearly express its intended *scope* (Claims about what? Evidence of what?). 'Engineering Process' was therefore proposed as the best overall description of this scope.

However, I believe that the intention with the proposed name was to focus on the role of 'Engineering Processes in Safety', as opposed to 'Processes for Safety Engineering', so the name may need a rethink.

Let's discuss this in tomorrow's WG meeting.

(Linguistic sidebar: The English language is renowned for its imprecision and ambiguity when building compound descriptors in this way, because it lacks clear grammar rules to aid parsing!)

I do not know if LTP (it stands for Linux Test Project, right?) is a
community or organisation; I would really just think LTP stands for
the test suite itself, i.e., the source code in the repository.
I mentioned LTP because it is both a consumer of Linux and a source of of potentially relevant engineering process material (test suites) that relate to it. If we wanted to analyse that material, and the processes around it, then we could gather evidence from the project's mailing list, Github project, and documentation (see http://linux-test-project.github.io/).

However, we wouldn't *necessarily* plan to use evidence relating to the work of LTP as a community/organisation to directly support our claims about Linux. We might instead consider how the LTP's processes, and the materials that it generates and maintains, might potentially be re-used by an organisation incorporating Linux as part of a product, to generate supporting evidence as part of *its* engineering processes.

I wrote:
As part of this work, we also plan to write a summary of the results and
conclusions of the work done by the Development Process WG, which will
also be made available in an elisa.tech Github repo. This is intended to
provide background for new participants and other WGs, as well as a
baseline / conceptual framework for the work of the new group.
Lukas wrote:
I think that is quite important; it might also be a separate group
(the continuation of the development process WG; those that have
invested and learned something in that group) but certainly should
happen. I would be very interested in the overall summary, results and
conclusions. I got lost on the way on what the consensus and lessons
learned really were in the course of all the discussions.
I certainly agree that this will require contributions and review by the members of the Dev Process WG who were involved in the historical discussions, but I think it makes sense for the new working group to 'own' it as an activity.

Note that I'm *not* proposing to devote WG sessions to authoring or reviewing these materials. The goal would be to identify topics that we would like to cover, ask for volunteers to write them up and submit the material in a GitHub PR, and reviewers to read and comment on these. We'll then regularly review progress in WG meetings and decide when contributions are ready for for 'publication' (merge into mainline).

If this activity come to dominate the new WG discussions (or we don't find time to do it!) then we might alternatively plan to have a monthly working session devoted to this.

Regards,

Paul

Join {devel@lists.elisa.tech to automatically receive all group messages.