{"action":"created","issue":{"url":"https://api.github.com/repos/audiodude/odeon/issues/16","labels_url":"https://api.github.com/repos/audiodude/odeon/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/audiodude/odeon/issues/16/comments","events_url":"https://api.github.com/repos/audiodude/odeon/issues/16/events","html_url":"https://github.com/audiodude/odeon/pull/16","id":102451770,"number":16,"title":"306: amend 304 for player file updates","user":{"login":"sashahart","id":696412,"avatar_url":"https://avatars.githubusercontent.com/u/696412?v=3","gravatar_id":"","url":"https://api.github.com/users/sashahart","html_url":"https://github.com/sashahart","followers_url":"https://api.github.com/users/sashahart/followers","following_url":"https://api.github.com/users/sashahart/following{/other_user}","gists_url":"https://api.github.com/users/sashahart/gists{/gist_id}","starred_url":"https://api.github.com/users/sashahart/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sashahart/subscriptions","organizations_url":"https://api.github.com/users/sashahart/orgs","repos_url":"https://api.github.com/users/sashahart/repos","events_url":"https://api.github.com/users/sashahart/events{/privacy}","received_events_url":"https://api.github.com/users/sashahart/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-08-21T19:56:28Z","updated_at":"2015-08-21T22:34:00Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/audiodude/odeon/pulls/16","html_url":"https://github.com/audiodude/odeon/pull/16","diff_url":"https://github.com/audiodude/odeon/pull/16.diff","patch_url":"https://github.com/audiodude/odeon/pull/16.patch"},"body":"I apologize in advance for the length of this rationale regarding proposal 306. Please read the diff. The diff is the important part, but the rationale is offered in case there are any initial questions.\r\n\r\nImmutable rule 118 stipulates that \"Each player's file must at all times contain the numeric score of the player.\" This is convenient, because players may not wish to sift through the log to recalculate scores, duplicating effort. However, neither rule 118 nor any other rule provides a mechanism for this to happen. Therefore, an undefined condition routinely arises where actual scores have changed, but these changes are not reflected in player files, violating rule 118. I believe the prevailing interpretation has been that this prevents advancement of game state until the player file is updated. Regardless, we need a mechanism to update the player files, and that mechanism should allow for prompt updates to reduce the duration of game hangs.\r\n\r\naudiodude proposed the use of the admin power and as far as I can tell this is legal, insofar as the player files do not materially affect the operation of the rules. So I vowed to support any score update PR, which in a 3-player game practically assures such PRs will go through. This has apparently functioned pretty well, albeit a bit awkwardly. However, all this was intended as an interim measure. Using the admin power to do updates all the time is a bit scary because wherever it is used, it is hard to categorically rule out material changes to the operation of rules (and the possibility of having to retroactively determine the game state after many moves made on false assumptions seems terrible). So updates by the admin power realistically require more detailed auditing, adding to player burden. Using the admin power also requires a majority vote, which slows down updates (therefore suspending game state per 118) and is not strictly necessary anyway.  So it seems procedurally useful to make more specific provisions for player file updates. \r\n\r\nTherefore I added a clause to 304's enumeration of allowed PR types. This clause inherits from the administrative power the property of occurring outside the turn order, and it inherits from the current situation the property of only requiring one approval besides the mere proposal of the PR. This also means it is not necessary for score update PRs to be +1 by their authors, which would be an additional annoyance. The single +1 may also simply merge the PR, further facilitating these boring routine updates.\r\n\r\nAt the cost of increasing the volume of text I have included clarification that errors are allowed, not to encourage them but because they should not cause indeterminate states or hangs. It is better to resolve these conditions with further edits by the same rule, allowing score disputes to proceed asynchronously. These PRs would be a good place for discussions and disputes regarding score calculation.\r\n\r\nObviously it would not be a done thing to intentionally falsify or obfuscate the player files, it would defeat the purpose. And it is difficult to tease out intent and whether the updater made an innocent mistake or not. So if anybody wishes, we may consider proposals which somehow penalize inaccurate updates. But I don't recommend this, since making PRs for score updates is boring and incentivizing it in other ways (like adding points) will probably create problems (like racing to be the one with the merged update PR). I think clarifying that the player file scores are non-authoritative means this problem can reasonably be addressed through social shame.\r\n\r\nI renumbered point 6 to point 7 in order to keep point 7 at the end, as the 'catchall'. This seemed more readable to me, even though it involved a renumbering.\r\n\r\nI considered making this a separate rule, but that would require amendments in 304, which enumerates the only allowed PR types, so I just included this inline.\r\n\r\nWhile this facilitates the existing practice of PR score updates, which should reduce hang time per rule 118, I don't think this is a complete and perfect solution, because rule 118 still hangs the game pending synchronization on scores. However, that's another issue and can be practically addressed by a custom of quickly PRing and +1/merging score updates at the end of each turn. Due to asynchrony and error tolerance, I believe this rule even permits ahead-of-time PRing of the score change in cases where the proposal has clearly passed, but the turn cannot advance yet because not all eligible voters have (irrelevantly) voted. "},"comment":{"url":"https://api.github.com/repos/audiodude/odeon/issues/comments/133580473","html_url":"https://github.com/audiodude/odeon/pull/16#issuecomment-133580473","issue_url":"https://api.github.com/repos/audiodude/odeon/issues/16","id":133580473,"user":{"login":"audiodude","id":57832,"avatar_url":"https://avatars.githubusercontent.com/u/57832?v=3","gravatar_id":"","url":"https://api.github.com/users/audiodude","html_url":"https://github.com/audiodude","followers_url":"https://api.github.com/users/audiodude/followers","following_url":"https://api.github.com/users/audiodude/following{/other_user}","gists_url":"https://api.github.com/users/audiodude/gists{/gist_id}","starred_url":"https://api.github.com/users/audiodude/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/audiodude/subscriptions","organizations_url":"https://api.github.com/users/audiodude/orgs","repos_url":"https://api.github.com/users/audiodude/repos","events_url":"https://api.github.com/users/audiodude/events{/privacy}","received_events_url":"https://api.github.com/users/audiodude/received_events","type":"User","site_admin":false},"created_at":"2015-08-21T22:34:00Z","updated_at":"2015-08-21T22:34:00Z","body":"But no rule dictates that a score might have been set \"unlawfully\". Further, there are no rules dictating any dispute process or resolution procedure for score-keeping. So basically I think this _is_ that rule, as far as any exists.\r\n\r\nI think that a rule that specifically eviscerates the authority of the score files is not one I can vote for. I would be willing to consider the rule with this language modified or preferably removed."}}