From fccf84cdb9ff1e36710a8fe66b2d2a990b6a6650 Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Wed, 19 Apr 2017 16:51:26 +0200 Subject: [PATCH 1/4] =?UTF-8?q?added=20draft=20pattern=20=E2=80=9C30=20day?= =?UTF-8?q?=20warranty=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 30-day-warranty.md | 82 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 30-day-warranty.md diff --git a/30-day-warranty.md b/30-day-warranty.md new file mode 100644 index 000000000..095a26f43 --- /dev/null +++ b/30-day-warranty.md @@ -0,0 +1,82 @@ +# Title + +30 Day Warranty + +# 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. + +- TBD: link to pattern "setting clear expectations for contributing code" + +- Team is scared of but in control (compensation) +- contributed code had to be heavily rewritten +- contributors might not be available after contribution for modifications/bugfixes + +# 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. + +# 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 + suspicition that the other team does not know how to write code that would + meet the teams expectations. +- Direction of loyalty: ? +- 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. + +# Solution + +Address the fears of both the receiving and the contributing teams by +establishing a 30 day period starting the with time the contributed code +goes into production, during which the contributing team consents to provide +bug fixes to the receiving team. + +a) clear contribution guidelines spelling out the expectations of the receiving + team and + +- as a contributor, you have to certify that the code meets defined + expectations (e. g. bugs can be fixed) +- create run books and desaster scenarios, warranty applies after desaster + scenario has been test. + +# 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 to heavyweight + +# Known Instances + +PayPal + +# Authors + +- Cedric Williams + +# Acknowledgement + +- Dirk +- Padma Sudarsan +- Klaas-Jan Stol +- Georg Grütter + +# State + +- Draft (2017 Spring InnerSource Summit) + +# Variants + +- (Dirk) Ensure cooperation of dependent teams by making them a community by having + more than one, meritocratically appointed TCs take responsibility. From a5ecdc2484030aaf76943f779a83d8eadc202d8b Mon Sep 17 00:00:00 2001 From: Georg Gruetter Date: Wed, 19 Apr 2017 17:00:11 +0200 Subject: [PATCH 2/4] - added missing force --- 30-day-warranty.md | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/30-day-warranty.md b/30-day-warranty.md index 095a26f43..3ad2b7633 100644 --- a/30-day-warranty.md +++ b/30-day-warranty.md @@ -10,10 +10,6 @@ blocks progress or is disrupted by frequent escalations. - TBD: link to pattern "setting clear expectations for contributing code" -- Team is scared of but in control (compensation) -- contributed code had to be heavily rewritten -- contributors might not be available after contribution for modifications/bugfixes - # Context Teams depends on another team accepting their contributions so that a component @@ -34,6 +30,8 @@ to write the contributed component. 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. # Solution @@ -45,11 +43,6 @@ bug fixes to the receiving team. a) clear contribution guidelines spelling out the expectations of the receiving team and -- as a contributor, you have to certify that the code meets defined - expectations (e. g. bugs can be fixed) -- create run books and desaster scenarios, warranty applies after desaster - scenario has been test. - # Resulting Context - the receiving team is willing to accept contributions and able to share the From 984e8ab100c910d97b522ed4e5f4c11364a885de Mon Sep 17 00:00:00 2001 From: cewilliams Date: Tue, 9 May 2017 16:55:39 -0500 Subject: [PATCH 3/4] Update 30-day-warranty.md --- 30-day-warranty.md | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/30-day-warranty.md b/30-day-warranty.md index 3ad2b7633..2f282f233 100644 --- a/30-day-warranty.md +++ b/30-day-warranty.md @@ -12,9 +12,9 @@ blocks progress or is disrupted by frequent escalations. # 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 +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. # Forces @@ -23,7 +23,7 @@ to write the contributed component. 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 - suspicition that the other team does not know how to write code that would + suspicion that the other team does not know how to write code that would meet the teams expectations. - Direction of loyalty: ? - There is a natural aversion to taking responsibility for code not written @@ -32,23 +32,32 @@ to write the contributed component. 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 # Solution Address the fears of both the receiving and the contributing teams by -establishing a 30 day period starting the with time the contributed code -goes into production, during which the contributing team consents to provide -bug fixes to the receiving team. +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. -a) clear contribution guidelines spelling out the expectations of the receiving - team and +- 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 to heavyweight +- keeps escalations from becoming too heavyweight # Known Instances @@ -60,7 +69,7 @@ PayPal # Acknowledgement -- Dirk +- Dirk-Willem van Gulik - Padma Sudarsan - Klaas-Jan Stol - Georg Grütter From 8184cf4a2a9950ed64c1c7c6ea9587a80672ac54 Mon Sep 17 00:00:00 2001 From: Tim Yao Date: Tue, 29 Aug 2017 15:10:17 -0500 Subject: [PATCH 4/4] Updated and sync'd with PLoP 2017 paper. Updated this pattern to match revised pattern in the PLoP 2017 paper on InnerSource Patterns, meeting reviewer comments. --- 30-day-warranty.md | 53 +++++++++++++++++++++------------------------- 1 file changed, 24 insertions(+), 29 deletions(-) diff --git a/30-day-warranty.md b/30-day-warranty.md index 2f282f233..cfb0ed0d8 100644 --- 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,7 +20,8 @@ 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 @@ -33,35 +29,34 @@ to write the contributed component. - 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.