Newcomer… but Not New
summary
Practical checklist for senior internal engineers moving code upstream: expect social and process friction, not technical gaps; use pre-review with a mentor and aim for novel commit messages that explain why (not the diff); target reviewers via blame, maintainers, or trade reviews; expect slow cycles and platform compatibility work; examples include JGit and OpenBMC integration, Gerrit/Git workflows, and an 827-line Git style guide — Google uses a “next” pre-release and a one-hour daily review slot to keep turnaround.
AI-written summary · about
chapters (11)
- 0:00Open source transition intro
- 4:56Cultural differences in work
- 11:40Code review with strangers
- 17:35Effective commit messages
- 20:02Finding mentors and pre-review
- 23:36Securing reviews and momentum
- 28:51Review delays and maintainer views
- 32:26Confidential changes upstream
- 35:59Release cycles and workarounds
- 38:46Open source benefits
- 41:21Q&A on commit messages
related talks
47mDevelopment Best Practices: An Overview of Working in the Software World
01h 05mGetting Good (or Better) at Code Reviews
29mCode review, do you speak it?
33mCode review for Open Source
34mDeep End Diving: Getting Up to Speed on New Codebases
24mElevating Young Developers: Best practices for seasoned developers on onboardings
39mEffective Code Review
46mGit Workflow Etiquette: Repository Organization for Clean Codebases