deploy: 51e0207

code-reviews/recipes/bash/index.html

@@ -6744,7 +6744,7 @@ <h1 id="bash-code-reviews">Bash Code Reviews</h1>
 <h2 id="style-guide">Style Guide</h2>
 <p>Developers should follow <a href="https://google.github.io/styleguide/shell.xml">Google's Bash Style Guide</a>.</p>
 <h2 id="code-analysis-linting">Code Analysis / Linting</h2>
-<p>Projects must check bash code with <a href="https://github.com/koalaman/shellcheck">shellcheck</a> as part of the <a href="../../continuous-integration/README.md">CI process</a>.
+<p>Projects must check bash code with <a href="https://github.com/koalaman/shellcheck">shellcheck</a> as part of the <a href="../../../CI-CD/continuous-integration/">CI process</a>.
 Apart from linting, <a href="https://github.com/mvdan/sh">shfmt</a> can be used to automatically format shell scripts. There are few vscode code extensions which are based on shfmt like shell-format which can be used to automatically format shell scripts.</p>
 <h2 id="project-setup">Project Setup</h2>
 <h3 id="vscode-shellcheck">vscode-shellcheck</h3>
@@ -6839,7 +6839,7 @@ <h2 id="code-review-checklist">Code Review Checklist</h2>
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

design/design-patterns/non-functional-requirements-capture-guide/index.html

@@ -6631,7 +6631,7 @@ <h3 id="operational-requirements">Operational Requirements</h3>
 <td>- Backup and Recovery: The application must have a Backup and Recovery plan in place that includes regular backups of all data and configurations, and a process for restoring data and functionality in the event of a disaster or disruption. <BR/>- Redundancy: The application must have Redundancy built into its infrastructure, such as redundant servers, network devices, and power supplies, to ensure high availability and minimize downtime in the event of a failure.<BR/>- Failover and high availability: The application must be designed to support Failover and high availability, such as by using load balancers or Failover clusters, to ensure that it can continue to operate in the event of a system failure or disruption.<BR/>- Disaster Recovery plan: The application must have a comprehensive disaster Recovery plan that includes procedures for restoring data and functionality in the event of a major disaster, such as a natural disaster, cyber attack, or other catastrophic event.<BR/>- Testing and Maintenance: The application must be regularly tested and maintained to ensure that it can withstand a disaster or disruption, and that all systems, processes, and data can be quickly restored and recovered.</td>
 </tr>
 <tr>
-<td><a href="../../reliability/README.md">Reliability</a></td>
+<td><a href="../../../non-functional-requirements/reliability/">Reliability</a></td>
 <td>System's ability to maintain functionality under varying conditions and failure scenarios.</td>
 <td>- Mean Time Between Failures (MTBF): The system should achieve an MTBF of at least 1000 hours, indicating a high level of reliability with infrequent failures. <BR/>- Mean Time to Recover (MTTR): The system should aim for an MTTR of less than 1 hour, ensuring quick recovery and minimal disruption in the event of a failure.<BR/>- Redundancy Levels: The system should include redundancy mechanisms to achieve a redundancy level of N+1, ensuring high availability and fault tolerance.</td>
 </tr>
@@ -6690,7 +6690,7 @@ <h3 id="security-and-compliance-requirements">Security and Compliance Requiremen
 <td>See <a href="https://aka.ms/tmt">Threat Modeling Tool</a></td>
 </tr>
 <tr>
-<td><a href="../../design/sustainability/readme.md">Sustainability</a></td>
+<td><a href="../../sustainability/">Sustainability</a></td>
 <td>Ability to operate over an extended period while minimizing environmental impact and resource consumption.</td>
 <td>- Energy Efficiency: Kilowatt-hours/Transaction.<BR/>- Carbon Footprint: Tons of CO2 emissions per year.</td>
 </tr>
@@ -6740,7 +6740,7 @@ <h3 id="user-experience-requirements">User Experience Requirements</h3>
 </thead>
 <tbody>
 <tr>
-<td><a href="../../accessibility/README.md">Accessibility</a></td>
+<td><a href="../../../non-functional-requirements/accessibility/">Accessibility</a></td>
 <td>The solution must be usable by people with disabilities. Compliance with accessibility standards. Support for assistive technologies</td>
 <td>- Alternative Text for Images: All images and non-text content must have alternative text descriptions that can be read by screen readers.<BR/>- Color contrast: The application must use color schemes that meet the recommended contrast ratio between foreground and background colors to ensure visibility for users with low vision.<BR/>- Focus indicators: The application must provide visible focus indicators to highlight the currently focused element, which is especially important for users who rely on keyboard navigation.<BR/>- Captions and Transcripts: All audio and video content must have captions and transcripts, to ensure that users with hearing impairments can access the content.<BR/>- Language identification: The application must correctly identify the language of the content, to ensure that screen readers and other assistive technologies can read the content properly.</td>
 <td></td>
@@ -6752,7 +6752,7 @@ <h3 id="user-experience-requirements">User Experience Requirements</h3>
 <td></td>
 </tr>
 <tr>
-<td><a href="../../user-interface-engineering/usability.md">Usability</a></td>
+<td><a href="../../../non-functional-requirements/usability/">Usability</a></td>
 <td>Intuitiveness, ease of learning, and user satisfaction with the software interface.</td>
 <td>- Task Completion Time: The average time it takes for users to complete specific tasks. A user must be able to complete an account settings in less than 2 minutes.<BR/>- Ease of Navigation: The ease with which users can navigate through the system and find the information they need. This can be measured by observing user interactions or conducting usability tests.<BR/>- User Satisfaction: User satisfaction can be measured using surveys, feedback forms, or satisfaction ratings. A satisfaction score of 70% or higher is typically considered satisfactory.<BR/>- Learnability: The ease with which new users can learn to use the system. This can be measured by the time it takes for users to perform basic tasks or by conducting usability tests with novice users.</td>
 <td></td>
@@ -6765,7 +6765,7 @@ <h3 id="user-experience-requirements">User Experience Requirements</h3>
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">July 3, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

design/design-reviews/recipes/index.html

@@ -6477,13 +6477,13 @@ <h3 id="milestone-epic-design-review"><a href="milestone-epic-design-review-reci
 <li>Design should be more detailed than game plan</li>
 <li>May require unique deployment, security and/or privacy characteristics from other milestones</li>
 </ul>
-<h3 id="feature-story-design-review"><a href="./feature-story-design-review-template.md">Feature / Story Design Review</a></h3>
+<h3 id="feature-story-design-review"><a href="templates/feature-story-design-review/">Feature / Story Design Review</a></h3>
 <ul>
 <li>Design for complex features or stories</li>
 <li>Will reuse deployment, security and other characteristics defined within game plan or milestone</li>
 <li>May require new libraries, OSS or patterns to accomplish goals</li>
 </ul>
-<h3 id="task-design-review"><a href="./task-design-review-template.md">Task Design Review</a></h3>
+<h3 id="task-design-review"><a href="templates/template-task-design-review/">Task Design Review</a></h3>
 <ul>
 <li>Highly detailed design for a complex tasks with many unknowns</li>
 <li>Will integrate into higher level feature/component designs</li>
@@ -6494,7 +6494,7 @@ <h3 id="task-design-review"><a href="./task-design-review-template.md">Task Desi
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

design/design-reviews/trade-studies/template/index.html

@@ -6751,7 +6751,7 @@ <h3 id="desired-outcomes">Desired Outcomes</h3>
 <blockquote>
 <p><strong>IMPORTANT</strong> This is <strong>not</strong> intended to define outcomes for the design activity itself. It is intended to define the outcomes for the solution being designed.</p>
 </blockquote>
