Re: Effect of “should certainly do foo” in policy
On Fri, 29 Jan 2010, Russ Allbery wrote:
> Basically, it would be nice to have a standard terminology to distinguish
> between the following states:
>
> 1. You must (or must not) do this, and doing otherwise is an RC bug.
>
> 2. You must (or must not) do this, but doing otherwise is a normal (or
> important, or minor) bug.
>
> 3. You should (or should not) do this unless you really know what you're
> doing and have thought about the consequences, but there are some
> legitimate exception cases.
>
> 4. You're explicitly permitted to do this (used primarily when something
> else could be read as implying that you're not allowed to do so, or to
> be clear about what other software can assume).
>
> RFC 2119 says that the first is MUST, the third is SHOULD, and the fourth
> is MAY. It doesn't have a keyword for the second case. We currently use
> "must" for the first case, "should" for the second case, and "may" for the
> fourth case and have no keyword for the third case (but sometimes reuse
> "should" to mean that as well).
I think it would be a good idea to capitalize (or otherwise emphasize)
these terms when they are making a state as is typically done in RFCs.
To avoid using should for #3 as well as #2, we could use OUGHT/OUGHT
NOT (or some other similar phrase; NEEDS may also work.) [We could
also use should for #3, and ought for #2, but AFAICT, most of us
assume that should means #2, with some shades of #3.]
I agree that phrases like this would make policy more readable. It
also has the benifit of coupling each requirement/statement to the
severity of a bug when writing tests to check for compliance with each
requirement/statement.
Don Armstrong
--
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
-- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.html
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: