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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
