about summary refs log tree commit diff
path: root/nixpkgs/CONTRIBUTING.md
diff options
context:
space:
mode:
Diffstat (limited to 'nixpkgs/CONTRIBUTING.md')
-rw-r--r--nixpkgs/CONTRIBUTING.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/nixpkgs/CONTRIBUTING.md b/nixpkgs/CONTRIBUTING.md
index 3cc123be431e..55232e9c3a54 100644
--- a/nixpkgs/CONTRIBUTING.md
+++ b/nixpkgs/CONTRIBUTING.md
@@ -378,7 +378,7 @@ The staging workflow exists to batch Hydra builds of many packages together.
 It works by directing commits that cause [mass rebuilds][mass-rebuild] to a separate `staging` branch that isn't directly built by Hydra.
 Regularly, the `staging` branch is _manually_ merged into a `staging-next` branch to be built by Hydra using the [`nixpkgs:staging-next` jobset](https://hydra.nixos.org/jobset/nixpkgs/staging-next).
 The `staging-next` branch should then only receive direct commits in order to fix Hydra builds.
-Once it is verified that there are no major regressions, it is merged into `master` using [a pull requests](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
+Once it is verified that there are no major regressions, it is merged into `master` using [a pull request](https://github.com/NixOS/nixpkgs/pulls?q=head%3Astaging-next).
 This is done manually in order to ensure it's a good use of Hydra's computing resources.
 By keeping the `staging-next` branch separate from `staging`, this batching does not block developers from merging changes into `staging`.