Eric Herman
Eric Herman
Revisiting the back cover text may be a good starting point; regardless, we should ensure that the executive summary and back cover text are aligned.
Looking at d0dbb84d94b3bd26427f5d2f37a0ced9687c039c ( and #339 ) the change from "email address" to instructions essentially combined the two requirements; I lean towards deleting the SHOULD.
incorporate this in https://github.com/publiccodenet/standard/issues/216
It seems https://www.technical-communication.org/tekom/publications/specialist-books/detail/standards-and-guidelines-for-api-documentation costs 70 euro.
Indeed, the documentation requirements are still vague, there is now reference to high level architecture and that source code should be documented at various levels. Not all software will have...
> The problem here is that we can't generate them after the fact as the `id` for these needs to be version controlled as well as they are both parts...
As discussed, I'm closing this now. If someone wishes to put forward additional guidance in the Standard for Public Code, then we will re-open this. Real-life examples should be highlighted...
Would it be more clear to make it a SHOULD NOT? Perhaps: * The code SHOULD NOT require services or platforms available from only a single vendor.
@jgroenen the code angle of the SHOULD NOT that you propose is covered by another criterion, but the services is a gap, your phrasing really "zeros-in" the lock-in aspect, maybe...
Given the changes to _Document codebase maturity_ from #729, is there still something we want to do with this issue?