Fixing linebreaks in 30 Day Warranty pattern, so that the lists get displayed correctly in the book (#300)

Author: spier

patterns/2-structured/30-day-warranty.md

@@ -18,29 +18,16 @@ Teams depend on another team accepting their contributions so that a component p
 
 ## 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).
+- 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
 
@@ -54,8 +41,7 @@ Note that the warranty period could be 45, 60, or 100 days too. The duration may
 
 ## Resulting Context
 
-- The receiving team is willing to accept contributions and able to share the
-  workload of initial adaptations/fixes.
+- 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.
 
@@ -81,5 +67,4 @@ This was tried and proven successful at PayPal.
 
 ## Variants
 
-- Ensure cooperation of dependent teams by making them a community by having
-  more than one, meritocratically appointed "[Trusted Committers](./trusted-committer.md)" (TCs) take responsibility.
+- Ensure cooperation of dependent teams by making them a community by having more than one, meritocratically appointed "[Trusted Committers](./trusted-committer.md)" (TCs) take responsibility.