On Thu, May 1, 2014 at 3:41 AM, Sean Hunt <[email protected]> wrote: > Notwithstanding the requirement that multiple Rule Changes cannot > occur simultaneously, the Rulekeepor CAN, in publishing the Ruleset, > generally format and make purely editorial changes to the rules as e > sees fit, and in particular, e CAN:
So as the on-and-off Rulekeepor: > 1) Change margins and spacing; I have always reformatted whitespace in new rules (obviously, since many proposals aren't indented at all, but even when they are, albeit preserving relative indentation). There is judicial precedent for this - although I don't remember the details, and we are now without a CFJ database again (my fault now that I assumed Arbitor, I guess). > b) Fix inconsistencies in enumerated lists, such as doubled or > skipped numbers; Is this intended to be self-referential? :) Anyway, this type of problem doesn't usually seem to occur. > 3) Change the numbering or bulleting style of a list; I would like to be able to resolve inconsistencies between '1)' and '(1)' and such - along with that I'd also make the indentation policy consistent, although as above I believe I can already do that. However, it's not really necessary for automation. In general I wouldn't mind having to report on such changes, although it would require me to remember to publish rulekeepor's notes when proposals with lists that need to be reformatted get enacted, which I should be doing anyway. A better rulekeepor might have no problem with this ;P > 4) Update cross-references; Not sure what you mean by cross-references. For a long time the ruleset had Zefram-era annotations with explicit lists of "cross-references", which of course were not rule text, but I wasn't maintaining them properly so I removed them. And rules don't, and probably shouldn't, explicitly name other rules... > 5) Correct obvious spelling and grammar errors, where there is a > single obviously correct form; and There is rarely a single obviously correct form for grammatical errors. > 6) Establish a capitalization convention. Meh, I don't want capitalization to be established by fiat. Addressing the broader topic, I agreed with scshunt on IRC that this general type of thing should happen. - I think the source format for the ruleset should change to a Git repository containing one file per rule, with unwrapped text. The unwrapped text would make it easier to generate a variable width HTML version, and one file per rule would make standard Git tools useful for browsing the history of either a single rule or the ruleset as a whole. (In case Wooble is reading this, yes, this is a complete change of heart; I was poorly informed in the past.) - Due to the potential for browsing directly using Git tools and the low variability in the set of properties of rules in particular, I'm not sold on forcing a directly machine-readable format rather than just relying on some simple regexes. But I do recognize that it's useful to be able to easily open ancient data. - If it is going to be machine readable, I'm not sure network headers are a good choice in general. They don't represent nested data well; even your Agoran decision example relies on the legal but unorthodox use of multiple copies of the same header. I would prefer YAML.
