You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: patterns/2-structured/governance-levels.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ Project Governance Levels
5
5
## Patlet
6
6
7
7
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.
8
-
Estabilishing a more accurate common language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity.
8
+
Establishing a more accurate common language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity.
9
9
10
10
## Problem
11
11
@@ -89,15 +89,15 @@ Examples of common InnerSource operating models are:
89
89
Examples of promoting the model names are:
90
90
91
91
- Using the names within project documentation and contributing guides (see also [Standard Base Documentation](../2-structured/base-documentation.md)).
92
-
-Labelling projects with the names in an [InnerSource Portal](../2-structured/innersource-portal.md).
92
+
-Labeling projects with the names in an [InnerSource Portal](../2-structured/innersource-portal.md).
93
93
- Presenting the names as a menu of adoption options for new InnerSource projects.
94
94
- Including the names and models in any internal InnerSource training or promotion.
95
95
96
96
## Resulting Context
97
97
98
98
- Cross team communication occurs efficiently without confusion using terms that are universally understood and centrally documented.
99
99
- Organization leaders understand the nuances within practising InnerSource and make better informed and more precise decisions that are easier to communicate.
100
-
- Increased standardisation of InnerSource practices within the organization as the named and documented building blocks are used by teams as a menu for adoption.
100
+
- Increased standardization of InnerSource practices within the organization as the named and documented building blocks are used by teams as a menu for adoption.
101
101
- Teams can adopt InnerSource best practices in a step-by-step way which makes adoption easier and less intimidating.
102
102
103
103
## Known Instances
@@ -108,7 +108,7 @@ Examples of promoting the model names are:
108
108
109
109

110
110
111
-
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.
111
+
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 categorization of each InnerSource project.
0 commit comments