On Sat, Jun 24, 2017 at 10:09 PM Gaelan Steele <g...@canishe.com> wrote:
> I like the idea of having separate repositories per report (like we have > now), which also allows recordkeepors to manage their tooling (under this > rule, I couldn't keep the rules in YAML, for example). I think we should > keep anything on GitHub as unofficial, which allows record keepers to do > whatever they wish with regards to citizens updating the report (possibly > with an Agency or Organization providing an incentive to do so). Well, the ruleset is something I’d very much not want to track on the Wiki, because (a) it doesn’t change that often, and (b) it’s easy enough to screw up that it should be the job of a somewhat trusted player, or at least someone who knows it’s eir responsibility and takes it seriously - not ‘whoever feels like updating the wiki’. But I’m sympathetic to wanting to allow recordkeepors to manage their tooling. Basically, I have a few overlapping concerns about the “keep it unofficial” model: - Sometimes recordkeepors have come up with some super fancy tooling, sometimes allowing self-service… and then gotten bored of the job of the game, leaving the next recordkeepor to start from scratch. - In that case and others, if the recordkeepor doesn’t have much direction or perhaps is new to the game, e’s likely to gravitate towards just doing what it says in the rules, not setting up (or even continuing) an unofficial system - especially one that puts semi-high requirements on other players (requiring them to update a website along with their actions). - Most importantly: Recordkeeping style is not always just an ‘implementation detail’. It fundamentally affects the type of rules we can, or tend to, enact. For example, some potential game systems have enough repetitive calculations that they’re infeasible to run without automation; others depend so fundamentally on interpreting human-written text that automation can be of little benefit. We can’t have the former without recordkeepors who know how to program. The latter is a bit more egalitarian, but requires more time commitment and, importantly, waiting time: automation can accept actions 24/7, run trusted, complex computations on them and show everyone the new state, while a human recordkeepor can’t always be online (and has better things to do), and even when actively working on recordkeeping, takes longer to work through things. So there has to be a slower pace, less frequent actions. And then there’s the third option of decentralized human recordkeeping, like what I’m proposing for the Wiki, which is sort of a compromise between automation and centralized human recordkeeping, but not quite the same as either. Latency is avoided because players can update the records themselves, but the bandwidth problem is magnified, as inexperienced players are both slower at making the necessary calculations, and less willing to spend time doing so. Unlike with an automated system, we can call on humans to interpret text if desired, but unlike with a single human recordkeepor, those interpretations can’t be authoritative/trusted. Significantly, even when a game idea is at its core amenable to different styles of tracking, as is usually the case, expectations of which method will be used often influence design decisions. If I’m writing a rule I expect to be implemented with automation, I can throw in random calculations and extra steps ‘for free’ - it does make the rule a bit harder for players to understand, but it won’t cause headaches for recordkeepors. On the other side, proposals are free-form text because we expect a human Rulekeepor to read adopted proposals and manually apply them to the ruleset. What if we wanted to automate it? We could try to design a program that recognizes common proposal idioms (“Amend Rule XXX by replacing… with…”), and maybe it would have a decent recognition rate… but if the proposal system had been designed with that in mind from the start, we’d just ask players to send proposals in diff format. There could be a little online script to assist less savvy players in generating them. On a larger scale, the whole idea that the canonical record of actions is a mailing list reflects a game designed primarily around centralized human recordkeeping - as opposed to automation, which would prefer a webapp, or decentralized recordkeeping, which would prefer a spreadsheet or a wiki. Not that I’m proposing making the wiki a canonical record, at least for now (in the future, if desired, we could probably split the difference by making a generic system for semi-structured wiki changes that also notify the list). But I think it can and should be ‘canonical enough’ to be referenced by SHALLs. Sure, in theory we could design rules around the expectation of a wiki, yet steadfastly avoid mentioning this in the rule text itself, leaving the details to explanatory annotations in proposals and unofficial proclamations from office holders. But why should we? It’s not like the rules need an exact specification of the server software and configuration; they just need the abstract concept of a wiki, like they already have the abstract concept of a “forum”. Back to tooling: IMO, if the recordkeepor of some wiki state wants to use a private system (not accessible to other players) to keep track of it, it should be eir responsibility to propagate changes back and forth between that system and the wiki - just as it’s currently the responsibility of recordkeepors to accept actions on the lists and send reports to them, rather than force players to use some web interface. On the other hand, if eir system is accessible and capable of self-service (ideally without requiring things like manually writing YAML), then it can fill the same role as a wiki. Maybe the recordkeepor should be able to designate their choice of website as the ‘wiki’ for a given piece of state, which could be the official wiki, some other wiki, or a custom-defined site with automation - any site that satisfies the basic requirement of public editing. (This post ended up kind of messy, but I’m too tired to restructure it any more, so I’m sending it anyway. :p)
