Skip to content

Instantly share code, notes, and snippets.

@mherrmann
Created October 16, 2020 05:36
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mherrmann/5ce21814789152c17abd91c0b3eaadca to your computer and use it in GitHub Desktop.
Save mherrmann/5ce21814789152c17abd91c0b3eaadca to your computer and use it in GitHub Desktop.
Hi! Thank you for offering a PR for one of my open source libraries. I really
appreciate it, because in most cases, I have very little time to maintain them.
I often get PRs that lead to a back-and-forth between me and the contributor,
where I ask them to undo many of the changes they have made. To avoid this in
your case, or to at least give you an idea why I'm asking you to adapt your PR,
here are my criteria for accepting PRs.
Every PR should have one, and only one, unique goal. Your PR should make the
absolute minimum number of changes that are required to achieve this goal.
Think about it from my perspective: I have to read through each change you make.
The fewer things you change, the easier it will be for me to see what you did,
and thus to gain confidence that your PR makes sense.
Some examples:
* Don't unnecessarily change whitespace, eg. switching tabs and spaces.
This leads to huge numbers of unnecessarily changed lines of code.
* Don't run a linter on my entire code base as a side effect of your PR.
* Don't unnecessarily introduce new tools or dependencies. I'm sure you have your
favorites. But don't force them on me or other contributors. Stick to those
that are absolutely required, or come with the language.
* Obey the same code style as the library: Tabs or spaces, maximum line length,
etc.
In short: Good PRs are minimal. You're very welcome to add several improvements.
But please make them in separate PRs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment