cspell complains about DrupalPractice.General.OptionsT.TforValue

Yes, of course I can do that. I could also turn off cspell entirely. Or I could use phpcs:disable/phpcs:ignore without an argument to disable everything instead of disabling just one specific sniff. But I think that's extremely bad practice.

But it's silly that Drupal-specific phpcs sniff names are not automatically excluded.

I mean, solving a phpcs issue with a phpcs:ignore causes a new cspell issue. That's just silly.

Either cspell should ignore things like phpcs directives or the phpcs sniffs should use naming/casing conventions that are recognized by cspell.

I *think* if it were named DrupalPractice.General.OptionsT.TForValue instead of DrupalPractice.General.OptionsT.TforValue then cspell wouldn't complain. (TFor instead of Tfor).

And since incorrect camel casing is considered a phpcs error, it's again very silly that the phpcs sniffs have incorrect camel casing.

And now we've come full circle.

I opened this issue in Core, where it was declared as not a core issue by @quietone and moved to Coder. See #4.

Now it's not a Coder issue anymore and it's "won't fix".

Note that my original post, back in July, did suggest two things:

1. Add the sniff names to the core dictionary, or
2. Correct the sniff names to follow core Drupal naming standards

Both of these are still viable options. Core objects to 1) and Coder objects to 2). I don't see how moving this back to Core and saying core should do 1) will get us anywhere, because that was rejected back in July.

And it feels like I'm being cut out of the conversation after 6 months and that my input so far is being thrown away, because this issue is now "won't fix" and the new issue does not preserve my contribution to this issue.

It is this dysfunctional Drupal core issue handling that has left so many little things unresolved for so many years. It can take 10 years to get a small patch like this through the system. Not an exaggeration - I can cite many examples. While major BC-breaking changes to core can happen in just a month. Again, not an exaggeration.

I find it enormously disrespectful and discouraging. This process has been a waste of my time and illustrates why community participation has dropped precipitously since the Drupal 7 days - core is sending the message that it doesn't care for community contributions.

Thank you @jonathan1055 for trying, but the fundamental problem seems to be that core maintainers don't really care about problems like this which affect contrib on a daily basis, and are unwilling to spend any time on the small issues.

However, you cannot expect the Drupal core maintainers or me as Coder maintainer do the work for you. We can give you direction and we can review merge requests when we have time, but the work is assigned to the community (you are part of that group).

I think it's very clear from my contribution history that I am perfectly willing to do the work. That has never been an issue. And you know that. My entire tenure of involvement in Drupal has been doing work (on a volunteer basis) that no one else is willing to do.

While I have demonstrated that I am quite willing to *spend* time contributing, I am *not* willing to *waste* time doing work that has no chance to be accepted.

Thus, when opening an issue I first point out a problem and posit a solution or two, and ask like I did above "What would be the proper fix here?". I expect the maintainers (core or Coder) to choose the way they want to resolve the issue.

IF there is agreement as to what should be done, THEN I will do the work if I can. It would be a huge waste of my time to do work that no one wants.

In this particular case, I personally would have solved it by renaming the Coder sniffs (with the necessary deprecations and testing) as well as ensuring through testing that no new sniffs get committed unless their names comply with Drupal coding standards. And like you say, it would be a lot of work and not the easiest solution. If I had done that work pre-emptively it would have been wasted effort because that course of action was rejected in #5.

I am sure @klausi did not intend to cut you out of the conversation, it just seemed that way when the issue was changed to 'closed (wont fix)'.

I was not trying to imply intent. I was just saying that it feels disrespectful when this happens. And it happens a LOT. At least a dozen time last year there were issues that I had been contributing to for YEARS, including writing patches and tests and re-rolls, that were closed because the issue was fixed by a new issue opened years later. A new issue where the poster had not even searched the issue queue for existing issues but the maintainer immediately accepted the solution that was offered in the newer issue - usually the same patch that I had working years before. And that's exactly why I will no longer offer complex patches up-front, until there is consensus for what should be done. It is IMO part of the maintainers role to set and/or approve direction and delegate implementation to those willing to take on the tasks, not just to sit in judgement. The maintainer has the birds-eye view, and is the one who should be saying "no, we're not going to go that way", or "yes, that looks like a good way to handle things so why don't you code that up and I'll commit it"

Isn't that how things work in your day job? What you work on is discussed and agreed with your manager and/or employees and/or clients (whether that work is good enough is a different discussion...). You should never be in the position of spending months or years on a task that management doesn't want or clients won't pay for. If that's SOP in your company, then you're going to lose employees. Drupal is no different, and Drupal *has* lost contributors hand over fist over the past 10 years.