Merging PRs

Basic rules of thumb to merge changes into Crystal

1. Do not directly commit to master, always create a branch.
2. If a crystal-lang org member creates a PR, at least one other member has to approve it before it is merged. In most of these cases the approver will just merge it. In some cases they may not feel sure to merge even when it looks good to them: in those cases it is totally ok to leave the PR approved and ask for another member to look at it for further assurance.
3. If a contributor who's not a member of the crystal-lang org creates a PR, at least two members of the crystal-lang org have to approve it before it is merged. This is not because of over jealousy: it is to guarantee that the knowledge about the change doesn't lie in just one person.

Minimum requirements to merge a PR

1. It must have passed CI.
2. Every new public API has to include some minimum documentation: params (and particularly interesting combinations of them if the method is complex), results, interesting, self-contained examples. By public API here we mean any method or member that can be accessed from outside the module/class/struct, etc.
3. Unless the PR is just a refactor or a documentation change, it must include changes to the specs that reflect and check the new behaviors.
4. If the change affects the compiler, run a couple of benchmarks to check how it affects compiler performance. If it affects the compiler negatively, involve other members in the discussion to ensure that the change is worth the performance penalty.