Improve Pattern: Unified Source Code Inventory (#362)

* New Patlet
* split properties into separate bullets (improves eadability; also matches the screenshot more closely)
* removing unnecessary punctuations
* reformatting Known Instances, to make it easier to add further orgs
* capitalize spelling of 'Organization' everywhere (except in the Patlet)
* Split up the two components that make up this the Solution in the Rationale section

Author: spier

patterns/1-initial/source-code-inventory.md

@@ -4,13 +4,14 @@ Unified Source Code Inventory
 
 ## Patlet
 
-In a large organization with different legal entities is often hard to get full visibility into all software assets, in particular all source code. This situation reduces the opportunities to increase business value and keep liability costs, such as software maintenance, under control across the organization as a whole. An organization-level source code inventory addresses these issues while exploiting opportunities to identify and support valuable InnerSource assets.
+Large organizations with many legal entities often don't have visibility into all of their software assets (repositories), limiting their ability to increase businesses value and control liability costs holistically.
+A unified source code inventory at organization-level addresses these issues, while exploiting opportunities to identify and support valuable InnerSource assets.
 
 ## Problem
 
-Given situations when InnerSource stakeholders do not value source code at the same level as other organization's assets; when source code strategies are ad-hoc and different among legal entities with little consolidation at organization-level; then it becomes harder both to select and support the right InnerSource project candidates as well as maximize business value of such a key asset.
+Given situations when InnerSource stakeholders do not value source code at the same level as other Organization's assets; when source code strategies are ad-hoc and different among legal entities with little consolidation at Organization-level; then it becomes harder both to select and support the right InnerSource project candidates as well as maximize business value of such a key asset.
 
-Can you get consistent answers within the organization to questions like?
+Can you get consistent answers within the Organization to questions like:
 
 * How would you find all source code touched by anyone in your legal entity?
 * How would you find out who else can also access each of the above?
@@ -20,36 +21,37 @@ Can you get consistent answers within the organization to questions like?
 
 ## Context
 
-* You work on Legal Entity within a complex Organization under continuous change (e.g., new acquisitions or changing business priorities).
+* You work on Legal Entity within a complex Organization under continuous change (e.g. new acquisitions or changing business priorities).
 * You cannot find all source code touched, shared and consumed within the Organization.
-* You do not have a clear policy on default sharing level when creating a new project (e.g., Open Source, InnerSource or Closed Source).
+* You do not have a clear policy on default sharing level when creating a new project (e.g. Open Source, InnerSource or Closed Source).
 * You cannot scan significant parts of the Organization's source code looking for duplication, similarity or code smells.
 * You do not know the existing ratios of Open Source, innerSource and Closed Source and their trend.
 * You cannot measure the diversity of contributions and resulting value for a given project.
 * You cannot identify and optimize tech stack diversity.
-* You cannot identify technical debt and determine the priorities for retirement (e.g., dead APIs/source).
+* You cannot identify technical debt and determine the priorities for retirement (e.g. dead APIs/source).
 
 ## Forces
 
-* Fragmentation of source code hosting systems in the organization.
-* Ad-hoc source code strategies scattered across the different Legal Entities in the organization.
+* Fragmentation of source code hosting systems in the Organization.
+* Ad-hoc source code strategies scattered across the different Legal Entities in the Organization.
 * Continuously changing map of the relationships between: projects, repositories, products, tech stacks, domains, solutions, platforms, services, components, sub-systems, people, authors, teams, external repositories.
-* Diverse software culture of teams across the organization (e.g., more open to collaboration or more siloed).
+* Diverse software culture of teams across the Organization (e.g. more open to collaboration or more siloed).
 
 ## Solutions
 
-### Set up an organization-level source code inventory live dashboard
+### Set up an Organization-level source code inventory live dashboard
 
 * Combination of manual and automated input data sources to a single source of truth
 * API available to add new data sources and extend coverage of the source code repository
 * Key meta-data about each repository:
   * Legal Entity
   * URL
-  * Version control system (e.g., GIT or SVN).
-  * Hosting vendor (e.g., GitHub, Gitlab or BitBucket) and hosting type (e.g., on-prem, private cloud or public cloud).
-  * Sharing level (e.g., Open Source, InnerSource, Closed Source).
+  * Version control system (e.g. GIT or SVN)
+  * Hosting vendor (e.g. GitHub, Gitlab or BitBucket)
+  * Hosting type (e.g. on-prem, private cloud or public cloud)
+  * Sharing level (e.g. Open Source, InnerSource, Closed Source)
 * Visualization in place to list all assets with options to filter based on meta-data
-* Enable access to automated source code static analysis tools (e.g., identify duplicated or similar code, flag code smells, benchmark test coverage).
+* Enable access to automated source code static analysis tools (e.g. identify duplicated or similar code, flag code smells, benchmark test coverage).
 
 Mockup dashboard             |  Mockup questionnaire
 :-------------------------:|:-------------------------:
@@ -69,31 +71,31 @@ Mockup dashboard             |  Mockup questionnaire
 
 ### For the Organization, Legal Entity and Project maintainers
 
-* We have explicit policies at Organization and Legal Entity level on source code strategy (e.g., where to create new repository or how to select the right sharing level).
+* We have explicit policies at Organization and Legal Entity level on source code strategy (e.g. where to create new repository or how to select the right sharing level).
 * We can find all source code touched, shared and consumed within the Organization or Legal Entity and take actions as needed.
 * We can measure the diversity of contributions and resulting business value for our project.
-* We can identify technical debt and determine the priorities for retirement (e.g., dead APIs/source).
+* We can identify technical debt and determine the priorities for retirement (e.g. dead APIs/source).
 
 ### For InnerSource governance
 
 * We can scan significant parts of our Organization's source code looking for opportunities of reuse, duplication, similarity or code smells.
 * We know the ratios of Open Source, InnerSource and Closed Source within the Organization so we can steer as needed.
 * We can identify and optimize tech stack diversity.
-* We can create awareness and culture shift on certain Legal Entities as needed (e.g., ratio of Open Source and InnerSource below average).
+* We can create awareness and culture shift on certain Legal Entities as needed (e.g. ratio of Open Source and InnerSource below average).
 
 ## Rationale
 
-It creates a dynamic and extendable single source of truth for repositories to capture, visualize and act on source code repositories across the Organization. That helps to create awareness and focus efforts on the right direction. The Source Code Strategy Assessment Framework helps teams to understand the value of intentional explicit policies on how to manage source code. It helps to create both continuous improvement cycles and references within the Organization of what others are doing.
+It creates a dynamic and extendable single source of truth for repositories to capture, visualize and act on source code repositories across the Organization. That helps to create awareness and focus efforts on the right direction.
 
-## Known Instances
+The Source Code Strategy Assessment Framework helps teams to understand the value of intentional explicit policies on how to manage source code. It helps to create both continuous improvement cycles and references within the Organization of what others are doing.
 
-This is under test at scale at:
+## Known Instances
 
-* Philips
+* Philips (under test at scale)
 
 ## References
 
-* Organization and Legal Entity terms as defined in [InnerSource License Pattern Glossary](../2-structured/innersource-license.md#glossary).
+* Organization and Legal Entity terms as defined in the [InnerSource License Pattern - Glossary](../2-structured/innersource-license.md#glossary).
 * Explore using this pattern in combination with the [InnerSource Portal](../2-structured/innersource-portal.md) pattern.
 
 ## Status