@vrybas.(blogs).here

Ruby / Rails / Agile / Productivity / Vim / ЗОЖ

Work-In-Progress Pull Requests

There’ve been a lot of criticism(1,2,3) on Github Pull Requests lately.

The summary is pretty much in this(4) Hacker News comment:

…GitHub is missing this kind of environment(IRC, Mailing List), so it’s almost inevitable that first contact between maintainers and potential contributors usually comes in the form of a pull request.

… and there’s no code review and discussion is done BEFORE a pull request, which is the main reason so many PRs are not accepted.

While it’s definitely true, it don’t have to be this way.

There’s a common mental model the Pull Request is something finished. The ready-to-ship kind of thing.

Well, not always.

In our team, we send Pull Requests as soon as there’s one commit in a new branch. Or even empty commit.

git commit -m "initial commit: User can verify their account" --allow-empty

Contributor starts with some basic ideas, small patches, failing tests. And then the PR grows collaboratively. Somebody contributes with comment. Somebody does commit. Sometimes commits are reverted and replaced with better solutions. It’s like an asynchronous pair programming with unlimited collaborators. The value is tremendous.

And PR got merged only when no one have better ideas. Ideally all team members, who are interested in keeping codebase clean and to have a collective code ownership(everyone, right?), should look through PR and leave thumbsup in comments. One thumb is required, others are optional(if you’re in a hurry with shipment, which you souldn’t).

Although this kind of Work-In-Progress PRs are possible only in repositories in which everyone has commit access to, I’d suggest to try this approach when sending PR from a fork. The early-on feedback is still very much valuable.

References:

neovim-prs

Comments