misc grammar tweaks

Author: Aoife

developers/contributing/index.qmd

@@ -15,7 +15,7 @@ Closing one of these may involve implementing new features, fixing bugs, or writ
 
 You can also join the `#turing` channel on the [Julia Slack](https://julialang.org/slack/) and say hello!
 
-If you are new to open-source software, please see [GitHub's introduction](https://guides.github.com/introduction/flow/) or [Julia's contribution guide](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md) on using version control for collaboration.
+If you are new to open source software, please see [GitHub's introduction](https://guides.github.com/introduction/flow/) or [Julia's contribution guide](https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md) on using version control for collaboration.
 
 ### Documentation
 
@@ -47,7 +47,7 @@ This one would run all files with "optim" or "hmc" in their path, such as `test/
 julia --project=. -e 'import Pkg; Pkg.test(; test_args=ARGS)' -- optim hmc --skip ext
 ```
 
-Or otherwise, set the global `ARGS` variable, and call `include("test/runtests.jl")`. 
+Alternatively, set the global `ARGS` variable, and call `include("test/runtests.jl")`. 
 
 ### Pull requests, versions, and releases
 
@@ -56,11 +56,11 @@ To make a contribution to one of the Turing packages, fork it on GitHub, start a
 Once you're done, open a pull request to the main repository under [TuringLang](https://github.com/TuringLang).
 Someone from the dev team will review your code (if they don't, ping `@TuringLang/maintainers` in a comment to get their attention) and check that the continuous integration tests pass (with some allowed exceptions, see below).
 If all looks good, we'll merge your PR with gratitude.
-If not, we'll help you fix it and then merge it with gratitude
+If not, we'll help you fix it and then merge it with gratitude.
 
 Everything in this section about pull requests and branches applies to the Turing.jl and DynamicPPL.jl repositories.
 Most of it also applies to other repositories under the TuringLang ecosystem, though some do not bother with the `main`/`breaking` distinction or with a `HISTORY.md`.
-As of August 2025 we are slowly moving towards having all repos do the full process, so a new `HISTORY.md` in a repo that doesn't yet have one is always welcome.
+As at August 2025 we are slowly moving towards having all repos do the full process, so a new `HISTORY.md` in a repo that doesn't yet have one is always welcome.
 
 #### Branches
 
@@ -81,7 +81,7 @@ Meanwhile, breaking changes can be developed and merged into `breaking`, which i
 Multiple breaking changes may be accumulated into `breaking`, before finally the `breaking`-to-`main` merge is done, and 0.20.0 is released.
 On `breaking` the version number should then immediately be bumped to 0.21.
 
-We do not generally back port of bug fixes, although we may consider doing so in special circumstances.
+We do not generally backport bug fixes, although we may consider doing so in special circumstances.
 
 #### Change history
 
@@ -101,7 +101,7 @@ CI checks other than tests and formatting serve various purposes, and some of th
 Some examples are
 
   - Anything running on a prerelease of Julia. These inform us of trouble ahead when that prerelease becomes an actual release, but don't require fixing for a PR to be merged.
-  - Any code coverage checks. Code coverate numbers can be helpful in catching missing tests or cases where the tests don't test what they are intended to. However, we do not insist on any particular coverage figures, since they are not a very good metric of a test suite's extensiveness.
+  - Any code coverage checks. Code coverage numbers can be helpful in catching missing tests or cases where the tests don't test what they are intended to. However, we do not insist on any particular coverage figures, since they are not a very good metric of a test suite's extensiveness.
   - The benchmarks on DynamicPPL repo. These should be investigated to understand why they fail. If the reason is a bug in the PR, an actual test should be added to the test suite to catch it. However, sometimes they fail for unrelated reasons.
   - Checks against some particular automatic differentiation backends. These are informative, telling us which backends have issues with which features, but often their breakage is beyond our control and we let it pass.
   - The CI check in the `docs` repo for whether the docs are built with the latest Turing.jl release. This test failing is a reminder that we should make a PR to update to the latest version, but does not need fixing when working on a PR that makes unrelated changes to the documentation.