Error codes: hyphens, underscores or camelCase

[roll]

Overview

It's not a tech problem. Just a possible UX (in wide meaning) improvement. In goodtables stack for now we use different word separation conventions:

• underscores in goodtables.yml - https://github.com/frictionlessdata/goodtables.io/blob/master/goodtablesio/schemas/job-conf.yml#L94-L116 (travis style)
• hyphens in data-quality-spec error codes - https://github.com/frictionlessdata/data-quality-spec/blob/master/spec.json

It's pretty minor but anyway now we could make life of our users a little bit easier for free if sync on it.

cc @amercader @pwalsh

[pwalsh]

By the end of 2017, I'd like to see data quality spec implemented in libraries across several programming languages, so I don't see a need to conform the naming of the spec along conventions in Python.

[roll]

I agree that's why I suppose I've selected it at first place (thought we use underscores for template strings). So @amercader may be we could rebase our goodtables.yml on hyphens style (like skip_rows -> skip-rows). But it's perfectionist's saying in me..

So it seems nothing to do with spec here.

[amercader]

As I understand it this spec is some abstraction that other libraries or services need to implement so we shouldn't worry about aligning the syntax on goodtables.io. I actually think that having the same convention that Travis, CircleCI, Codecov, etc (use underscores) is a benefit for GTIO.

[pwalsh]

So @roll can we close as wontfix?

[roll]

WONTFIX

PS. done)