Pull Requests

I'd like to start a discussion around how we handle pull requests, both on internal projects and on open source ones. I personally think agreeing on a certain workflow for pull requests that we try to stick to most of the time is super valuable, since it tends to increase productivity and decrease friction (especially when dealing with a large number of projects, as we do).

Having clear guidelines also helps for external contributors, since it sets clear expectations of how we work and deal with PRs.

So, what I'd like to suggest to kick off the discussion is a few points (not saying we're not doing these at the moment, just my ideas on what I think makes a good PR workflow for teams):

- Always use descriptive PR titles & descriptions.
- Squash commit history if full of "temp" and "experimental" commits that don't add value to the history.
- Keep PR size to a minimum to make them easy to review and low-risk to merge in. (IMO, a 500 line change limit is a good guideline).
- Keep individual forks of our repos, and keep experimental branches there. Submit a PR when ready. On private projects we can use a branch prefix (for example `josu/experimental-`) to distinguish experimental branches.
- Favor private branches instead of "WIP" PRs. Reduces noise for the rest of the team. Clearly mark WIP PRs when really needed (for example if testing out things on CI).

What do you guys think of the above? Agree/disagree, or anything you'd like to add? Let the discussion...BEGIN! 💃