Merge branch 'master' of github.com:maxcapraro/InnerSourcePatterns

Author: maxcapraro

.github/CODEOWNERS

@@ -0,0 +1,40 @@
+# See GitHub documentation:
+# https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners
+
+# This is a comment.
+# Each line is a file pattern followed by one or more owners.
+
+# These owners will be the default owners for everything in
+# the repo. Unless a later match takes precedence,
+# @global-owner1 and @global-owner2 will be requested for
+# review when someone opens a pull request.
+*       @lenucksi @nyeates @gruetter @NewMexicoKid @cewilliams
+
+# Order is important; the last matching pattern takes the most
+# precedence. When someone opens a pull request that only
+# modifies JS files, only @js-owner and not the global
+# owner(s) will be requested for a review.
+# *.js    @js-owner
+
+# You can also use email addresses if you prefer. They'll be
+# used to look up users just like we do for commit author
+# emails.
+# *.go [email protected]
+
+# In this example, @doctocat owns any files in the build/logs
+# directory at the root of the repository and any of its
+# subdirectories.
+# /build/logs/ @doctocat
+
+# The `docs/*` pattern will match files like
+# `docs/getting-started.md` but not further nested files like
+# `docs/build-app/troubleshooting.md`.
+# docs/*  [email protected]
+
+# In this example, @octocat owns any file in an apps directory
+# anywhere in your repository.
+# apps/ @octocat
+
+# In this example, @doctocat owns any file in the `/docs`
+# directory in the root of your repository.
+# /docs/ @doctocat

.github/workflows/main.yml

@@ -2,7 +2,7 @@
 
 name: Link Check on README.md
 
-on: push
+on: [push, pull_request]
 jobs:
   linkChecker:
     runs-on: ubuntu-latest

30-day-warranty.md

@@ -1,18 +1,18 @@
-# Title
+## Title
 
 30 Day Warranty
 
-# Context
+## Context
 
 Teams depend on another team accepting their contributions so that a component produced by the receiving team can be used by the contributing team. The receiving team does not have the resources, knowledge, permission, and/or inclination to write the contributed component.
 
 - TBD: link to pattern "setting clear expectations for contributing code"
 
-# Problem
+## Problem
 
 A team develops a component which is used throughout an organization.  This team resists accepting or outright rejects contributions (feature requests).  This behavior blocks progress and leads to frequent disruption from escalations.
 
-# Forces
+## Forces
 
 - There is distrust of contributions due to a past history of cheating: teams
   submitted half finished contributions and subsequently filed requests for
@@ -38,7 +38,7 @@ A team develops a component which is used throughout an organization.  This team
   they are mitigated in a contribution; the system itself is somewhat brittle
   (may not be ways to fully test and catch all problems).
 
-# Solution
+## Solution
 
 Address the fears of both the receiving and the contributing teams by establishing a 30 day period starting with the time the contributed code goes into production, during which the contributing team consents to provide bug fixes to the receiving team.
 
@@ -48,35 +48,35 @@ Note that the warranty period could be 45, 60, or 100 days too. The duration may
 
 <img alt="30 Day Warranty" src="/assets/img/thirtydaywarranty.jpg" width="70%">
 
-# Resulting Context
+## Resulting Context
 
 - The receiving team is willing to accept contributions and able to share the
   workload of initial adaptations/fixes.
 - Increased transparency and fairness.
 - Keeps escalations from becoming too heavyweight.
 
-# Known Instances
+## Known Instances
 
 This was tried and proven successful at PayPal.
 
-# Authors
+## Authors
 
 - Cedric Williams
 
-# Acknowledgement
+## Acknowledgement
 
 - Dirk-Willem van Gulik
 - Padma Sudarsan
 - Klaas-Jan Stol
 - Georg Grütter
 
-# Status
+## Status
 
 Proven
 
 Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
 
-# Variants
+## Variants
 
 - Ensure cooperation of dependent teams by making them a community by having
   more than one, meritocratically appointed "[Trusted Committers](project-roles/trusted-committer.md)" (TCs) take responsibility.

