Sean Hunt wrote: > Roger Hicks wrote: >> On Wed, Sep 16, 2009 at 01:00, Ed Murphy <emurph...@socal.rr.com> wrote: >>> Detail: http://zenith.homelinux.net/cotc/viewcase.php?cfj=2682 >>> >>> ============================== CFJ 2682 ============================== >>> >>> It is POSSIBLE to increase a player's voting limit on an >>> ordinary decision by playing a Roll Call card. >>> >>> ======================================================================== >> >> There are two possible interpretations of R2156: the first is that it >> creates a static voting limit which can not be changed, and the second >> that it initializes a dynamic value voting limit which can then be >> modified as described in other rules. R2156 gives us no clear guidance >> on which of these interpretations should be used. However, other rules >> (such as R2260) would seem to suggest that the latter interpretation >> is more in line with the intent. Since one interpretation would lead >> to a conflict between rules and the other would not the correct choice >> is to use the latter. I judge TRUE. >> >> BobTHJ > > I intend, with 2 support, to appeal this judgment. Whether or not a > given interpretation would cause a rules conflict is not a valid reason > to pick it over any other (see R217). I do not know if this makes the > judgment incorrect or not. I recommend REMAND so that the judge can > correct eir arguments and possibly eir judgment.
In the event of ambiguity, the standard of CSJI, moderated by judicial discretion, applies. E might plausibly argue that rules conflicts are against the best interests of the game; this was how I initially read the judgement. However, I strongly disagree with that syllogism. Such a precedent would allow low-powered rules to effectively override high-powered ones, by pretending to avoid conflict while subverting the natural meaning of the high-powered rule entirely. On the other hand, one might argue that this simply means we need to write our Rules more securely, so that these kinds of shenanigans must conflict. Either way, I agree that I would like to see these points addressed.
signature.asc
Description: OpenPGP digital signature
