Merge pull request #942 from alphagov/pull-request-chores

Chore: Tidy up some formatting on the pull request pages

source/standards/pull-requests.html.md.erb

@@ -1,11 +1,11 @@
 ---
 title: Pull requests
-last_reviewed_on: 2023-07-21
+last_reviewed_on: 2024-11-05
 review_in: 12 months
 ---
 # <%= current_page.data.title %>
 
-Pull requests (PRs) let you tell others about changes you've pushed to a branch in a repository on GitHub.
+Pull requests (PRs) let you tell others about changes you’ve pushed to a branch in a repository on GitHub.
 
 ## Why should you use pull requests?
 
@@ -35,7 +35,7 @@ You should make sure that:
 
 - your local repository has the most recent changes on the target branch
 - the title and description of the PR are clear and accurately represent your changes
-- the title and description reference the source of the change, which could be a Zendesk ticket or a Jira card
+- the title and description reference the source of the change, which could be a support ticket (Zendesk, or Service Now) or a Jira card
 - the description contains links to any related PRs
 - any screenshots have text descriptions for accessibility
 - any contentious changes or side effects have clear descriptions of the pros and cons
@@ -46,11 +46,11 @@ As such, the canonical description of changes should be in the commit messages.
 
 ### Reviewing a request
 
-Taking time to properly review a PR is as important as making the change itself, and it is crucial that we show compassion when critiquing someone else's work.
+Taking time to properly review a PR is as important as making the change itself, and it is crucial that we show compassion when critiquing someone else’s work.
 
 April Wensel has a talk about [Compassionate-Yet-Candid Code Reviews](https://www.slideshare.net/AprilWensel/compassionate-yet-candid-code-reviews).
 
-It suggests 3 key questions to ask ourselves when reviewing or commenting on someone else's work:
+It suggests 3 key questions to ask ourselves when reviewing or commenting on someone else’s work:
 
 - Is it true?
 - Is it necessary?
@@ -116,7 +116,7 @@ If we do not want to merge it because it does not fit with our plans, thank them
 
 If it fits, but we cannot merge it due to quality or style issues, then tell them that we are able to merge the PR if they make some changes.
 
-We can tell the requester what improvements we'd like to see, but we should not require the contributor to make them all. For example, we might add missing tests ourselves or collaborate with them to add tests.
+We can tell the requester what improvements we’d like to see, but we should not require the contributor to make them all. For example, we might add missing tests ourselves or collaborate with them to add tests.
 
 We should close PRs due to lack of activity but invite people to reopen them if they pick things up again.