[contribution] Update contribution guidelines.

cranelift/CONTRIBUTING.md

@@ -69,8 +69,8 @@ version. See the [rustfmt quickstart] for setup.
 [format-all.sh] is a script for running the appropriate version of rustfmt,
 which may be convenient when there are multiple versions installed.
 
-[rustfmt-preview]: https://github.com/rust-lang-nursery/rustfmt
-[rustfmt quickstart]: https://github.com/rust-lang-nursery/rustfmt#quick-start
+[rustfmt-preview]: https://github.com/rust-lang/rustfmt
+[rustfmt quickstart]: https://github.com/rust-lang/rustfmt#quick-start
 [format-all.sh]: https://github.com/CraneStation/cranelift/blob/master/format-all.sh
 
 ### Rustc version support
@@ -90,7 +90,20 @@ We use [issues] for asking questions and tracking bugs and unimplemented
 features, and [pull requests] (PRs) for tracking and reviewing code
 submissions.
 
-When submitting PRs:
+### Before submitting a PR
+
+Consider opening an issue to talk about it. PRs without corresponding issues
+are appropriate for fairly narrow technical matters, not for fixes to
+user-facing bugs or for feature implementations, especially when those features
+might have multiple implementation strategies that usefully could be discussed.
+
+Our issue templates might help you through the process.
+
+### When submitting PRs
+
+ - Please fill in the pull request template as appropriate. It is usually
+   helpful, it speeds up the review process and helps understanding the changes
+   brought by the PR.
 
  - Write clear commit messages that start with a one-line summary of the
    change (and if it's difficult to summarize in one line, consider
@@ -106,8 +119,14 @@ When submitting PRs:
  - For pull requests that fix existing issues, use [issue keywords]. Note that
    not all pull requests need to have accompanying issues.
 
-Anyone may submit a pull request, and anyone may comment on or review others'
-pull requests. Pull requests are merged by members of the [Core Team].
+ - Assign the review to somebody from the [Core Team], either using suggestions
+   in the list proposed by Github, or somebody else if you have a specific
+   person in mind.
+
+ - When updating your pull request, please make sure to re-request review if
+   the request has been cancelled.
+
+### Focused commits or squashing
 
 We generally squash sequences of incremental-development commits together into
 logical commits (though keeping logical commits focused). Developers may do
@@ -115,8 +134,16 @@ this themselves before submitting a PR or during the PR process, or Core Team
 members may do it when merging a PR. Ideally, the continuous-integration tests
 should pass at each logical commit.
 
-Core Team members may push minor changes directly, though should create PRs
-for significant changes.
+### Review and merge
+
+Anyone may submit a pull request, and anyone may comment on or review others'
+pull requests. However, one review from somebody in the [Core Team] is required
+before the Core Team merges it.
+
+Even Core Team members should create PRs for every change, including minor work
+items (version bump, removing warnings, etc.): this is helpful to keep track of
+what has happened on the repository. Very minor changes may be merged without a
+review, although it is always preferred to have one.
 
 [issues]: https://guides.github.com/features/issues/
 [pull requests]: https://help.github.com/articles/about-pull-requests/