Every workplace I’ve been has had some sort of convention for nitpick PR comments. ConventionalComments.org defines nitpicks as "trivial preference-based requests" that are "non-blocking by nature."
There are a few problems I have run into with nitpicks. If something is truly trivial or preference-based, a developer probably should not change it. A trivial issue should have little-to-no business impact. There are usually plenty of features or bugs to work on that will deliver value.
The next problem I have seen is mislabeling: a non-trivial issue masquerading as a nitpick. For example, some code that doesn’t follow a style guide. These sorts of things may seem trivial at the time but they'll slowly erode the quality of the codebase.
The final issue I have seen is this can result in serial nitpickers and nitpick fatigue: people who gladly list all their trivial recommendations on a PR. These are often really smart people. But others start valuing their PR comments less because of the volume of comments.
Ultimately, whether or not the team uses nitpick comments isn't nearly as important as having open communication about expectations. Agree on what is and isn't a nitpick. Decide whether nitpicks can block approval. And encourage team members to chat with each other during the PR process if there is going to be a large number of comments or if there is any confusion.
If you enjoyed this article, consider subscribing on Feedly or your favorite RSS consumer.