Merge branch 'master' into pattern/introducing-metrics-in-innersource

30-day-warranty.md

@@ -4,13 +4,13 @@
 
 # Context
 
-Teams depends 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, inclination to write the contributed component.
+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
 
-A team developing a component which is used throughout an organization is resisting to accept or rejects contributions (feature requests) and as a result blocks progress or is disrupted by frequent escalations.
+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
 
@@ -77,4 +77,4 @@ Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
 # Variants
 
 - Ensure cooperation of dependent teams by making them a community by having
-  more than one, meritocratically appointed "Trusted Committers" (TCs) take responsibility.
+  more than one, meritocratically appointed "[Trusted Committers](https://github.com/paypal/InnerSourcePatterns/blob/master/project-roles/trusted-committer.md)" (TCs) take responsibility.

CONTRIBUTING.md

@@ -46,6 +46,12 @@ If you are asked to 'Commit directly...' vs 'Create a new branch...'
 * Only [Trusted Collaborators](/meta/trusted-collaborators.md) (TC's) are asked this; we are adding most contributors as TC's.
 
 
+## Other Tips For Submissions
+
+* Place each sentence on a new line.
+_GitHub_ allows leaving comments on a line-by-line basis.
+Review and comment on the content of submitted text is much easier if there are multiple lines on-which to leave comments.
+Sentences on consecutive lines will be collapsed into a single paragraph (like this one) for the final reader of the content.
 
 # B. Discussing Early Ideas in Issues
 

README.md

@@ -11,30 +11,34 @@ The below lists all known patterns. They are grouped into four stages of maturit
 * [Common Requirements](https://github.com/paypal/InnerSourcePatterns/blob/master/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](https://github.com/paypal/InnerSourcePatterns/blob/master/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](https://github.com/paypal/InnerSourcePatterns/blob/master/dedicated-community-leader.md) - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.*
+* [Praise Participants](https://github.com/paypal/InnerSourcePatterns/blob/master/praise-participants.md) - *Thank contributors effectively to engender further engagement from them and to encourage others to contribute*
 * [Review Committee](https://github.com/paypal/InnerSourcePatterns/blob/master/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](https://github.com/paypal/InnerSourcePatterns/blob/master/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.*
 
 #### Reviewed Pattern Ideas (not yet proven but reviewed)
 
 * [Modular Code](https://github.com/paypal/InnerSourcePatterns/blob/master/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.*
-* [Poor Naming Conventions](https://github.com/paypal/InnerSourcePatterns/blob/master/poor-naming-conventions.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.*
+* [Improve Findability](https://github.com/paypal/InnerSourcePatterns/blob/master/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)
 
 * [Assisted Compliance](https://github.com/paypal/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
+* [Cross-Team Project Valuation](https://github.com/paypal/InnerSourcePatterns/blob/master/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.*
 * [Reluctance to Receive Contributions](https://docs.google.com/document/d/13QDN-BpE_BixRFVGjao32n4Ctim0ROXAHbBWMBOijb4/edit) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them.*
 * [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
 * [Overcome Acquisition Based Silos - Developers](https://github.com/paypal/InnerSourceCommons/wiki/Overcome-Acquisition-based-Silos)
 * [Overcome Acquisition Based Silos - Managers](https://github.com/paypal/InnerSourceCommons/wiki/Overcome-Acquisition-based-Silos)
-* [Open Source Trumps InnerSource](https://github.com/paypal/InnerSourcePatterns/pull/46)
-* [Overcoming Project Management Time Pressures](https://github.com/paypal/InnerSourcePatterns/pull/47)
-* [Start as Experiment](https://github.com/paypal/InnerSourcePatterns/pull/66) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.*
+* [Open Source Trumps InnerSource](https://github.com/paypal/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
+* [Overcoming Project Management Time Pressures](https://github.com/paypal/InnerSourcePatterns/pull/47) - *Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.*
+* [Start as Experiment](https://github.com/paypal/InnerSourcePatterns/blob/master/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/paypal/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)
 
 * [Don't Bother Looking](https://github.com/paypal/InnerSourcePatterns/pull/60)
 * [Junkyard Styled Inner Sourcing](https://github.com/paypal/InnerSourcePatterns/pull/61)
-* [Different Repo For Shared Code Than the Product Org Uses In Its Build](https://github.com/paypal/InnerSourceCommons/wiki/Different-repo-for-shared-code-than-the-product-org-uses-in-its-build)
+* [Shared Code Repo Different from Build Repo](https://github.com/paypal/InnerSourceCommons/wiki/Shared-Code-Repo-Different-from-Build-Repo) - *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](https://github.com/paypal/InnerSourceCommons/wiki/Donut:-Creating-Developer-Incentive-Alignment-for-InnerSource-Contribution)
 * [Change the Developers Mindset](https://github.com/paypal/InnerSourceCommons/wiki/Pattern:-change-the-developers-mindset)
 * [Share Your Code to Get More Done - Likely Contributors Variant](https://github.com/paypal/InnerSourceCommons/wiki/Pattern:-Share-Your-Code-to-Get-More-Done---Likely-Contributors-Variant)
@@ -55,8 +59,8 @@ Patterns are a way of describing a repeatable, proven solution to a problem with
 
 * [`What are patterns?` Youtube videos](http://bit.ly/innersource_patterns_videos) - Watch a set of 2-5 min youtube videos explaining Inner Source 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).
-* [Detailed Pattern Background and Examples](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) (PDF) -  Get a detailed understanding of why and how to interact with our patterns during this presentation from Tim Yao and Padma Sudarsan from the ISC Fall Summit in 2016.
 * [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_9iQb93uBQWmYwMFpyaGh4OFU) - *Tim Yao and Padma Sudarsan* (PDF). Detailed pattern background and examples -- Get a detailed understanding of why and how to interact with our patterns.
 
 
 # How can you use Inner Source Patterns?

contracted-contributor.md

@@ -36,7 +36,7 @@ hours, not during free time.
 Without support by middle management, the total number of contributors and, as
 a result, the amount of contributions made and value generated by the
 InnerSource initiative will likely fall below expectation of top level
-management. This will likely be ampflified if there is no adequate funding for
+management. This will likely be amplified if there is no adequate funding for
 and empowerment of [Dedicated Community Leaders](dedicated-community-leader.md).
 This runs the risk of top level management abandoning the InnerSource idea.
 
@@ -68,7 +68,7 @@ This runs the risk of top level management abandoning the InnerSource idea.
 
 ## Solution
 
-Set up a formal contracting between the contributor, her line manager and a
+Set up a formal contracting between the contributor, their line manager and a
 centrally funded and steered InnerSource governance office (ISGO). Have the
 ISGO reimburse business units who contracted contributors for the contracted
 time. 
@@ -111,7 +111,7 @@ empowering middle management to sign off on it:
 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 status.
+  eventually achieve [Trusted Committer](https://github.com/paypal/InnerSourcePatterns/blob/master/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
   successful only for a few companies with a culture condusive to that.

crossteam-project-valuation.md

@@ -0,0 +1,9 @@
+# Title
+
+Cross Team Valuation
+
+# Patlet
+
+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.
+
+**This pattern is currently [under development in a Pull Request](https://github.com/paypal/InnerSourcePatterns/pull/87)**

dedicated-community-leader.md

@@ -15,7 +15,7 @@ Selecting the wrong persons and/or not providing enough capacity for them risks
 
 ## Story
 
-Consider the following story. A company wants to start an InnerSource initiative in order to foster collaboration across organizational boundaries. They have decided to start with an experimental phase with limited scope. Management has selected a suitable pilot topic for the first InnerSource community and expects contributions from many business units across the organization. The company has nominated a new hire to head the community for 50 % of his work time, because he was not yet 100 % planned for. After 6 months, the community has received only a few contributions, most of which are from a single business unit. The company replaces the community leader with someone who has a longer history in the company, this time for only 30 % of his time. After another 6 months, the number of contributions has picked up only  marginally. The company is no longer convinced that InnerSource helps to achieve their goal of increased, cross divisional collaboration and abandons InnerSource. 
+Consider the following story. A company wants to start an InnerSource initiative in order to foster collaboration across organizational boundaries. They have decided to start with an experimental phase with limited scope. Management has selected a suitable pilot topic for the first InnerSource community and expects contributions from many business units across the organization. The company has nominated a new hire to head the community for 50 % of his work time, because he was not yet 100 % planned for. After 6 months, the community has received only a few contributions, most of which are from a single business unit. The company replaces the community leader with someone who has a longer history in the company, this time for only 30 % of his time. After another 6 months, the number of contributions has picked up only marginally. The company is no longer convinced that InnerSource helps to achieve their goal of increased, cross divisional collaboration and abandons InnerSource. 
 
 ## Context
 
@@ -31,8 +31,7 @@ If a company does not significantly invest in the initial InnerSource community
 
 The value contribution of InnerSource projects will not be obvious for many managers which are steeped in traditional project management methods. Those managers are less likely to assign one of their top people, who are usually in high demand by non InnerSource-projects, to an InnerSource project for a significant percentage of their work time.
 
-Communication takes up a significant percentage of a community managers daily work. At the same time, he or she will likely also have to spearhead the initial development, too. In the face of limited capacity, inexperienced leaders will tend to focus on development and neglect communication. The barrier for potential contributors to make their first contribution and to commit to the community will be much higher if the community leader is hard to reach or is slow to respond to feedback and questions for lack of time. Furthermore, technically inexperienced leaders will most likely have a harder time to attract and retain highly experienced contributors than a top performer with a high degree of visibility within a company would have. 
-r
+Communication takes up a significant percentage of a community managers daily work. At the same time, he or she will likely also have to spearhead the initial development, too. In the face of limited capacity, inexperienced leaders will tend to focus on development and neglect communication. The barrier for potential contributors to make their first contribution and to commit to the community will be much higher if the community leader is hard to reach or is slow to respond to feedback and questions for lack of time. Furthermore, technically inexperienced leaders will most likely have a harder time to attract and retain highly experienced contributors than a top performer with a high degree of visibility within a company would have.
 
 If a community can not grow fast enough and pick up enough speed, chances are they won't be able to convincingly demonstrate the potential of InnerSource.
 

discover-your-innersource.md

@@ -55,7 +55,7 @@ Make it easy to find the reusable code.
 * Developers are now looking internally for software components
 * Search results are combined (internal and external)
 * Process changes, establishing a common communications channel, and encouraging and rewarding owners of reusable code to use the same search engine can contribute to changing the corporate culture. Transformation begins from the grassroots but requires strategic involvement of thought leaders. 
-* See [Improved Findability](https://github.com/paypal/InnerSourcePatterns/blob/master/poor-naming-conventions.md) (aka Poor Naming Conventions or Badly Named Piles) as a related pattern.
+* See [Improved Findability](https://github.com/paypal/InnerSourcePatterns/blob/master/improve-findability.md) (aka Poor Naming Conventions or Badly Named Piles) as a related pattern.
 
 ## Status
 Brainstormed pattern idea in progress
@@ -67,4 +67,4 @@ Brainstormed pattern idea in progress
 * Tim Yao
 
 ## Acknowledgements
-* Contributions from Russ Ruttledge, Ofer Hermoni and Robert Hanmer
+* Contributions from Russ Rutledge, Ofer Hermoni and Robert Hanmer

introducing-metrics-in-innersource.md

@@ -2,6 +2,12 @@
 
 Introducing Metrics in InnerSource
 
+# Patlet
+
+Involve all stakeholders in designing and interpreting metrics to measure the
+current status in terms of _health_ and performance of the InnerSource 
+initiative.
+
 # Context
 
 An organization is planning to apply or this is in the early stages of applying InnerSource. This would like to measure the current status in terms of 'health' and performance of the initiative, and if the expected outcomes such as an increase in the level of cross-divisional and cross-location collaboration are actually taking place.
@@ -119,3 +125,4 @@ evolves and help them with their daily work.
 # State
 
 Early Idea
+

meta/FAQ.md

@@ -6,3 +6,9 @@ This is a list of frequently asked questions about InnerSource Patterns
 ## Why use a patterns approach to InnerSource?
 * It abstracts information from known instances of proven solutions so that other people/companies can understand not only what was done by why it worked and how to adapt it to their own situations.
 
+## How do you use the pattern?
+* Each organization has its own history (*context*) and culture (a source of *forces*) and even goals, so using a pattern to solve their problems will generally require adaptation of that pattern. Try to identify things about your situation that are unique and apply those as makes sense to the *Context* and *Forces* identified in the pattern. See if these additional constraints might require changes to the *Solution* to ensure that the pattern will work.
+* Patterns can also be used as a short-hand when discussing InnerSource programs across organizational boundaries.
+
+## I'd like to consult with the IS Patterns community; do I need to have participating members sign NDAs?
+* You could do that, but be aware that the vast majority of IS Patterns meetings are held under the [Chatham House Rule](https://www.chathamhouse.org/chatham-house-rule) that should provide sufficient protection to enable a productive discussion.