Merge pull request #2216 from betterscientificsoftware/curfman-patch-1

Update TechnicalDebtInPractice.md

CuratedContent/TechnicalDebtInPractice.md

@@ -22,7 +22,7 @@ A more general definition of software technical debt might be:
 
 While there are many free sources of information about software technical debt and how to address it ([for example](https://bssw.io/items/keep-interest-on-technical-debt-from-sinking-your-software-project)), arguably, none of them provide the type of cohesive, comprehensive, in-dept treatment on the topic provided by the book ***Technical Debt in Practice: How to Find It and Fix It***.
 
-### Categories and Common Sources of Technical Debt
+### Categories and common sources of technical debt
 
 This book covers the detection, quantification, and correction of technical debt in the following standard areas of software development (along with common sources of technical debt in each area):
 
@@ -55,7 +55,7 @@ This book covers the detection, quantification, and correction of technical debt
   * Documents outdated
   * Too much documentation
 
-In addition to these universal categories, it also covers more specialized types of technical debt:
+In addition to these universal categories, the book also covers more specialized types of technical debt:
 
 * **Technical debt in machine learning systems**:
   * Poor integration (with non-model components)
@@ -82,7 +82,7 @@ The authors also take on broader types of (non-technical) software project debt
   * Black cloud (Information overload due to lack of structured communication and info management)
   * Lone wolf (Renegade contributors that don't coordinate or collaborate with peers)
 
-### Technical Debt Principle and Interest Payments
+### Technical debt principle and interest payments
 
 The comparison of technical debt to financial debt and the concepts of debt ***principle*** and debt ***interest*** payments have been widely embraced in the software development community.
 The differentiation between the *principle* of paying down a given source of technical debt as opposed to the *interest* payment for not paying down that debt is critical.
@@ -95,7 +95,7 @@ The interest payment cost accumulates over time, so the length of time between w
 Even a smaller interest payment integrated over a long period of time can result in a huge cumulative cost to the project.
 --->
 
-### Insights and Guidance on the Management of Technical Debt
+### Insights and guidance on the management of technical debt
 
 Some of the more interesting (and non-obvious) arguments and insights the authors make about technical debt in this book include:
 
@@ -112,7 +112,7 @@ Some of the more interesting (and non-obvious) arguments and insights the author
 * Companies and **organizations that don't view software as a core asset tend to produce software with large amounts of unmanaged technical debt**.
 * Software projects that don't pay down significant and obvious technical debt **drive away good developers and result in lower-performing development teams** (which in turn create more unmanaged technical debt).
 
-### Software Engineering Best Practices and Technical Debt
+### Software engineering best practices and technical debt
 
 A lot of the material in this book espouses the virtues of modern agile software development technical practices and principles such as:
 
@@ -121,12 +121,12 @@ A lot of the material in this book espouses the virtues of modern agile software
 * [Test-driven development](https://en.wikipedia.org/wiki/Test-driven_development)
 * [Peer code review](https://bssw.io/items?topic=peer-code-review)
 * [Continuous integration](https://bssw.io/items?topic=continuous-integration-testing) and modern [DevOps](https://bssw.io/items/what-is-devops)
-* Usage of newer language features and tools (e.g. [modern C++20+ vs. C++98](https://bssw.io/items/c-core-guidelines), [static analyzers and linters](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#appendix-d-supporting-tools), [code formatters](https://bssw.io/blog_posts/coding-conventions), etc.)
+* Usage of newer language features and tools (e.g., [modern C++20+ vs. C++98](https://bssw.io/items/c-core-guidelines), [static analyzers and linters](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#appendix-d-supporting-tools), [code formatters](https://bssw.io/blog_posts/coding-conventions), etc.)
 
-and many others.  However, it places these agile technical practices within the consistent framework of technical debt avoidance, reduction, and management (thereby providing a solid connection to bottom-line software productivity and sustainability).
+and many others.  However, the book places these agile technical practices within the consistent framework of technical debt avoidance, reduction, and management (thereby providing a solid connection to bottom-line software productivity and sustainability).
 Therefore, this book could be used to introduce many of these modern software engineering practices and help motivate them better than is often done in other software engineering literature.
 
-### Technical Debt Case Studies
+### Technical debt case studies
 
 The book is filled with many case studies in the application of technical debt analysis, quantification, and reduction efforts.
 Examples of some of the more interesting case studies include:

CuratedContent/diataxis.md

@@ -1,7 +1,7 @@
-## Diátaxis: A systematic approach to technical documentation authoring.
+## Diátaxis: A Systematic Approach to Technical Documentation Authoring
 
 <!--- deck text start --->
-Diátaxis provides a framework for thinking about how to structure the content, style and
+Diátaxis provides a framework for thinking about how to structure the content, style, and
 organization for technical documentation.
 <!--- deck text end --->
 
@@ -28,12 +28,12 @@ horizontally, and *Action* to *Cognition* vertically.  The four documentation fo
 four quadrants of the grid: Learning (with tutorials), How-To Guides (with goals), Information (with
 technical references) and Understanding (with explanations).  This visual model helps clarify the
 purpose of each documentation type.  For example, how-to guides fall into the second quadrant,
-characterized by content focused on practical action and application.  In addition to end-users,
-this framework provides value to documentation creators and maintainers as it helps them identify
+characterized by content focused on practical action and application.  In addition to aiding end-users,
+this framework provides value to documentation creators and maintainers, as it helps them identify
 where within this structure new or updated information needs to be added.
 
 In practice, documentation authoring is a challenging task.  Having the Diátaxis structure in mind
-can help clarify which of the content form a particular idea might best fit into; instead of
+can help clarify into which of the content forms a particular idea might best fit; instead of
 force-fitting all documentation in a single manual.  Certain concepts, though, can be difficult to
 categorize and might fit into multiple locations on the Diátaxis grid.  So, like many tools and
 processes, this approach doesn't eliminate the complexity of technical work but provides a