From 1deb38d9448074afab84cd8a9a4c70f7df2fd060 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Wed, 12 Jun 2024 17:10:27 +0100 Subject: [PATCH 01/25] First draft: Managing capacity for reviewing contributions --- .../1-initial/capacity-for-contributions.md | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 patterns/1-initial/capacity-for-contributions.md diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md new file mode 100644 index 000000000..524c3d339 --- /dev/null +++ b/patterns/1-initial/capacity-for-contributions.md @@ -0,0 +1,68 @@ +## Title + +Mananging capacity for reviewing contributions + +## Patlet + +Reviewing InnerSource contributions takes time and effort. This should be reflected in capacity planning, especially for larger contributions. Expectations and available capacity should be transparent so that contributors understand when their contributions will be reviewed and released. + +## Problem + +Large InnerSource contributions are causing delays to other work in the team and/or contributons are taking longer to be released than expected. Reviewing contributions may be significant invisible work, not tracked in a team's agile development process. + +## Story + +The BBC's connected TV application are built by a number of teams, each with different areas of responsibility. They work on each other's areas of the codebase via InnerSource on a regular basis. + +The team reapsonsible for the build process for the JavaScript bundles received a major pull request, changing how depedencies were bundled. This PR introduced a new build time dependency, a new strucutre to the deployed JavaSctipt bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required signicant time to code review, test, and ensure the team understood the new tooling snd structure introduced. Normally, InnerSource contriobutions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, delivery manager, and product manager, to prioritise this work against other work. Time was set aside to review this contribution at future date. + +This process was formalised in the team: +* Larger contributions have a ticket created on the team's backlog and included in prioritisation disacussion alongside other tickets. The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released. +* Smaller contributions can still be reviewed ad-hoc. + +## Context + +Maintainers of a successful InnerSource project are finding it difficult to review contributions, especially large contributions. They do not want to disrupt their team's other work, but also want to support contributions by reviewing/releasing them in a timely fashion. + +## Forces + +* Contributors expect timely feedback on their contributions +* Maintaining team are expected to deliver other work alongside reviewing contributions +* Missing communication between contributors and maintainers on expectations/lead time for contributions to be reviewed/released +* Tension in prioritising InnerSource contributions against other work + +## Solutions + +* Reviewing larger contributions is tracked in the team's ticketing system/bug tracker (e.g. Jira, GitHub issues) +* Maintaing team is given time to review larger contributions in team capacity planning +* Reviewing contributions is prioritised against other work (e.g. in sprint planning) +* Maintainers communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released +* Maintaing team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback + +## Resulting Context + +Maintaining team understands the overhead of reviewing large contributions and is given capacity to do so. Delivery and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the maintainers will provide initial feedback. + +## Rationale (optional) + +Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. +Can expand on what-if's or theories. + +## Known Instances + +BBC iPlayer & Sounds + +## Status (optional until merging) + +General pattern status is stored in GitHub's Label tagging - see any pull request. +Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful. + +You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further." + +## Author(s) + +Tom Sadler + +## Acknowledgments + +Clare Dillon From 6cc70c2e65a8610d027d41b08d767e18ddb57095 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 12 Jun 2024 18:33:39 +0200 Subject: [PATCH 02/25] Auto-fix for markdownlint issues --- patterns/1-initial/capacity-for-contributions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 524c3d339..f5722d249 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -17,6 +17,7 @@ The BBC's connected TV application are built by a number of teams, each with dif The team reapsonsible for the build process for the JavaScript bundles received a major pull request, changing how depedencies were bundled. This PR introduced a new build time dependency, a new strucutre to the deployed JavaSctipt bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required signicant time to code review, test, and ensure the team understood the new tooling snd structure introduced. Normally, InnerSource contriobutions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, delivery manager, and product manager, to prioritise this work against other work. Time was set aside to review this contribution at future date. This process was formalised in the team: + * Larger contributions have a ticket created on the team's backlog and included in prioritisation disacussion alongside other tickets. The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released. * Smaller contributions can still be reviewed ad-hoc. From e357e1f1423a1047b0d964082b5ce50b04914552 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Wed, 12 Jun 2024 18:38:45 +0200 Subject: [PATCH 03/25] Fixing various spellings/typos --- .../1-initial/capacity-for-contributions.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index f5722d249..cfcb33404 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -1,6 +1,6 @@ ## Title -Mananging capacity for reviewing contributions +Managing capacity for reviewing contributions ## Patlet @@ -8,17 +8,17 @@ Reviewing InnerSource contributions takes time and effort. This should be reflec ## Problem -Large InnerSource contributions are causing delays to other work in the team and/or contributons are taking longer to be released than expected. Reviewing contributions may be significant invisible work, not tracked in a team's agile development process. +Large InnerSource contributions are causing delays to other work in the team and/or contributions are taking longer to be released than expected. Reviewing contributions may be significant invisible work, not tracked in a team's agile development process. ## Story The BBC's connected TV application are built by a number of teams, each with different areas of responsibility. They work on each other's areas of the codebase via InnerSource on a regular basis. -The team reapsonsible for the build process for the JavaScript bundles received a major pull request, changing how depedencies were bundled. This PR introduced a new build time dependency, a new strucutre to the deployed JavaSctipt bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required signicant time to code review, test, and ensure the team understood the new tooling snd structure introduced. Normally, InnerSource contriobutions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, delivery manager, and product manager, to prioritise this work against other work. Time was set aside to review this contribution at future date. +The team responsible for the build process for the JavaScript bundles received a major pull request, changing how dependencies were bundled. This PR introduced a new build time dependency, a new structure to the deployed JavaScript bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required significant time to code review, test, and ensure the team understood the new tooling and structure introduced. Normally, InnerSource contributions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, delivery manager, and product manager, to prioritize this work against other work. Time was set aside to review this contribution at future date. -This process was formalised in the team: +This process was formalized in the team: -* Larger contributions have a ticket created on the team's backlog and included in prioritisation disacussion alongside other tickets. The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released. +* Larger contributions have a ticket created on the team's backlog and included in prioritization discussion alongside other tickets. The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released. * Smaller contributions can still be reviewed ad-hoc. ## Context @@ -30,15 +30,15 @@ Maintainers of a successful InnerSource project are finding it difficult to revi * Contributors expect timely feedback on their contributions * Maintaining team are expected to deliver other work alongside reviewing contributions * Missing communication between contributors and maintainers on expectations/lead time for contributions to be reviewed/released -* Tension in prioritising InnerSource contributions against other work +* Tension in prioritizing InnerSource contributions against other work ## Solutions * Reviewing larger contributions is tracked in the team's ticketing system/bug tracker (e.g. Jira, GitHub issues) -* Maintaing team is given time to review larger contributions in team capacity planning -* Reviewing contributions is prioritised against other work (e.g. in sprint planning) +* Maintaining team is given time to review larger contributions in team capacity planning +* Reviewing contributions is prioritized against other work (e.g. in sprint planning) * Maintainers communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released -* Maintaing team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback +* Maintaining team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback ## Resulting Context From 0762eaeabcd1fb5f88df38217c87deabcc79a96e Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 22 Jun 2024 09:29:24 +0200 Subject: [PATCH 04/25] Removing empty template section --- patterns/1-initial/capacity-for-contributions.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index cfcb33404..5b1d22253 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -44,11 +44,6 @@ Maintainers of a successful InnerSource project are finding it difficult to revi Maintaining team understands the overhead of reviewing large contributions and is given capacity to do so. Delivery and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the maintainers will provide initial feedback. -## Rationale (optional) - -Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. -Can expand on what-if's or theories. - ## Known Instances BBC iPlayer & Sounds From ca9941f0f02a8ae9f1cf39687404d26c1651720c Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 22 Jun 2024 09:29:50 +0200 Subject: [PATCH 05/25] Marking status as "Initial" --- patterns/1-initial/capacity-for-contributions.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 5b1d22253..c7c1b9afa 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -50,10 +50,7 @@ BBC iPlayer & Sounds ## Status (optional until merging) -General pattern status is stored in GitHub's Label tagging - see any pull request. -Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful. - -You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further." +Initial ## Author(s) From 94a9ac64f417d96f04bb7831d9ed3d5dd5cbf364 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 22 Jun 2024 09:30:12 +0200 Subject: [PATCH 06/25] Fix section title --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index c7c1b9afa..e1a9ca950 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -48,7 +48,7 @@ Maintaining team understands the overhead of reviewing large contributions and i BBC iPlayer & Sounds -## Status (optional until merging) +## Status Initial From 1f5eec45d6722062aab4adc841da995dab6f05aa Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sat, 22 Jun 2024 09:39:33 +0200 Subject: [PATCH 07/25] Replacing delivery manager with project manager --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index e1a9ca950..233b48c75 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -42,7 +42,7 @@ Maintainers of a successful InnerSource project are finding it difficult to revi ## Resulting Context -Maintaining team understands the overhead of reviewing large contributions and is given capacity to do so. Delivery and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the maintainers will provide initial feedback. +Maintaining team understands the overhead of reviewing large contributions and is given capacity to do so. Project manager and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the maintainers will provide initial feedback. ## Known Instances From 124922fa2e9386fc8db4a1a887dd489164f907ed Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 17:06:37 +0100 Subject: [PATCH 08/25] Update patterns/1-initial/capacity-for-contributions.md Co-authored-by: Sebastian Spier --- patterns/1-initial/capacity-for-contributions.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 233b48c75..e958eb5ed 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -14,7 +14,9 @@ Large InnerSource contributions are causing delays to other work in the team and The BBC's connected TV application are built by a number of teams, each with different areas of responsibility. They work on each other's areas of the codebase via InnerSource on a regular basis. -The team responsible for the build process for the JavaScript bundles received a major pull request, changing how dependencies were bundled. This PR introduced a new build time dependency, a new structure to the deployed JavaScript bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required significant time to code review, test, and ensure the team understood the new tooling and structure introduced. Normally, InnerSource contributions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, delivery manager, and product manager, to prioritize this work against other work. Time was set aside to review this contribution at future date. +The team responsible for the build process for the JavaScript bundles received a major pull request, changing how dependencies were bundled. This PR introduced a new build time dependency, a new structure to the deployed JavaScript bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required significant time to code review, test, and ensure the team understood the new tooling and structure introduced. + +Normally, InnerSource contributions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, project manager, and product manager, to prioritize this work against other work. Time was set aside to review this contribution at a future date. This process was formalized in the team: From 3502897779a642e3cde6a5e35e2234fddfeb548b Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Mon, 24 Jun 2024 18:21:18 +0200 Subject: [PATCH 09/25] Rewording Co-authored-by: Tom Sadler --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index e958eb5ed..e1262c380 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -4,7 +4,7 @@ Managing capacity for reviewing contributions ## Patlet -Reviewing InnerSource contributions takes time and effort. This should be reflected in capacity planning, especially for larger contributions. Expectations and available capacity should be transparent so that contributors understand when their contributions will be reviewed and released. +Reviewing InnerSource contributions takes time and effort. This should be reflected in capacity planning, especially for larger contributions. Expectations and available capacity should be transparent so that contributors understand when their contributions will be reviewed and, if accepted, released. ## Problem From 47ef2ceded358a75543ff158b5be85a6a765c7c6 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:11:12 +0100 Subject: [PATCH 10/25] Use 'host team' for consistency of terms --- patterns/1-initial/capacity-for-contributions.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index e1262c380..351be1c06 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -25,26 +25,26 @@ This process was formalized in the team: ## Context -Maintainers of a successful InnerSource project are finding it difficult to review contributions, especially large contributions. They do not want to disrupt their team's other work, but also want to support contributions by reviewing/releasing them in a timely fashion. +Host team of a successful InnerSource project are finding it difficult to review contributions, especially large contributions. They do not want to disrupt their team's other work, but also want to support contributions by reviewing/releasing them in a timely fashion. ## Forces * Contributors expect timely feedback on their contributions -* Maintaining team are expected to deliver other work alongside reviewing contributions -* Missing communication between contributors and maintainers on expectations/lead time for contributions to be reviewed/released +* Host team are expected to deliver other work alongside reviewing contributions +* Missing communication between contributors and host team on expectations/lead time for contributions to be reviewed/released * Tension in prioritizing InnerSource contributions against other work ## Solutions * Reviewing larger contributions is tracked in the team's ticketing system/bug tracker (e.g. Jira, GitHub issues) -* Maintaining team is given time to review larger contributions in team capacity planning +* Host team is given time to review larger contributions in team capacity planning * Reviewing contributions is prioritized against other work (e.g. in sprint planning) -* Maintainers communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released -* Maintaining team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback +* Host team communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released +* Host team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback ## Resulting Context -Maintaining team understands the overhead of reviewing large contributions and is given capacity to do so. Project manager and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the maintainers will provide initial feedback. +Host team understands the overhead of reviewing large contributions and is given capacity to do so. Project manager and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the host team will provide initial feedback. ## Known Instances From f4bdb57642afca998839c35016ed78f2f60e3fe3 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:18:03 +0100 Subject: [PATCH 11/25] Expand solution to include contributors giving early visibility of contributions --- patterns/1-initial/capacity-for-contributions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 351be1c06..af93ca054 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -36,6 +36,7 @@ Host team of a successful InnerSource project are finding it difficult to review ## Solutions +* Contributors are encouraged to give the host team early visibility of larger contributions (e.g. via GitHub Issues, draft PRs, [RFCs](../2-structured/transparent-cross-team-decision-making-using-rfcs.md), or informal discussions) and are made aware that not doing so could delay review of their contribution * Reviewing larger contributions is tracked in the team's ticketing system/bug tracker (e.g. Jira, GitHub issues) * Host team is given time to review larger contributions in team capacity planning * Reviewing contributions is prioritized against other work (e.g. in sprint planning) From d9d5e284a5820b3f6fb2d82767f0326d417117b7 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:19:25 +0100 Subject: [PATCH 12/25] Add note in forces around preferring smaller PRs --- patterns/1-initial/capacity-for-contributions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index af93ca054..4ea86276f 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -33,6 +33,7 @@ Host team of a successful InnerSource project are finding it difficult to review * Host team are expected to deliver other work alongside reviewing contributions * Missing communication between contributors and host team on expectations/lead time for contributions to be reviewed/released * Tension in prioritizing InnerSource contributions against other work +* Contributors already strive to make small PRs, but find instances where larger PRs are unavoidable ## Solutions From 17b0f76dca1aef13048d6b1ab576ad1fc877b985 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:22:26 +0100 Subject: [PATCH 13/25] Capitalise Agile --- patterns/1-initial/capacity-for-contributions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 4ea86276f..36312c3b5 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -8,7 +8,7 @@ Reviewing InnerSource contributions takes time and effort. This should be reflec ## Problem -Large InnerSource contributions are causing delays to other work in the team and/or contributions are taking longer to be released than expected. Reviewing contributions may be significant invisible work, not tracked in a team's agile development process. +Large InnerSource contributions are causing delays to other work in the team and/or contributions are taking longer to be released than expected. Reviewing contributions may be significant invisible work, not tracked in a team's Agile development process. ## Story @@ -33,7 +33,7 @@ Host team of a successful InnerSource project are finding it difficult to review * Host team are expected to deliver other work alongside reviewing contributions * Missing communication between contributors and host team on expectations/lead time for contributions to be reviewed/released * Tension in prioritizing InnerSource contributions against other work -* Contributors already strive to make small PRs, but find instances where larger PRs are unavoidable +* Contributors already strive to make small PRs in line with Agile, InnerSource, and Continuous Delivery principles, but find instances where larger PRs are unavoidable ## Solutions From a9382a16e4ef84b4f122364a4a5f908e48fcdb91 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:32:31 +0100 Subject: [PATCH 14/25] Add note on smaller contributions being reviewed ad-hoc --- patterns/1-initial/capacity-for-contributions.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 36312c3b5..8061eccf4 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -43,11 +43,14 @@ Host team of a successful InnerSource project are finding it difficult to review * Reviewing contributions is prioritized against other work (e.g. in sprint planning) * Host team communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released * Host team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback +* Smaller contributions are still reviewed ad-hoc; the team may have guidelines on what they consider to be a smaller contribution (e.g. review should take less than an hour) ## Resulting Context Host team understands the overhead of reviewing large contributions and is given capacity to do so. Project manager and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the host team will provide initial feedback. +Smaller PRs are still reviewed ad-hoc, minimising overhead and unnecessary additional process. + ## Known Instances BBC iPlayer & Sounds From d185cf69193131fdf26c7de071fb09320c36067e Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:39:45 +0100 Subject: [PATCH 15/25] Recognise potential pitfalls in prioritisation --- patterns/1-initial/capacity-for-contributions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 8061eccf4..b36d3d303 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -51,6 +51,8 @@ Host team understands the overhead of reviewing large contributions and is given Smaller PRs are still reviewed ad-hoc, minimising overhead and unnecessary additional process. +There may still be conflict in prioritising contribution reviews, especially if the host team is overburdened with other work. This only works if contributions are valued by the decision makers in the team's planning process. + ## Known Instances BBC iPlayer & Sounds From 827de522008eb6c03d4e483c9f58ba2480967739 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:40:37 +0100 Subject: [PATCH 16/25] Add reviewers to Acknowledgments --- patterns/1-initial/capacity-for-contributions.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index b36d3d303..2f892b63b 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -68,3 +68,7 @@ Tom Sadler ## Acknowledgments Clare Dillon +Sebastian Spier +Guilherme Dellagustin +Michael Basil +Bill Westfall \ No newline at end of file From cc2aa4b22fe2ee1dac630725e17e6c622a0c6324 Mon Sep 17 00:00:00 2001 From: Tom Sadler Date: Mon, 24 Jun 2024 18:44:35 +0100 Subject: [PATCH 17/25] Fix linting --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 2f892b63b..45e2d1dad 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -71,4 +71,4 @@ Clare Dillon Sebastian Spier Guilherme Dellagustin Michael Basil -Bill Westfall \ No newline at end of file +Bill Westfall From 58521a7809ee3b7fbee869e9b742bb606ed65739 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 17:13:41 +0100 Subject: [PATCH 18/25] Formatting --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index 45e2d1dad..f08b0d48b 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -55,7 +55,7 @@ There may still be conflict in prioritising contribution reviews, especially if ## Known Instances -BBC iPlayer & Sounds +- BBC iPlayer & Sounds ## Status From facb787edf7bbebafc7b34a205cdb7d15d16d709 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 17:16:57 +0100 Subject: [PATCH 19/25] Simplify wording --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index f08b0d48b..b4e7485ea 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -42,7 +42,7 @@ Host team of a successful InnerSource project are finding it difficult to review * Host team is given time to review larger contributions in team capacity planning * Reviewing contributions is prioritized against other work (e.g. in sprint planning) * Host team communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released -* Host team has a service level objective (SLO) (e.g. 2 working days) for contributions receiving initial feedback +* Host team has a service level objective (SLO) (e.g. 2 working days) for providing initial feedback to new contributions * Smaller contributions are still reviewed ad-hoc; the team may have guidelines on what they consider to be a smaller contribution (e.g. review should take less than an hour) ## Resulting Context From 3e0bb1c406c9d2f7c31fd929196257f3de82fa4e Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 17:20:13 +0100 Subject: [PATCH 20/25] Formatting - splitting into multiple bullets --- patterns/1-initial/capacity-for-contributions.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index b4e7485ea..fdada1d27 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -20,7 +20,8 @@ Normally, InnerSource contributions would be reviewed ad-hoc, but the team estim This process was formalized in the team: -* Larger contributions have a ticket created on the team's backlog and included in prioritization discussion alongside other tickets. The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released. +* Larger contributions have a ticket created on the team's backlog and included in prioritization discussion alongside other tickets. +* The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released. * Smaller contributions can still be reviewed ad-hoc. ## Context From adb7cc077a3ef7c0cfb613c796a86e8feaa0950a Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 17:21:03 +0100 Subject: [PATCH 21/25] Camel Casing --- patterns/1-initial/capacity-for-contributions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/capacity-for-contributions.md b/patterns/1-initial/capacity-for-contributions.md index fdada1d27..ed5be960e 100644 --- a/patterns/1-initial/capacity-for-contributions.md +++ b/patterns/1-initial/capacity-for-contributions.md @@ -1,6 +1,6 @@ ## Title -Managing capacity for reviewing contributions +Managing Capacity for Reviewing Contributions ## Patlet From 40b2595144705eb671679d6a10fd2ff3db065c4c Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Sun, 29 Dec 2024 17:24:21 +0100 Subject: [PATCH 22/25] Adding link to this pattern to the README --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index a6e4004cf..f84e28469 100644 --- a/README.md +++ b/README.md @@ -84,6 +84,7 @@ Our mission * [Incubator Pipeline](/patterns/1-initial/incubator-pipeline.md) - *A team maintaining a widely shared code library wants to accept contributions from other teams, without lowering the overall quality of their library. Therefore the shared library team uses an incubator pipeline to set a lower bar for contributions to enter and a higher bar to exit and become a top-level unit in the library.* * [InnerSource Customer Interview Questions](/patterns/1-initial/innersource-customer-interview-questions.md) - *An organization has decided to create an InnerSource program but are unsure which issues they should address first. Using a customer interview will help evaluate pain points across the organization, to prioritize the areas where InnerSource will have the biggest positive impact.* * [Creating an InnerSource Strategy](/patterns/1-initial/creating_an_innersource_strategy.md) - *Sometimes, it is difficult to convince people of the relevance of InnerSource for your organization and/or to get support from management. Creating an InnerSource strategy, that connects your InnerSource approach and activities to the goals and the overall strategy of your organization, can help in this regard.* +* [Managing Capacity for Reviewing Contributions](/patterns/1-initial/capacity-for-contributions.md) - *Reviewing InnerSource contributions takes time and effort. This should be reflected in capacity planning, especially for larger contributions. Expectations and available capacity should be transparent so that contributors understand when their contributions will be reviewed and, if accepted, released.*