This somewhat repeats partly what is already stated in the introduction:

• Any of the items in this list might be skipped, if clearly and logically
  articulated reasons are presented.

How about "can be presented" instead of "are presented"? Otherwise it sounds like those reasons have to be documented. In cases it is not obvious why an exception was made, documenting it might make sense. But e.g. for exceptions to the coding convention I'd personally wouldn't like to "fill out forms to formally grant an exception" (purposely wildly exaggerating here).

@miri64: I deduplicated the section you quoted from the introduction and reused its wording.

The diff in content are now:

• The exceptions are broader to apply on all guidelines and explicitly also on the coding convention
• The need to document the reasons for the exception is weakened to can be presented

i'm not in favor of the proposed changes. (1) a separate section unnecessarily blows up the document. the statement is already prominently located (first bullet point). in particular, it is located up-front of Section 4. - Review the code against the coding conventions, which means it also applies to Section 4. (2) There is no reason to weaken the statement. usually, it is important to document exceptions. the description in the Coding Conventions is sufficiently flexible. ("shall" instead of "must")

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.