Review of EFFSP doc

(EFFSP) for optional use by Eclipse Foundation Working Groups

This document contains quite a lot of "must" and "demands", but here we say the process is "optional". Can we clarify the criteria for WGs deciding whether to use this process?

The EFFSP is concerned with building software

Only "building"? Is this also for designing, developing etc? And is it applicable for use on pre-existing software?

moving releases of that software through certification

Is the intention that the process includes certification, or only prepares inputs for a separate certification process?

This document, and future revisions thereof will be approved by the Eclipse Foundation Board of Directors.

Saying this, it does not appear that any BoD members have signed off so far. Is the intention to have BoD members approve each merge request?

the terms of those documents shall take precedence

This order of precedence seems a little odd to me. If e.g. EFWGP takes precedence over a safety process, we may appear to have our priorities wrong. Perhaps we could state that any conflict would be escalated and resolved at BoD level?

Please see Functional Safety Committee.

Either there is a missing link, or this is redundant text.

deliver software, documentation, and Safety Manuals

Note that not all safety standards require a Safety Manual - for example ISO 26262 doesn't.

Requirement :: As defined by NIST

Other definitions exist, e.g. "Statement that identifies a product* or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability. (ISO/IEC 2007)".

Is there a particular reason for choosing the NIST version?

Safety Manual Project :: TBD

I'm unclear about the rationale for having a separate project for a safety manual but believe this may lead to extra complexity, work and cost.

Eclipse Foundation infrastructure must be used for all activities related to this Functional Safety Process

This is quite a bold statement - is Eclipse planning to invest in testing infrastructure etc?

with additional demands for Requirements management, Commits, and Code Review

It seems a bit odd to call out just these specific topics. As far as I know safety standards don't have anything to say about Commits, but they do care about architecture, unit testing and lots of other things not mentioned here.

first class artefacts and their management a first-class development activity

Not sure what is meant by "first-class" here. Should we consider introducing (and defining) the word "normative"?

GitLab or GitHub issues are not suitable for tracking requirements.

I don't disagree, but it seems strange to call this out?

As a best practice, the EMO recommends that each Requirement be captured in a separate file, using the identifier of the Requirement as the file name (plus a format-appropriate extension).

Not sure this is worth calling out either?

All commits that involve changes to software or tests must correspond to a Requirement.

We state this, but then contradict it in the very next sentence. In any case I suggest this statement is unworkable in practice.

All commits that involve changes to the software or tests must have a commit message that has a meaningful summary and body.

There are best-practice guides for commit messages - does EF already have something we could refer to, rathe than this sentence?

explicit code review

What is meant by this?

by at least one other Committer before being merged into the main branch

As far as I know safety standards tend to have expectations about safety competence/experience in contributors and reviewers - should this be considered here?

Safety Manual projects (SMP) leverage many of the notions of Eclipse Projects as defined by the EDP, but are not open source projects

I'm new here, but to me this seems quite a risky strategy for EF. Given the intention is not open source, I'll not comment further on SMP content.

Exceptions to this process may be granted only with approval of the Executive Director

Is the expectation really to have all changes approved at Director level? With no mention of approval from a safety perspective?