3 ms·
I maintain a few open source projects, and found this list to align very closely with my own desires: https://davidwalsh.name/45-github-issues-dos-donts https:/
by djmashko2 10y ago
I maintain a few open source projects, and found this list to align very closely with my own desires: https://davidwalsh.name/45-github-issues-dos-donts https://davidwalsh.name/45-github-issues-dos-donts
Some highlights:
- Do submit one pull request to address one issue.
- Do submit two pull request to address two issues.
- Do not tack on a minor whitespace or semicolon changes in unrelated commits or Pull Requests, even if the minor change is correct. Make a dedicated commit or Pull Request instead.
In general, the smaller and easier to understand a PR is, the easier to merge. I've seen a lot of PRs lose their way due to a "while I'm here" mentality of fixing code style etc, and it often obscures the real purpose of the contribution.
- clusmore 10y ago>- Do not tack on a minor whitespace or semicolon changes in unrelated commits or Pull Requests, even if the minor change is correct. Make a dedicated commit or Pull Request instead. Second this point in particular. I work in a small team (4 people) and we used to have a policy of doing code cleanup as we go, but we didn't do very thorough code reviews. After we improved our review policy, now using Pull Requests in Visual Studio Team Services, reviews involving code cleanup became a nightmare - hundreds of syntactic-but-not-semantic changes to dozens of files with a handful of the real changes hidden in there somewhere. We've since changed our cleanup policy so that they must be submitted separately, and even then we try to keep re-architecture and other semantic changes separate from more trivial cleanup, like typos in comments or identifiers, rearranging of methods, etc.