remove none-working links

docs/agile-development/advanced-topics/collaboration/why-collaboration.md

@@ -7,7 +7,7 @@ In engagements, we aim to be highly collaborative because when we code together,
 
 There are two common patterns we use for collaboration: Pairing and swarming.
 
-**Pair programming** (“pairing”) - two software engineers assigned to, and working on, one shared story at a time during the sprint. The Dev Lead assigns a user story to two engineers -- one primary engineer (story owner) and one secondary engineer (pairing assignee). The definition aligns with the Agile Alliance’s [definition](https://www.agilealliance.org/glossary/pairing).
+**Pair programming** (“pairing”) - two software engineers assigned to, and working on, one shared story at a time during the sprint. The Dev Lead assigns a user story to two engineers -- one primary engineer (story owner) and one secondary engineer (pairing assignee). The definition aligns with the Agile Alliance’s [definition](https://www.agilealliance.org/glossary/pair-programming/).
 
 **Swarm programming** (“swarming”) - three or more software engineers collaborating on a high-priority item to bring it to completion.
 

docs/automated-testing/fault-injection-testing/README.md

@@ -29,7 +29,6 @@ Fault injection methods are a way to increase coverage and validate software rob
 * **Error** - That part of the system state that may cause a subsequent failure.
 * **Failure** - An event that occurs when the delivered service deviates from correct state.
 * **Fault-Error-Failure cycle** - A key mechanism in [dependability](https://en.wikipedia.org/wiki/Dependability): A fault may cause an error. An error may cause further errors within the system boundary; therefore each new error acts as a fault. When error states are observed at the system boundary, they are termed failures.
-(Modeled by [Laprie/Avizienis](https://www.nasa.gov/pdf/636745main_day_3-algirdas_avizienis.pdf))
 
 #### Fault Injection Testing Basics
 

docs/automated-testing/integration-testing/README.md

@@ -59,7 +59,7 @@ Many tools and frameworks can be used to write both unit and integration tests.
 - [moq](https://github.com/moq/moq4)
 - [Cucumber](https://cucumber.io/)
 - [Selenium](https://www.selenium.dev/)
-- [Behave (Python)](https://behave.readthedocs.io/en/latest/tutorial.html)
+- [Behave (Python)](https://behave.readthedocs.io/en/latest/tutorial/)
 
 ## Conclusion
 

docs/code-reviews/recipes/markdown.md

@@ -48,7 +48,7 @@ A comprehensive list of markdownlint rules is available [here](https://github.co
 
 ### proselint
 
-[`proselint`](http://proselint.com/) is a command line utility that lints the text contents of the document.  It checks for jargon, spelling errors, redundancy, corporate speak and other language related issues.
+[`proselint`](https://github.com/amperser/proselint) is a command line utility that lints the text contents of the document.  It checks for jargon, spelling errors, redundancy, corporate speak and other language related issues.
 
 It's available both as a [python package](https://github.com/amperser/proselint/#checks) and a [node package](https://www.npmjs.com/package/proselint).
 

docs/design/design-patterns/rest-api-design-guidance/README.md

@@ -91,6 +91,5 @@ In particular, when working in an existing API ecosystem, be sure to align with
 * [Detailed HTTP status code definitions](https://www.restapitutorial.com/httpstatuscodes.html)
 * [Semantic Versioning](https://semver.org/)
 * [Other Public API Guidelines](http://apistylebook.com/design/guidelines/)
-* [OpenAPI Design Practices](https://oai.github.io/Documentation/best-practices.html)
 * [Microsoft TypeSpec](https://github.com/Microsoft/typespec)
 * [Microsoft TypeSpec GitHub Workflow samples](https://github.com/cse-labs/typespec-workflow-samples/)