Add core flagWords even when project has a custom .cspell.json

-1,

We chose to have our own config, gitlab_templates should not override us.

If this is added it should be opt-in not opt-out (per the BC rule they no change should be made that breaks existing test runs).

There is also a sample here or how a project that already has a cspell file can be referencing core without gitlab templates needing to be involved https://git.drupalcode.org/project/quasar_cspell/-/tree/main/docs/sample...

found that there are currently 117 projects that have their own .cspell.json file

I clicked a random one in the sample and found it implanting a variant of above to include cores dictionary.

https://git.drupalcode.org/project/vertex_ai_search/-/blob/1.0.x/.cspell...

Thanks for the above, and also for leaving your edit in strikethrough. That helps us to know from what angle you are approaching this, and I respsect your point of view about BC.

So, given that these flagWords are not in a dictionary, but this work is part of a general advancement of the state of Drupal code, I would still suggest that it should be opt-out, not opt-in. Many of the projects that have their own cspell config are doing it for other reasons, not to avoid using core flagWords.

It's good that we are having this discussion.

but this work is part of a general advancement of the state of Drupal code,

I will note that Contrib is not Drupal code, each contrib project is its own unique environment, what is good for Core may not be best for contrib, the only ones who can make that decision is the individual maintainers (Note: I've not reviewed the new flagword list this is a general concept statement).

This becomes more true when I look at the linked issue and it says "Many of these will have to be ignored, not fixed. So we could see an increase in the simple counts" as already and indicator that the change could be considered disruptive.

Many of the projects that have their own cspell config are doing it for other reasons, not to avoid using core flagWords.

This is true, however every single maintainer accepted that they would manually need to sync their lists when they deployed this file. I'm not against it as an opt-in.

I would still suggest that it should be opt-out, not opt-in.

For context:
Yesterday I had a test fail, due to the changes I wasn't surprised and I attributed it to a change in PHPUnit that I would need to track down. Later another MR came in with a similar failure on a change I was not expecting to cause a test failure. My first thought after this second failure was "What did gitlab_templates change this time that my tests that passed a week ago no longer pass". It turned out that it was a legitimate failure, however that is the situation that gitlab_templates has left me in as a maintainer.

It is only in typing this that I realize that means I no longer trust the tooling, that is a dangerous mindset for a maintainer to be in, and every time we make tests that cause failures we increase the burden on maintainers. This was why I pushed for the "any change that could cause a test that previously succeeded to fail" to be opt-in/major-only.

I feel like we've been through this in the past already. Nobody is forcing you to use the tooling that we provide, that part is really opt-in.

Also, you know that you can pin the version of the templates that you want/need, and then you won't get any changes: https://project.pages.drupalcode.org/gitlab_templates/info/templates-ver...

So, if you choose not to do that, then you are choosing to stay up to date and receive the "defaults", which will change over time as core moves forward. Some people like this way, some people don't, and that's why you can choose.

Sadly it seems like we have.

I likely just need to accept that there is no longer a “we won’t break contrib” BC policy for gitlab_templates and avoid expressing those concerns going forward.