README.md

@@ -1,4 +1,6 @@
-This repository contains the InnerSource Patterns collected by the [InnerSource Commons][isc-website]. These patterns are InnerSource best practices codified in a specific format to make it easy to understand, evaluate, and reuse them. 
+# InnerSource Patterns
+
+This repository contains the InnerSource Patterns collected by the [InnerSource Commons][isc-website]. These patterns are InnerSource best practices codified in a specific format to make it easy to understand, evaluate, and reuse them.
 
 Below you find [what a pattern is][gh-what-are-patterns], a [list of known patterns][gh-list-of-patterns], and [how to use these patterns][gh-how-to-use-patterns] in your organization.
 
@@ -10,37 +12,37 @@ You are already using InnerSource in your company and want to share your ideas a
 [gh-how-to-use-patterns]: https://github.com/InnerSourceCommons/InnerSourcePatterns#how-can-you-use-inner-source-patterns
 [gh-contribute]: https://github.com/InnerSourceCommons/InnerSourcePatterns#how-to-contribute
 
-# Mission Statement
+## Mission Statement
 
 Our mission in this working group
 - Collect and document agreed upon best practices of how to do InnerSource - in the form of patterns
 - Continuously publish the most mature patterns as an ebook
- 
 
-# List of Patterns
+## List of Patterns
 
 The below lists all known patterns. They are grouped into four stages of maturity.
 
-#### Reviewed Patterns (proven and reviewed)
+### Reviewed Patterns (proven and reviewed)
 
 * [30 Day Warranty](30-day-warranty.md) - *a pattern for getting a reluctant code-owning team to accept code submissions from outside their team.*
 * [Common Requirements](common-requirements.md) - *Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.*
 * [Contracted Contributor](contracted-contributor.md) - *Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.*
 * [Dedicated Community Leader](dedicated-community-leader.md) - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.*
 * [Gig Marketplace](gig-marketplace.md) - *Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.*
