Editorial pass & migration to mkdocs.

There's a lot in grimoire.ca that I either no longer stand behind or feel pretty weird about having out there.

3 files changed, 253 insertions, 0 deletions

diff --git a/docs/nomic/index.md b/docs/nomic/index.md
new file mode 100644
index 0000000..8e28e6e
--- /dev/null
+++ b/docs/nomic/index.md
@@ -0,0 +1,10 @@
+# Nomic
+
+[Nomic](https://legacy.earlham.edu/~peters/nomic.htm) is a game invented in 1982 by Peter Suber, as an appendix to his PhD thesis _The Paradox of Self-Amendment_. In Nomic, the primary move available to the players is to change the rules of the game in a structured way. Nomic itself was intended as a minimalist study of procedural law, but it has been played very successfully by many groups over the years.
+
+I first played Nomic through [Agora](http://www.dfw.net/~ccarroll/agora/), a long-running Nomic of a heavily procedural bent (as opposed to variants like BlogNomic, that have developed in much more whimsical directions). I've found the game, and the communities that have sprung up around the game, deeply fascinating as a way to examine how groups reach consensus and exercise decisions.
+
+I briefly experimented with the notion of running a procedural Nomic - a mini-Agora - via Github, and produced two documents:
+
+* [Notes Towards Initial Rules for a Github Nomic](notes.md)
+* [Github Nomic Rules](rules.md)
diff --git a/docs/nomic/notes.md b/docs/nomic/notes.md
new file mode 100644
index 0000000..7ff43e5
--- /dev/null
+++ b/docs/nomic/notes.md
@@ -0,0 +1,90 @@
+# Notes Towards Initial Rules for a Github Nomic
+
+This document is not part of the rules of a Nomic, and is present solely as a guide to the design of [this initial ruleset](rules.md), for play on Github. It should be removed before the game starts, and at no time should it be consulted to guide gameplay directly.
+
+Peter Suber's [Nomic](http://legacy.earlham.edu/~peters/writing/nomic.htm) is a game of rule-making for one or more players. For details on the rationale behind the game and the reasons the game might be interesting, see Suber's own description.
+
+# Changes from Suber's Rules
+
+## Format
+
+I've marked up Suber's rules into Markdown, one of Github's “native” text markup formats. This highly-structured format produces quite readable results when viewed through the Github website, and allows useful things like HTML links that point to specific rules.
+
+I've also made some diff-friendliness choices around the structure of those Markdown documents. For want of a better idea, the source documents are line-broken with one sentence per line, so that diffs naturally span whole sentences rather than arbitrarily-wrapped text (or unwrapped text). Since Github automatically recombines sequences of non-blank lines into a single HTML paragraph, the rendering on the web site is still quite readable.
+
+I have not codified this format in the rules themselves.
+
+## Asynchrony
+
+In its original form, Nomic is appropriate for face-to-face play. The rules assume that it is practical for the players to identify one another using out-of-game context, and that it is practical for the players to take turns. Each player is expected to wait indefinitely (or, more likely, to apply non-game social pressure) if the preceding player takes inordinately long to complete their turn. Similarly, Judgement interrupts the flow of game play and brings turns to a stop.
+
+This Nomic is to be played on Github, and the players are _not_ likely to be present simultaneously, or to be willing to wait indefinitely.
+
+It's possible for Suber's original Nomic rules to be amended, following themselves, into a form suitable for asynchronous play. This has happened several times: for examples, see [Agora](http://agoranomic.org/) and [BlogNomic](http://blognomic.com/), though there are a multitude of others. However, this process of amendment takes _time_, and, starting from Suber's initial rules, would require a period of one-turn-at-a-time rule-changes before the game could be played more naturally in the Github format. This period is not very interesting, and is incredibly demanding of the initial players' attention spans.
+
+In the interests of preserving the players' time, I have modified Suber's initial ruleset to replace sequential play with a simple asynchronous model of play. In summary:
+
+* Every player can begin a turn at any time, even during another player's (or players') turn, so long as they aren't already taking a turn.
+* Actions can be resolved in any order, depending on which proposals players choose to vote on, and in what order.
+* The initial rules allow for players to end their turns without gathering every vote, once gameplay has proceeded far enough for non-unanimous votes to be possible.
+
+I have attempted to leave the rules as close to Suber's original rules as possible otherwise while implementing this change to the initial ruleset. I have faith that the process of playing Nomic will correct any deficiencies, or, failing that, will clearly identify where these changes break the game entirely.
+
+I have, as far as I am able, emulated Suber's preference for succinctness over thoroughness, and resisted the urge to fix or clarify rules even where defects seem obvious to me. In spite of my temptation to remove it, I have even left the notion of “winning” intact.
+
+## Rule-numbering
+
+The intent of this Nomic is to explore the suitability of Github's suite of tools for proposing, reviewing, and accepting changes to a corpus of text are suitable for self-governed rulemaking processes, as modelled by Nomic. Note that this is a test of Github, not of Git: it is appropriate and intended that the players rely on non-Git elements of Github's workflow (issues, wiki pages, Github Pages, and so on), and similarly it is appropriate and intended that the authentic copy of the game in play is the Github project hosting it, not the Git repo the project contains, and certainly not forks of the project or other clones of the repository.
+
+To support this intention, I have re-labelled the initial rules with negative numbers, rather than digits, so that proposals can be numbered starting from 1 without colliding with existing rules, and so that they can be numbered by their Pull Requests and Github issue numbers. (A previous version of these rules used Roman numerals for the initial rules. However, correctly accounting for the priority of new rules over initial rules, following Suber, required more changes than I was comfortable making to Suber's ruleset.) I have made it explicit in these initial rules that Github, not the players, assigns numbers to proposals. This is the only rule which mentions Github by name. I have not explicitly specified that the proposals should be implemented through pull requests; this is an intentional opportunity for player creativity.
+
+## Projects & Ideas
+
+A small personal collection of other ideas to explore:
+
+### Repeal or replace the victory criteria entirely
+
+“Winning” is not an objective I'm personally interested in, and Suber's race to 200 points by popularity of proposal is structurally quite dull. If the game is to have a victory condition, it should be built from the ground up to meet the players' motivations, rather than being retrofitted onto the points-based system.
+
+### Codify the use of Git commits, rather than prose, for rules-changes
+
+This is unstated in this ruleset, despite being part of my intention for playing. So is the relationship between proposals and the Git repository underpinning the Github project hosting the game.
+
+### Clarify the immigration and exit procedures
+
+The question of who the players _are_, or how one becomes a player, is left intentionally vague. In Suber's original rules, it appears that the players are those who are engaged in playing the game: tautological on paper, but inherently obvious by simple observation of the playing-space.
+
+On Github, the answer to this question may not be so simple. A public repository is _visible_ to anyone with an internet connection, and will accept _proposed_ pull requests (and issue reports) equally freely. This suggests that either everyone is, inherently, a player, or that player-ness is somehow a function of engaging with the game. I leave it to the players to resolve this situation to their own satisfaction, but my suggestion is to track player-ness using repository collaborators or organization member accounts.
+
+### Figure out how to regulate the use of Github features
+
+Nomic, as written, largely revolves around sequential proposals. That's fine as far as it goes, but Github has a very wide array of project management features - and that set of features changes over time, outside the control of the players, as Github roll out improvements (and, sometimes, break things).
+
+Features of probable interest:
+
+* The `gh-pages` branch and associated web site.
+* Issue and pull request tagging and approval settings.
+* Third-party integrations.
+* Whether to store non-rule state, as such arises, in the repository, or in the wiki, or elsewhere.
+* Pull request reactions and approvals.
+* The mutability of most Github features.
+
+### Expand the rules-change process to permit a single proposal to amend many rules
+
+This is a standard rules patch, as Suber's initial rule-set is (I believe intentionally) very restrictive.
+
+This may turn out to be less relevant on Github, if players are allowed to submit turns in rapid succession with themselves.
+
+### Transition from immediate amendment to a system of sessions
+
+Why not? Parliamentary procedure is fun, right?
+
+In an asynchronous environment, the discrete phases of a session system (where proposals are gathered, then debated, then voted upon, then enacted as a unit) might be a better fit for the Github mode of play.
+
+### Evaluate other models of proposal vetting besides majority vote
+
+Github open source projects regularly have a small core team of maintainers supporting a larger group of users. Is it possible to mirror this structure in Nomic? Is it wise to do so?
+
+I suspect this is only possible with an inordinately large number of players, but Github could, at least in principle, support that number of players.
+
+Note that this is a fairly standard Nomic passtime.
diff --git a/docs/nomic/rules.md b/docs/nomic/rules.md
new file mode 100644
index 0000000..912b4c8
--- /dev/null
+++ b/docs/nomic/rules.md
@@ -0,0 +1,153 @@
+# Github Nomic Rules
+
+## Immutable Rules
+
+### Rule -216.
+
+All players must always abide by all the rules then in effect, in the form in which they are then in effect. The rules in the Initial Set are in effect whenever a game begins. The Initial Set consists of rules -216 through -201 (immutable) and rules -112 through -101 (mutable).
+
+### Rule -215.
+
+Initially, rules -216 through -201 are immutable, and rules -112 through -101 are mutable. Rules subsequently enacted or transmuted (that is, changed from immutable to mutable or vice versa) may be immutable or mutable regardless of their numbers, and rules in the Initial Set may be transmuted regardless of their numbers.
+
+### Rule -214.
+
+A rule-change is any of the following:
+
+1. the enactment, repeal, or amendment of a mutable rule;
+
+2. the enactment, repeal, or amendment of an amendment of a mutable rule; or
+
+3. the transmutation of an immutable rule into a mutable rule or vice versa.
+
+(Note: This definition implies that, at least initially, all new rules are mutable; immutable rules, as long as they are immutable, may not be amended or repealed; mutable rules, as long as they are mutable, may be amended or repealed; any rule of any status may be transmuted; no rule is absolutely immune to change.)
+
+### Rule -213.
+
+All rule-changes proposed in the proper way shall be voted on. They will be adopted if and only if they receive the required number of votes.
+
+### Rule -212.
+
+Every player is an eligible voter.
+
+### Rule -211.
+
+All proposed rule-changes shall be written down before they are voted on. If they are adopted, they shall guide play in the form in which they were voted on.
+
+### Rule -210.
+
+No rule-change may take effect earlier than the moment of the completion of the vote that adopted it, even if its wording explicitly states otherwise. No rule-change may have retroactive application.
+
+### Rule -209.
+
+Each proposed rule-change shall be given a number for reference. The numbers shall be assigned by Github, so that each rule-change proposed in the proper way shall receive the a distinct integer from all prior proposals, whether or not the proposal is adopted.
+
+If a rule is repealed and reenacted, it receives the number of the proposal to reenact it. If a rule is amended or transmuted, it receives the number of the proposal to amend or transmute it. If an amendment is amended or repealed, the entire rule of which it is a part receives the number of the proposal to amend or repeal the amendment.
+
+### Rule -208.
+
+Rule-changes that transmute immutable rules into mutable rules may be adopted if and only if the vote is unanimous among the eligible voters. Transmutation shall not be implied, but must be stated explicitly in a proposal to take effect.
+
+### Rule -207.
+
+In a conflict between a mutable and an immutable rule, the immutable rule takes precedence and the mutable rule shall be entirely void. For the purposes of this rule a proposal to transmute an immutable rule does not "conflict" with that immutable rule.
+
+### Rule -206.
+
+If a rule-change as proposed is unclear, ambiguous, paradoxical, or destructive of play, or if it arguably consists of two or more rule-changes compounded or is an amendment that makes no difference, or if it is otherwise of questionable value, then the other players may suggest amendments or argue against the proposal before the vote. A reasonable time must be allowed for this debate. The proponent decides the final form in which the proposal is to be voted on and, unless the Judge has been asked to do so, also decides the time to end debate and vote.
+
+### Rule -205.
+
+The state of affairs that constitutes winning may not be altered from achieving _n_ points to any other state of affairs. The magnitude of _n_ and the means of earning points may be changed, and rules that establish a winner when play cannot continue may be enacted and (while they are mutable) be amended or repealed.
+
+### Rule -204.
+
+A player always has the option to forfeit the game rather than continue to play or incur a game penalty. No penalty worse than losing, in the judgment of the player to incur it, may be imposed.
+
+### Rule -203.
+
+There must always be at least one mutable rule. The adoption of rule-changes must never become completely impermissible.
+
+### Rule -202.
+
+Rule-changes that affect rules needed to allow or apply rule-changes are as permissible as other rule-changes. Even rule-changes that amend or repeal their own authority are permissible. No rule-change or type of move is impermissible solely on account of the self-reference or self-application of a rule.
+
+### Rule -201.
+
+Whatever is not prohibited or regulated by a rule is permitted and unregulated, with the sole exception of changing the rules, which is permitted only when a rule or set of rules explicitly or implicitly permits it.
+
+## Mutable Rules
+
+### Rule -112.
+
+A player may begin a turn at any time that suits them. Turns may overlap: one player may begin a turn while another player's is in progress. No player may begin a turn unless all of their previous turns have ended.
+
+All players begin with zero points.
+
+### Rule -111.
+
+One turn consists of two parts in this order:
+
+1. proposing one rule-change and having it voted on, and
+
+2. scoring the proposal and adding that score to the proposing player's score.
+
+A proposal is scored by taking the proposal number, adding nine to it, multiplying the result by the fraction of favourable votes the proposal received, and rounding that result to the nearest integer.
+
+(This scoring system yields a number between 0 and 10 for the first proposal, with the upper limit increasing by one for each new proposal; more points are awarded for more popular proposals.)
+
+### Rule -110.
+
+A rule-change is adopted if and only if the vote in favour is unanimous among the eligible voters. If this rule is not amended before each player has had two turns, it automatically changes to require only a simple majority.
+
+If and when rule-changes can only be adopted unanimously, the voting may be ended as soon as an opposing vote is counted. If and when rule-changes can be adopted by simple majority, the voting may be ended as soon as a simple majority in favour or a simple majority against is counted.
+
+### Rule -109.
+
+If and when rule-changes can be adopted without unanimity, the players who vote against winning proposals shall receive 10 points each.
+
+### Rule -108.
+
+An adopted rule-change takes full effect at the moment of the completion of the vote that adopted it.
+
+### Rule -107.
+
+When a proposed rule-change is defeated, the player who proposed it loses 10 points.
+
+### Rule -106.
+
+Each player always has exactly one vote.
+
+### Rule -105.
+
+The winner is the first player to achieve 200 (positive) points.
+
+### Rule -104.
+
+At no time may there be more than 25 mutable rules.
+
+### Rule -103.
+
+If two or more mutable rules conflict with one another, or if two or more immutable rules conflict with one another, then the rule with the lowest ordinal number takes precedence.
+
+If at least one of the rules in conflict explicitly says of itself that it defers to another rule (or type of rule) or takes precedence over another rule (or type of rule), then such provisions shall supersede the numerical method for determining precedence.
+
+If two or more rules claim to take precedence over one another or to defer to one another, then the numerical method again governs.
+
+### Rule -102.
+
+If players disagree about the legality of a move or the interpretation or application of a rule, then the player moving may ask any other player to be the Judge and decide the question. Disagreement for the purposes of this rule may be created by the insistence of any player. This process is called invoking Judgment.
+
+When Judgment has been invoked, no player may begin his or her turn without the consent of a majority of the other players.
+
+The Judge's Judgment may be overruled only by a unanimous vote of the other players taken before the next turn is begun. If a Judge's Judgment is overruled, then the Judge may ask any player other than the moving player, and other than any player who has already been the Judge for the question, to become the new Judge for the question, and so on, except that no player is to be Judge during his or her own turn or during the turn of a team-mate.
+
+Unless a Judge is overruled, one Judge settles all questions arising from the game until the next turn is begun, including questions as to his or her own legitimacy and jurisdiction as Judge.
+
+New Judges are not bound by the decisions of old Judges. New Judges may, however, settle only those questions on which the players currently disagree and that affect the completion of the turn in which Judgment was invoked. All decisions by Judges shall be in accordance with all the rules then in effect; but when the rules are silent, inconsistent, or unclear on the point at issue, then the Judge shall consider game-custom and the spirit of the game before applying other standards.
+
+### Rule -101.
+
+If the rules are changed so that further play is impossible, or if the legality of a move cannot be determined with finality, or if by the Judge's best reasoning, not overruled, a move appears equally legal and illegal, then the first player unable to complete a turn is the winner.
+
+This rule takes precedence over every other rule determining the winner.