- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Sun, 20 Dec 2020 07:59:16 +0000
- To: public-css-archive@w3.org
https://www.w3.org/2020/Process-20200915/#errata > Working Groups decide how to document errata. Such documentation must identify the affected technical report text and describe the error; it may also describe some possible solution(s). Readers of the technical report should be able easily to find and see the errata that apply to that specific technical report with their associated tests. Errata may be documented in a separate errata page or tracking system. They may, in addition or alternatively, be annotated inline alongside the affected technical report text or at the start or end of the most relevant section(s). Thus, errata must indeed be maintained, but the WG now has a choice about how to do so, and inline in the spec is an acceptable way of doing it. > I think the checker is wrong, because the process document uses the term candidate corrections, as does the 2020 Rec text for Contain 1, while the checker seems to want proposed corrections. Thus, I believe the checker is wrong and should be updated to match the term used in the Process Document. Agreed. the process now recognizes both candidate and proposed corrections (as different stages of the same thing), and the checker should allow both. > I'm fairly sure that the precise form of wording that the checker asks for is not mandated by the Process Document Indeed it doesn't. I'll let the team figure out precisely what wording you want to allow and how you want to check for it, but the Process is not the constraining factor here. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5807#issuecomment-748576072 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 20 December 2020 07:59:17 UTC