Closed bblfish closed 1 year ago
This is what people call a editorial change, so I don't think I need to wait that long to let it go through, as it fixes an obvious error.
Agree that this is editorial and in the interest of being practical, these kinds of changes done in good faith do not need significant reviews / process, IMO! Moreover, this change falls outside of the technical reports, and more specifically general operational content / guidance / navigations etc. So, that's generally the Chairs call. It is not coming out of the blue either. You've linked to prior discussion that has rough consensus. Good to go! And, having a PR is good notice but it could be done without it too - depending on other things that may be part of the process or repository set up, e.g., could've made the commit directly into main and linked to the issue in the commit comment. So, it is trackable in any case.
On a related note, for changes pertaining to specifications, I suggest adopting W3C Process's https://www.w3.org/2023/Process-20230612/#correction-classes where PRs indicate which correction class the proposed change is intended to be. It communicates to the reviewer how they should approach their review which can also set expectations on how long the review period could be. It is good information for the changelog in the specification. We have this going in Solid specifications now (which was previously a practise in the PR): https://solidproject.org/ED/protocol#changelog . Bonus: each change entry is machine-readable.
Thanks, I'll commit to this PR then.
As you understand these new processes well, do you know how to make a PR that would make this effective here?
Also should the README be moved to the root so that it is more visible? (it may have been an artefact of mercurial's setup that it is in the specs folder.
fix for issue #18