How to Get Reviewers
to Block your
Tips to decrease your productivity by 75%+!
Add spelling/grammatical errors to the commit
Remov some dupcilate unit tests
Their our several locations wear some unit test mixins our
incorrectly used multiple times...
Make the commit message unrelated to the change
● Describe a problem only vaguely related to
● Use “Closes-Bug:” like hashtags on Twitter.
(The numbers afterward should be
Fix a known bug without a link to its Launchpad bug ID
● Launchpad is used to track the status of
bugs. Make sure the core team and release
manager don’t know that a critical bug has
Make a high-impact change without a blueprint
Anything that changes the following:
● The REST API or messaging API
● Internal APIs used by many files
● Runtime behavior that affects users
No unit tests
Don’t include any unit tests with your change.
This is especially true if existing tests didn’t
break with a behavior changing patch.
Describe the Bug
Describe the bug in the commit messages
instead of in the fix.
There is a race condition in the L3 code.
A deadlock exists. Not anymore.
Include 1 test for a 1000-line change
Make the number of tests you create inversely
proportional to the number of lines changed.
Change as much unrelated whitespace as
This makes back-porting changes terrible for
Fix unrelated bugs in the same patch
Make small changes to nearby functions that
are completely irrelevant to the change at hand.
This confuses reviewers and also makes back-porting
Make broad changes that don’t do anything
“Fix capitalization of every inline comment in
the code base”
This produces tons of merge conflicts for other
patches in review.
Long response times
Wait weeks to respond to comments from
reviewers and to upload corrected patches so
reviewers have to relearn the whole thing.
Make functions untestable
Make functions that fulfill the following
● >100 lines
● variable names so short they are unreadable
● variable names so long they require several
line-wraps to work with