Pull requests don't need to be completed features

[matthewkmayer]

A pull request is a signal for feedback requested (http://scottchacon.com/2011/08/31/github-flow.html). They do not need to be a completed feature.

Small PRs are:

• easier to review
• allow short lived branches (trunk based development, no merge hell)
• easier to respond to feedback
• allow focus to remain on the task at hand instead of having multiple PRs for different tasks in flight

Large PRs:

• encourage rubber stamp approvals
• aren't empathetic to reviewers
• are more likely to have merge conflicts

Assumption: trunk based development (TBD) is superior to GitFlow or other SCM strategies with long lived branches.

[matthewkmayer]

Chacon:

Actually, we use it more as a branch conversation view more than a pull request. You can send pull requests from one branch to another in a single project (public or private) in GitHub, so you can use them to say “I need help or review on this” in addition to “Please merge this in”.

https://trunkbaseddevelopment.com/continuous-review/ :

A PR is one or more commits towards a goal described in an accompanying piece of text. The act of creating the PR from the branch signals the end (or a pause) in work, and the wish for the reviewers to get busy

[matthewkmayer]

Also rephrase the distance idea from https://trunkbaseddevelopment.com/5-min-overview/ .

[matthewkmayer]

Tickets/stories are what to do, coding and branching strategies are how to do them. Orthogonal concepts.

[matthewkmayer]

A common question is "if one PR doesn't fulfill a ticket/issue, how does the developer know when the ticket is done?" Answer: the same way they do it for a single PR: verify the desired behavior is present.

[matthewkmayer]

"Cutting the cord between pull requests and tickets"