Create Not-invented-here 2.md

ISC Fall Summit 2017 discussion

Author: ErinMB

Not-invented-here 2.md

@@ -0,0 +1,63 @@
+## Title  
+- Not Invented Here (v2) Note: will review & merge
+
+## Problem
+Team or community is resistant to accept contributions from external contributors.
+Note: Split this based on use case: org-wide dysfunction vs team-level
+
+## Story (Optional)
+Sometimes there is a story that helps people understand the pattern better.
+
+## Context
+- There is focus on intra-team cohesion and collaboration as opposed to cross-team collaboration
+- You can't predict where the next contrib is coming from (might be a force?)
+- Historical culture of silos, lack of cross-domain collaboration 
+- Acknowledge that no matter what you do, some won't read contrib files
+- Acknowledge that no matter what you do, conflicting business goals/measures may result in dis-incentive to engage
+- Individuals fear being made replaceable
+- Your contribution extends the usability of my widget, but I'm not allocated to support it/I fear change - fear of increased support load
+- Fear of increased support load in general
+
+## Forces
+- Teams tightly control their processes/engagement models
+- Contributing teams do not read contrib.md or prepare ("fling it over the wall")
+- Conflicting business goals/individual performance measures may result in groups or individuals being dis-incented to engage
+- Fear of diluting your perceived value
+- Teams are more comfortable being held accountable for their own work - hesitant to take on unknown risk- ex: will i break my own product if I accept this? will I break stuff on a wider scale?
+- Teams are hesitant to reuse/consume others' code
+- Perceived value of accepting contributions that have narrow impact 
+
+## Sketch (optional)
+visual illustration
+
+## Solutions
+- Provide template to use for code submission requirements. (Must include testing. Many companies have built-in, automated testing. Documented communication) For both host and contributors. Requires/assumes compliance.
+- Mentorship (requirements can be informed via tracking above results)
+- Talking is good /relationship building
+- Finding incentives to drive IS behavior (incentives and measures can vary at a team level)
+- Shift to a "profoundly found elsewhere" culture
+- Demonstrate organizational interest in outside opinions
+- Identify influencers who agree to be early adopters - set the stage for others
+- Contributability is a mark of quality
+
+## Resulting Context
+What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.
+
+## Rationale (optional)
+Explains why this is the right solution; using totally different words WHY this solution balances these force and this context to solve this problem. Can expand on what-if's or theories.
+
+## Known instances (optional)
+Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context
+
+May mention:
+* A particular business
+* Anonymyzed instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...". 
+
+## Status (optional until merging)
+General pattern status is stored in githubs Label tagging - see any pull request. Note that this github label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful. You might store other related info here info, such as review history: "Three of us reviewed this on 2/5/17 and it needs Johns expertise before it can go further"
+
+## Author(s)
+Often, this is yourself; If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To); Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution)
+
+## Acknowledgements
+Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.