Normative meanings for policy directive wording (was: Effect of “should certainly do foo” in policy)
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> On Sun, Jan 24, 2010 at 11:19:33AM -0800, Russ Allbery wrote:
> > The ideal solution would come as part of a general Policy rewrite to
> > use more formal and precise language.
>
> I am not sure this is desirable. The policy is a technical document
> and not a legal document and should be easy to read. We should assume
> that developers will interpret policy in good faith and not try to
> find loop-hole to justify package brokenness.
That isn't the failure case I see very often, and I will presume to
speak for Russ by asserting it's not the case he's primarily aiming to
address.
Much more common is the case where several people have, in good faith,
come to contradictory interpretations of the policy. The damage from
this is extensive, as I'm sure we can recall from countless arguments
with more heat than light about what Policy intends to say.
So relying on good-faith interpretations is clearly insufficient: where
feasible, and without significantly impeding readability, I think we
should be (re-)wording Policy to avoid these ambiguities.
> Making the policy language less natural will negatively affect
> developpers that read policy to follow it in good faith.
“More formal and precise” doesn't necessarily mean “less natural”.
Precision of wording, and standard use of terms throughout a document,
can often make the document much more readable.
A specific suggestion that I like from Russ is to adopt the RFC 2119
definitions of directive words: must, must not, may, should, and so on.
Those have long been proven effective in technical documents, and as a
native English reader I don't find they detract at all from the natural
use of language.
--
\ “We can't depend for the long run on distinguishing one |
`\ bitstream from another in order to figure out which rules |
_o__) apply.” —Eben Moglen, _Anarchism Triumphant_, 1999 |
Ben Finney
Reply to: