Updated and sync'd with PLoP 2017 paper.

NewMexicoKid · web-flow · commit 8184cf4a2a99 · 2017-08-29T15:10:17.000-05:00
Updated this pattern to match revised pattern in the PLoP 2017 paper on InnerSource Patterns, meeting reviewer comments.
diff --git a/30-day-warranty.md b/30-day-warranty.md
@@ -2,20 +2,15 @@
 
 30 Day Warranty
 
-# Problem
+# Context
 
-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.
+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.
 
 - TBD: link to pattern "setting clear expectations for contributing code"
 
-# Context
+# Problem
 
-Teams depends on other teams to add functionality to a component
-they depend on so that they can deliver features in their own components. The
-requiring team does not have the resources, knowledge, permission, or inclination 
-to write the contributed component.
+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.
 
 # Forces
 
@@ -25,43 +20,43 @@ to write the contributed component.
 - If code is contributed from outside the team, the team has the natural 
   suspicion that the other team does not know how to write code that would
   meet the teams expectations.
-- Direction of loyalty: ?
+- Each team looks first to help its own leaders achieve their own goals. This direction 
+  of loyalty can complicate resolution of this problem.
 - There is a natural aversion to taking responsibility for code not written
   by oneself.
 - Contributed needs to be heavily rewritten before being accepted into the
   codebase.
 - There is the fear of the contributors not being available for support with
   fixing bugs after the time on contribution.
 - Teams fear contributed code will lead to high(er) maintenance costs but do 
-  not know how to control for that
+  not know how to control for that.
 - Receiving teams may fear that teaching others how to contribute code will 
-  expose technical debt in their system and that visibility may be damaging
+  expose technical debt in their system and that visibility may be damaging.
 - Receiving teams may not believe that they will get acceptable code no 
-  matter how much mentoring they provide
+  matter how much mentoring they provide.
 - Either team may not feel confident in measuring risks or certifying that 
-  they are mitigated in a contribution
+  they are mitigated in a contribution; the system itself is somewhat brittle 
+  (may not be ways to fully test and catch all problems).
 
 # Solution
 
-Address the fears of both the receiving and the contributing teams by 
-establishing a warranty period, generally 30 days starting when the contributed code
-goes into production. During this time the contributing team commits to provide
-bug fixes and/or staff support to the receiving team for issues around their contribution.
+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.
+
+Provide clear contribution guidelines spelling out the expectations of the receiving team and the contributing team.
+
+Note that the warranty period could be 45, 60, or 100 days too. The duration may vary based upon the constraints of the project, the software life cycle of the project, commitments to customers, and other factors.
 
-- Clear contribution guidelines establish expectations and agreements before
-   work starts
-- Warranty periods may vary depending on the risk levels involved
 
 # 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
+- 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
 
-PayPal
+This was tried and proven successful at PayPal.
 
 # Authors
 
@@ -76,9 +71,9 @@ PayPal
 
 # State
 
-- Draft (2017 Spring InnerSource Summit)
+Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
 
 # Variants
 
-- (Dirk) Ensure cooperation of dependent teams by making them a community by having
-  more than one, meritocratically appointed TCs take responsibility.
+- Ensure cooperation of dependent teams by making them a community by having
+  more than one, meritocratically appointed "Trusted Committers" (TCs) take responsibility.
