I alluded to this in my original post, but let me elaborate. I've never really liked the "weekly ASCII email report" paradigm, for a few reasons:
- In practice, a week is often too long to wait to be updated on the latest state, so officeholders often maintain a continually updated web copy on their personal sites (sometimes including automation, like the CotC DB, but often just .txt files at a URL), sometimes actually with more information, or in a more structured format, than the published reports - but those web copies often lack history tracking; the URLs often break after the officeholder quits, without anyone archiving the data; not everyone knows how to put up a site; and the need to set something up increases the initial investment of effort required to take over an office. - If they don't have a website and only publish a weekly report, it's easy for gameplay to suffer as a result - especially the kind of 'pure gameplay' (i.e. points, competition between players, etc.) systems that often seem to falter in Agora, since they tend to have more interdependent state and move faster than the proposal/CFJ systems. - The system expects one person to do all the tracking, and makes it difficult, requiring setting up separate external infrastructure, to adopt any alternative, such as sharing the work among a group, or self-service (where players would be expected to update the state themselves after performing actions, and the official recordkeeper is responsible merely for reviewing the history for mistakes). The latter in particular would be quite helpful during times of decreased activity, since even if the office is empty and no review occurs, players could still check the current state and try to take actions. We've often gotten into situations where an office is empty, the last report was published several months ago, and some people have tried to perform actions since then but nobody really knows what the state is. - Maintaining report formatting is something I still find kind of annoying; I imagine it can be a bigger obstacle for new players. The obvious answer is to track state on some sort of wiki, as many (most?) other nomics have. This has been brought up before, but IIRC there have been some concerns, mainly around issues like centralization and difficulty of archival. If you just set up some MediaWiki instance, it's easy for the site to go down, taking a significant chunk of history with it - or even for the software to become obsolete, considering how long Agora's life has been. In comparison, plaintext mailing list archives will be readable for a very long time, and everyone subscribing to the list 'archives' it in their own email archive, unless they delete old mail. Also, wikis are a bit harder to use as backend storage for automation. But the solution to *that* has been around for many years now. We can use wiki software that uses a Git repository as its backend - there are a few open source implementations around for that, or we could just use GitHub (centralized isn't a big deal if migration is trivial). The content would be formatted in Markdown, which is highly portable between different software and also generally readable as plaintext. Anyone could edit either through the wiki interface or by cloning the Git repository locally; in the latter case, just like with any other Git repo, they'd get a full copy of the history, and migrating to another host would just be a matter of pushing to a different remote. Since it's a wiki, the server would be open to unauthenticated pushes, except for force pushes (deleting history). Git itself may become obsolete someday, but revision control systems have a pretty good history of migration mechanisms - today you can convert from RCS or CVS or SVN to Git, between Git and Mercurial, etc. The same will be true for any Git replacement. By the way, I once bashed Wooble's decision to migrate the ruleset from RCS to Mercurial on the grounds that RCS was simpler and made it easier to understand what history is being kept (just a plaintext file with a list of diffs), edit history, migrate, etc.. I was, uh, dead wrong. Migration isn't hard, and if necessary it's easy to edit history with Git using rebase. (But unlike the old ruleset RCS history, I don't propose that the history of this wiki repo be edited or used as an authoritative source of anything - it should just be a real history of when the document was edited. Old rulesets can be tracked with more explicit metadata.) Anyway, I envision that: - The wiki wouldn't just be an unofficial backup store. It would be a new type of Forum (for reports only, not actions), and office requirements would be changed from "publish X each week/month" to "at least once each week/month, modify the wiki page to reflect the current gamestate, and add an 'up to date as of' stamp". For some things the requirement could work differently - e.g. if Patent Titles are only awarded/revoked by action of the Herald, then the Herald could simply be required to update the wiki immediately after such action, without any actual periodic duty. I suppose we could also require occasionally republishing wiki reports to a public forum, but I don't think it's necessary. - Actions would still have to be taken on a public forum (we're not BlogNomic), but for some types of records we might decide to encourage updating the wiki page oneself afterward. For other records self-service might be disallowed/discouraged, with an exception if the office is vacant (or perhaps the officer delinquent). - For now there wouldn't be any explicit system in the rules for sharing duties, but with a wiki it would be easy for the officeholder to work that out with 'deputies' if desired, and it might be a good use case for contracts someday... - There would be no more fixed-width formatting for anything, including the ruleset; just Markdown and soft wrapping. If anyone likes reading in fixed width (I kind of do), scripts could be used for alternate presentations. This way, anyone with a web browser can maintain reports through the wiki interface without having to do anything fancy. Ideally we'd have some basic scripting for things like counting rows in a table, etc.; not crucial though. (How many times have Registrar's reports been published with a mismatch between the stated player count and the actual list? Too many.) - Probably, for most types of records, there should be a history section (like what you see in reports) which would be updated along with the actual state; relying on the wiki history isn't good enough because it conflates modifying the gamestate and merely updating the records to match the gamestate. - There would be one wiki/repository for most of the game, rather than dividing by office or game aspect; this way the implicitly propagated repo history includes obsolete stuff. - Officers would be encouraged to maintain any unofficial recordkeeping on the wiki too rather than their own site. Even for automated systems, if possible, using the wiki as a backing store would be ideal. Any comments? Anyone really hate wikis?
