Removing old status flags + Various non-content cleanup (InnerSourceCommons#290)

spier · web-flow · commit a0070bb2c3b2 · 2021-02-07T20:41:48.000+01:00
No content changes!
Removing old status 'Proven' from most Structured Patterns. Also some smaller formatting and ordering changes. 
Setting correct Status for our 'Initial' Patterns. Removing option sections that were blank. Some typo fixes.
diff --git a/patterns/1-initial/bad-weather-for-liftoff.md b/patterns/1-initial/bad-weather-for-liftoff.md
@@ -25,22 +25,24 @@ TBD
 - There is a natural tendency to pick low hanging fruits (e. g. tooling) and stop there.
 - For InnerSource to blossom, a critical mass of experienced developers which can walk the talk is required.
 
-## Sketch (optional)
-
 ## Solution
 
 TBD
 
 ## Resulting Context
 
-## Rationale (optional)
+TBD
+
+## Known Instances
 
-## Known Instances (optional)
+TBD
 
 ## Status
 
-Donut
+* Initial (Donut)
 
 ## Author(s)  
 
-* Georg Grütter, Wyane DuPont, Michael Dorner
+* Georg Grütter
+* Wyane DuPont
+* Michael Dorner
diff --git a/patterns/1-initial/code-consumers.md b/patterns/1-initial/code-consumers.md
@@ -39,11 +39,11 @@ The following are potential solutions that have been proposed to this problem:
 
 # Resulting Context
 
-_needs work..?_
+TBD
 
 # Known Instances
 
-_needs work...?_
+TBD
 
 # Authors
 
diff --git a/patterns/1-initial/concept-anchor.md b/patterns/1-initial/concept-anchor.md
@@ -58,11 +58,11 @@ InnerSource helps in this process by its emphasis on a CI/CD workflow as well as
 
 ## Resulting Context
 
-**TBD**
+TBD
 
 ## Status
 
-Donut
+* Initial (Donut)
 
 ## Author(s)
 
diff --git a/patterns/1-initial/defeat-hierarchical-constraints.md b/patterns/1-initial/defeat-hierarchical-constraints.md
@@ -30,6 +30,6 @@ Developers feel empowered to spend at least 20% of their time on inner sourcing
 
 ## Status
 
-Donut
+* Initial (Donut)
 
 ## Author(s)
diff --git a/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md b/patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md
@@ -66,15 +66,13 @@ TBD
 * devs take on professional mentorship responsibilities for their peers rather than leaving it to non-technical management
 * career progression clearly identified & understood by engs and management
 
-## Rationale (optional)  
+## Known Instances
 
-## Known Instances (optional)  
+TBD
 
 ## Status  
 
-* Initial
-* Old status: Unproven
-* Old status: brainstormed solution
+* Initial (brainstormed solution)
 
 ## Author
 
diff --git a/patterns/1-initial/discover-your-innersource.md b/patterns/1-initial/discover-your-innersource.md
@@ -59,6 +59,8 @@ Make it easy to find the reusable code.
 
 ## Known Instances
 
+TBD
+
 ## Resulting Context
 
 * Internal components are easily visible
@@ -70,8 +72,7 @@ Make it easy to find the reusable code.
 
 ## Status
 
-* Initial
-* Brainstormed pattern idea in progress
+* Initial (brainstormed solution)
 
 ## Authors
 
diff --git a/patterns/1-initial/duplicated-projects.md b/patterns/1-initial/duplicated-projects.md
@@ -4,7 +4,7 @@ Duplicated Projects
 
 ## Patlet
 
-Forthcoming ...
+TBD
 
 ## Problem
 
@@ -51,7 +51,3 @@ e.g. Splunk.
 ## Status
 
 * Initial
-
-## Author(s)
-
-## Acknowledgements
diff --git a/patterns/1-initial/include-product-owners.md b/patterns/1-initial/include-product-owners.md
@@ -61,7 +61,7 @@ Key Performance Indicators (KPIs) for Product Owners are primarily product focus
 
 ## Status
 
-* Initial (still missing Patlet and at least one Known Instance)
+* Initial
 * Created at the Spring Summit 2017 in Geneva, Switzerland
 
 ## Authors
diff --git a/patterns/1-initial/innersource-portal-hygiene.md b/patterns/1-initial/innersource-portal-hygiene.md
@@ -69,6 +69,5 @@ The automatically managed InnerSource portal and badge system has ensured that t
 
 ## Status
 
-**Initial**
-
-Based of PR [#120](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/120) we decided to merge this pattern in a relatively early state, as the upstream had disappeared and we didn't want to loose the content. See further discussions in the PR itself.
+* Initial
+* Based of PR [#120](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/120) we decided to merge this pattern in a relatively early state, as the upstream had disappeared and we didn't want to loose the content. See further discussions in the PR itself.
diff --git a/patterns/1-initial/introducing-metrics-in-innersource.md b/patterns/1-initial/introducing-metrics-in-innersource.md
@@ -56,7 +56,7 @@ Consider a third party that is seen as a neutral player to produce such metrics.
 
 Have specific training on the topic of metrics and good practices to use them. An example is to have a methodology to follow metrics such as the Goal-Question-Metric approach or the Objectives-KeyResults one. On the other hand, try to reflect the short-term and medium-term goals in the metrics to be used.
 
-Metrics when published or discussed should be done so in the aggregate without refering to specific people.
+Metrics when published or discussed should be done so in the aggregate without referring to specific people.
 
 Produce a characterization of metrics as this might be helpful for others to understand and follow.
 
@@ -70,13 +70,15 @@ Note: The aforementioned metrics are some common examples. They aren't a one-siz
 
 The organization builds a monitoring and reporting infrastructure for the metrics that flow directly from its business goals.
 
-Those metrics will provide visibility into the current situation of the project to the C-level executives. By comparing the metric measurements before applying inner source and to the metric measurements after applying the inner source initiative, it is possible to guage the effectiveness of the inner source initiave.
+Those metrics will provide visibility into the current situation of the project to the C-level executives. By comparing the metric measurements before applying InnerSource and to the metric measurements after applying the InnerSource initiative, it is possible to gauge the effectiveness of the InnerSource initiative.
 
 Continued monitoring of these metrics will help middle management and developers understand how the initiative evolves and will help them with their daily work.
 
 ## Known Instances
 
-## State
+TBD
+
+## Status
 
 Initial
 
diff --git a/patterns/1-initial/junkyard-styled-innersourcing.md b/patterns/1-initial/junkyard-styled-innersourcing.md
@@ -35,8 +35,7 @@ Two situations:
 
 ## Status
 
-* Initial
-* Brainstormed pattern idea in progress
+* Initial (brainstormed solution)
 
 ## Authors
 
diff --git a/patterns/1-initial/organizational-mindset-change.md b/patterns/1-initial/organizational-mindset-change.md
@@ -32,6 +32,4 @@ All of the company heartily adopts inner sourcing! Cake for everyone!
 
 ## Status
 
-Donut
-
-## Author(s)  
+* Initial (Donut)
diff --git a/patterns/1-initial/reluctance-to-accept-contributions.md b/patterns/1-initial/reluctance-to-accept-contributions.md
@@ -51,8 +51,9 @@ The last 3 patterns above were mentioned to be "under construction" at the time
 
 ## Status
 
-11 Oct 2016 - First draft
-13 Apr - Reviewed & Revised
+* Initial
+* 11 Oct 2016 - First draft
+* 13 Apr - Reviewed & Revised
 
 ## Author
 
diff --git a/patterns/1-initial/share-your-code-to-get-more-done.md b/patterns/1-initial/share-your-code-to-get-more-done.md
@@ -2,8 +2,6 @@
 
 Share Your Code to Get More Done
 
-Old title: Share Your Code to Get More Done - Likely Contributors Variant
-
 ## Patlet
 
 TBD
@@ -46,9 +44,9 @@ TBD
 * People from outside the traditional silo are contributing successfully
 * More development is getting done per period (sprint)
 
-## Rationale (optional)
+## Known Instances
 
-## Known instances (optional)
+TBD
 
 ## Status
 
@@ -59,3 +57,7 @@ TBD
 ## Author
 
 David Marcucci
+
+## Alias
+
+Old title: Share Your Code to Get More Done - Likely Contributors Variant
diff --git a/patterns/1-initial/shared-code-repo-different-from-build-repo.md b/patterns/1-initial/shared-code-repo-different-from-build-repo.md
@@ -28,8 +28,8 @@ Ideally, overhead is minimized or eliminated. Or integrate the shared code repos
 
 ## Known Instances
 
-## Status
+TBD
 
-Unproven
+## Status
 
-## Author  
+Initial
diff --git a/patterns/2-structured/30-day-warranty.md b/patterns/2-structured/30-day-warranty.md
@@ -77,7 +77,6 @@ This was tried and proven successful at PayPal.
 ## Status
 
 * Structured
-* Old status: Proven
 * Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
 
 ## Variants
diff --git a/patterns/2-structured/common-requirements.md b/patterns/2-structured/common-requirements.md
@@ -53,8 +53,8 @@ TBD
 ## Status
 
 * Structured
-* Old status: Proven
+* Drafted Aug 2016
 
 ## Author
 
-Robert Hanmer, 22 Aug 2016, 20 Sept 2016  
+Robert Hanmer
diff --git a/patterns/2-structured/contracted-contributor.md b/patterns/2-structured/contracted-contributor.md
@@ -124,7 +124,6 @@ A formal contracting is also beneficial for contributors and communities:
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Author
 
diff --git a/patterns/2-structured/crossteam-project-valuation.md b/patterns/2-structured/crossteam-project-valuation.md
@@ -70,7 +70,7 @@ In-practice, though, it does give a framework by which you can make a sound deci
 After having good, reasonable data according to the above explanation, you should fund dedicated development hours toward running the project up to _**at least**_ of the lesser of the following three levels:
 
 1. The raw hours saved by the formula above.  Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.
-1. The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to faciliate their work going into a shared location.
+1. The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to facilitate their work going into a shared location.
 1. Whatever feels good to you.  One intentional side-effect of having a valuation formula is that it  naturally forces measurement of the key points of usage that provide value to consumers.
 
 Those measurements can be understood and consumed in their raw form to provide you with a gut-feel idea of how valuable is the project.
@@ -94,15 +94,15 @@ They will provide a head-and-shoulders improvement in on-the-ground results over
 
 * Nike
 
+## Status
+
+* Structured
+* Old status: Proven in multiple domains.
+
 ## Authors
 
 * Russ Rutledge
 
 ## Acknowledgement
 
 * Jeremiah Wright for teaching me to think about cross-team projects as an internal business dealing in the currency of developer time.
-
-## Status
-
-* Structured
-* Old status: Proven in multiple domains.
diff --git a/patterns/2-structured/dedicated-community-leader.md b/patterns/2-structured/dedicated-community-leader.md
@@ -67,7 +67,6 @@ Dedicated Community Leader
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Authors
 
diff --git a/patterns/2-structured/gig-marketplace.md b/patterns/2-structured/gig-marketplace.md
@@ -66,7 +66,6 @@ When used in combination with the InnerSource Portal pattern, the Gig Marketplac
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Author(s)
 
diff --git a/patterns/2-structured/innersource-license.md b/patterns/2-structured/innersource-license.md
@@ -69,7 +69,6 @@ It is worth mentioning that so far the software shared under this InnerSource li
 ## Status
 
 * Structured
-* Old status: Proven
 * The experiment listed under **Known Instances** is running since 02/2020. The initial experience shows first positive effects but more experience is needed to fully evaluate the pattern.
 
 ## Author(s)
diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
@@ -65,7 +65,6 @@ The InnerSource Portal has enabled InnerSource project owners to advertise their
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Author(s)
 
diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md
@@ -214,20 +214,18 @@ long term.
 * Zylk
 * Bitergia
 
+## Status
+
+* Structured
+* Drafted in September 2019
+
 ## Authors
 
 * Daniel Izquierdo Cortazar
 * Isabel Drost-Fromm
 * Jorge
 * Nerea
 
-## Acknowledgements
-
 ## Alias
 
 Maturity model: Learn about InnerSource best practices
-
-## Status
-
-* Structured
-* Drafted in September 2019
diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
@@ -68,7 +68,6 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Author(s)
 
diff --git a/patterns/2-structured/repository-activity-score.md b/patterns/2-structured/repository-activity-score.md
@@ -112,7 +112,6 @@ The repository activity score is a simple calculation based on the GitHub API. I
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Author(s)
 
diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md
@@ -82,7 +82,6 @@ Europace AG
 ## Status
 
 * Structured
-* Old status: Proven
 
 ## Author(s)
 
diff --git a/patterns/2-structured/trusted-committer.md b/patterns/2-structured/trusted-committer.md

-Original file line number
+Diff line change
 ## Problem
 -  - Project maintainers want to find ways to scale their ability to support a project
 -  - Project maintainers want to find ways to lengthen the value delivered by a project
 -  - Project maintainers want to visibly reward frequent contributors and empower them to amplify their value contribution.
 -  - Lack of language for recognizing contributions across teams within an organization
 +- Project maintainers want to find ways to scale their ability to support a project
 +- Project maintainers want to find ways to lengthen the value delivered by a project
 +- Project maintainers want to visibly reward frequent contributors and empower them to amplify their value contribution.
 +- Lack of language for recognizing contributions across teams within an organization
 ## Context
 -  - You are the maintainer of a cross-team library, service, or shared resource
 -  - You receive regular contributions
 -  - There are motivated contributors looking to build expertise through InnerSource projects
 +- You are the maintainer of a cross-team library, service, or shared resource
 +- You receive regular contributions
 +- There are motivated contributors looking to build expertise through InnerSource projects
 ## Forces
 -  - Over the lifecycle of a project the focus of the maintainers may shift away to accommodate changing business priorities
 -  - Contributors seek visible artifacts of their contributions demonstrating value
 -  - Maintaining a project of reasonable complexity is taxing for a small team
 +- Over the lifecycle of a project the focus of the maintainers may shift away to accommodate changing business priorities
 +- Contributors seek visible artifacts of their contributions demonstrating value
 +- Maintaining a project of reasonable complexity is taxing for a small team
 ## Solution