{"action":"created","issue":{"url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/issues/3","repository_url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi","labels_url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/issues/3/comments","events_url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/issues/3/events","html_url":"https://github.com/gartonrd/SnowflakesWiFi/pull/3","id":149619457,"number":3,"title":"Live status","user":{"login":"Multiball","id":3421068,"avatar_url":"https://avatars.githubusercontent.com/u/3421068?v=3","gravatar_id":"","url":"https://api.github.com/users/Multiball","html_url":"https://github.com/Multiball","followers_url":"https://api.github.com/users/Multiball/followers","following_url":"https://api.github.com/users/Multiball/following{/other_user}","gists_url":"https://api.github.com/users/Multiball/gists{/gist_id}","starred_url":"https://api.github.com/users/Multiball/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Multiball/subscriptions","organizations_url":"https://api.github.com/users/Multiball/orgs","repos_url":"https://api.github.com/users/Multiball/repos","events_url":"https://api.github.com/users/Multiball/events{/privacy}","received_events_url":"https://api.github.com/users/Multiball/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2016-04-20T00:27:54Z","updated_at":"2016-04-21T18:54:51Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/pulls/3","html_url":"https://github.com/gartonrd/SnowflakesWiFi/pull/3","diff_url":"https://github.com/gartonrd/SnowflakesWiFi/pull/3.diff","patch_url":"https://github.com/gartonrd/SnowflakesWiFi/pull/3.patch"},"body":"First crack at providing a viewer for which record the log is currently displaying. Not perfect, but it might not be able to be perfect."},"comment":{"url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/issues/comments/213065629","html_url":"https://github.com/gartonrd/SnowflakesWiFi/pull/3#issuecomment-213065629","issue_url":"https://api.github.com/repos/gartonrd/SnowflakesWiFi/issues/3","id":213065629,"user":{"login":"Multiball","id":3421068,"avatar_url":"https://avatars.githubusercontent.com/u/3421068?v=3","gravatar_id":"","url":"https://api.github.com/users/Multiball","html_url":"https://github.com/Multiball","followers_url":"https://api.github.com/users/Multiball/followers","following_url":"https://api.github.com/users/Multiball/following{/other_user}","gists_url":"https://api.github.com/users/Multiball/gists{/gist_id}","starred_url":"https://api.github.com/users/Multiball/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Multiball/subscriptions","organizations_url":"https://api.github.com/users/Multiball/orgs","repos_url":"https://api.github.com/users/Multiball/repos","events_url":"https://api.github.com/users/Multiball/events{/privacy}","received_events_url":"https://api.github.com/users/Multiball/received_events","type":"User","site_admin":false},"created_at":"2016-04-21T18:54:51Z","updated_at":"2016-04-21T18:54:51Z","body":"Common versioning practice is to allow a bunch of small changes without upping the version number, then, at some point, decide that you have enough changes to warrant updating the version number. For teams that have a periodic release, say, once a week, this typically happens when the release is cut; whichever changes made it in that week are part of the newest version. In this case, we can simply declare a new version whenever we decide the accumulated changes are significant enough.\r\n\r\nAs for checking code integrity, there's no call on what exactly you're \"supposed\" to do; you can check the branch out and test it yourself if you think it's necessary, or just agree that it's good to merge after looking at it. In production situations, there are typically batteries of automated tests that need to be run before a branch is cleared to merge, but we don't have any such tests. It might be an interesting thing to look into, though. At any rate, in the absence of automated tests, we have to rely on manual testing. I try to make sure that my code works satisfactorily before putting it up for review, but, as happened with the bug related to skipping spaces in an fl5, I don't always get it 100%. If you want to double-check it, then I invite you to do so. If you think the code looks good enough without trying it first, then you're not strictly obligated to.\r\n\r\nThe purpose of a pull request is to get approval to merge from the relevant parties; the process is generally called \"code review.\" If the code passes its review (as stated above, the nature of the review is complicated by the absence of automated tests), then it is mergeable by whomever convention dictates should merge it. Everyone has the power to push the \"merge\" button at any time; who does is a matter of convention. The convention I'm used to is that the person who created the pull request pushes the button, but it doesn't have to be that way. I don't mind it if you want to push the button, and I also don't mind if you want me to push the button. Which would you prefer?"}}