Merge branch 'master' into rrrutledge-patch-3

Author: rrrutledge

30-day-warranty.md

@@ -10,7 +10,7 @@ Teams depends on another team accepting their contributions so that a component
 
 # 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
 

README.md

@@ -12,6 +12,8 @@ The below lists all known patterns. They are grouped into four stages of maturit
 * [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.*
 * [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)
 
@@ -25,9 +27,9 @@ The below lists all known patterns. They are grouped into four stages of maturit
 * [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)
+* [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)
-* [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.*
+* [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)

dedicated-community-leader.md

@@ -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

@@ -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

@@ -0,0 +1,16 @@
+**Note: This pattern is currently under development in [this Pull
+Request](https://github.com/paypal/InnerSourcePatterns/pull/83)**
+
+## Title
+
+Introducing Metrics in the InnerSource Initiative
+
+## Patlet
+
+Involve all stakeholders in designing and interpreting metrics to measure the
+current status in terms of _health_ and performance of the InnerSource 
+initiative.
+
+
+
+

meta/pattern-template.md

@@ -2,7 +2,7 @@
 Short Title Here
 
 ## Patlet
-Concise 1-2 sentance description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet
+Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet
 
 ## Problem
 What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentances, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.

praise-participants.md

@@ -0,0 +1,64 @@
+## Title
+Praise Participants
+
+## Patlet
+After an inner source contribution, it's important to thank the contributor for their time and effort.
+This pattern gives guidance that not only effectively acknowledges the contribution but also endgenders further engagement from the contributor and others.
+
+## Problem
+How can we properly express our gratitude to a contributor for their inner source contribution to a project?
+It can be easy to forget to do so or not know the words or medium to use for adequate effect and sincerity.
+Praise and thanks are easy, affordable ways to keep contributors and their managers motivated and excited to continue.
+A pattern in this area makes it easy to do and ensures that the message comes across clearly and sincerely.
+
+## Context
+* You are the trusted committer or maintainer on an inner source project.
+* You value the community of contributors and want to maintain and grow it.
+
+## Forces
+* You are busy, which makes it easy to forget some of the soft touches like praise and thanks.
+* You may not be someone that is comfortable in social situations or good with words.
+* Peer recognition is very important to job satisfaction and career development.
+
+## Solutions
+It feels good to anyone to be recognized by others.
+In a professional setting, increased recognition is also an avenue to increased influence and growth.
+Any time someone gives to your inner source project, recognize them with a sincere and qualified "thank you".
+
+For non-trivial contributions (all code contributions and also significant time contributions), say thank you via the following mechanisms:
+
+1. Call out the person by name in any chat location (e.g. _Slack_) where you organize your project activity.  Let everyone know what they did and thank them publicly.  Example:
+
+> Everyone @here give a high-five to @andrew.clegg for updating the _rcs-viewer_ to the latest version of the _hebo-client_ (https://github.com/rcs/rcs-viewer/pull/81).
+Thanks for helping keep this library up-to-date, Andy!
+
+2. Send an email to them and their manager (cc'd) privately thanking them for the contribution.
+For code contributions often-times you can just forward the merge notification mail.  Example:
+
+> Hi, Andy, I want to thank you again for making this update.
+It may have been a small amount of time, but it's attention like this from each person that make the RCS project work for all of us.
+Thanks for solving your own problem in a way that also makes the _rcs-viewer_ better for everyone.
+
+## Resulting Context
+Feedback like this leaves the contributor with a fantastic feeling and ready to come back for more.
+Combining **both** forms of thanks gives them recognition in front of their peers (breadth) and in front of their direct manager (depth).
+There's a subtle encouragement for those peers in chat to consider contributing themselves and for that manager to look for appropriate circumstances to encourage their other direct reports to do the same.
+Additionally, awareness of the inner source project spreads to the manager, who may have previously not known of the team's use and involvement with it.
+
+One caveat - keep it real.
+Make sure that your words stem from the sincere thanks that you feel inside for what they've done.
+Keep the level and verbosity of praise appropriate to their level of involvement.
+Overdoing it may feel insincere and mechanical and defeat your purpose in reaching out.
+
+## Known instances
+
+* Nike (multiple projects)
+
+## Author(s)
+
+* Russ Rutledge
+
+## Acknowledgements
+
+* [Todd Lisonbee](https://github.com/tlisonbee) for encouraging to "keep it real".
+* [Isabel Drost-Fromm](https://github.com/MaineC) for [this extra explanation](https://youtu.be/h3MPewsk5PU?t=357) of a "qualified" thank you.

service-vs-library.md

@@ -0,0 +1,87 @@
+## Title
+Service vs. library: It's inner source, not inner deployment
+
+## Patlet
+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.
+
+## Problem
+
+When teams are working in a DevOps environment developers are responsible for a
+feature end-to-end: From the customer down to deployment, maintenance and
+support. This poses a challenge when working across team boundaries: Escalation
+chains may not be the same for errors happening in either team. Coupling
+source code and deployment leaves the teams with the question of who is
+responsible for on-call support in the event of errors. As a result teams are
+reluctant to join forces even if there is significant overlap in requirements.
+
+## Context
+
+Teams are working in a micro-services environment.
+
+They are organised in full functional DevOps teams: Each team is responsible for
+their contributions end-to-end, including maintenance, on-call and customer
+support.
+
+A team is tasked with providing a service to their downstream customers that is
+fairly similar to an existing service built by another team.
+
+## Forces
+
+Organisational escalation paths may be different for each of the teams.
+
+Members of each team may be unwilling to answer on-call support for errors that
+do not affect their own downstream customers.
+
+Severity levels for the same types of errors may be different across team
+boundaries due to different SLA definitions per team/customer relationship.
+
+## Solutions
+
+Decouple responsibility for source code from deployment: Both teams work to
+identify exactly where there is overlap and synergies.
+
+Only shared source code is kept as part of the InnerSource project with shared
+responsiblity.
+
+Decouple configuration and deployment pipelines from actual business logic.
+Establish a second deployment of the service for the second team.
+
+Treat the common base as a library that is used by both teams with shared code
+ownership.
+
+## Resulting Context
+
+Teams are willing to collaborate, benefitting from sharing the work of
+implementing the business logic.
+
+A service that originally was built specifically to work in one environment is
+converted into a more general solution based on a specific business requirement.
+
+Both teams get to know their respective escalation policy and deployment setup,
+potentially identifying improvements for their own setup.
+
+The likelihood that changes are needed and made in the shared source code
+increases, leading to more frequent oportunities to refine, improve and optimise
+the implementation.
+
+## See also
+
+Related to this pattern is the [Thirty day warrenty](https://github.com/paypal/InnerSourcePatterns/blob/master/30-day-warranty.md) pattern that takes a different approach to solving the forces described above.
+
+## Known instances
+
+Europace AG
+
+## Author(s)
+
+Isabel Drost-Fromm
+
+## Acknowledgements
+
+Thank you Tobias Gesellchen for review internal to Europace AG.
+

start-as-experiment.md

@@ -0,0 +1,117 @@
+# Title
+
+Start as an Experiment
+
+# Patlet
+
+Start your InnerSource initiative as a time limited experiment to make it 
+easier for managers unfamiliar with InnerSource to endorse and support the 
+initiative.
+
+# Problem
+
+An InnerSource initiative is considered but not started because management is 
+unsure about its outcome and, as a result, is not willing to commit to an 
+investment.
+
+# Context
+
+The company is considering to leverage InnerSource to increase the efficiency
+of collaboration on software projects. However, most managers are not familiar
+with the Open Source working model and are instead accustomed to hierarchical,
+top-down control style management. The idea of InnerSource is very popular with
+software developers in the company, not the least because many developers use
+or are actively developing Open Source software.
+
+# Forces
+
+- Managers will want to validate the claims of improved collaboration through
+  InnerSource before making a long term investment. This usually involves
+  measuring the improvements.
+- If the InnerSource initiative will likely have a huge uptake among developers
+  and if many projects are likely to rely on it, a decision to shut it down
+  will be very unpopular and therefore hard to make. The perceived resulting
+  loss of control might deter some managers to even start with InnerSource.
+- Implementing InnerSource style working models are often a radically departure
+  from previously practiced working models. It is therefore likely, that
+  existing, mandatory processes are no longer applicable and that appropriate
+  governing processes are missing. The result might be that one has to operate
+  in a regulatory, sometimes legal no-mans land. Examples are tax and export
+  control related regulations in large corporations with multiple legal
+  entities in multiple countries.
+
+# Solution
+
+Declare the InnerSource initiative as a time limited experiment. Define and
+communicate the criteria for projects to join the InnerSource experiment. The
+criteria should be chosen such that they maximize the chances of building a 
+healthy InnerSource community around the selected InnerSource projects. They
+should also help to ensure that the setting of the projects is such that they 
+can later be used to gain externally valid insights into the effects of 
+applying InnerSource. Examples for such criteria are
+
+- Sufficient geographical distribution of developers
+- Sufficient departmental mix of developers,
+- Openness of communication within community,
+- Career path based on merit within community,
+- Democratic decision making within community.
+
+Consider designating the end of the experiment a _pivot_, _change_ or _pause_
+point to re-evaluate. Also consider establishing a [Review
+Committee](review-committee.md) to increase the chances of management buy-in
+through participation. Depending on company culture, it might be helpful to
+accompany the experiment with appropriate metrics [First Steps With
+Metrics](introducing-metrics-in-innersource.md). If the projects in the
+experiment don't provide a direct impact on the companies revenue, consider
+introducing [Cross Team Valuation](crossteam-project-valuation.md) to highlight
+their value contributions.
+
+# Resulting Context
+
+Managers are able to kick start InnerSource for the following reasons:
+
+- The experimental setup eases the need of managers to scrutinize the
+  InnerSource program numbers in the same way that they would for typical
+  projects.
+- The possibility of failure of the experiment is understood and accepted. The
+  personal risk for the supporting managers is minimized.
+- Even in case of a failure, the setup ensures that the company will learn from
+  the experiment.
+- In case of success, the data gathered during the experiment will allow
+  managers to make a longer lasting commitment to InnerSource. 
+
+Participants in the InnerSource experiment are now conscious of the fact that
+they have to prove to management that InnerSource yields the promised benefits.
+It will therefore help to focus work on those activites which provide the most
+demonstrable value thus increasing the chances of success.
+
+Finally, starting as an experiment makes it much easier to sidestep regulations
+and forces such as tool and process policies which could decrease the chances
+of success.
+
+# Related Patterns
+
+- _Trial Run_ (from the book [_Fearless
+  Change_](http://www.fearlesschangepatterns.com/))
+
+# Known Instances
+
+- Robert Bosch GmbH (globally distributed software development)
+
+# Author
+
+- Georg Grütter (Robert Bosch GmbH)
+
+# Status
+
+Proven Pattern
+
+# Acknowledgements
+
+- Jason Zink (Robert Bosch GmbH)
+- Diogo Fregonese (Robert Bosch GmbH)
+- Robert Hansel (Robert Bosch GmbH)
+- Hans Malte Kern (Robert Bosch GmbH)
+- Russ Rutledge (Nike)
+- Tim Yao (Nokia)
+- Clint Cain (Optum)