I hear the sentiment of what everyone is saying here. I have a foot in both camps by reviewing a lot of these PRs and also waiting sometimes >1yr for my own PRs to be reviewed.
My best advice is to keep your PRs short. A short, simple PR will get reviewed more quickly. It raises fewer questions, has lower risk, and is much less likely to become complicated or conflict with anything else. Less than 100 lines automatically gets the ‘short PR’ tag. If you can break a 600 line PR into 10x 60line PRs, it will be way quicker, as you are not asking for such a bulk time commitment from the reviewer.
Second piece of advice - put yourself in the mindset of the reviewer. They are just another human. Make the description really clear, explain what you are doing and why. Don’t give them lots to figure out. If you are doing something that might break things, describe how you’ve mitigated the risks.
Lastly - be the change you want to see. While you are waiting, review some other people’s PRs. They will value it and often return the favor.
Pinging your PR or tagging people is not a good idea unless there is a specific reason for urgency such as something else being broken. Many reviewers will de-prioritise overly pinged PRs to avoid encouraging this behaviour.
In case anyone is not aware, this is the list of open PRs for HA core (currently over 500), the default sort is newest first. I recommend looking at where your PR is on this list before insisting that you’ve waited an unreasonably long time.
Thank you for your contributions (and your patience!).
Respectfully, your post comes off a bit “privileged”. Have you ever owned/maintained a project as large as home assistant with this breadth of integrations without expecting compensation? Some things I’d counsel you on personally:
This project has a high amount of PR contributions.
Your personal PR isn’t special just because you wrote it.
Your personal PR isn’t “free code”. It will have to be modified to be better quality, potentially change design, etc. If you’re a developer you should know PR’s aren’t the finish line. They’re the half way point. You have a proposal that takes work to be production ready.
How small are your PR’s?
How good is your code?
Have you looked into what you could do to start reducing the overall piles of PR’s instead of whining yours isn’t being addressed?
I suspect you’ll change perspective after you’ve developed 15+ years and/or get some more personal hobbies that consume your personal time.
My 2c, solution is not to review faster or more, solution is to have the HA platorm clean from integrations,
Have all integrations managed by HACS,
Have more strict rules to tegister custom components to HACS with automation tests (as part of pre-commit), and when there is a breaking change that requires opening code of many components it will be easy to notify the developers of that component as they are registered with their repo in HACS.
Forcing moving to HACS is sweeping the issue under a carpet aka failure, it is not a solution. HACS grew into a somewhat close to must-have for HA. HACS also carries a lot of unusable stuff, however it isn’t relevant to the point. There’s enough integrations which are used instead of their core counterparts, sometimes, even because of the bugs and instabilities in the core ones. It’s effectively a claim that devs give no stability guarantee for integrations in HA.
Root cause from a 100 yards seems to be that Home Assistant is understaffed and underfunded, with maintainer priorities drifting away from users and an org structure that is struggling to scale to meet demand. Good engineers are not necessarily good managers. So basically typical big open source project issues. These are great problems to have, but need to be handled in the next few years or the project will be supplanted by another that can better handle the organization and funding side of things.
My suggested solution:
Break Home Assistant core into multiple repositories, identify components with most stale PRs, then assign more HA team members to regularly review those and/or grant top contributors to those repositories merge permissions.
Create strict PR merge requirements and enforce them by revoking permissions if a contributor is merging without verifying.
Have the HA team focus on building a rock solid integration testing framework so the volunteer reviewer army can scale without decreasing stability or putting all PRs on shoulders of HA team. Make adding integ tests (not just unit tests) part of PR merge requirements.
Not perfect, but better than current situation of asking contributors to review other contributor PRs they can’t merge, and PRs lingering for 6+ months as a result, often before being abandoned. Allot of community good will is being wasted.