-<p>As mentioned in the <a href="../../../user-interface-engineering/README.md">User Interface</a> section, if the trade study is analyzing an application development solution, make use of the <em>persona stories</em> to derive desired outcomes. For example, if a persona story exemplifies a certain accessibility requirement, the parallel desired outcome may be "The application must be accessible for people with vision-based disabilities".</p>
+<p>As mentioned in the <a href="../../../../UI-UX/">User Interface</a> section, if the trade study is analyzing an application development solution, make use of the <em>persona stories</em> to derive desired outcomes. For example, if a persona story exemplifies a certain accessibility requirement, the parallel desired outcome may be "The application must be accessible for people with vision-based disabilities".</p>
 <h3 id="evaluation-criteria">Evaluation Criteria</h3>
 <p>The former should be condensed down to a set of "evaluation criteria" that we can rate any potential solutions
 against. Examples of evaluation criteria:</p>
@@ -6779,7 +6779,7 @@ <h4 id="constraints-optional">Constraints (Optional)</h4>
 <li>Integrations or dependencies with other systems. For example, push notifications to client apps must be done via existing websockets channel.</li>
 </ul>
 <h4 id="accessibility">Accessibility</h4>
-<p><strong>Accessibility is never optional</strong>. Microsoft has made a public commitment to always produce accessible applications. For more information visit the official <a href="https://www.microsoft.com/accessibility">Microsoft accessibility site</a> and read the <a href="../../../accessibility/README.md">Accessibility</a> page.</p>
+<p><strong>Accessibility is never optional</strong>. Microsoft has made a public commitment to always produce accessible applications. For more information visit the official <a href="https://www.microsoft.com/accessibility">Microsoft accessibility site</a> and read the <a href="../../../../non-functional-requirements/accessibility/">Accessibility</a> page.</p>
 <p>Consider the following prompts when determining application accessibility requirements:</p>
 <ul>
 <li>Does the application meet industry accessibility standards?</li>
@@ -6891,7 +6891,7 @@ <h2 id="next-steps">Next Steps</h2>
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

developer-experience/onboarding-guide-template/index.html

@@ -6540,7 +6540,7 @@ <h2 id="contacts">Contacts</h2>
 <h2 id="team-agreement-and-code-of-conduct">Team Agreement and Code of Conduct</h2>
 <ul>
 <li>Include the team's code of conduct or agreement that defines a set of expectation from each team member and how the team has agreed to operate.</li>
-<li>Working Agreement Template - <a href="../agile-development/team-agreements/working-agreements.md">working agreement</a></li>
+<li>Working Agreement Template - <a href="../../agile-development/team-agreements/working-agreement/">working agreement</a></li>
 </ul>
 <h2 id="dev-environment-setup">Dev Environment Setup</h2>
 <ul>
@@ -6563,7 +6563,7 @@ <h2 id="resources">Resources</h2>
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

documentation/guidance/project-and-repositories/index.html

@@ -6516,7 +6516,7 @@ <h2 id="common-documentation-to-all-repositories">Common Documentation to all Re
 <li>E.g., ownership, respect, collaboration, transparency.</li>
 </ul>
 </li>
-<li><a href="../../agile-development/team-agreements/working-agreements.md">Working Agreement</a><ul>
+<li><a href="../../../agile-development/team-agreements/working-agreement/">Working Agreement</a><ul>
 <li>How we work together as a team and what our expectations and principles are.</li>
 <li>E.g., communication, work-life balance, scrum rhythm, backlog management, code management.</li>
 </ul>
@@ -6539,7 +6539,7 @@ <h2 id="common-documentation-to-all-repositories">Common Documentation to all Re
 <li><a href="../pull-requests/">Pull Requests</a></li>
 <li><a href="../../../code-reviews/">Code Review Process</a></li>
 <li><a href="../../../code-reviews/process-guidance/reviewer-guidance/">Code Review Checklist</a><ul>
-<li><a href="../../code-reviews/recipes/README.md">Language Specific Checklists</a></li>
+<li><a href="../../code-reviews/recipes/">Language Specific Checklists</a></li>
 </ul>
 </li>
 </ul>
@@ -6566,7 +6566,7 @@ <h2 id="common-documentation-to-all-repositories">Common Documentation to all Re
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

documentation/tools/automation/index.html

