standardize alerts

content/Journey/_index.md

@@ -31,7 +31,7 @@ You may have some others on the list that as you start implementing will come in
 
 Every process we add needs to add value. There's obvious value in doing performance testing unless we are demanding performance at a level that isn't required for the use case. However, before we define CAB documentation as required for "deployable", why does that process exist? One common reason for that meeting is a compliance rule for "two sets of eyes on every change". However, that can be validated by automation without the need to bundle changes and wait for a meeting.
 
-{{%alert info%}}
+{{% alert %}}
 We wanted to investigate the impact of change approval processes on software delivery performance. Thus, we asked about four possible scenarios:
 
 - All production changes must be approved by an external body (such as a manager or CAB).
@@ -40,15 +40,15 @@ We wanted to investigate the impact of change approval processes on software del
 - We have no change approval process.
 
 The results were surprising. We found that approval only for high-risk changes was not correlated with software delivery performance. Teams that reported no approval process or used peer review achieved higher software delivery performance. Finally, teams that required approval by an external body achieved lower performance.
-{{%/alert%}}
+{{% /alert %}}
 
 Excerpt from *Accelerate* by Nicole Forsgren Ph.D., Jez Humble & Gene Kim
 
 ## Solving the Challenge of CI
 
 The first challenge for the team is [continuous integration](https://www.martinfowler.com/articles/continuousIntegration.html). CD requires CI and CI is very effective at uncovering most of the problems many teams have that impact quality. Martin Fowler has an [excellent blog post on introducing CI](https://www.martinfowler.com/articles/continuousIntegration.html#IntroducingContinuousIntegration) into the workflow. Over the years, we've seen many common problems that teams have.
 
-You may find more. Notice that tooling is rarely the problem. Always, "why can't we deliver working changes to the trunk today?", is the roadmap of problems to solve.  
+You may find more. Notice that tooling is rarely the problem. Always, "Why can't we deliver working changes to the trunk today?", is the roadmap of problems to solve.  
 
 ### Code review takes too long / has too many approvers
 
@@ -72,7 +72,7 @@ Teams are not good at testing initially for the same reason they aren't good at
 
 ### Individual tasks are too big
 
-CI means we are integrating partially completed features continuously. TDD helps us learn how to decompose tasks into very small, releasable changes that do not break existing behaviors. However, the initial habit is often to wait to integrate changes until they are "complete". This results in large change-sets that are more difficult to code review. This makes code review take more time, requires more re-work, and reduces the ability of the reviewer to spot problems. [Evolutionary coding methods](../minimumcd/ci/#recommended-practices) allows the release of incomplete features until they are ready and allow us to drive down the size of changes. By focusing as a team to decompose tasks into hours of work rather than days and using engineering techniques to control release, we have improved clarity, smaller change-sets, and higher quality.
+CI means we are integrating partially completed features continuously. TDD helps us learn how to decompose tasks into very small, releasable changes that do not break existing behaviors. However, the initial habit is often to wait to integrate changes until they are "complete". This results in large changesets that are more difficult to code review. This makes code review take more time, requires more re-work, and reduces the ability of the reviewer to spot problems. [Evolutionary [coding methods](/minimumcd/ci/#recommended-practices) allow the release of incomplete features until they are ready and allow us to drive down the size of changes. By focusing as a team to decompose tasks into hours of work rather than days and using engineering techniques to control release, we have improved clarity, smaller change-sets, and higher quality.
 
 ### Stories are too big & lack testable acceptance criteria
 

content/MinimumCD/TDB.md → content/MinimumCD/TBD/_index.md

@@ -7,9 +7,9 @@ type: docs
 
 {{%alert info%}}
 
-"Trunk-based development has been shown to be a predictor of high performance in software development and delivery. It is characterized by fewer than three active branches in a code repository; branches and forks having very short lifetimes (e.g., less than a day) before being merged into master; and application teams rarely or never having "code lock" periods when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases."
+"Trunk-based development has been shown to be a predictor of high performance in software development and delivery. It is characterized by fewer than three active branches in a code repository; branches and forks having very short lifetimes (e.g., less than a day) before being merged; and application teams rarely or never having "code lock" periods when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases."
 
-{{%/alert%}}
+{{% /alert %}}
 
 Excerpt from *Accelerate* by Nicole Forsgren Ph.D., Jez Humble & Gene Kim
 

content/Practices/SmallBatches/_index.md

@@ -21,7 +21,7 @@ This comes from a misunderstanding of what CD is for. Yes, we can deliver featur
 
 ### Commit Smaller Changes
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 "Following our principle of working in small batches and building quality in, high-performing teams keep branches short-lived (less than one day's work) and integrate them into trunk/master frequently. Each change triggers a build process that includes running unit tests. If any part of this process fails, developers fix it immediately."
 
 -- Accelerate: Forsgren, et al
@@ -37,7 +37,7 @@ How small is small? It's typical for teams who have only been taught Scrum to re
 
 In 2012, Paul Hammant, author of "Trunk-Based Development and Branch by Abstraction" made the following suggestion:
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 "Story sizes should average as close to one day as possible. If they don't, your Agile project is going to be harder for nearly everyone involved. If your average is significantly greater than that one day, then change something until you get there."
 
 -- [Call to Arms: Average Story Size of One Day](https://paulhammant.com/2012/04/24/call-to-arms-average-story-sizes-of-one-day/)

content/Translations/German/_index.md

@@ -5,7 +5,7 @@ weight: 3
 type: docs
 ---
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 
 "Kontinuierliche Lieferung vebessert die Geschwindigkeit und Qualität der Auslieferung, und hilft zugleich die Kultur zu verbessern, Burnout und Mühsal in der Entwicklung zu vermeiden."
 

content/Translations/Portuguese-BR/_index.md

@@ -8,7 +8,7 @@ type: docs
 
 ## Mínimo viável para a Entrega Contínua
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 
 "A entrega contínua não só melhora a qualidade e capacidade de entrega, bem como ajuda na evolução da cultura, reduz a estafa e as dificuldades na implantação."
 

content/Translations/Portuguese/_index.md

@@ -8,7 +8,7 @@ type: docs
 
 ## Mínimo viável para a Entrega Contínua
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 
 "A entrega contínua não só melhora a qualidade e capacidade de entrega, bem como ajuda na evolução da cultura, reduz o cansaço e as dores do desenvolvimento/release."
 

content/Translations/Sinhala/_index.md

@@ -8,7 +8,7 @@ type: docs
 
 ## අඛණ්ඩ බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීමට අවමයෙන් කලයුතු සහ කලහැකිදේ
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 
 "අඛණ්ඩ බෙදාහැරීමට හැකි මෘදුකාංග නිපදවීමේ ක්‍රියාවලිය මගින් මෘදුකාංග බෙදාහැරීමේ කාර්ය සාධනය සහ ගුණාත්මකභාවය යන දෙකම වැඩිදියුණු කරන අතර, එම නිපදවන පරිසරයේ අභිවර්ධනයක්ද ඇතිකරයි. තවද මේ බෙදාහැරීමේ කටයුතු සීග්‍ර වීමත් සමග එම කාර්ය කරන්නන් ධනාත්මක මානසිකත්වයෙන් පසුවේ."
 

content/Translations/Spanish/_index.md

@@ -7,7 +7,7 @@ type: docs
 
 ## Entrega Continua Mínima Viable
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 "La entrega continua mejora tanto el rendimiento como la calidad de la entrega, y también ayuda a mejorar la cultura y a reducir el agotamiento y el dolor del despliegue."
 
 -- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Traducción no oficial)

content/Translations/Texan/_index.md

@@ -6,7 +6,7 @@ type: docs
 ---
 
 
-{{% alert title="Tip" %}}
+{{% alert %}}
 "Continuous delivery improves both delivery performance and quality, and also helps improve culture and reduce burnout and deployment pain."
 
 -- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations