From the time that FPC was formed, we've had the understanding that unless we write guidelines with specific entries for every single package in the distribution, for every rule we make there will be a package which needs to break it. So there's been an unwritten rule which basically says that if you just can't obey some guideline or another, you document it in your specfile and move on, and if you get into a fight with a reviewer over it, eventually you'd go to FPC, FESCO, etc. This is why the guidelines sometimes use "must", sometimes use "should", and sometimes just make suggestions.

Prompted by the recent FESCo ticket https://fedorahosted.org/fesco/ticket/1587 (regarding "offensive" package names) and the related discussion in today's FESCo meeting, I decided to propose that we codify this policy by adding something like the following section near the top of the main guidelines page.

Begin draft.

== General Exception Policy ==

These guidelines can never cover all possible contingencies, there will always be packages which need exceptions. It is the packager's responsibility to follow these guidelines as closely as is feasible and to clearly document, as comments in the package specfile, instances where they cannot be followed.

If, in a guideline, the language "should" or "is suggested" is used and it is not feasible for the package to conform to that guideline, the packager may deviate from the guideline. The deviation MUST be minimal, and both the nature of the deviation and the reasoning behind it MUST be documented in the specfile.

Where the language "must", "is required to" or "needs to" is used, the packager may deviate from the guideline only with approval from the packaging committee. Please follow the procedure at https://fedoraproject.org/wiki/Packaging_Committee for making these requests. (XXX Add the procedure there and use a link to the subsection.)

End draft.

This also highlights the need, which I have long tried to avoid, for using more precise language when it comes to indicating the strength of guidelines. I generally prefer that they read as English instead of Lawyer, but I guess it's time to tighten things up. I can see three states: MUST, SHOULD and "is suggested/is recommended/please consider", where the latter is just a something the packager can ignore without an explanation. If we pass this draft, I'll start going over the existing pages to tighten up the language.

And yes, I know I have enough on my plate already, but I saw this as a way out of this mess without having to worry about writing a guideline on "offensive" package names.