From 5e9f452385e46058abde6011e902adf070ba86c3 Mon Sep 17 00:00:00 2001 From: Matthew Bauer Date: Mon, 19 Nov 2018 12:51:28 -0600 Subject: [PATCH] doc/reviewing-contributions: pull-requests -> pull requests MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This makes things more consistent. It’s also how GitHub refers to pull requests. --- README.md | 2 +- doc/reviewing-contributions.xml | 56 ++++++++++++++++----------------- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/README.md b/README.md index 278ef66cf7e..29c023e4dcd 100644 --- a/README.md +++ b/README.md @@ -20,7 +20,7 @@ release and `nixos-unstable` for the latest successful build of master: % git rebase channels/nixos-18.09 ``` -For pull-requests, please rebase onto nixpkgs `master`. +For pull requests, please rebase onto nixpkgs `master`. [NixOS](https://nixos.org/nixos/) Linux distribution source code is located inside `nixos/` folder. diff --git a/doc/reviewing-contributions.xml b/doc/reviewing-contributions.xml index 79ebc400d36..0bf3dc9e9f8 100644 --- a/doc/reviewing-contributions.xml +++ b/doc/reviewing-contributions.xml @@ -18,35 +18,35 @@ The Nixpkgs project receives a fairly high number of contributions via GitHub - pull-requests. Reviewing and approving these is an important task and a way + pull requests. Reviewing and approving these is an important task and a way to contribute to the project. - The high change rate of Nixpkgs makes any pull-request that remains open for + The high change rate of Nixpkgs makes any pull request that remains open for too long subject to conflicts that will require extra work from the submitter - or the merger. Reviewing pull-requests in a timely manner and being responsive + or the merger. Reviewing pull requests in a timely manner and being responsive to the comments is the key to avoid this issue. GitHub provides sort filters that can be used to see the most recently and the least - recently updated pull-requests. We highly encourage looking at + recently updated pull requests. We highly encourage looking at - this list of ready to merge, unreviewed pull-requests. + this list of ready to merge, unreviewed pull requests. - When reviewing a pull-request, please always be nice and polite. + When reviewing a pull request, please always be nice and polite. Controversial changes can lead to controversial opinions, but it is important to respect every community member and their work. GitHub provides reactions as a simple and quick way to provide feedback to - pull-requests or any comments. The thumb-down reaction should be used with + pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution. - Pull-request reviews should include a list of what has been reviewed in a + pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review. @@ -58,8 +58,8 @@ Package updates - A package update is the most trivial and common type of pull-request. These - pull-requests mainly consist of updating the version part of the package + A package update is the most trivial and common type of pull request. These + pull requests mainly consist of updating the version part of the package name and the source hash. @@ -75,7 +75,7 @@ - Add labels to the pull-request. (Requires commit rights) + Add labels to the pull request. (Requires commit rights) @@ -142,8 +142,8 @@ - Pull-requests are often targeted to the master or staging branch, and - building the pull-request locally when it is submitted can trigger many + pull requests are often targeted to the master or staging branch, and + building the pull request locally when it is submitted can trigger many source builds. @@ -172,14 +172,14 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD - Fetching the pull-request changes, PRNUMBER is the - number at the end of the pull-request title and - BASEBRANCH the base branch of the pull-request. + Fetching the pull request changes, PRNUMBER is the + number at the end of the pull request title and + BASEBRANCH the base branch of the pull request. - Rebasing the pull-request changes to the nixos-unstable branch. + Rebasing the pull request changes to the nixos-unstable branch. @@ -188,10 +188,10 @@ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD The nox tool can - be used to review a pull-request content in a single command. It doesn't + be used to review a pull request content in a single command. It doesn't rebase on a channel branch so it might trigger multiple source builds. PRNUMBER should be replaced by the number at the end - of the pull-request title. + of the pull request title. $ nix-shell -p nox --run "nox-review -k pr PRNUMBER" @@ -228,7 +228,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER" New packages - New packages are a common type of pull-requests. These pull-requests + New packages are a common type of pull requests. These pull requests consists in adding a new nix-expression for a package. @@ -239,7 +239,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER" - Add labels to the pull-request. (Requires commit rights) + Add labels to the pull request. (Requires commit rights) @@ -359,7 +359,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER" - Add labels to the pull-request. (Requires commit rights) + Add labels to the pull request. (Requires commit rights) @@ -472,7 +472,7 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER" - Add labels to the pull-request. (Requires commit rights) + Add labels to the pull request. (Requires commit rights) @@ -574,21 +574,21 @@ $ nix-shell -p nox --run "nox-review -k pr PRNUMBER" like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. They will give you information about the reviewing process. The main reviewers for a topic can be hard to find as - there is no list, but checking past pull-requests to see who reviewed or + there is no list, but checking past pull requests to see who reviewed or git-blaming the code to see who committed to that topic can give some hints. Container system, boot system and library changes are some examples of the - pull-requests fitting this category. + pull requests fitting this category. -
- Merging pull-requests +
+ Merging pull requests It is possible for community members that have enough knowledge and - experience on a special topic to contribute by merging pull-requests. + experience on a special topic to contribute by merging pull requests.