Zefram wrote:
> Ian Kelly wrote:
> > the list of cards, which had grown
> >long enough that it was just taking up too much space in the ruleset.
>
> Because, of course, it is physically impossible for an email message to
> be longer than 347 kB.
It was also a matter of organization, cards were spread willy-nilly
throughout the ruleset. A proactive Rulekeepor could have dealt with
that, perhaps.
But lest we forget, a more important reason to separate was that we
wanted card text to be modifiable by means other than Proposals
(e.g. blueprints) but we didn't want to re-write all of "rule changes"
just for cards. It was sensible devolution. Of particular interest
(R2114/2):
A document is a cardbook if so designated by the rules.
[...]
A cardbook may only be changed as explicitly permitted by the
rules.
[...]
If there are conflicts between a card or element definition in a
cardbook and the rules, then the conflict shall be resolved as
if the definition were contained in the text of the rule that
defines the particular cardbook. This rule takes precedence
over any rule that would require a different method of resolving
such conflicts.
This meant that a single "rule" could in effect contain an entire
cardbook, but the "effective text" of the rule could be changed by
methods (defined by the rules) that didn't include proposals. Such
compartmentalization of the card subgame was seen as a Good Thing.
As the current Contracts rule requires proposals to amend contracts,
it doesn't offer that benefit. Also, the current Contracts
rule doesn't allow much in resolving conflicts between
Contracts and Rules. I think a compromise is hard-coding each
contract's relationship with the rules by name in its own rule, and
getting rid of generic contracts (in this case, the Envoy just
becomes a single rule).
-Goethe
