Rob Oxspring

We're definitely making progress on this but I think there's still plenty to do :)

Seems to me that the philosophy of Zally so far is to implement Zalando's chosen guidelines by default but that rules should be configurable and allow other deployments to make...

The big difference I see between existing rules and change rules is that the change rules need the additional context of some baseline version of the spec, and violations might...

Just to be clear @maxim-tschumak: Are you thinking this should still be part of the wider https://github.com/zalando/zally project or are you politely encouraging us to spin out an entirely separate...

#630 was tackling a very specific case where I'd noticed a gap. I've not done the research implied here.

It's painful to compare the guideline here with the rules-config.conf since the former describes a mapping from status -> methods but the latter describes method -> statuses. We should converge...

Note that JSON output has previously been discussed under #648 with the conclusion that programmatic access should be using the API directly rather than via the CLI. Will be interesting...

Generally looks good to me. Where do violations fit in? Based on the existing architecture I'm presuming that each check can produce 0..1 violation, and therefore going forward a rule...

Just wanted to make sure I'm understanding the distinction between the various concepts and trying identify the principles of identifying rules and checks. For example looking at the Zalando Guideline...

Personally, I've never had a problem with the idea that rules would have to be compiled, packaged and then placed in some directory for Zally to use next time it...