Updates to Documentation criteria missing rationale and implementation details #159
Conversation
SecurityCRob
commented
Jan 24, 2025
SecurityCRob
commented
…n details <title> Signed-off-by: CRob <[email protected]>
| Alternatively, the project could published their | ||
| desired support and duration through such outlets | ||
| as a project blog, mailing list, or FAQ. |
There was a problem hiding this comment.
I think the challenge here (and part of why this should be level 2 or level 3) is that there is no standard place to find this information for a project. For example, Istio data is fetched from https://istio.io/latest/docs/releases/supported-releases/, parsed through the selector: table argument and then run through a few regexes ('^~?(?P<value>\w+ \d+(, \d+)?).*', for example).
I'd love to see some better standards here, but I'm nervous about making this a requirement without a clear way to measure compliance or for consumers to use the result. If we want to push security-insights, we could try to enforce that as a mechanism, though I think current adoption is fairly low.
There was a problem hiding this comment.
As much as I desire one location to store this, it has never naturally developed over the last decade(s). As we roll this out as a standard for LF projects, we could be more prescriptive with how this should be implemented (and automated/templatetize it for our projects) then as others saw it, they could possibly adopt that location.
There was a problem hiding this comment.
Yes, that's what I'm advocating for. I think it's okay to take one or two items and say "hey, here's a standard place to put this" and people will either create the file or symlink it if the requirements are fairly easy to fit with their existing content. In turn, that will make the work of folks like endoflife.date easier.
I suspect it's part of a more-mature project, so at least level 2 (my other PR, no need to include it here).
There was a problem hiding this comment.
One thing that occurred in discussion this week in Minder was that projects using GitHub releases could actually update existing releases to include some release text indicating when a release is out of support.
I'm not sure what similar options are available for container images, helm charts, and language packages.
There was a problem hiding this comment.
My $0.02 is that DO-14 is more practical for non-archived (unsupported) projects. People often don't know until after it's done that a project will be unmaintained in a few months or a year.
Relying on the archived bit seems tricky -- how do you distinguish between a project which is "done" (e.g. https://github.com/yosida95/uritemplate) and a project which is abandoned to the point that no one can hit "archive"?
The best I've come up with is having some sort of sentinel "heartbeat" file that needs to be touched every ~year that says "In 2025, this project was supported by $entity".
Maybe we could pivot this to that format?
adjusted text to attempt to meet Evan's ask Signed-off-by: CRob <[email protected]>
