Proposed changes to the config file format about kickoff HOT 3 CLOSED

hi @hanzi ,

I really like most of that. The config looks readable to me and if there are no drawbacks, I even like the better naming. I'll open an issue for each of the points I want to approve.

Points 1+2 are perfectly a valid and should be refactored.

As you stated, point 3 is a matter of opinion, and I think, it is not such a big thing to define them seperately and additionally we have those values easily handable in a variable without adding to much parse_url and if-isset-magic. So I would like to keep this as is.

Point 4: I like that.

Point 5: Yes it looks weird and was just to make things work. This could definitely be done better.

Or, we could drop the sections node entirely and just treat defaults as a special kind of section.

No, there is also a Rules section, where custom rule classes can be placed.

Rule Sets

I like it better, if those rule sets are kept in a separate command as already done with the seo check. I don't want this project to become overly complex with too many configuration possibilities. This makes the necessary learning curve too big and might overwhelm users.

I hope I covered all of your points.

I'll open the issues later the day.

Thank you very much for your input.

Regards
Markus

from kickoff.

No, there is also a Rules section, where custom rule classes can be placed.

Whoops, I totally forgot about that. Can we rename that node, though? I’d like to see a distinction between “Modify the list of available rules” and “Choose the rules that should apply”. At the moment, both are called rules, even though they’re different concerns. How about rule definitions?

I like it better, if those rule sets are kept in a separate command as already done with the seo check. I don't want this project to become overly complex with too many configuration possibilities. This makes the necessary learning curve too big and might overwhelm users.

I would argue that it actually lowers the learning curve since you can use one or two pre-defined rule collections instead of having to read through all the available rules and select the ones you think are necessary.

Instead of introducing a dedicated node for that I also thought about making it a “fake rule” like - include rule set: seo. But that felt like an ugly obfuscation and mix of concerns.

from kickoff.

Hi there,

in my opinion those presets are not really usable, since you normally have to configure those rules according to your needs. What we get with this option is another configuration element, which can be added to your configuration file, which adds some noise to your learning.
For me, those predefined rulesets are nothing more than a "quick check", just to see quickly, if there are any major issues. So a separate command will decouple "quick check" and "detailed configured checks". And as such, I'd rather like to keep this out for now.

As for the other points:
I opened a branch 2.0 and committed the changes, which were mostly taken from your suggestions. I refactored some minor things additionally. I will add some minor refactorings tomorrow or the day after and will most likely merge those changes into dev-master.

One bigger thing, I didn't do:
Your rules really look readable and all, but in the end, I sticked with the existing naming for several reasons:

• Most likely you will copy&paste them from somewhere, which is easier, if it is one string
• The prose seems sometimes to abstract too much: prevents framing might also be achieved by other ways
• The configuration is inconsistent, sometimes its

rule: value

On the other hand it can be

rule: 
    key: value

You are right, it might feel better for some rules to configure them "inline", but this makes it inconsistent. Maybe I will reconsider this in the future. But for now, I would really stick with the "weird naming" ;-)

Regards
Markus

from kickoff.