Manoj Srivastava <[EMAIL PROTECTED]> writes: > Hmm. I think I like the idea of the policy documents being the > law, and the technical committee like the justices, who lay down > interpretations (which are referred to latter as and adjunct to prior > law).
The committee does more than interpret. They can decide that a debated section of policy is completely wrong and choose a compromise which reverses it for example. > I still find the wording confusing. "All that policy can say > is whether something conforms to or does not conform to policy". Yes, specifically it can not say that... > policy ought to (should) be followed (is that not an oxymoron?). > I am not required to follow it, and yet it is authoritative to > bug filers; I an see a lot of contention developing there. (and > again, the tech committee is brought in.) Yes, that's why Ian proposed defined qualifiers for the various policy sections. We (developers) just assume that policy is correct until the tech committee tells us otherwise. If, for example, I choose to violate policy, I had better have a really good reason. In most cases it's clear to all concerned that the reason is valid, and we have to amend policy, or that I'm wrong and should make my package conform. If I'm really stubborn and insist that my reason is valid, I can ask the tech committee to make a decision. They might say that that section of the policy is correct, and I should conform, or they might agree with me. So we really just continue debating policy as we always have been. > who likes the quiet certitude of the ISO standards Putting the policy in that light really does put too much power in the policy maintainer's hands. Guy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