+* [InnerSource License](innersource-license.md) - *Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An **InnerSource License** provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.*
 * [InnerSource Portal](innersource-portal.md) - *Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for InnerSource project owners to attract an outside audience.*
 * [Praise Participants](praise-participants.md) - *Thank contributors effectively to engender further engagement from them and to encourage others to contribute*
 * [Review Committee](review-committee.md) - *A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.*
 * [Service vs. library: It's inner source, not inner deployment](service-vs-library.md) - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's
 possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.*
 * [Trusted Committer](project-roles/trusted-committer.md) - *Many inner-source projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.*
 
-#### Reviewed Pattern Ideas (not yet proven but reviewed)
+### Reviewed Pattern Ideas (not yet proven but reviewed)
 
 * [Modular Code](modular-code.md) - *Management does not want to spend the extra resources needed to develop modular components and make them available in a visible repository for others to use.*
 * [Improve Findability](improve-findability.md) - *People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding inner source solutions and a reduction in code reuse.*
 
-#### Pattern Drafts (proven, not yet fully reviewed)
+### Pattern Drafts (proven, not yet fully reviewed)
 
 * [Assisted Compliance](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Cross-Team Project Valuation](crossteam-project-valuation.md) - *It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
@@ -53,17 +55,17 @@ possible to either deploy the same service in independent environments with sepa
 * [Start as Experiment](start-as-experiment.md) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.*
 * [Include Product Owners](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/71) - *Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.*
 
-#### Pattern Ideas (not yet proven; brainstormed)
+### Pattern Ideas (not yet proven; brainstormed)
 
-* [Don't Bother Looking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/60)
+* [Discover Your InnerSource](discover-your-innersource.md)
 * [Junkyard Styled Inner Sourcing](junkyard-styled-innersourcing.md)
 * [Shared Code Repo Different from Build Repo](shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
 * [Incentive Alignment](developer-incentive-alignment-for-innersource-contribution.md)
 * [Change the Developers Mindset](change-the-developers-mindset.md)
 * [Share Your Code to Get More Done - Likely Contributors Variant](share-your-code-to-get-more-done.md)
 * [Introducing Metrics in InnerSource](introducing-metrics-in-innersource.md) - *Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.*
 
-#### Pattern Donuts (needing a solution)
+### Pattern Donuts (needing a solution)
 
 * [How to Defeat the Hierarchical Constraints](defeat-hierarchical-constraints.md)
 * [Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47)
@@ -72,47 +74,30 @@ possible to either deploy the same service in independent environments with sepa
 * [Bad Weather For Liftoff](bad-weather-for-liftoff.md)
 * [Get Contributions Despite Silo Thinking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/38)
 
-
-# What are Inner Source Patterns?
+## What are InnerSource Patterns?
 
 Patterns are a way of describing a repeatable, proven solution to a problem with a context. They follow a simple form that helps people wanting to implement the solution to understand the constraints on the problem, the forces that must be balanced and the resulting context (the situation you are left with after the solution is applied). In inner sourcing, patterns can provide a way for the InnerSource Commons participants to concisely share information with each other, improving the practice of inner sourcing. Each of the patterns are divided into Title, Problem Statement, Context, Forces, and Solutions as their main sections.
 
-* [`What are patterns?` Youtube videos](http://bit.ly/innersource_patterns_videos) - Watch a set of 2-5 min youtube videos explaining Inner Source Patterns
+* [`What are patterns?` Youtube videos](http://bit.ly/innersource_patterns_videos) - Watch a set of 2-5 min youtube videos explaining InnerSource Patterns
 * [Pattern Discussion Webinar](https://youtu.be/i-0IVhfRVFU) - We held a webinar 2017-03-16 to live-discuss a donut pattern (go to 24:30 for the discussion). This is an illustration of the review process we follow. Also see the [June 1, 2017 O'Reilly Webinar on InnerSource Patterns](http://www.oreilly.com/pub/e/3884).
 * [Pattern Template File](meta/pattern-template.md) - View a skeleton inner source pattern to get an idea on what goes into a new pattern!
 * [Introduction to InnerSource Patterns (2016 Fall Summit presentation)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) - *Tim Yao and Padma Sudarsan* (PDF). Detailed pattern background and examples -- Get a detailed understanding of why and how to interact with our patterns. Also see the [Introduction to InnerSource Patterns (2017 Fall Summit)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) *Tim Yao and Bob Hanmer* (PDF).
 
-# How can you use Inner Source Patterns?
+## How can you use InnerSource Patterns?
 
 Patterns must be used in a thoughtful manner. They cannot be blindly applied. In most cases, you will need to adapt the given solution to your own situation; but the information given in the pattern, defining the context (immovable constraints) and forces (constraints that can be changed and balanced against each other), should help you do this. Note that you will also need to determine if there are additional constraints (company context and company forces) that apply to your particular company/organization that must be added to the pattern (as a kind of filter). These additional constraints may require additional solution steps to be applied.
 
 The pattern form is useful for describing proven patterns but it can also be used for *brainstorming solutions* where patterns are not yet established, since the form gives a structured way for thinking about a problem. You could also create a *donut pattern* (filling in the problem, context, forces and resulting context fields but leaving the solution blank) as a way of asking the InnerSource Commons community for help (to find a proven solution or to brainstorm things to try).
 
-
-# How to Contribute?
+## How to Contribute?
 
 We welcome your contribution - be it small or huge! To learn more about how you can become a contributor, please see our [CONTRIBUTING.md](CONTRIBUTING.md) file.
 
-
-# Pattern Meta Info
-
-The topics below cover information about how we define, operate, and upkeep this collection of patterns.
-
-* [Pattern Template](meta/pattern-template.md) - Start a new pattern with a copy of this
-* [Pattern States](meta/pattern-states.md) - Definitions of the various states and review steps a pattern can be in
-* [Pattern System](pattern-system.md) (draft) For a human reader it is not easy to digest a long list of patterns. We are working on labeling and classifying the patterns further. See [Pattern System](pattern-system.md) for our current thoughts.
-* [Trusted Committers](TRUSTED-COMMITTERS.md) - Who these people are, what elevated rights they get, and how you can become one
-* [Publishing](meta/publishing.md) - How we take completed, reviewed, proven patterns and publish them toward an online book
-* [Markdown Info](meta/markdown-info.md) - Markdown is the ascii text format our patterns are written in; this document briefly defines how we use it
-* [Contributing](CONTRIBUTING.md) - How to interact with our group, create your own patterns, or take part in our review-process; Github / Web centric instructions
-  * [Alternate Command-line steps](meta/technical-git-howto.md) - If you want to contribute a pattern using `git` from the command-line, this is your document
-  * [Meetings](meta/meetings.md) - Become involved with the people and communications of the Inner Source Patterns group
-
-# Related References
+## Related References
 
 * [A pattern language for pattern writing](http://hillside.net/index.php/a-pattern-language-for-pattern-writing), Meszaros and Doble
 
-# Licensing
+## Licensing
 
 ![Creative Commons License](https://i.creativecommons.org/l/by-sa/4.0/88x31.png)
 

TRUSTED-COMMITTERS.md

@@ -4,11 +4,11 @@ Trusted committers (TCs) are those members of our working group who have elevate
 
 ## Current Trusted Committers
 
-* @lenucksi
-* @nyeates
-* @gruetter
-* @NewMexicoKid
-* @cewilliams
+* [@lenucksi](https://github.com/lenucksi)
+* [@nyeates](https://github.com/nyeates)
+* [@gruetter](https://github.com/gruetter)
+* [@NewMexicoKid](https://github.com/NewMexicoKid)
+* [@cewilliams](https://github.com/cewilliams)
 
 ## Process for Adding new Trusted Committers
 
@@ -30,6 +30,6 @@ We follow this process (adapted from [here](https://tech.europace.de/voting-in-n
    * New TC is added to the #innersource-patterns-tcs channel
    * New TC is praised in the [#innersource-patterns](https://app.slack.com/client/T04PXKRM0/C2EFRTS6A) channel.
 
-
 ## Admins
+
 A handful of individuals are currently the technical GitHub Admins for this repository. This includes most members of the InnerSource Commons' #tech-infra team and members of the [InnerSource Commons GitHub Organization](https://github.com/innersourcecommons). However, please channel working group-specific requests through the trusted committers.

bad-weather-for-liftoff.md

@@ -44,9 +44,3 @@ Donut
 ## Author(s)  
 
 * Georg Grütter, Wyane DuPont, Michael Dorner
-
-## See Also
-
-This pattern was originally created in this wiki and then ported here.
-Original wiki page:
-https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut:-Bad-weather-for-liftoff

change-the-developers-mindset.md

@@ -58,7 +58,3 @@ Old status: Pattern Idea
 ## See Also
 
 This pattern has been moved for discussion at https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/39
-
-This pattern was originally created in this wiki and then ported here.
-Original wiki page:
-https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Pattern:-change-the-developers-mindset

contracted-contributor.md

@@ -62,7 +62,7 @@ hours, not during free time.
   which does not benefit his day-to-day work, the more will the workload for
   his teammates in his business unit increase.
 - Individual contributors will likely consider participating in InnerSource
-  as an opportunity to enhance their professional netowrk within the company
+  as an opportunity to enhance their professional network within the company
   and to gain knowledege and experience in the technical area of her
   contributions.
 
@@ -113,7 +113,7 @@ A formal contracting is also beneficial for contributors and communities:
 - With a stable group of contributors, it is more likely that some of them will
   eventually achieve [Trusted Committer](project-roles/trusted-committer.md) status.
 - A formal contracting provides a basis for resolving conflict related to
-  participation in InnerSource activities. Note that mediate will likely be
+  participation in InnerSource activities. Note that mediation will likely be
   successful only for a few companies with a culture condusive to that.
 
 ## Known Instances