Navigating Pull Request Reviews: Managing Feedback, Committer Engagement, and Author Responsibilities

Their intent is not to denounce your code, they want your code to be as good as it can be. Through their experience, they may also take notice of a seemingly insignificant issue that has caused problems before. Sometimes however, they can also get a bit carried away and become too perfectionistic. If you feel some of the requests are unreasonable, out of scope, or merely a matter of personal preference, try to nicely ask the reviewers whether these requests are *critical* to the PR's success. While we do have a set of [official standards for the Nix community](https://github.com/NixOS/rfcs), we don't have standards for everything and there are often multiple valid ways to achieve the same goal. Unless there are standards forbidding the patterns used in your code or there are serious technical, maintainability or readability issues with your code, you can disregard these requests. Please communicate this clearly though; a simple "I prefer it this way and see no major issue maintaining it" can save a lot of arguing. If you are unsure about some change requests, please ask reviewers *why* they requested them. This will usually reveal how important they deem it to be and will help educate you about standards, best practices, unwritten rules as well as preferences people have and why. Some committers have stronger opinions on some things and may not want to merge your PR if you don't follow their requests. It is totally fine to get yourself a second or third opinion in such a case. ### Committers work on a push-basis It's possible for you to get a review but nothing happens afterwards, even if you respond to review comments. A committer not following up on your PR does not necessarily mean they're disinterested, they may have simply had other circumstances preventing them from doing so. Committers typically handle many PRs at the same time and it is not realistic for them to keep up with all of them immediately. If someone approved and didn't merge a few days later, they most likely just forgot. Please see it as your responsibility to actively remind reviewers of your open PRs.

This document offers guidance on handling pull request reviews, emphasizing that while reviewers aim to improve code quality, they can sometimes become overly perfectionistic or make requests based on personal preference. Authors are advised to politely question the criticality of such requests and, if they do not violate official standards or cause serious technical issues, they can be respectfully declined with a clear explanation. The text also encourages authors to ask for the 'why' behind review comments to understand their importance and educational value. For instances where committers have very strong opinions, seeking a second opinion is suggested. Finally, it highlights that committers work on a 'push-basis,' meaning follow-up might be delayed due to workload or oversight, and places the responsibility on the PR author to actively remind reviewers about their open pull requests.