Fix broken links and markdown (#993)

* clean up privacy readme * ignoring medium.com and towardsdatascience.com as they reject bots * fixing ignores * ignoring github.com * cleaning up links * add linkcheck.json * remove the ignore patterns in the markdown link checker file as they are no longer used * add ignore links * remove fnocera and add shiran * ignore github --------- Co-authored-by: Tess Ferrandez <[email protected]>
microsoft · Sep 18, 2023 · 54ea14b · 54ea14b
1 parent 58a00e2
commit 54ea14b
Show file tree

Hide file tree

Showing 10 changed files with 100 additions and 135 deletions.
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
@@ -1,4 +1,4 @@
-*   @tessferrandez @fnocera @nyouens
+*   @tessferrandez @shiranr @nyouens
 
 /docs/* @tessferrandez @shiranr @tompaana
 
diff --git a/.markdown-link-check.json b/.markdown-link-check.json
@@ -1,43 +1,17 @@
 {
-  "ignorePatterns": [
-    {"pattern": "^./INSERT_URL_TO_ISSUE"},
-    {"pattern": "^./link-to-the-work-item"},
-    {"pattern": "^https://portal.azure.com"},
-    {"pattern": "^http://link-to-feature-or-story-work-item"},
-    {"pattern": "^http://link-to-task-work-item"},
-    {"pattern": "^http://link-to-story-work-item"},
-    {"pattern": "^http://link-to-work-item"},
-    {"pattern": "^https://tanzu.vmware.com/developer/guides/kubernetes/observability-prometheus-grafana-p1"},
-    {"pattern": "^https://www.w3.org/blog/2019/12/trace-context-enters-proposed-recommendation/"},
-    {"pattern": "^https://blog.cloudflare.com/cloudflare-outage/"},
-    {"pattern": "^https://thanos.io"},
-    {"pattern": "^https://gitlab.com/palisade/palisade-release"},
-    {"pattern": "(.*\\.)?.opentelemetry.io"},
-    {"pattern": "(.*\\.)?.pluralsight.com"},
-    {"pattern": "^https://www.github.com"},
-    {"pattern": "^https://marketplace.visualstudio.com"},
-    {"pattern": "^https://opensource.org/licenses/MIT"},
-    {"pattern": "^https://www.researchgate.net/publication/301839557_The_landscape_of_software_failure_cause_models"},
-    {"pattern": "^https://www.cmu.edu/iso/governance/guidelines/data-classification.html"},
-    {"pattern": "^https://machinelearningmastery.com/how-to-get-baseline-results-and-why-they-matter/"},
-    {"pattern": "^https://www.perfecto.io/"},
-    {"pattern": "^https://www.ranorex.com/free-trial/"},
-    {"pattern": "^https://argo-cd.readthedocs.io/"},
-    {"pattern": "^http://pytest.org/"},
-    {"pattern": "^http://code.visualstudio.com/"},
-    {"pattern": "^https://plantuml.com/"}
-  ],
-  "httpHeaders": [
-    {
-      "urls": ["https://docs.github.com/",
-        "https://help.github.com/",
-        "https://github.com/",
-        "https://blog.cloudflare.com/"],
-      "headers": {
-        "Accept-Encoding": "zstd, br, gzip, deflate"
+    "ignorePatterns": [],
+    "httpHeaders": [
+      {
+        "urls": [
+          "https://docs.github.com/",
+          "https://help.github.com/",
+          "https://github.com/",
+          "https://blog.cloudflare.com/"],
+        "headers": {
+          "Accept-Encoding": "zstd, br, gzip, deflate"
+        }
       }
-    }
-  ],
-  "retryOn429": true,
-  "aliveStatusCodes": [200, 206, 302, 0]
-}
+    ],
+    "retryOn429": true,
+    "aliveStatusCodes": [200, 206, 302, 0]
+  }
diff --git a/docs/code-reviews/recipes/markdown.md b/docs/code-reviews/recipes/markdown.md
@@ -188,7 +188,7 @@ Save your guidelines together with your documentation, so they are easy to refer
 - Avoid duplication of content, instead link to the `single source of truth`
 - Link but don't summarize. Summarizing content on another page leads to the content living in two places
 - Use meaningful anchor texts, e.g. instead of writing `Follow the instructions [here](../recipes/markdown.md)` write `Follow the [Markdown guidelines](../recipes/markdown.md)`
-- Make sure links to Microsoft docs (like `https://learn.microsoft.com/something/somethingelse`) do not contain the language marker `/en-us/` or `/fr-fr/`, as this is automatically determined by the site itself.
+- Make sure links to Microsoft docs do not contain the language marker `/en-us/` or `/fr-fr/`, as this is automatically determined by the site itself.
 
 ### Lists
 

diff --git a/docs/continuous-delivery/recipes/terraform/save-output-to-variable-group.md b/docs/continuous-delivery/recipes/terraform/save-output-to-variable-group.md
@@ -118,22 +118,22 @@ In addition, you can notice we are also using [predefined variables](https://lea
       AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
 ```
 
-| System variables | Description |
-| -- | -- |
-| [System.AccessToken](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#systemaccesstoken)| Special variable that carries the security token used by the running build. |
-| [System.TeamFoundationCollectionUri](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables-devops-services) | The URI of the Azure DevOps organization. |
-| [System.TeamProjectId](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables-devops-services) | The ID of the project that this build belongs to. |
+| System variables                                                                                                                                                            | Description                                                                 |
+|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
+| [System.AccessToken](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#systemaccesstoken)                                | Special variable that carries the security token used by the running build. |
+| [System.TeamFoundationCollectionUri](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables-devops-services) | The URI of the Azure DevOps organization.                                   |
+| [System.TeamProjectId](https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables-devops-services)               | The ID of the project that this build belongs to.                           |
 
 ## Library security
 
 Roles are defined for Library items, and membership of these roles governs the operations you can perform on those items.
 
-| Role for library item | Description |
-| -- | -- |
-| Reader | Can view the item. |
-| User | Can use the item when authoring build or release pipelines. For example, you must be a 'User' for a variable group to use it in a release pipeline. |
-| Administrator | Can also manage membership of all other roles for the item. The user who created an item gets automatically added to the Administrator role for that item. By default, the following groups get added to the Administrator role of the library: Build Administrators, Release Administrators, and Project Administrators. |
-| Creator | Can create new items in the library, but this role doesn't include Reader or User permissions. The Creator role can't manage permissions for other users. |
+| Role for library item | Description                                                                                                                                                                                                                                                                                                               |
+|-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Reader                | Can view the item.                                                                                                                                                                                                                                                                                                        |
+| User                  | Can use the item when authoring build or release pipelines. For example, you must be a 'User' for a variable group to use it in a release pipeline.                                                                                                                                                                       |
+| Administrator         | Can also manage membership of all other roles for the item. The user who created an item gets automatically added to the Administrator role for that item. By default, the following groups get added to the Administrator role of the library: Build Administrators, Release Administrators, and Project Administrators. |
+| Creator               | Can create new items in the library, but this role doesn't include Reader or User permissions. The Creator role can't manage permissions for other users.                                                                                                                                                                 |
 
 When using `System.AccessToken`, service account `<ProjectName> Build Service` identity will be used to access the Library.
 

diff --git a/docs/continuous-integration/devcontainers/README.md b/docs/continuous-integration/devcontainers/README.md
@@ -21,15 +21,15 @@ Here are below pros and cons for both approaches:
 ### Run CI pipelines in native environment
 
 | Pros                                                  | Cons                                                                                                                                         |
-| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+|-------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
 | Can use any pipeline tasks available                  | Need to keep two sets of tooling and their versions in sync                                                                                  |
 | No container registry                                 | Can take some time to start, based on tools/dependencies required                                                                            |
 | Agent will always be up to date with security patches | The dev container should always be built within each run of the CI pipeline, to verify the changes within the branch haven't broken anything |
 
 ### Run CI pipelines in the dev container without image caching
 
 | Pros                                                                                               | Cons                                                                                                      |
-| -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+|----------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
 | Utilities scripts will work out of the box                                                         | Need to rebuild the container for each run, given that there may be changes within the branch being built |
 | Rules used (for linting or unit tests) will be the same on the CI                                  | Not everything in the container is needed for the CI pipeline&#185;                                       |
 | No surprise for the developers, local outputs (of linting for instance) will be the same in the CI | Some pipeline tasks will not be available                                                                 |
@@ -44,7 +44,7 @@ Here are below pros and cons for both approaches:
 ### Run CI pipelines in the dev container with image registry
 
 | Pros                                                                                                                                                                                                                                                                                            | Cons                                                                                                      |
-| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|
 | Utilities scripts will work out of the box                                                                                                                                                                                                                                                      | Need to rebuild the container for each run, given that there may be changes within the branch being built |
 | No surprise for the developers, local outputs (of linting for instance) will be the same in the CI                                                                                                                                                                                              | Not everything in the container is needed for the CI pipeline&#185;                                       |
 | Rules used (for linting or unit tests) will be the same on the CI                                                                                                                                                                                                                               | Some pipeline tasks will not be available   &#178;                                                        |

diff --git a/docs/machine-learning/ml-feasibility-study.md b/docs/machine-learning/ml-feasibility-study.md
@@ -140,5 +140,5 @@ The main outcome is a feasibility study report, with a recommendation on next st
   * We may look at re-scoping the problem taking into account the findings of the feasibility study
   * We assess the possibility to collect more data or improve data quality
 
-- If there is enough evidence to support the hypothesis that this problem can be solved using ML 
+- If there is enough evidence to support the hypothesis that this problem can be solved using ML
   * Provide recommendations and technical assets for moving to the operationalization phase
diff --git a/docs/machine-learning/ml-project-management.md b/docs/machine-learning/ml-project-management.md
@@ -31,9 +31,7 @@ Within this framework, the team follows these Agile ceremonies:
 #### Examples of ML deliverables for each sprint
 
 - Working code (e.g. models, pipelines, exploratory code)
-- Documentation of new hypotheses, and the acceptance or rejection of previous hypotheses as part of a Hypothesis Driven Analysis (HDA). See more resources on HDA here:
-  1. [HDA](https://datasciencevademecum.com/2015/11/10/agile-data-science-iteration-0-the-hypothesis-driven-analysis) (from the Data Science Vademecum website).
-  2. [Hypothesis Driven Development](https://barryoreilly.com/explore/blog/how-to-implement-hypothesis-driven-development/) (from Barry Oreilly's website).
+- Documentation of new hypotheses, and the acceptance or rejection of previous hypotheses as part of a Hypothesis Driven Analysis (HDA). For more information see [Hypothesis Driven Development on Barry Oreilly's website](https://barryoreilly.com/explore/blog/how-to-implement-hypothesis-driven-development/)
 - Exploratory Data Analysis (EDA) results and learnings documented
 
 ## Notes on collaboration between ML team and software development team