Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Chore: Tidy up some formatting on the pull request pages #942

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Chore: Tidy up some formatting on the pull request pages #942

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6d59ebb
Chore: Change apostrophe within review content to U+0027
huwd Jul 30, 2024
c15cc87
Minor revision to examples of sources for commit messages
huwd Jul 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions source/standards/pull-requests.html.md.erb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ 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?

Expand Down Expand Up @@ -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
Expand All @@ -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?
Expand Down Expand Up @@ -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.

Expand Down