Add GOALS.md, revise contribution process, freshen up to use arewesafetycriticalyet.org #149
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,44 @@ | ||||||
| # Goals | ||||||
|
|
||||||
| ## Elevator pitch | ||||||
|
|
||||||
| We will make Rust coding guidelines available within this repository. The coding guidelines will additionally be deployed to an accessible location on the internet. These coding guideliens will comply with relevant standards for various safety-critical industries such as: IEC 61508, ISO 26262, and DO 178. | ||||||
|
|
||||||
| ## Detailed | ||||||
|
|
||||||
| In general these coding guidelines will be a set of rules of do / do not do with examples which should cover all "general" aspects of the Rust programming language, e.g. enums, structs, traits, and so on. We will use the [FLS](https://rust-lang.github.io/fls/index.html) as a means to ensure we have a reasonable coverage of the language. | ||||||
|
|
||||||
| There will be an addendum which covers how various safety standards like ISO 26262 map onto the coding guidelines. | ||||||
|
|
||||||
| ## Criteria | ||||||
|
|
||||||
| * We produce coding guidelines that make a "best effort" attempt at cataloging common pieces (e.g. functions, arithmetic, unsafe) of the Rust programming language and how they fit into a safety-critical project | ||||||
| * We will use [MISRA Compliance: 2020](https://misra.org.uk/app/uploads/2021/06/MISRA-Compliance-2020.pdf) for categorization | ||||||
PLeVasseur marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||
| * We include a rationale with links to parts of the Rust Project and wider Rust community for guidance | ||||||
| * We will include linkage where appropriate to to various standards, e.g. CERT C, MISRA C, DO 178, ISO 26262 | ||||||
| * We will include practical recommendations on how to use this piece of the language using compliant and non-compliant examples | ||||||
| * We will develop an addendum matrix to reduce burden of attaching these later | ||||||
|
||||||
| * We will begin with DO 178 and ISO 26262 at perhaps chapter level, maybe subsection level _for now_ and expand later | ||||||
|
||||||
| * We will release the coding guidelines tagged with the versions of stable Rust that they support (e.g. `1.42`) | ||||||
| * We will find or create Clippy lints which will cover decidable guidelines | ||||||
|
|
||||||
| ### Criteria obtained by discussion with Tooling Subcommittee | ||||||
|
|
||||||
| * We will affix a label for each guideline, which describes whether said guideline is decidable or not (in the [theory of computation sense](https://en.wikipedia.org/wiki/Decidability_(logic))) | ||||||
| * We will include for each guideline a minimum of one compliant and one non-compliant example of code, to help illustrate its exact meaning and context. | ||||||
| * We will consider only the language reference / spec, not the tooling availability when writing the coding guidelines | ||||||
| * We aim to produce evidence-based guidelines, with statistics around human error when programming Rust, to support: | ||||||
| 1. What guidelines are written, and | ||||||
| 2. Why a specific suggestion was made | ||||||
| * We will produce the guidelines in an artifact that's easily machine readable and consistent format to make it easier to consume by tool vendors to some minimal viable artifact. | ||||||
|
||||||
| * We will produce the guidelines in an artifact that's easily machine readable and consistent format to make it easier to consume by tool vendors to some minimal viable artifact. | |
| * We will produce the guidelines in an artifact that's easily machine readable and of a consistent format, to make it easier to consume by tool vendors to some minimal viable artifact. |
This one is hard to parse. I assumed there's a missing "of a" and a missing comma in the middle.
But I'm still not 100% sure what we mean here.
- An artifact that's easily machine readable, got it, perfect.
- Of a consistent format, nice.
- (1) and (2) are there so that these are easier to consume by tool vendors. Awesome.
- ... but then we say "to some minimal viable artifact". Maybe it was "to some minimally viable artifact", but I'm still not sure what that means in the context of everything else.
Maybe this needs to be split into multiple sentences? Maybe multiple bullet points. Whatever we may need to express what we mean to say here, is good :3
There was a problem hiding this comment.
I'll give some thought to point 4.
There was a problem hiding this comment.
Addressed in 01e2a2c
PLeVasseur marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
I wonder if a link to what we mean by "subset the language" would help.
You and I know exactly what we mean by that, and people who have worked with MISRA probably understand the concept as well. But I wonder if other folks who work on Safety Critical know about it too?
Maybe there's a reference we can point to, that explains the concept?
There was a problem hiding this comment.
Perhaps it is better to simply omit the point. It doesn't seem that important to mention the method for shipping something
| * "Something" shipped to alleviate pressure at organizations is better than "nothing is available" even if we have to heavily subset the language | |
| * "Something" shipped to alleviate pressure at organizations is better than "nothing is available" |
There was a problem hiding this comment.
I'll add another bullet point to clarify what I mean and why for subsetting the language. I do think it's important to make this obvious as it's an accepted means of allowing certain parts of the language and not others by IEC 61508 and ISO 26262 (and possibly others).
There was a problem hiding this comment.
Addressed in 25cae3b. Please give this a read-through and let me know.
Uh oh!
There was an error while loading. Please reload this page.