Settle on required presubmit checks (automatic & manual)

[harpojaeger]

• Travis CI
• Linting; I think every PR should have to pass the linter 100%. Most findings can be fixed easily, if not entirely automatically, and this makes an enormous difference for code readability and maintainability. Also, it sucks for your first PR to fail linting because of messiness left over from other people's work. We could make exceptions to this rule in cases where the failing code is from previous work and correcting it would be seriously out-of-scope.
• Changelog: We should have one, and every PR should add to it. This will vastly simplify versioning and releases.
• Small PRs: The best summary of this that I know of is: "If something could reasonably be in its own pull request, it probably should." I don't think automatic size checks make sense in most cases, but I'd like to establish and document the norm that things should be split up whenever possible. A PR is ready for merge when it won't break the app at build or runtime and contains enough functionality that it won't make the codebase a great deal more confusing as-is. Even if there's more work to be done, or some unused code now needs to be removed, if that can be done in its own PR, it'll make the review process much, much faster and easier for everyone involved.

[bchrobot]

• Agree
• Agree
• Agree
• Agree. In the case of very complex PRs, we can encourage splitting it up into chained PRs. The first PR targets develop and each subsequent set of changes targets the previous PR's branch rather than develop. The child PRs can be reviewed independently and either merged down into one branch, or merged sequentially into develop (requires changing the PR base branch). Pushing branches to spokecommunity/Spoke may make this easier.
  • I think we should also encourage people to include better robust PR descriptions that include high level rationale and how to review the PR (what order to read files in -- going through files alphabetically is not always the best way to make sense of the changes).

[harpojaeger]

Very good points. Of those two strategies, I favor branches being merged sequentially, so each merge is as contained as possible. And +10 to PR descriptions that describe why a system works the way it does, how to read it and how to test it.

[jlegrone]

How about a contributor's license agreement?

[jlegrone]

I also touch on changelog generation in https://github.com/spokecommunity/Spoke/issues/4