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?

  • Does this answer your question? code review with git-flow and github – gnat Feb 10 at 15:45
  • 1
    @gnat Thank you, but it does not. I am asking about reviewing code that is incomplete and not ready to be merged. That question is about ready-to-merge features. – Evorlor Feb 10 at 15:50
  • 1
    Have you considered pair programming? – Didier L Feb 11 at 9:47
  • 1
    Frame challenge: Don't send a group mail asking everybody to chime in. Pick one fellow team member if they will review your code. (And I'd also opt for a personal meeting instead of e-mail ping-pong. When you're new in an area, you have too many wrong assumptions and open questions to be effectively communicated in writing.) You can't have it both ways: Either you (potentially) inconvenience someone or you don't get useful feedback. – Jann Poppinga Feb 11 at 13:43
  • 4
    "then they would have to find the diffs themselves, which not everyone knows how to do" ...what? It may not be the ideal tool for your specific task, but this is such a basic development tool that if technical members of your team don't know how to compare two branches in git then I would seriously be having a rethink. (Hint: In GitHub, the button right next to "Create pull request" says "Compare".) – user3067860 Feb 11 at 19:12

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.

  • 12
    Another convention is to just use [WIP] in the title of the PR. – phipsgabler Feb 11 at 9:47
  • 9
    "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" — this feels very important, +1. If you don't do this in advance, you're likely to get feedback on things you know aren't right (not linted, lacking tests or whatever) which will be frustrating to you (since it's on your TODO list) and frustrating to them (since they put in the time for granular feedback & it's not valuable). – anotherdave Feb 11 at 12:08
  • 1
    Note that this feature is only available for repos that are open source, or paid private to the enterprise. Essentially it’s a paid feature (+ for open source) – Kzqai Jun 4 at 14:36
  • 1
    @Kzqai: I didn't know that feature was restricted, I guess because we're using it on open-source repos. – FrustratedWithFormsDesigner Jun 4 at 15:36

This comes down to the tools that you are using.

Since you mention GitHub, I'll point out that GitHub supports draft pull requests. Other tools may also have similar capabilities. The purpose of draft pull requests is exactly what you point out - to let people have a good view of the pull request yet prevent merging until it's ready.

Not all tools support this, though. Bitbucket, for example, doesn't. However, you can configure tools like Bitbucket to prevent merging if someone adds a task. For a draft pull request, a developer can open the pull request and add a task. Not assigning assignees to review can also indicate that it's a draft and make it less likely to merge.

For developers, though, I don't think that pointing them to a branch and asking them to use diff tools to compare would be a problem. This kind of functionality is built into a lot of mainstream IDEs already.

  • 2
    just for the record. GitLab implements MR (Merge requests) and it's basically the same thing. – Laiv Feb 10 at 16:05
  • "asking them to use diff tools to compare would be a problem" Ah yes how we did it in the "good" old days. It'll probably be a good reminder of how awful that experience was and why PRs took over the world so quickly. So no please don't do that. – Voo Feb 11 at 8:26
  • @Laiv Gitea also implements draft PRs. – wizzwizz4 Feb 11 at 9:23
  • 1
    @Vood I have merged two forks with 6month of changes never synced, with Meld and many questions to both teams XD – Laiv Feb 11 at 10:01
  • 2
    @Laiv "They were so preoccupied with whether or not they could, they didn't stop to think if they should" ;-) – Voo Feb 11 at 13:33

All code is a work in progress and every PR is a request for comment. Since our tools should be used to help us work, we first should decide how we want to work.

  1. Always merge your own PR, and never merge someone else's PR.

This is your code and you're the expert at how it should be merged and how conflicts would be resolved. If it's understood that you're responsible for your own code until the point it's merged, then you won't need to worry about accidental merges. For people who merge other people's code: stop micromanaging.

  1. Submitting a PR should be the one and only standard for requesting feedback.

Each reviewer has their own standards and as a team you'll have common standards. There is no reason to ask for different standards when requesting a review, regardless if the code will be merged or it's just an idea. Adopting this rule also means your team knows the role of a PR and has a direction to which to improve the process. Common additions to the PR is automated testing, syntax rules, security checks, etc.

  1. You should indicate in code the intentions (if possible)

In general all PRs should be ready to be merged at the time the PR is made, that's the idea all the reviewers should have when reviewing. Whenever possible, you should make features such that it can be controlled with a feature flag. Even if you're not ready to merge, or don't have the intention, your code should be. Designing features that can be controlled with flags encourages modular designs, allows the code to be merged in small pieces, and most importantly indicates this work is a Work In Progress.

  1. Submit PRs along the way

As you build a feature you'll find your PR is made up of code needed to support the feature and the code for the feature itself. Support code would be refactors required, creating new utilities, adding a new service, etc. While this is needed for your PR's main feature to work, it could also be done as its own PR. This allows you to get feedback early while also being able to merge the code, in addition you can continue to work on feature while waiting for comments on the smaller ideas. When it comes to the main feature, there should be far less feedback to even request.

  1. All code is work in progress

All code merged in should be near perfect, but with the understanding that you can always make another PR. The first priority of a PR is to ensure the code won't break the application, so that should be the main purpose of the review. The second priority is to ensure the code can be maintained, like style and common practices. Anything beyond the strictest measure of correctness and strictest definition of maintenance is extra, and should be understood as such. Always feel free to make any comment, but also have the goal that the code should be merged in ASAP. But don't create TODO tickets just to get a PR merged, that's purely unethical.

  1. The PR process is also a work in progress

Teams of different sizes and capabilities will have different practices. As your team grows and evolves, make sure you allow your process to grow and evolve too.

  • 1
    "Always merge your own PR, and never merge someone else's PR" — many environments have decided how they want to work is by having "core" committers, so you often can't merge your own PR, one of the core team must merge. This is why it's called a Pull Request in the first place. – Stephen P Jun 3 at 17:14
  • 1
    @StephenP Pull Request is a tool terminology, and not a part of git itself. This goes along my intro: "tools should be used to help us work". And what you are describing is how the tool is instructing your work. I have worked in companies with very strict Change Control, and everyone merged their own code just fine, so I've experience the possibility. The company invested the effort to solve the problem for the employees instead of for the business. I recommend checking out Extreme Ownership and the practices taught there. – Michael Ozeryansky Jun 3 at 21:09
  • I think this also needs comments that don't assume the developer is already all-seeing and fully-fledged, rather that the dev may not yet understand the codebase, so interaction and support is a better model in those cases. – Philip Oakley yesterday
  • @PhilipOakley I didn't intended to write this assuming any level, and actually re-reading my post I still think it would apply to any experience. Giving new devs the same freedom as a senior devs is fairly important, and there's nothing stopping a senior from helping or for the dev to ask for help. Having an open process would allow entry level engineers to focus on the code itself and not the process. – Michael Ozeryansky 19 hours ago

Not the answer you're looking for? Browse other questions tagged or ask your own question.