Merge pull request #843 from alphagov/date-bump-batch2

Minor amends to a bunch of pages

source/manuals/code-review-guidelines.html.md.erb

@@ -1,6 +1,6 @@
 ---
 title: How to review code
-last_reviewed_on: 2022-09-21
+last_reviewed_on: 2023-11-02
 review_in: 9 months
 ---
 
@@ -46,7 +46,7 @@ You should consider if the code in a PR has:
 * missing or additional elements following a merge or rebase
 * capacity for reusability
 
-You should always check code for linting issues. You could consider running automated linting before merging PRs, for example with [GitHub Actions](/standards/source-code/use-github.html#using-github-actions-and-workflows).
+You should always check code for linting issues. You could consider running automated linting before merging PRs, for example with [GitHub Actions][].
 
 ## Code libraries
 
@@ -86,20 +86,19 @@ The Service Manual contains guidance about [deploying software][].
 
 Before you approve a PR, you should consider if it affects any existing documentation. You should make sure the PR's documentation is clear and unambiguous, and in the right place.
 
-If you want to learn more about writing clearly for technical audiences you can contact GDS technical writers using the [#tech-writers Slack channel][].
+If you want to learn more about writing clearly for technical audiences you can contact GDS technical writers using the [#gds-technical-writing Slack channel][].
 
 ## Further reading
 
-Find out more about writing and reviewing pull requests on the [GDS Tech Learning Pathway][].
+Find out more about writing and reviewing pull requests on the [Pull requests page][].
 
 [GitHub review]: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
 [pull requests (PRs)]: https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
-[technical debt]: https://gds-way.cloudapps.digital/standards/technical-debt.html
-[programming language style guides]: https://gds-way.cloudapps.digital/manuals/programming-languages.html
-[open source]: https://gds-way.cloudapps.digital/standards/publish-opensource-code.html
-[how to manage third party software dependencies here]: https://gds-way.cloudapps.digital/standards/tracking-dependencies.html
+[technical debt]: /standards/technical-debt.html
+[programming language style guides]: /manuals/programming-languages.html
+[open source]: /standards/publish-opensource-code.html
+[how to manage third party software dependencies here]: /standards/tracking-dependencies.html
 [deploying software]: https://www.gov.uk/service-manual/technology/deploying-software-regularly
-[GDS Tech Learning Pathway]: https://github.com/alphagov/gds-tech-learning-pathway/blob/main/resources/other/code-reviews.html.md
-[Programming language style guides]: https://gds-way.cloudapps.digital/manuals/programming-languages.html
-
-[#tech-writers Slack channel]: https://gds.slack.com/messages/tech-writers
+[Pull requests page]: /standards/pull-requests.html
+[GitHub Actions]: /standards/source-code/use-github.html#using-github-actions-and-workflows
+[#gds-technical-writing Slack channel]: https://gds.slack.com/archives/CAD0R2NQG

source/manuals/programming-languages.html.md.erb

@@ -1,7 +1,7 @@
 ---
 layout: core
 title: Style guides
-last_reviewed_on: 2022-07-11
+last_reviewed_on: 2023-11-02
 review_in: 12 months
 ---
 

source/standards/continuous-delivery.html.md.erb

@@ -1,6 +1,6 @@
 ---
 title: Use continuous delivery
-last_reviewed_on: 2022-09-22
+last_reviewed_on: 2023-11-02
 review_in: 12 months
 ---
 
@@ -59,7 +59,7 @@ You can understand the effect of your changes on production using [production mo
 Find out more about continuous delivery from:
 
 - [Architecting for Continuous Delivery][] - Jez Humble at Agile India 2016 (video)
-- [2020 State of DevOps Report][] - see where you are and how to get to the next stage
+- [2023 State of DevOps Report][] - see where you are and how to get to the next stage
 - [Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations][Accelerate] - by Nicole Forsgren Jez Humble Gene Kim
 - [Trunk Based Development][] - a source control branching method
 
@@ -71,4 +71,4 @@ Find out more about continuous delivery from:
 [Architecting for Continuous Delivery]: https://www.youtube.com/watch?v=Lx9ssegE6FA
 [Accelerate]: https://wordery.com/accelerate-nicole-forsgren-phd-9781942788331?cTrk=OTc2NDYwNzZ8NWI2ZDg5NGJkYzAyZjoxOjE6NWI2ZDg5NDQwM2ZhODguNDU0MTgxMTU6ODJlODM3ODY%3D
 [Trunk Based Development]: https://trunkbaseddevelopment.com/
-[2020 State of DevOps Report]: https://puppet.com/resources/report/2020-state-of-devops-report
+[2023 State of DevOps Report]: https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report

source/standards/source-code/index.html.md.erb

@@ -1,6 +1,6 @@
 ---
 title: How to store source code
-last_reviewed_on: 2022-09-21
+last_reviewed_on: 2023-11-02
 review_in: 12 months
 ---
 
@@ -37,7 +37,7 @@ Your open source code project should:
 
 * publish packages to relevant language specific repositories such as [PyPI - the Python Package Index][] or [RubyGems][]
 * post contributors' guidelines in a contributing file, like the [Go repository][]
-* set up any tests to run in a public continuous integration environment using tools such as [Github Actions](use-github.html#using-github-actions-and-workflows) or [Jenkins][]
+* set up any tests to run in a public continuous integration environment using tools such as [Github Actions](use-github.html#using-github-actions-and-workflows)
 
 You could also provide a mailing list so people can discuss your project.
 
@@ -52,7 +52,6 @@ You could also provide a mailing list so people can discuss your project.
 [Semantic Versioning]: https://semver.org/spec/v2.0.0.html
 [PyPI - the Python Package Index]: https://pypi.org/
 [RubyGems]: https://rubygems.org/
-[Jenkins]: https://www.jenkins.io/
 [Go repository]: https://golang.org/CONTRIBUTORS
 [keeping some data and code closed]: https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed
 [how to open previously closed code and your responsibilities for maintaining open code]: https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable