Improvements to contribution guide

Author: mhauru

developers/contributing/index.qmd

@@ -51,23 +51,23 @@ Or otherwise, set the global `ARGS` variable, and call `include("test/runtests.j
 
 ### Pull requests, versions, and releases
 
-We merge all code changes through pull requests on GitHub. To make a contribution to one of the Turing packages, fork it on GitHub, start a new branch on your fork, and add commits to it. 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 `@maintainers` in a comment to get their attention) and check that the continuous integration tests pass. If all looks good, we'll merge your PR with much joy and gratefulness. If not, we'll help you fix it and then merge it with much joy and gratefulness.
+We merge all code changes through pull requests on GitHub. To make a contribution to one of the Turing packages, fork it on GitHub, start a new branch on your fork, and add commits to it. 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. If all looks good, we'll merge your PR with much joy and gratitude If not, we'll help you fix it and then merge it with much joy and gratitude
 
-All of the below applies to both 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.
+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.
 
 #### Branches
 
-Like Julia packages generally, Turing follows [semantic versioning](https://semver.org/). Because of this, we have two long-standing branches in our repository: `main` and `breaking`. All code that gets released as a new version of Turing gets merged into `main`, and a release is made from there. However, any breaking changes should first be merged into `breaking`. `breaking` will then periodically merged into `main`.
+Like Julia packages generally, Turing follows [semantic versioning](https://semver.org/). Because of this, we have two persistently alive branches in our repository: `main` and `breaking`. All code that gets released as a new version of Turing gets merged into `main`, and a release is made from there. However, any breaking changes should first be merged into `breaking`. `breaking` will then periodically be merged into `main`.
 
 The idea is that `breaking` always contains commits that build towards the next breaking release in the semantic versioning sense. That is, if the changes you make might break or change the behaviour of correctly written code that uses Turing.jl, your PR should target the `breaking` branch, and your code should be merged into `breaking`. If your changes cause no such breakage for users, your PR should target `main`. Notably, any bug fixes should merge directly into `main`.
 
-This way we can frequently release new patch version from `main`, while developing breaking changes in parallel on `breaking`. E.g. if the current version is 0.19.3, and someone fixes a bug, we can merge the fix into `main` and release the latest it as 0.19.4. Meanwhile, breaking changes can be developed and merged into `breaking`, which is building towards a release of 0.20.0. Multiple breaking changes may be cumulated into `breaking`, before finally the `breaking`-to-`main` merge is done, and 0.20.0 is released. `breaking` should then immediately start targeting 0.21.
+This way we can frequently release new patch version from `main`, while developing breaking changes in parallel on `breaking`. E.g. if the current version is 0.19.3, and someone fixes a bug, we can merge the fix into `main` and release it as 0.19.4. Meanwhile, breaking changes can be developed and merged into `breaking`, which is building towards a release of 0.20.0. 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 bother doing backports of bug fixes, though may consider them in special circumstances.
+We do not generally bother doing backports of bug fixes, though we may consider them in special circumstances.
 
 #### Change history
 
-We keep a cumulative changelog in a file called `HISTORY.md`. It should have an entry for every new breaking release, explaining everything our users need to know about the changes, such as any features that have been deleted, any changes to syntax or interface, etc. Any major new features should also be described in `HISTORY.md`, as may any other changes that are useful for users to know about. Bug fixes generally don't need an entry in `HISTORY.md`. Any new breaking release must have an entry in `HISTORY.md`, entiers for non-breaking releases are optional.
+We keep a cumulative changelog in a file called `HISTORY.md` at the root of the repository. It should have an entry for every new breaking release, explaining everything our users need to know about the changes, such as what may have broken and how to fix things to work with the new version. Any major new features should also be described in `HISTORY.md`, as may any other changes that are useful for users to know about. Bug fixes generally don't need an entry in `HISTORY.md`. Any new breaking release must have an entry in `HISTORY.md`, entries for non-breaking releases are optional.
 
 #### Please make mistakes
 
@@ -76,6 +76,7 @@ Getting pull requests from outside the core developer team is one of the greates
 #### For Turing.jl core developers
 
 If you are a core developer of TuringLang, two notes, in addition to the above, apply:
+
 1. You don't need to make your own fork of the package you are editing. Just make a new branch on the main repository, usually named `your-username/change-you-are-making` (we don't strictly enforce this convention though). You should definitely still make a branch and a PR, and never push directly to `main` or `breaking`.
 2. You can make a release of the package after your work is merged into `main`. This is done by leaving a comment on the latest commit on `main`, saying
 
@@ -88,7 +89,7 @@ Release notes:
 
 The `@JuliaRegistrator` bot will handle creating a pull request into the Julia central package repository and tagging a new release in the repository. The release notes should be a copy-paste of the notes written in `HISTORY.md` if such an entry exists, or otherwise (for a patch release) a short summary of changes.
 
-Even core devs should always merge all their code through pull requests into `main` or `breaking`. All code should generally be reviewed by another core developer and pass continuous integration (CI) checks. Exceptions can be made in some cases though, such as ignoring failing CI checks where the cause is known and not due to the current pull request, or skipping code review when the pull request author is an experienced developer of the package and the changes are utterly trivial.
+Even core devs should always merge all their code through pull requests into `main` or `breaking`. All code should generally be reviewed by another core developer and pass continuous integration (CI) checks. Exceptions can be made in some cases though, such as ignoring failing CI checks where the cause is known and not due to the current pull request, or skipping code review when the pull request author is an experienced developer of the package and the changes are trivial.
 
 ### Code Formatting