The Do’s and Don’t of Pull Requests and Bug Triage in Open Source Projects
summary
Advice: always create a topic branch instead of committing on master, keep master synced and rebase when resolving conflicts, and for review address comments with new commits then squash rather than opening a new PR. Run and pass CI and run recommended tests locally, add tests for new code, combine small related fixes into one PR but break large features into multiple logical PRs or commits. Triage uses labels and automation (example repo shows over 2,000 open issues and a transition from needs-triage to triage accepted).
AI-written summary · about
chapters (9)
- 0:00Introduction
- 1:10Overview
- 4:15Pull Requests
- 6:20Commit Messages
- 8:20Separate PRs
- 9:35Multiple PRs
- 10:37Review Comments
- 12:00Conflicts
- 12:55Triaging
related talks
21mA Guide to Perfecting Pull Requests
28mPull Requests: Merging good practices into your project
38mPull Requests and Reviews for Good
44mSurviving Code Reviews
29mThe Art of Humanizing Pull Requests (PR’s)
21mContinuous Improvements of The Code Review Process
16mAn unpopular opinion: Get rid of Pull Requests!
30mEffective Pull Request Reviews