From e8900584aed2c1e5df05198ed24c4d16d9345b38 Mon Sep 17 00:00:00 2001 From: "Daniel Mackay [SSW]" <2636640+danielmackay@users.noreply.github.com> Date: Thu, 14 Dec 2023 12:37:24 +1000 Subject: [PATCH 1/3] Add tip for creating a great pull request --- rules/do-you-use-co-creation-patterns/rule.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/do-you-use-co-creation-patterns/rule.md b/rules/do-you-use-co-creation-patterns/rule.md index 5fc81843f84..73d387f8c30 100644 --- a/rules/do-you-use-co-creation-patterns/rule.md +++ b/rules/do-you-use-co-creation-patterns/rule.md @@ -42,6 +42,7 @@ Inefficient code reviews can be caused by: * This requires a smaller block of time to review which makes it easier for the reviewer to find the time * Less risk - reduces the chance of an incorrect approach being taken * Get quality feedback - small blocks of code are easier to digest + * Create a [great pull request](https://www.ssw.com.au/rules/write-a-good-pull-request/) to make it easier for the reviewer to understand your changes. * Reviewer - When reviewing asynchronously * Be explicit and suggest the exact code changes where possible (GitHub has a feature for this, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request) * Call the developer for more complicated changes @@ -82,4 +83,3 @@ Co-creation allows us to have both quality and throughput by providing the follo TODO: Add a PR screenshot of pair programming, show the PR Dan M with Jack R for the big PR for Rules GPT TODO: Add a PR screenshot of mob programming, we need to demonstrate what the PR would look like for this --> - From e73af0654c4ffdd6e2a3dc40503bb1e57309e2d6 Mon Sep 17 00:00:00 2001 From: "Daniel Mackay [SSW]" <2636640+danielmackay@users.noreply.github.com> Date: Thu, 14 Dec 2023 12:38:23 +1000 Subject: [PATCH 2/3] Add related rule for writing a good pull request --- rules/do-you-use-co-creation-patterns/rule.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rules/do-you-use-co-creation-patterns/rule.md b/rules/do-you-use-co-creation-patterns/rule.md index 73d387f8c30..198b9fcb585 100644 --- a/rules/do-you-use-co-creation-patterns/rule.md +++ b/rules/do-you-use-co-creation-patterns/rule.md @@ -7,6 +7,7 @@ authors: url: https://ssw.com.au/people/daniel-mackay related: - over-the-shoulder + - write-a-good-pull-request created: 2022-11-21T00:28:43.256Z guid: 4ff555fd-3f4c-416b-9fc3-1bf9409cc0ab --- From 49874d4208abb2611f8912a9b73f8fe56559c482 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Thu, 14 Dec 2023 23:27:46 +0000 Subject: [PATCH 3/3] Auto-fix Markdown files --- rules/do-you-use-co-creation-patterns/rule.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules/do-you-use-co-creation-patterns/rule.md b/rules/do-you-use-co-creation-patterns/rule.md index 198b9fcb585..04047736178 100644 --- a/rules/do-you-use-co-creation-patterns/rule.md +++ b/rules/do-you-use-co-creation-patterns/rule.md @@ -45,7 +45,7 @@ Inefficient code reviews can be caused by: * Get quality feedback - small blocks of code are easier to digest * Create a [great pull request](https://www.ssw.com.au/rules/write-a-good-pull-request/) to make it easier for the reviewer to understand your changes. * Reviewer - When reviewing asynchronously - * Be explicit and suggest the exact code changes where possible (GitHub has a feature for this, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request) + * Be explicit and suggest the exact code changes where possible (GitHub has a feature for this, see ) * Call the developer for more complicated changes ## The Ultimate Solution - Co-Creation Patterns @@ -58,7 +58,7 @@ That leads us to synchronous, continuous code reviews and co-creation patterns We can avoid this by using co-creation patterns. As a general rule, Pull Requests with less than 20 lines of code, and larger changes with a degree of complexity/risk, make good candidates for co-creation. > The idea is that you do small PR's but also limit WIP. If you create several small PR's quickly and are waiting for code reviews, you can become blocked very quickly. By co-creating, the small PR's get reviewed & merged instantly which avoids getting blocked and enables you to smash out loads of small PRs! 💪 -> +> > Daniel Mackay - SSW Solution Architect ### Patterns