[Keyboard] add arrowmechanics/wings

[philvec]

---

Description

• implement all essential funcionality for wings kb
• add default layout

this PR has been re-created after cleaning up the mess in the old invalid one (closed): #23227

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[zvecr]

This PR seems to have too many comments/issues vs. few changes that it actually introduces. Closing to create a clean version since it may take too much time to dig into things that are already fixed.

Exactly the opposite, and this should not have been done. Now you have created more work for reviewers as we need to cross-reference the old PR to make sure all comments are addressed.

[philvec]

Despite the facts, I really don't want to cause trouble.
BUT why exactly do You need to cross-reference it, can't we treat it as a different PR (what it actually IS) ? By the time I was mainly just applying the reviewers' suggestions, numerous other PRs were merged, some without having the checks passed, some created later than this one. Some side-comments of mine (like the one mentioning a possible issue with more important code) were not addressed at all though there were multiple reviewers' activity marks. Are You sure these are all good practices?
On the other hand, since I was just applying the suggestions, the job that needed to be done there as well as the mentioned cross-referencing here would require less keypresses (and thus less time for a kayboard-geek I guess? 😆 ) than writing Your comment. Literally reading outloud all the lines of code in this PR would take less time than You guys spent together writing these comments and seeing my responses. Sorry it went this way, but I really don't want that.
So here it is, a new PR, consider it a different story, do the review from scratch - it will come easier (and sooner!) anyway, thats how it seems.
Or otherwise, what is the real problem here?

Honestly, I understand this is Your time You guys commit, but I guess there is also responsibility. If its real issues and You are here and see them, please tell me what to improve and I will do so. I will do anything I can to speed this up, but I guess I shouldnt be saying 'please' and write other non-statement-like, not-directly-code-related stuff, because its not considered a good practice, right?
PLEASE guys, just do the review, I am torturing the refresh button here for two weeks already. 😢

[tzarc]

BUT why exactly do You need to cross-reference it,

Because too many people close PRs with a whole bunch of requested changes that they don't feel like doing, reopening a new one with the hopes that we don't pull them up on the same requested changes.

We now need to refer to the old one, and for each and every requested change you're asking us to refer to TWO pull requests -- what did we ask for last time, and did you actually fix it this time.

Repeat for the next PR reviewer.

These are the sorts of supposedly "helpful" things that make things much, much worse for people reviewing.

We understand you feel super happy and excited about your PR, but at this stage there are 324 other PRs open, and from our perspective, yours isn't special. You'll have to wait for someone to get to it.

[philvec]

#23320

• just another keyboard one from the list - less than 2 days, numerous commits and comments - 2 approving reviews already
  How does one make their PR "special" ?

[tzarc]

There are no "special" PRs -- that's the entire point. Some of my own open PRs are still unreviewed by others since early January.
And besides, that PR has one approving review, not two. All the churn is from dunk2k, who is not a QMK maintainer.

To gain some perspective, please have a read of these links:

• GitHub Etiquette
• Don't be that open-source user, don't be me
• Open Source Maintainers Owe You Nothing
• Entitlement in Open Source

I'll also point out that debating the situation and getting us to take the time to describe why things are as they are takes time away from actual reviews. Food for thought.

[philvec]

Yeah, I get it, I get it... Really didn't want to demand anything from anyone, was just curious what else I can do. The last argument of Yours I mentioned myself above. I am a geek too for years, I know the OS vibe. I will stop commenting, just consider this perspective: if there's anything I can do, review/write any needed code myself, walk Your dog, do the chores - I'd really love to if only I could. If I can contribute anyhow in particular, if there's any task around QMK nobody wants to do - please tell me, maybe it so happens that I have the skills - I do Python for a living but I know C since I was 10 - I can spend a full day or two on that. filip@arrowmechanics.com
I'm not the one demanding, I'm the one excited, I hope that keeps You guys from getting burnt out 😉

[philvec]

@nooges by the last commit I guess You may be the one who understands <3 also, thanks @dunk2k but I'll let sb check Your suggestions as I am not sure and don't want to cause more hussle

[philvec]

THANK YOU AND HAPPY EASTER