How to tell if an issue is editorial

Editorial issues fall into two broad categories:

• Problems with the presentation of the specification, which, when fixed, would not alter the (intended) meaning of the specification. Typos and obvious inconsistencies fall into this category.
• Inconsistencies between working papers voted into the draft and the actual text of the draft. Forgetting to include a section of a voted-in paper in the draft is an example of such an issue. These issues may be considered editorial even if they change the meaning of the specification, since they are easy to verify and generally fix the intended meaning of the specification.

Most editorial fixes fall into the first category of presentational issues. Some examples include:

• Typos.
• Formatting errors (e.g. inline text that should be in typewriter font but is not).
• Internal inconsistencies (e.g. two different declarations for the same function overload, when it is clear which is the correct declaration).
• Unclear writing, when the intention of the text in question is well-known to the committee, but the presentation could be clearer.
• Incorrect usage of Standards Wording Idioms.
• Anything that changes non-normative text. Non-normative text is contained in code examples and notes (the ones that start with "[Note -" and end with "- end note]") and does not have any bearing on the meaning of the standard. Changes to such wording can usually be done by the editor when requested.

If you are not sure whether your proposed edit falls into the above categories, you should consider submitting it as a technical issue instead.