Apply suggestions from code review

Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com>
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
This commit is contained in:
LeSeulArtichaut 2020-09-12 15:28:15 +02:00 committed by Joshua Nelson
parent ade9b19f51
commit ab47942c65
2 changed files with 3 additions and 3 deletions

View File

@ -154,7 +154,7 @@ rebase when bringing the latest changes from the master branch to your feature
branch. Also, please make sure that fixup commits are squashed into other branch. Also, please make sure that fixup commits are squashed into other
related commits with meaningful commit messages. related commits with meaningful commit messages.
If you encounter merge commits, your PR will get marked as `S-waiting-on-author`. If you encounter merge conflicts, your PR will get marked as `S-waiting-on-author`.
When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-review`. When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-review`.
See [this chapter][labeling] for more details. See [this chapter][labeling] for more details.

View File

@ -29,11 +29,11 @@ with a few restrictions. This is mostly useful in two cases:
**Helping with issue triage**: Rust's issue tracker has more than 5,000 open **Helping with issue triage**: Rust's issue tracker has more than 5,000 open
issues at the time of this writing, so labels are the most powerful tool that we issues at the time of this writing, so labels are the most powerful tool that we
have to keep it as tidy as possible. You may not spend hours in the issue tracker have to keep it as tidy as possible. You don't need to spend hours in the issue tracker
to triage issues, but if you open an issue, you should feel free to label it if to triage issues, but if you open an issue, you should feel free to label it if
you are comfortable with doing it yourself. you are comfortable with doing it yourself.
**Updating the status of a PR**: we use "status labels" to reflect the status of **Updating the status of a PR**: We use "status labels" to reflect the status of
PRs. For example, if your PR has merge conflicts, it will automatically be assigned PRs. For example, if your PR has merge conflicts, it will automatically be assigned
the `S-waiting-on-author`, and reviewers might not review it until you rebase your the `S-waiting-on-author`, and reviewers might not review it until you rebase your
PR. Once you do rebase your branch, you should change the labels yourself to remove PR. Once you do rebase your branch, you should change the labels yourself to remove