RFC: MnemOS Technical Readiness Levels #229
Conversation
|
Open design question(s):
|
|
Also, for anyone who hasn't seen NASA's TRLs, that was a vague inspiration, but not mapped 1:1 due to the differences in context + expectations. |
| * A: Production Level - paid support available | ||
| * B: Ready for general usage | ||
| * C: In wide usage | ||
| * D: In Implementation | ||
| * E: In Design/RFC/Experiment | ||
| * F: Early proposal | ||
| * G-W: Reserved | ||
| * X: Deprecated | ||
| * Y: Retired | ||
| * Z: Declined |
There was a problem hiding this comment.
i'm not convinced that letters are the best naming scheme here. they do indicate an ordering of states, which is valuable, and give the states a very short name, which is also potentially valuable. however, it's not super obvious what they mean if documentation just states that something has TRL "A" --- the reader has to then go look at the docs to see what TRL "A" means. it might be better to indicate that the names of the TRLs should be used in documentation, rather than the letters, and the lettering/numbering scheme should be used primarily internally to this document?
so, for example, the docs for a component maybe should generally say:
Technical Readiness Level: Production-Ready (A)
rather than
Technical Readiness Level: A
what do you think?
There was a problem hiding this comment.
Yeah, I think there's something to be said about abbreviations being convenient for those in the know, and confusing for those that aren't.
We could also ditch the letters and give each level a punchy one word name to keep things easy to include and repeat.
| * Strictly follow semver and have a version >= 1.0.0 | ||
| * Have basic documentation | ||
| * Have some testing | ||
| * Are used across the MnemOS project and platforms | ||
|
|
||
| ### C: In Wide Usage | ||
|
|
||
| This level is considered general mature, though it may have "rough edges" or may not be mature when used outside | ||
| of the way it is currently employed. | ||
|
|
||
| This level is intended for components that are already used and seem to be working fine, but have not yet been | ||
| thoroughly documented or tested for robustness. They are likely in use in one or more places in the MnemOS | ||
| repository, and likely have been mostly stable for a reasonable amount of time. | ||
|
|
||
| Developers should expect that components with a "C" MTRL are likely to work, but may require additional care | ||
| and verification, particularly when integrating into a new application or platform. It is likely possible to | ||
| sponsor efforts to move a component from MTRL "C" to "B" or "A". | ||
|
|
||
| Components with a "C" MTRL: | ||
|
|
||
| * May not strictly follow semver, and may have a version < 1.0.0 |
There was a problem hiding this comment.
it occurs to me that we have a TRL that's like, "follows semver, and is >1.0" and "doesn't follow strict semver, and is < 1.0". it might be worth having something for "follows semver strictly but is pre-1.0"?
There was a problem hiding this comment.
It's maybe worth noting that an MTRL C could be pre-1.0 and strictly follow semver.
Basically: if there is a meaningful stratefication you can think of here, happy to insert a C+/C- category, but I'd rather have a specific reason for stratefying them that way, rather than just to fill the 2x2 matrix of "follows semver" and "is >= 1.0".
1.0 and not-1.0 could also maybe be better described as "actually cares about version number and/or is published" and "lol whatever's at the tip of main goes".
There was a problem hiding this comment.
I think that "follows semver" vs "may break at any time" and "follows semver, with frequent semver changes" vs "follows semver, is 1.0 and won't churn versions frequently" are maybe two different level distinctions, but honestly, 🤷♀️
|
do we wanna go ahead and merge this? i'm happy to adopt the TRL scheme, at least provisionally, and we can go back and change the TRL system later if we want to. |
This RFC proposes a set of readiness levels that can be applied to components and features
of the MnemOS project.