Add conditions to deciding if a blog post is needed

Very +1 to this will save a lot of overhead.

Thanks for opening this! Adding myself as a supporter in general. Agreed that most of the time, the blog step is extra work for no benefit.

One very minor nit is that linking to https://www.drupal.org/about/core/policies/core-change-policies/allowed-... is somewhat unhelpful for coding style changes, since the definition there is:

High-risk and disruptive changes

• changes requiring an upgrade path
• changes that risk regressions
• other disruptive bug fixes or high-risk changes

The first two points don't make any sense for coding standards, and the last point is a circular definition (basically "disruptive changes means disruptive changes"). I'd drop the link, since it doesn't add any value in this context IMHO.

That said, it wouldn't hurt to be a little more specific for the criteria that the CS committee will use to decide if something is "disruptive". 😅 Not entirely sure if we should add that to the process docs directly, or what.

Here's some brainstorming about it:

Generally, I'd say new standards about new language features we haven't started widely using would be not disruptive. Or changes to standards to be more permissive than we already are (e.g. "no longer require ...") aren't disruptive, since they allow even more code to be compliant. No one *has* to adopt these new standards and change their existing code, so it's not disruptive.

So here are some possible definitions of a "disruptive" coding standard that would trigger a blog post:

1. Would cause existing phpcs jobs that currently pass to start failing.
2. Would require more than 100 (?) lines of change to the existing Drupal Core codebase to be in compliance.
3. Changes an already agreed standard to to be more specific and would likely require changes to Drupal Core and many (TBD) contributed projects.

We should pick one of these (or something else), I'm not saying all these criteria need to be met. They're sort of different ways of trying to phrase the same basic idea. If anyone has a more concise and accurate definition, please suggest alternatives / improvements. I'm not attached to any of this.

Thanks again!
-Derek

+1 - I am not sure there is enough interest outside of our small group to warrant the time taken here. Most real world projects I work on have their own ruleset based on Coder with a small number of tweaks; so far any changes haven't caused any significant impact that I recall.

I think we should leave the definition of "disruptive" open to the individual case, I'm not sure we can plan in advance all types of things that might be disruptive.

Yeah, I'm cool with not formally documenting what counts as "disruptive", and leaving that to the discretion of the committee case-by-case. But I wanted to at least start the conversation so we have some sense of what we actually mean. 😅

I think things like requiring use statements be sorted alphabetically would be "disruptive", since when coder preemptively made that change and rolled it out, all of a sudden a ton of contrib projects started getting failing phpcs jobs. That's the sort of thing we should be wary of.

I think this is good as it is now. I think we can close this issue as it is now done.

Looks good, thanks y'all.