@@ -6464,7 +6464,7 @@ <h1 id="how-to-automate-simple-checks">How to Automate Simple Checks</h1>
 <li><a href="https://github.com/tcort/markdown-link-check">markdown-link-check</a> to extract links from markdown texts and check whether each link is alive (200 OK) or dead.</li>
 <li><a href="../../../code-reviews/recipes/markdown/#write-good">write-good</a> to check English prose.</li>
 <li><a href="https://github.com/tmaier/docker-markdown-spellcheck">Docker image for node-markdown-spellcheck</a>, a lightweight docker image to spellcheck markdown files.</li>
-<li><a href="../../continuous-integration/dev-sec-ops/secret-management/static-code-analysis.md">static code analysis</a></li>
+<li><a href="../../../CI-CD/dev-sec-ops/secrets-management/static-code-analysis/">static code analysis</a></li>
 </ul>
 </li>
 </ul>
@@ -6479,7 +6479,7 @@ <h1 id="how-to-automate-simple-checks">How to Automate Simple Checks</h1>
 <li>Automation<ul>
 <li><a href="https://pre-commit.com/">pre-commit</a> to use Git hook scripts to identify simple issues before submitting our code or documentation for review.</li>
 <li>Check <a href="../../../code-reviews/recipes/markdown/#build-validation">Build validation</a> to automate linting for PRs.</li>
-<li>Check <a href="../../continuous-integration/markdown-linting/README.md">CI Pipeline for better documentation</a> for a sample pipeline with <code>markdownlint</code>, <code>markdown-link-check</code> and <code>write-good</code>.</li>
+<li>Check <a href="../../../CI-CD/recipes/ci-pipeline-for-better-documentation/">CI Pipeline for better documentation</a> for a sample pipeline with <code>markdownlint</code>, <code>markdown-link-check</code> and <code>write-good</code>.</li>
 </ul>
 </li>
 </ul>
@@ -6493,7 +6493,7 @@ <h2 id="on-linting-rules">On Linting Rules</h2>
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

machine-learning/agile-development-considerations-for-ml-projects/index.html

@@ -6538,7 +6538,7 @@ <h2 id="goals">Goals</h2>
 <li><a href="../../agile-development/advanced-topics/effective-organization/scrum-of-scrums/">Scrum of Scrums</a> (where applicable)</li>
 <li><a href="../../agile-development/ceremonies/#sprint-planning">Sprint planning</a></li>
 <li><a href="../../agile-development/ceremonies/#stand-up">Stand-ups</a></li>
-<li><a href="../agile-development/team-agreements/working-agreements.md">Working agreement</a></li>
+<li><a href="../../agile-development/team-agreements/working-agreement/">Working agreement</a></li>
 </ul>
 <h2 id="agile-process-during-exploration-and-experimentation">Agile Process During Exploration and Experimentation</h2>
 <ol>
@@ -6576,7 +6576,7 @@ <h2 id="collaboration-between-data-scientists-and-software-developers">Collabora
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 22, 2024</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>

source-control/secrets-management/index.html

@@ -6414,15 +6414,15 @@ <h1 id="working-with-secrets-in-source-control">Working with Secrets in Source C
 <div class="highlight"><pre><span></span><code><span class="c1"># remove private configuration</span>
 *.private.config
 </code></pre></div>
-<p>For more details on proper management of credentials and secrets in source control, and handling an accidental commit of secrets to source control, please refer to the <a href="../continuous-delivery/secrets-management/README.md">Secrets Management</a> document which has further information, split by language as well.</p>
-<p>As an extra security measure, apply <a href="../continuous-integration/dev-sec-ops/secret-management/credential_scanning.md">credential scanning</a> in your CI/CD pipeline.</p>
+<p>For more details on proper management of credentials and secrets in source control, and handling an accidental commit of secrets to source control, please refer to the <a href="../../CI-CD/dev-sec-ops/secrets-management/">Secrets Management</a> document which has further information, split by language as well.</p>
+<p>As an extra security measure, apply <a href="../../CI-CD/dev-sec-ops/secrets-management/credential_scanning/">credential scanning</a> in your CI/CD pipeline.</p>
 
   <hr>
 <div class="md-source-file">
   <small>
 
       Last update:
-      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">March 6, 2023</span>
+      <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 26, 2024</span>
 
 
   </small>