未验证 提交 e744fb7a 编写于 作者: M Mazdak Farrokhzad 提交者: GitHub

Rollup merge of #59172 - varkor:contributing-contributions, r=steveklabnik

Update and clean up several parts of CONTRIBUTING.md
......@@ -15,7 +15,7 @@ links to the major sections:
* [Helpful Links and Information](#helpful-links-and-information)
If you have questions, please make a post on [internals.rust-lang.org][internals] or
hop on [#rust-internals][pound-rust-internals].
hop on the [Rust Discord server][rust-discord], [Rust Zulip server][rust-zulip] or [#rust-internals][pound-rust-internals].
As a reminder, all contributors are expected to follow our [Code of Conduct][coc].
......@@ -27,14 +27,17 @@ can give you a good example of how a typical contribution would go.
[pound-rust-internals]: https://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust-internals
[internals]: https://internals.rust-lang.org
[rust-discord]: http://discord.gg/rust-lang
[rust-zulip]: https://rust-lang.zulipchat.com
[coc]: https://www.rust-lang.org/conduct.html
[rustc-guide]: https://rust-lang.github.io/rustc-guide/
[walkthrough]: https://rust-lang.github.io/rustc-guide/walkthrough.html
## Feature Requests
[feature-requests]: #feature-requests
To request a change to the way the Rust language works, please head over
to the [RFCs repository](https://github.com/rust-lang/rfcs) and view the
to the [RFCs repository](https://github.com/rust-lang/rfcs) and view the
[README](https://github.com/rust-lang/rfcs/blob/master/README.md)
for instructions.
......@@ -129,28 +132,40 @@ request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git
before every push to make sure you never forget to make this check.
All pull requests are reviewed by another person. We have a bot,
@rust-highfive, that will automatically assign a random person to review your
[@rust-highfive][rust-highfive], that will automatically assign a random person to review your
request.
If you want to request that a specific person reviews your pull request,
you can add an `r?` to the message. For example, Steve usually reviews
you can add an `r?` to the message. For example, [Steve][steveklabnik] usually reviews
documentation changes. So if you were to make a documentation change, add
r? @steveklabnik
to the end of the message, and @rust-highfive will assign @steveklabnik instead
to the end of the message, and @rust-highfive will assign [@steveklabnik][steveklabnik] instead
of a random person. This is entirely optional.
After someone has reviewed your pull request, they will leave an annotation
on the pull request with an `r+`. It will look something like this:
@bors: r+ 38fe8d2
@bors r+
This tells @bors, our lovable integration bot, that your pull request has
been approved. The PR then enters the [merge queue][merge-queue], where @bors
This tells [@bors][bors], our lovable integration bot, that your pull request has
been approved. The PR then enters the [merge queue][merge-queue], where [@bors][bors]
will run all the tests on every platform we support. If it all works out,
@bors will merge your code into `master` and close the pull request.
[@bors][bors] will merge your code into `master` and close the pull request.
Depending on the scale of the change, you may see a slightly different form of `r+`:
@bors r+ rollup
The additional `rollup` tells [@bors][bors] that this change is eligible for to be
"rolled up". Changes that are rolled up are tested and merged at the same time, to
speed the process up. Typically only small changes that are expected not to conflict
with one another are rolled up.
[rust-highfive]: https://github.com/rust-highfive
[steveklabnik]: https://github.com/steveklabnik
[bors]: https://github.com/bors
[merge-queue]: https://buildbot2.rust-lang.org/homu/queue/rust
Speaking of tests, Rust has a comprehensive test suite. More information about
......@@ -190,7 +205,7 @@ before the PR is merged.
[breaking-tools-built-with-the-compiler]: #breaking-tools-built-with-the-compiler
Rust's build system builds a number of tools that make use of the
internals of the compiler. This includes
internals of the compiler. This includes
[Clippy](https://github.com/rust-lang/rust-clippy),
[RLS](https://github.com/rust-lang/rls) and
[rustfmt](https://github.com/rust-lang/rustfmt). If these tools
......@@ -292,18 +307,8 @@ the submodule to. Running `./x.py build` should work now.
Documentation improvements are very welcome. The source of `doc.rust-lang.org`
is located in `src/doc` in the tree, and standard API documentation is generated
from the source code itself.
Documentation pull requests function in the same way as other pull requests,
though you may see a slightly different form of `r+`:
@bors: r+ 38fe8d2 rollup
That additional `rollup` tells @bors that this change is eligible for a 'rollup'.
To save @bors some work, and to get small changes through more quickly, when
@bors attempts to merge a commit that's rollup-eligible, it will also merge
the other rollup-eligible patches too, and they'll get tested and merged at
the same time.
from the source code itself. Documentation pull requests function in the same way
as other pull requests.
To find documentation-related issues, sort by the [T-doc label][tdoc].
......@@ -428,7 +433,8 @@ are:
* Although out of date, [Tom Lee's great blog article][tlgba] is very helpful
* [rustaceans.org][ro] is helpful, but mostly dedicated to IRC
* The [Rust Compiler Testing Docs][rctd]
* For @bors, [this cheat sheet][cheatsheet] is helpful (Remember to replace `@homu` with `@bors` in the commands that you use.)
* For [@bors][bors], [this cheat sheet][cheatsheet] is helpful
(though you'll need to replace `@homu` with `@bors` in any commands)
* **Google!** ([search only in Rust Documentation][gsearchdocs] to find types, traits, etc. quickly)
* Don't be afraid to ask! The Rust community is friendly and helpful.
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册