From 873465e7a9d6e133044d5e660e7beb82d5a2d30b Mon Sep 17 00:00:00 2001 From: Benjamin Bouvier Date: Thu, 17 Oct 2019 17:39:44 +0200 Subject: [PATCH] [contribution] Update contribution guidelines. --- cranelift/CONTRIBUTING.md | 41 ++++++++++++++++++++++++++++++++------- 1 file changed, 34 insertions(+), 7 deletions(-) diff --git a/cranelift/CONTRIBUTING.md b/cranelift/CONTRIBUTING.md index 97ce756eb9..e5e5b9410f 100644 --- a/cranelift/CONTRIBUTING.md +++ b/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/