New Developer Etiquette: My PR is stalled. Should I leave it open?

So my first ever contribution to a big open source project is a PR to get the decora_wifi integration to setup through config flow. I won’t lie, getting a dev environment set up was daunting for someone who has only taken a couple of University level programming classes, but the documentation was very thorough and with a few exceptions I was able to get everything set up, develop a draft of the integration, test it in a Docker container on my own Leviton switches, and submit the PR. The feedback on the PR has been excellent too, and I’ve learned a ton from the reviewers, but I’ve admittedly been pretty slow to make the necessary changes both because I’m still learning the API and style guidelines and because I’ve been dealing with a bit of personal crap…

Anyway, bottom line is this: my PR has been open since May; I’ve made requested changes, added tests for the config flow and common code, opened the PR for the documentation change (which has since been approved) and generally gotten my code to a much better place than it was, but because of how long it’s been open it’s so far down the list that I feel like it’s no longer being looked at. Also, because it’s my first contribution, it requires maintainer approval for workflows to run and that was never done, so it’s just kind of hanging out there, open but maybe not being considered.

It seems likely that it would be rude to close the existing PR and open a new one from the same branch in an attempt to bump the proposed changes back to the front of the line, and I understand that everyone else is also working on this in their spare time so I don’t want to be all impatient. But at the same time I don’t want to be sitting on this months-old open PR that nobody wants to deal with and maybe discouraging others from developing on this integration. What is the correct thing for me to do?

1 Like

It would bump it further back in the queue. There’s a fair few that need reviewing.

1 Like

Ok, sounds like the best bet is just to be patient and wait it out then. Anything I need to look out for or do on my end specifically with regard to getting Workflows approved to run?

You could politely ask for a review in the core developers channel on discord. https://discord.gg/K6myJyzY

1 Like

Periodically adding a comment to the PR may help it move up in the queue.

1 Like

Ok, got a workflow approval and made the changes, but now I’m back to waiting for approval again. I do understand why that’s necessary, but it doesn’t make for a great experience–kind of wish GitHub would make it possible to waive that requirement (or only require approval once) for PRs that don’t make any changes to the repository’s .github/workflows/. I guess that’s really a GitHub limitation, not an HA thing, though.

Anyway, in the meantime, are there things one can do to make sure that pylint, etc. on my development box produces the same errors/warnings/etc that the workflow would–maybe a previous thread or something? Ideally, I guess I’d like to minimize the number of rounds of re-approval needed to get this thing over the finish line.