Development – Pull Requests

DateVersionChanges
2021-11-21v1.1.0Fixed the wording to make the statements easier to read.
2025-10-17v1.2.0Moved from Confluence to Blog.

1.1 Pull requests MUST be used in asynchronous workflows. When programmers work alone, continuously integrating their code with the rest of the team.

1.2 Pull requests SHOULD NOT be used for synchronous workflows. When programmers work in pair or mobs.

1.3 Pull Requests SHOULD NOT be used for trivial changes, like fixing a syntax error, spelling, or test failure.

2 As a Requester

A requester is the person that is creating the pull request they want reviewed.

2.1 The requester MUST keep to one issue per pull request. An issue could be a bug, feature or change request.

2.2 Pull requests for refactorings MUST be kept to one change only. Examples refactored price calculation. Refactored error handling. Upgraded to latest version of .NET Core.

2.3 The pull request SHOULD contain the following information

  • Title of the change including the issue number and issue name.
  • Description of the change.
  • Considerations you made during the change.
  • How to review it.
  • Reference to an open issue.
  • Designated reviewer.

If you do not submit a thorough pull request, you cannot expect any good reviews.

3 As a Reviewer

Reviewer is the person that receive or pick up the pull request to review it.

3.1 Getting assigned to a pull request you SHOULD review it within a business day to avoid negative impact on flow.

3.2 Reviewer MUST pull the pull request to their local environment.

3.3 Reviewer MUST run the code under review.

3.4 Reviewer SHOULD implement changes deemed necessary, preferably with the requester to improve collaboration.

3.5 Pull request comments SHOULD be used for all communication regarding the pull request.

3.6 The pull request SHOULD be merged as soon as it has been reviewed, by the reviewer if this facilitates flow.

3.7 The branch SHOULD be squashed and deleted during merge.