{"action":"opened","issue":{"url":"https://api.github.com/repos/steelbrain/linter/issues/1298","repository_url":"https://api.github.com/repos/steelbrain/linter","labels_url":"https://api.github.com/repos/steelbrain/linter/issues/1298/labels{/name}","comments_url":"https://api.github.com/repos/steelbrain/linter/issues/1298/comments","events_url":"https://api.github.com/repos/steelbrain/linter/issues/1298/events","html_url":"https://github.com/steelbrain/linter/issues/1298","id":200663651,"number":1298,"title":"Messages v2 protocol ideas","user":{"login":"fulldecent","id":382183,"avatar_url":"https://avatars.githubusercontent.com/u/382183?v=3","gravatar_id":"","url":"https://api.github.com/users/fulldecent","html_url":"https://github.com/fulldecent","followers_url":"https://api.github.com/users/fulldecent/followers","following_url":"https://api.github.com/users/fulldecent/following{/other_user}","gists_url":"https://api.github.com/users/fulldecent/gists{/gist_id}","starred_url":"https://api.github.com/users/fulldecent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fulldecent/subscriptions","organizations_url":"https://api.github.com/users/fulldecent/orgs","repos_url":"https://api.github.com/users/fulldecent/repos","events_url":"https://api.github.com/users/fulldecent/events{/privacy}","received_events_url":"https://api.github.com/users/fulldecent/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-01-13T15:52:27Z","updated_at":"2017-01-13T15:52:27Z","closed_at":null,"body":"Structured Acceptance Test is an open format that is very similar to the Messages v2 protocol.\r\n\r\nhttps://github.com/fulldecent/structured-acceptance-test\r\n\r\nTo promote interoperability between all linters / acceptance tests processes in the world, it would be nice if the messages v2 protocol and STAT format were harmonized. Note: STAT format is already harmonized (one-to-one compatible) with Code Climate's SPEC format.\r\n\r\nAlready I see Messages v2 adds `fixes`, an awesome feature.\r\n\r\nThis issue makes other comparisons in an effort to promote one-to-one compatibility between STAT and Messages v2.\r\n\r\n-----\r\n\r\nFollowing are ways that Messages v2 are different than STAT and rationality for updating it to match STAT:\r\n\r\n - (From messages v1.) `Trace` includes a `severity` -- recommendation: remove this -- if a backtrace references other code then that other code is assumed valid therefore the other referenced code should not be classified as *error*, *warning* or *info*.\r\n\r\nHere are new features that Messages v2 (and Standard Linter v2) can consider adding which STAT already has.\r\n\r\n - STANDARD LINTER v2. Linter documentation of *repeatability*. Some linting processes may be able to specify that their results are guaranteed not to change under certain circumstances. The consumer (Atom) could use this information to great benefit by not repeating a lint operation if it knows that results will be the same. Here are three categories of repeatability with examples:\r\n   - **Volatile** -- *Linter that checks if today's date is in the target file*. This test must be rerun constantly, Atom should rerun the linter every time you edit or open the file. **This is the weakest guarantee and should be default. (Or you can make specifying repeatability required to avoid implicit default.)**\r\n   - **Repeatable** -- *Linter compiles c code*. If the code compiled yesterday, you can be sure it will compile again today (assuming same compiler and compiler settings are used.) But if file `a` is edited then all other files must be rechecked.\r\n   - **Associative** -- *Linter that greps for swear words*. If file `a` is edited then there is not need to rerun the linter for file `b`. **This is the strongest guarantee that a linter can make.**\r\n\r\n - MESSAGE v2. Time to fix. An estimated time, in seconds, that a human would need to correct this problem. Some producers like to make this estimate, so STAT allows it in the data format.\r\n - MESSAGE v2. Category. Code Climate defined several categories of issues. STAT includes them and provides documentation for these categories.\r\n - MESSAGE v2. `solution` without replacement text or process. It may be desirable to list recommendations using imperative language even if you are not able to provide an exact fix.\r\n   - **Problem message (you already have this)** -- this explains what the problem is. *Warning: swear words are not allowed in this document.* \r\n   - **Fix with replacement text (you already have this)** -- this is clickable and uses imperative wording. *Replace `s**t` with `poop`.*\r\n   - **Fix without replacement text (proposed new feature)** -- this tells you what to do using imperative language but does not have a recommended clickable replacement. *Reword this sentence to make it more classy.*"}}
{"actor":{"display_login":"fulldecent"}}