From 3de9e0bb10e5abc90cc5f466c7b59277514a05a4 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Thu, 16 Sep 2021 21:54:06 +0100 Subject: [PATCH 01/24] patlet --- patterns/1-initial/governance-levels.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 196570df6..6c90cb04a 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -2,6 +2,12 @@ Transparent Governance Levels +## Patlet + +Several groups are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. + +Estabilishing a more accurate internal language that is understood across all teams allows everyone to communicate intent or set expectations efficiently and without ambiguity. + ## Context Several teams are using InnerSource patterns and best practices. However the From 0b3c33b140a67629b51e0e137274b0cb73050fd8 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Thu, 16 Sep 2021 22:07:00 +0100 Subject: [PATCH 02/24] lint fix --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 6c90cb04a..0297ab2bf 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -4,7 +4,7 @@ Transparent Governance Levels ## Patlet -Several groups are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. +Several groups are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. Estabilishing a more accurate internal language that is understood across all teams allows everyone to communicate intent or set expectations efficiently and without ambiguity. From e7ae5efda233c16a36d87a9676c0e49d26b2317a Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Thu, 16 Sep 2021 22:56:59 +0100 Subject: [PATCH 03/24] problem/story --- patterns/1-initial/governance-levels.md | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 0297ab2bf..3bdbe60cd 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -4,25 +4,21 @@ Transparent Governance Levels ## Patlet -Several groups are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. +Several teams are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. Estabilishing a more accurate internal language that is understood across all teams allows everyone to communicate intent or set expectations efficiently and without ambiguity. -## Context +## Problem -Several teams are using InnerSource patterns and best practices. However the -degree to which they welcome not only contributions but give equal collaboration -rights to contributors differ. As a result there are unmatched expectations, -confusion and frustration when teams collaborate across team boundaries. +Several teams are using InnerSource practices. However the degree to which they welcome contributions and give equal collaboration rights to contributors differ. Despite these differences, all teams refer to their way of working as "InnerSource" without any additional qualifiers. -## Problem +The result is confusion and frustration when teams collaborate as the expectation of what InnerSource means in practice is different in each team. This confusion also affects strategy planning and decisions on future InnerSource intent as the term is too vague which leads to long discussions and time lost on clarifications. + +## Story + +For two projects InnerSource best practices have been adopted. Project A has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. Project B is fully owned by one team with contributions from multiple teams. New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications. -For two projects InnerSource best practices have been adopted. Project A -has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. -Project B is fully owned by one team, only contributions are coming from -multiple teams. New contributors to either project are regularly confused about -the level of influence they can gain to the respective project. This leads to -long discussions, escalations and time lost on clarifications. +Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke sub-options for their leadership to consider before a decision could be made. ## Forces From 971b4adaf8cc6de13e6c0733d7f6e44e080bbef8 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Wed, 22 Sep 2021 21:56:33 +0100 Subject: [PATCH 04/24] update forces --- patterns/1-initial/governance-levels.md | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 3bdbe60cd..87f7e3b7e 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -6,7 +6,7 @@ Transparent Governance Levels Several teams are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. -Estabilishing a more accurate internal language that is understood across all teams allows everyone to communicate intent or set expectations efficiently and without ambiguity. +Estabilishing a more accurate internal language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity. ## Problem @@ -22,15 +22,10 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Forces -- For project A shared ownership works well, members coming from multiple teams - are working together. -- For project B the backing team would like to retain a certain level of - ownership and control. Sharing ownership with other Trusted Committers outside - of the original team is not an option. -- Contributors want clarity on the level of influence they can gain in an - InnerSource project they are involved with. -- Writing detailed guidelines into each contributions file leads to a lot of - text that is hard to understand for engineers. +- Projects adopt different InnerSource patterns and practices to optimise for their context. +- Contributors want clarity on the level of influence they can gain in an InnerSource project they are involved with. +- Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits. +- Writing a detailed description of a set of InnerSource practices requires significant effort to write and to read. ## Solution @@ -40,22 +35,22 @@ used in contributing files. Examples of building blocks: -* **Bug reports and issues welcome**: People outside the core development team are +- **Bug reports and issues welcome**: People outside the core development team are welcome to read the code. They can submit feature requests and bug reports for things they would like to see changed. -* **Contributions welcome**: People outside the core development team may use the +- **Contributions welcome**: People outside the core development team may use the code, make modifications and feed those modifications back into the projects. Trusted committers are willing to mentor those contributions to a state where they can be accepted or communicate clearly why the proposed change cannot be made. -* **Shared write access**: In addition to the above people outside the core +- **Shared write access**: In addition to the above people outside the core development team may gain write access to the source repository. Influence on roadmap decisions as well as influence on who else gains write access is restricted to the core development team. -* **Shared ownership**: Members of different teams collaborate on the project as +- **Shared ownership**: Members of different teams collaborate on the project as equal peers. Everyone has the ability to merge code. Everyone has an equal say on the project direction. Everyone has an equal say in who else to add to this group. From 5c4a4996fff20726890eded974ca5969557a3e92 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Wed, 22 Sep 2021 22:22:43 +0100 Subject: [PATCH 05/24] re-added context --- patterns/1-initial/governance-levels.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 87f7e3b7e..b66cc2a7f 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -20,6 +20,10 @@ For two projects InnerSource best practices have been adopted. Project A has a s Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke sub-options for their leadership to consider before a decision could be made. +## Context + +InnerSource concepts are estabilished within an organisation with multiple projects and teams adopting InnerSource patterns and practices. Internal InnerSource practices are not prescribed in detail and teams/projects have the autonomy to optimise for their local circumstances. + ## Forces - Projects adopt different InnerSource patterns and practices to optimise for their context. From 3ef3e896520d5975d47aacc78f2d680941a5c2fc Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Wed, 22 Sep 2021 23:10:59 +0100 Subject: [PATCH 06/24] updated solution --- patterns/1-initial/governance-levels.md | 39 +++++++++++-------------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index b66cc2a7f..7ad8d1ea9 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -6,7 +6,7 @@ Transparent Governance Levels Several teams are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. -Estabilishing a more accurate internal language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity. +Estabilishing a more accurate common language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity. ## Problem @@ -22,7 +22,7 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Context -InnerSource concepts are estabilished within an organisation with multiple projects and teams adopting InnerSource patterns and practices. Internal InnerSource practices are not prescribed in detail and teams/projects have the autonomy to optimise for their local circumstances. +InnerSource concepts are estabilished within an organisation with multiple projects and teams adopting InnerSource. Internal InnerSource practices are not prescribed in detail and teams/projects have the autonomy to optimise for their local circumstances. ## Forces @@ -33,37 +33,32 @@ InnerSource concepts are estabilished within an organisation with multiple proje ## Solution -Establish standardised building blocks which can be used by projects to signify -how much influence they are willing to share. Those building blocks can then be -used in contributing files. +The solution is to create a universally understood language to describe standard building blocks for InnerSource in your organisation: -Examples of building blocks: +1. Identify the common recurring InnerSource operating models that exist in your teams and projects. +2. Document them in detail, and give each a distinctive name. +3. Promote the use of these names to describe projects until the name's meaning is understood across the whole organisation. -- **Bug reports and issues welcome**: People outside the core development team are - welcome to read the code. They can submit feature requests and bug reports for - things they would like to see changed. +Examples of common InnerSource operating models (1) are: -- **Contributions welcome**: People outside the core development team may use the - code, make modifications and feed those modifications back into the projects. - Trusted committers are willing to mentor those contributions to a state where - they can be accepted or communicate clearly why the proposed change cannot be - made. +- **Bug Reports and Issues Welcome**: People outside the core development team may use the code. They can submit feature requests and bug reports for things they would like to see changed. +- **Contributions Welcome**: People outside the core development team may use the code. They can also make modifications and submit them to core team for inclusion. +- **Shared Ownership**: Members of different teams collaborate on the project as equal peers. Everyone has the ability to merge code. Everyone has an equal say on the project direction. Everyone has an equal say in who else to add to this group. -- **Shared write access**: In addition to the above people outside the core - development team may gain write access to the source repository. Influence on - roadmap decisions as well as influence on who else gains write access is - restricted to the core development team. +Examples of promoting the names (3) are: -- **Shared ownership**: Members of different teams collaborate on the project as - equal peers. Everyone has the ability to merge code. Everyone has an equal say - on the project direction. Everyone has an equal say in who else to add to this - group. +- Using the names within project documentation and contributing guides. +- Labelling projects with the names in an [InnerSource Portal](../2-structured/innersource-portal.md). +- Presenting the names as a menu of adoption options for new InnerSource projects. +- Including the names and models in any internal InnerSource training or promotion. ## Resulting Context Teams can adopt InnerSource best practices in a step-by-step way. By documenting individual steps contributor confusion is avoided. +also results in increasing standardisation as the names are used as a menu + ## Known Instances TBD From 7aec8f36509ded8e56cf1ff139085e9847e25b9e Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Fri, 8 Oct 2021 20:59:01 +0100 Subject: [PATCH 07/24] resulting context --- patterns/1-initial/governance-levels.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 11c1f1f47..20ae67453 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -36,7 +36,7 @@ InnerSource concepts are estabilished within an organisation with multiple proje The solution is to create a universally understood language to describe standard building blocks for InnerSource in your organisation: 1. Identify the common recurring InnerSource operating models that exist in your teams and projects. -2. Document them in detail, and give each a distinctive name. +2. Document each model in detail, and give each a distinctive name. 3. Promote the use of these names to describe projects until the name's meaning is understood across the whole organisation. Examples of common InnerSource operating models (1) are: @@ -54,10 +54,10 @@ Examples of promoting the names (3) are: ## Resulting Context -Teams can adopt InnerSource best practices in a step-by-step way. By documenting -individual steps contributor confusion is avoided. - -also results in increasing standardisation as the names are used as a menu +- Cross team communication occurs efficiently without confusion using terms that are universally understood and centrally documented. +- Organisation leaders understand the nuances within practising InnerSource and make better informed and more precise decisions that are easier to communicate. +- Increased standardisation of InnerSource practices within the organisation as the named and documented building blocks are used by teams as a menu for adoption. +- Teams can adopt InnerSource best practices in a step-by-step way which makes adoption easier and less intimidating. ## Known Instances @@ -65,8 +65,9 @@ TBD ## Status -Initial (Early draft) +Initial ## Authors -* Isabel Drost-Fromm +- Isabel Drost-Fromm +- Rob Tuley From 6051039695e15a29018c9262de8d0b2bef0e0248 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Fri, 8 Oct 2021 21:08:19 +0100 Subject: [PATCH 08/24] pyramid example --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 20ae67453..6ab54aff1 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -61,7 +61,7 @@ Examples of promoting the names (3) are: ## Known Instances -TBD +- Flutter Entertainment define an "[Inner Source Pyramid](https://innersource.flutter.com/how/)" to define 3 different InnerSource models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. ## Status From eff361ad1a76bc71482505c9d5b25931f9ed2919 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Fri, 8 Oct 2021 21:42:42 +0100 Subject: [PATCH 09/24] language tweaks --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 6ab54aff1..dcbc6d337 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -61,7 +61,7 @@ Examples of promoting the names (3) are: ## Known Instances -- Flutter Entertainment define an "[Inner Source Pyramid](https://innersource.flutter.com/how/)" to define 3 different InnerSource models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. +Flutter Entertainment define an "[Inner Source Pyramid](https://innersource.flutter.com/how/)" to describe 3 different InnerSource models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. ## Status From ed0cc30b9b9f4ae37072e7d2c6d517cf8b0cafd1 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 21:09:58 +0000 Subject: [PATCH 10/24] Context into list as suggested Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index dcbc6d337..e49bdc756 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -22,7 +22,9 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Context -InnerSource concepts are estabilished within an organisation with multiple projects and teams adopting InnerSource. Internal InnerSource practices are not prescribed in detail and teams/projects have the autonomy to optimise for their local circumstances. +- InnerSource concepts are established within an organisation with multiple projects and teams adopting InnerSource. +- Internal InnerSource practices are not prescribed in detail. +- Teams/projects have the autonomy to optimise for their local circumstances. ## Forces From c71d86315290dfc98a28f07a4e3591029aaf2c7d Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 21:42:26 +0000 Subject: [PATCH 11/24] Lint correction Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index e49bdc756..2f21a1c73 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -22,7 +22,7 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Context -- InnerSource concepts are established within an organisation with multiple projects and teams adopting InnerSource. +- InnerSource concepts are established within an organisation with multiple projects and teams adopting InnerSource. - Internal InnerSource practices are not prescribed in detail. - Teams/projects have the autonomy to optimise for their local circumstances. From a49aa99d162d0ffaeee5f8edcb4ee17e9a8e4441 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 21:52:05 +0000 Subject: [PATCH 12/24] simplified language --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 2f21a1c73..c08c63e7a 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -31,7 +31,7 @@ Project C is currently closed source and used only by team 1. Team 2 want to use - Projects adopt different InnerSource patterns and practices to optimise for their context. - Contributors want clarity on the level of influence they can gain in an InnerSource project they are involved with. - Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits. -- Writing a detailed description of a set of InnerSource practices requires significant effort to write and to read. +- Writing a detailed description of a set of InnerSource practices requires significant effort. ## Solution From 3dece2f8e02e19f010ca6bdf70cac9fb881ddafc Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 21:56:29 +0000 Subject: [PATCH 13/24] Link to related pattern Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index c08c63e7a..19acfd8da 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -49,7 +49,7 @@ Examples of common InnerSource operating models (1) are: Examples of promoting the names (3) are: -- Using the names within project documentation and contributing guides. +- Using the names within project documentation and contributing guides (see also [Standard Base Documentation](../2-structured/project-setup/base-documentation.md)). - Labelling projects with the names in an [InnerSource Portal](../2-structured/innersource-portal.md). - Presenting the names as a menu of adoption options for new InnerSource projects. - Including the names and models in any internal InnerSource training or promotion. From 882e8311e3abd776ad9234b813f7711b56355fec Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 21:57:34 +0000 Subject: [PATCH 14/24] Naming convention Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 19acfd8da..97af9d245 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -63,7 +63,7 @@ Examples of promoting the names (3) are: ## Known Instances -Flutter Entertainment define an "[Inner Source Pyramid](https://innersource.flutter.com/how/)" to describe 3 different InnerSource models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. +Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutter.com/how/) to describe 3 different InnerSource operating models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. ## Status From 3e0410c295a32ec7a87f7026db2143083f53809d Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 22:02:37 +0000 Subject: [PATCH 15/24] Next level Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 97af9d245..69948ee0e 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -67,7 +67,7 @@ Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutte ## Status -Initial +Structured ## Authors From 5aae502382a6ec633ee0c9f01882f5d0f0ece888 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 22:26:50 +0000 Subject: [PATCH 16/24] forces update --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 69948ee0e..530b3b387 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -29,7 +29,7 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Forces - Projects adopt different InnerSource patterns and practices to optimise for their context. -- Contributors want clarity on the level of influence they can gain in an InnerSource project they are involved with. +- Users want clarity on the level of influence they can gain in an InnerSource project when deciding whether or how to use it. - Leaders want clarity on InnerSource project intentions to understand the expected cost and benefits. - Writing a detailed description of a set of InnerSource practices requires significant effort. From e740d8f54438ade3f900b080d7e4eb30e572c095 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Sun, 23 Jan 2022 22:49:04 +0000 Subject: [PATCH 17/24] added flutter pyramid image --- assets/img/flutter-pyramid.svg | 3 +++ patterns/1-initial/governance-levels.md | 2 ++ 2 files changed, 5 insertions(+) create mode 100644 assets/img/flutter-pyramid.svg diff --git a/assets/img/flutter-pyramid.svg b/assets/img/flutter-pyramid.svg new file mode 100644 index 000000000..a23d324d4 --- /dev/null +++ b/assets/img/flutter-pyramid.svg @@ -0,0 +1,3 @@ + + +
1. Readable Source
1. Readable Source
2. Guest
Contributions
2. Guest...
3. Maintainers in
Multiple Teams
3. Maintainers in...Viewer does not support full SVG 1.1 \ No newline at end of file diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 530b3b387..ee989b20f 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -63,6 +63,8 @@ Examples of promoting the names (3) are: ## Known Instances +Flutter InnerSource Pyramid + Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutter.com/how/) to describe 3 different InnerSource operating models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. ## Status From 6bd44a0cd52d35d21e8a8b5cbc74883c15bc39e5 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Tue, 22 Nov 2022 22:20:28 +0000 Subject: [PATCH 18/24] minor language --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index ee989b20f..301b540ec 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -18,7 +18,7 @@ The result is confusion and frustration when teams collaborate as the expectatio For two projects InnerSource best practices have been adopted. Project A has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. Project B is fully owned by one team with contributions from multiple teams. New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications. -Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke sub-options for their leadership to consider before a decision could be made. +Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke options for their leadership to consider before a decision could be made. ## Context From fe960d4aad806db40493a250f03f248fe25ec1d2 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Tue, 22 Nov 2022 22:22:34 +0000 Subject: [PATCH 19/24] suggest from S Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 301b540ec..5bbfbf327 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -35,7 +35,11 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Solution -The solution is to create a universally understood language to describe standard building blocks for InnerSource in your organisation: +The solution is to create a universally understood language to describe the InnerSource operating models that are used in your organisation. + +We define **InnerSource operating model** as a description of how much influence the core development team of a project ist willing to share with contributing teams. Or in other terms, the level of influence a contributing team can gain in the respective project. + +The shared language for these InnerSource operating models can be established with these steps: 1. Identify the common recurring InnerSource operating models that exist in your teams and projects. 2. Document each model in detail, and give each a distinctive name. From 67fbe1e0757c6b7a2f17244860ca1c5366b662ad Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Tue, 22 Nov 2022 22:23:42 +0000 Subject: [PATCH 20/24] Update patterns/1-initial/governance-levels.md Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 5bbfbf327..00a9d13de 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -51,7 +51,7 @@ Examples of common InnerSource operating models (1) are: - **Contributions Welcome**: People outside the core development team may use the code. They can also make modifications and submit them to core team for inclusion. - **Shared Ownership**: Members of different teams collaborate on the project as equal peers. Everyone has the ability to merge code. Everyone has an equal say on the project direction. Everyone has an equal say in who else to add to this group. -Examples of promoting the names (3) are: +Examples of promoting the model names (3) are: - Using the names within project documentation and contributing guides (see also [Standard Base Documentation](../2-structured/project-setup/base-documentation.md)). - Labelling projects with the names in an [InnerSource Portal](../2-structured/innersource-portal.md). From 3fbd665b73e7ce61f30156250b46f4cd4f94bffb Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Tue, 22 Nov 2022 22:26:51 +0000 Subject: [PATCH 21/24] fix lint --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index 00a9d13de..ff708260e 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -35,7 +35,7 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ## Solution -The solution is to create a universally understood language to describe the InnerSource operating models that are used in your organisation. +The solution is to create a universally understood language to describe the InnerSource operating models that are used in your organisation. We define **InnerSource operating model** as a description of how much influence the core development team of a project ist willing to share with contributing teams. Or in other terms, the level of influence a contributing team can gain in the respective project. From 08dda66b89876c4392c41a94e685d55124190e8a Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Wed, 23 Nov 2022 19:50:16 +0000 Subject: [PATCH 22/24] markdown for svg img Co-authored-by: Sebastian Spier --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index ff708260e..ac6c7e489 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -67,7 +67,7 @@ Examples of promoting the model names (3) are: ## Known Instances -Flutter InnerSource Pyramid +![InnerSource Pyramid used by Flutter Entertainment](../../assets/img/flutter-pyramid.svg) Flutter Entertainment define an [InnerSource Pyramid](https://innersource.flutter.com/how/) to describe 3 different InnerSource operating models: Readable Source, Guest Contributions and Maintainers in Multiple Teams. Each name is centrally documented. The use of these names is encouraged via repeated usage, direct training and categorisation of each InnerSource project. From 5095397492098ea7371325986b7c98e39170a379 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Wed, 23 Nov 2022 20:16:19 +0000 Subject: [PATCH 23/24] Added open source comparison --- patterns/1-initial/governance-levels.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index ac6c7e489..e1345d61d 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -14,12 +14,28 @@ Several teams are using InnerSource practices. However the degree to which they The result is confusion and frustration when teams collaborate as the expectation of what InnerSource means in practice is different in each team. This confusion also affects strategy planning and decisions on future InnerSource intent as the term is too vague which leads to long discussions and time lost on clarifications. -## Story +## Stories -For two projects InnerSource best practices have been adopted. Project A has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. Project B is fully owned by one team with contributions from multiple teams. New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications. +### Example of Confusion + +For two projects InnerSource best practices have been adopted. Project A has a shared ownership model with [Trusted Committers](../2-structured/trusted-committer.md) from multiple teams. Project B is fully owned by one team with contributions from other teams. New users of either project are regularly confused about the level of influence they can gain in the respective project. This leads to long discussions, escalations and time lost on clarifications. + +### Example of Delayed Decision Project C is currently closed source and used only by team 1. Team 2 want to use project C and the leadership of the two teams negotiates options which include InnerSource practices. Agreement takes longer than expected because the "InnerSource" term did not describe a target state that could be agreed without ambiguity, and the teams had to document bespoke options for their leadership to consider before a decision could be made. +### Examples from Open Source + +Like "InnerSource", Open Source is also a broad term. + +There are projects on GitHub, published purely for the pleasure of the author with no intention of long term maintenance, not intention to fix bugs submitted by users. This would be the equivalent of "Bug Reports and Issues Welcome" - you can report the bug, but its on the owner to find the time to fix it. + +There are projects where the roadmap is created in-house, hidden from public view. Where commit rights come and go with the contract of the employees of one company (e.g. MongoDB, Elastic, Tensorflow). Users are welcome to submit patches, they will even be mentored through. All development happens in the open, but control and strategy is never shared. This would be the equivalent of stage "Contributions Welcome". + +There are projects that share write access, but do not share the power to decide who gets write access next. This applies to everyone who is only a committer at an Apache project. There are projects that are fully shared across multiple independent organisations (e.g. k8s, any Apache project) - those would be "Shared Ownership". + +The same levels make sense inside of organisations. + ## Context - InnerSource concepts are established within an organisation with multiple projects and teams adopting InnerSource. From 6abcb491f83f126ae62fe5ff75875a5e72170bc9 Mon Sep 17 00:00:00 2001 From: Rob Tuley Date: Wed, 23 Nov 2022 20:21:12 +0000 Subject: [PATCH 24/24] lint fix --- patterns/1-initial/governance-levels.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/governance-levels.md b/patterns/1-initial/governance-levels.md index e1345d61d..5b65d11a1 100644 --- a/patterns/1-initial/governance-levels.md +++ b/patterns/1-initial/governance-levels.md @@ -26,7 +26,7 @@ Project C is currently closed source and used only by team 1. Team 2 want to use ### Examples from Open Source -Like "InnerSource", Open Source is also a broad term. +Like "InnerSource", Open Source is also a broad term. There are projects on GitHub, published purely for the pleasure of the author with no intention of long term maintenance, not intention to fix bugs submitted by users. This would be the equivalent of "Bug Reports and Issues Welcome" - you can report the bug, but its on the owner to find the time to fix it.