Unrecommend openapi-tags

[philsturgeon]

User story.
As a non-Stoplight user I do not understand the importance of tags, so it is a surprise when im told I absolutely must add them.

Is your feature request related to a problem?
Spectral users occasionally ask why Spectral is telling them to do things not in the OpenAPI spec. The answer is usually "this is a linter, not a validator" and that most of the rules are useful: avoiding bugs, stopping them getting hacked, etc.

One rule which doesn't fit the description is openapi-tags. It is useful for bigger APIs, but I'm working on a single endpoint OpenAPI description and adding tags to that is pretty redundant. It's there because Stoplight docs like tags, but for a single endpoint API I don't need my docs grouped like that anyhow.

Describe the solution you'd like

For v6.0 we should just make this one rule recommended: false.

Additional context

In the future I'd like to look into a spectral-stoplight-ruleset with all sorts of rules relevant to Stoplight but not particularly relevant to other tools. Food for thought whilst working on this so we know the direction at least.

[lornajane]

I wonder if we could move to having a "minimally-valid" ruleset and then "probably-best-practice" ones? I agree with most of the current setup but always turn off tags since they don't make sense in our many small APIs. We use them in a few places, but not many.

[philsturgeon]

Although it's not explicitly stated anywhere, this is what recommended was meant to be. By default you only get rules with recommended: true, and to get all the rules you do this:

extends:
- ["spectral:oas", "all"]

Having all rules is basically the "strict mode" from speccy (remember --ruleset=strict?). If you enable this, prepare for a world of pain, but otherwise we tell you if things are structurally and semantically correct.

openapi-tags has felt out of place in this model, as its more of a strict thing than other rules so we're moving it over.