I am working on a feature with a system that I am unfamiliar with. The feature is not ready, but I want to show the code to my team (who is familiar with the system) so they can give me early feedback. We are a fully remote team.
Making a pull request on GitHub so they can see the differences seems like the easiest way to do this. But then I will be creating a pull request that is not ready to be merged. This sounds dirty to me for various reasons, such as it muddies up the PRs, and someone may accidentally merge it.
I could just point them to a branch, but then they would have to find the diffs themselves, which not everyone knows how to do. They are also much less likely to review the code at all. I am hoping to let them review the code on their own time, instead of setting up yet another meeting.
Is there a standard for getting early feedback on work-in-progress features?
Best Answer
GitHub allows for PR to be in a "draft" state. Your team can see the differences, and even comment on it, but it's still obviously a work-in-progress, and cannot be merged until you click a "ready for review" button, which makes it mergeable.
I'd also say that if it's a work-in-progress, give them a clue as to what you want them to focus on, such as saying "I'm most concerned about the payment processing algorithm in SomeClass". That way they don't spend time reviewing other parts of the code that are subject to change even as they review.
See Draft Pull Requests and Convert Pull Request to Draft.