30 Day Warranty

30-day-warranty.md

@@ -0,0 +1,79 @@
+# Title
+
+30 Day Warranty
+
+# 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.
+
+- 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.
+
+# Forces
+
+- There is distrust of contributions due to a past history of cheating: teams
+  submitted half finished contributions and subsequently filed requests for 
+  fixes that make it ready for use in production.
+- 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.
+- 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.
+- Receiving teams may fear that teaching others how to contribute code will 
+  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.
+- Either team may not feel confident in measuring risks or certifying that 
+  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 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.
+
+
+# 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
+
+This was tried and proven successful at PayPal.
+
+# Authors
+
+- Cedric Williams
+
+# Acknowledgement
+
+- Dirk-Willem van Gulik
+- Padma Sudarsan
+- Klaas-Jan Stol
+- Georg Grütter
+
+# State
+
+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.