[contribution] Update contribution guidelines.
@@ -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/
