Scan Details - Linux-first Docs for Azure

1418

Pages Scanned

49

Pages Flagged

1418

Changed Pages

3.5%

% Pages Flagged

Scan Information

Started At: 2025-08-05 00:00:10

Finished At: 2025-08-05 00:31:04

Status: completed

Target URL: https://github.com/MicrosoftDocs/azure-docs/tree/main/articles

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing a PowerShell automation script but not an equivalent Bash or Linux shell script. The 'Automate with scripts' section lists Azure CLI and PowerShell, but the PowerShell example is shown directly, while the Azure CLI is only linked. There are no explicit Linux or cross-platform shell examples, and the scripting guidance implicitly prioritizes Windows tooling and patterns.

Recommendations:

Provide explicit Bash or Linux shell script examples for automating certificate binding, alongside PowerShell.
Show Azure CLI commands inline, not just as a link, to give equal visibility to cross-platform tooling.
Include notes or sections that clarify all steps can be performed from Linux/macOS as well as Windows.
Where scripting is referenced, ensure both PowerShell and Bash/CLI examples are present and equally prominent.
Review screenshots and UI references to ensure they are not Windows-specific or, if they are, provide Linux/macOS equivalents where relevant.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell command-line examples for scripting and automation, without any equivalent Azure CLI (cross-platform) or Bash examples. PowerShell is a Windows-native tool (though now cross-platform, but still Windows-centric in Azure docs), and its installation instructions and usage are emphasized. There are no Linux- or macOS-specific instructions, nor are there any Bash or Azure CLI examples, which are more common on Linux systems. The order of presentation also places PowerShell before ARM templates, and there is no mention of cross-platform scripting approaches.

Recommendations:

Add equivalent Azure CLI (az) command examples for all PowerShell scripts, as Azure CLI is cross-platform and widely used on Linux/macOS.
Include Bash script examples where appropriate, especially for resource creation and management.
Explicitly mention that the steps are cross-platform where possible, and clarify any OS-specific requirements.
Consider presenting Azure CLI examples before or alongside PowerShell to avoid the impression of Windows-first bias.
Add a section or note for Linux/macOS users, including any prerequisites or differences in experience.
Review links and references to ensure they are not PowerShell-exclusive (e.g., link to both PowerShell and CLI guides).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation prioritizes Windows development environments by providing Package Manager Console (PowerShell-based) instructions and referencing Visual Studio (a Windows-centric IDE) before or instead of Linux alternatives. There are no explicit instructions or examples for Linux users, such as using the .NET CLI on Linux, or alternative editors like VS Code. The focus on Windows tools and lack of Linux-specific guidance may hinder parity and accessibility for Linux developers.

Recommendations:

Add explicit Linux instructions for installing the required NuGet packages using the .NET CLI, and clarify that these commands work cross-platform.
Mention and provide examples for using cross-platform editors like Visual Studio Code, including how to open a terminal and run .NET CLI commands.
Reorder sections so that cross-platform (CLI-based) instructions appear before Windows/Visual Studio-specific instructions.
Clearly state which steps are Windows-specific and which are cross-platform, to help Linux and macOS users navigate the tutorial.
If possible, include screenshots or terminal output from Linux environments to demonstrate parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-specific tools and workflows. Package installation instructions are given for the .NET Core CLI (cross-platform) and then for the Visual Studio Package Manager Console, which is Windows-only and uses PowerShell syntax. There are no explicit Linux or macOS-specific instructions, nor is there mention of Linux-native editors or workflows. The documentation assumes Visual Studio and Windows-centric tools as the default development environment.

Recommendations:

Add explicit instructions for Linux and macOS users, such as using VS Code or JetBrains Rider as alternatives to Visual Studio.
Clarify that the .NET Core CLI commands work on Windows, Linux, and macOS, and consider listing them first.
Provide terminal commands for installing packages using the .NET CLI as the primary method, and mention Visual Studio/PowerShell as an alternative.
Include notes about file paths and environment differences (e.g., appsettings.json location, directory separators) between Windows and Linux/macOS.
Avoid assuming Visual Studio as the default IDE; mention cross-platform editors and workflows.
Where UI navigation is described (e.g., in Azure portal), clarify that these steps are platform-agnostic.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell instructions for verifying results, but does not include Linux- or macOS-specific shell examples (e.g., bash, zsh) or mention platform-specific differences. The PowerShell section uses Windows-style variable assignment, and the prerequisites mention Azure PowerShell requirements without clarifying cross-platform support. There are no explicit Linux or macOS command-line examples or troubleshooting notes.

Recommendations:

Add explicit bash/zsh (Linux/macOS) shell examples for variable assignment and command usage, especially in the verification steps.
Clarify that Azure PowerShell is cross-platform, or provide platform-specific notes if there are differences.
In prerequisites, mention that both Azure CLI and PowerShell are available on Windows, Linux, and macOS, and provide installation links for each platform.
Ensure that all code snippets and instructions are tested and presented for both Windows (PowerShell) and Linux/macOS (bash) environments.
Consider adding a 'Platform differences' note if any commands or behaviors differ between Windows and Linux/macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for finding outbound IP addresses, but the PowerShell examples are given equal prominence and are not explicitly marked as Windows-only, which may confuse Linux/macOS users. There are no explicit Linux shell or Bash alternatives for PowerShell commands, and the documentation does not clarify that Azure PowerShell is primarily a Windows tool. Additionally, outbound IPv6 support is noted as being available only for Windows apps, with no Linux parity or roadmap mentioned.

Recommendations:

Clearly indicate that Azure PowerShell commands are primarily for Windows environments, and recommend Azure CLI for cross-platform use.
Provide Bash or shell script equivalents for PowerShell commands where possible, or clarify when no equivalent exists.
In sections where both CLI and PowerShell are shown, present the Azure CLI (cross-platform) example first, and PowerShell second.
Explicitly state the platform limitations for outbound IPv6 support and, if possible, provide a roadmap or alternatives for Linux users.
Add a note or table summarizing which tools/commands are cross-platform and which are Windows-specific.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides installation instructions for the required NuGet packages using both the .NET Core CLI and the Visual Studio Package Manager Console (PowerShell). However, the Package Manager Console (a Windows/Visual Studio-specific tool) is given equal prominence to the cross-platform .NET CLI, and no explicit Linux or non-Windows development environment guidance is offered. There are no Linux-specific instructions or terminal examples, and the Visual Studio workflow is highlighted, which is Windows-centric.

Recommendations:

Clearly indicate that the .NET Core CLI instructions are cross-platform and preferred for Linux/macOS users.
Add explicit Linux/macOS terminal instructions (e.g., using bash/zsh) for installing packages.
De-emphasize or move the Visual Studio/Package Manager Console (PowerShell) instructions to a secondary position, or label them as 'Windows/Visual Studio only'.
Include a note or section on developing and running the sample on Linux (e.g., using VS Code, JetBrains Rider, or the terminal).
Ensure that all tooling and workflow steps are described in a platform-neutral way unless a step is truly Windows-specific.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias through the exclusive use of Azure PowerShell commands and references to the PowerShell Gallery for migration scripts. Azure CLI is mentioned, but the provided command examples use PowerShell cmdlets and patterns (e.g., Set-AzContext, Register-AzProviderFeature) rather than cross-platform Azure CLI equivalents. There are no Linux-specific or bash shell examples, and no mention of Linux tooling or workflows. The migration script is only referenced as a PowerShell script, with no alternative for Linux users.

Recommendations:

Provide Azure CLI (az) command examples alongside or before PowerShell examples, as Azure CLI is cross-platform and preferred by many Linux users.
Explicitly mention that the migration script is only available as a PowerShell script, and provide a bash/Azure CLI alternative or instructions for Linux users.
When listing tools or workflows (e.g., for registering previews), ensure both PowerShell and Azure CLI examples are given, or default to Azure CLI for cross-platform parity.
Add a section or callout for Linux/macOS users, clarifying supported tools and any differences in workflow.
Review linked tutorials (e.g., 'tutorial-autoscale-ps.md') to ensure they also provide non-Windows, non-PowerShell options.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias, particularly in the Helm installation section, where Windows instructions (including use of the Windows-specific 'winget' package manager and PowerShell command) are presented before Linux instructions. The Linux example is present but less detailed. There is also a reference to Azure Cloud Shell, which is cross-platform but often used in a Windows context. The rest of the documentation uses Azure CLI and Bash, which are cross-platform, but the explicit ordering and detail of Windows instructions indicate a 'windows_first' and 'windows_tools' bias.

Recommendations:

Present Linux and Windows installation instructions for Helm with equal prominence and detail, ideally side-by-side or in a tabbed format with no ordering preference.
Provide explicit Bash and PowerShell examples for all relevant commands, not just for Helm installation.
Include macOS installation instructions for Helm to further improve parity.
Avoid referencing Windows-specific tools (like 'winget') without providing equivalent Linux package manager examples (e.g., apt, yum, snap).
Clarify that Azure CLI and Helm commands are cross-platform and can be run in any supported shell environment.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exclusively references Azure PowerShell scripts for migration, with no mention of Azure CLI, Bash, or Linux-native tooling. All migration automation examples and caveats are described in the context of PowerShell, which is traditionally associated with Windows environments. There are no Linux/Unix shell or cross-platform examples, nor is there guidance for users who may prefer or require non-Windows tooling.

Recommendations:

Provide equivalent Azure CLI (az) commands or scripts for migration tasks alongside PowerShell examples.
Explicitly mention that migration can be performed from Linux/macOS environments using Azure CLI or Bash, and provide relevant instructions.
Include cross-platform sample scripts or reference documentation for both PowerShell and CLI/Bash to ensure parity.
Clarify any limitations or differences between PowerShell and CLI approaches, if applicable.
Add a section addressing Linux/macOS users and their migration workflow.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page references Azure PowerShell as the only example for creating an autoscaling, zone-redundant application gateway, without mentioning or linking to equivalent instructions for Linux users (such as Azure CLI or ARM templates). This suggests a bias towards Windows tooling and may make it less accessible for users on Linux or macOS platforms.

Recommendations:

Provide equivalent examples and tutorials using Azure CLI, which is cross-platform and widely used on Linux.
Include references or links to ARM/Bicep template-based deployment guides for users who prefer declarative infrastructure.
When listing 'Next steps' or providing code samples, ensure that both PowerShell and CLI (and/or template) options are presented side-by-side or with clear links.
Explicitly mention that Azure PowerShell is available cross-platform, but also clarify when instructions are Windows-specific.
Audit other documentation pages linked from this one to ensure Linux parity is maintained throughout the user journey.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation page does not provide any platform-specific command-line examples, but the only 'Next steps' link points to a PowerShell-based tutorial, which is Windows-centric. There is no mention of Linux tools, Bash, or cross-platform CLI methods, and the documentation implicitly assumes PowerShell as the default automation tool.

Recommendations:

Include links to equivalent tutorials using Azure CLI (az), which is cross-platform and works on Linux, macOS, and Windows.
Explicitly mention that configuration can be performed using Azure CLI, ARM templates, or REST API, not just PowerShell.
Provide example commands or scripts for both PowerShell and Azure CLI when demonstrating configuration steps.
Add a 'Next steps' link to a Linux-friendly or cross-platform guide, such as 'Configure URL redirection using Azure CLI'.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell and CLI as the primary configuration tools, with PowerShell consistently mentioned first. There are no explicit Linux or Bash examples, nor are Linux-native tools or workflows referenced. The guidance and links for configuration focus on PowerShell, and the absence of Linux/Bash-specific instructions or parity in tool coverage may hinder Linux users.

Recommendations:

Include explicit Bash/Azure CLI examples alongside or before PowerShell examples for all configuration steps.
When referencing configuration tools, use neutral phrasing (e.g., 'Azure CLI or PowerShell') and ensure both are covered equally.
Add links to Linux/Bash-focused configuration guides, not just PowerShell documentation.
If mentioning PowerShell, clarify that Azure CLI is fully supported and provide parallel instructions.
Review all 'Next steps' and instructional links to ensure Linux users are not directed only to PowerShell-based guides.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. While the main certificate generation steps use OpenSSL (cross-platform), Windows and PowerShell tools are prioritized or exclusively featured in several areas: Windows is mentioned first in prerequisites, IIS (Windows web server) instructions precede Linux alternatives, and only Azure PowerShell is shown for Application Gateway configuration (no Azure CLI or ARM template examples). File paths and screenshots also reflect Windows environments.

Recommendations:

Provide Azure CLI and/or ARM template examples alongside or before Azure PowerShell for Application Gateway configuration, especially for uploading certificates and backend HTTP settings.
Balance web server configuration examples by presenting Linux/Unix (Apache, NGINX) before or alongside IIS, or alternate their order.
Use neutral or Linux-style file paths in examples, or provide both Windows and Linux path variants where relevant.
In prerequisites, mention Linux before or alongside Windows, and clarify that OpenSSL is available on both platforms.
Include screenshots and instructions that reflect both Windows and Linux environments, especially for tasks like adding certificates to the trusted root store.
Where possible, link to both Windows and Linux documentation for related tasks (e.g., editing the hosts file, importing certificates).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation exhibits a Windows bias by prioritizing PowerShell commands for configuration checks, exclusively recommending Fiddler (a Windows-centric tool) for network debugging, and providing installation instructions that assume a Windows environment (e.g., 'Run as administrator'). There are no Linux or cross-platform alternatives mentioned for command-line or debugging tasks.

Recommendations:

Provide equivalent Azure CLI commands for checking Application Gateway settings, as Azure CLI is cross-platform.
Include examples using Linux-native tools for network debugging, such as tcpdump, Wireshark, or curl, alongside or instead of Fiddler.
When referencing downloadable tools, mention cross-platform options (e.g., Wireshark, mitmproxy) and provide installation instructions for both Windows and Linux.
Avoid language and screenshots that assume a Windows environment (e.g., 'right click and run as administrator'), or supplement with Linux-specific instructions.
Ensure that troubleshooting steps and log analysis can be performed on both Windows and Linux systems, and provide examples for each.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell-based examples for automating Key Vault integration with Application Gateway, with no equivalent Azure CLI (cross-platform) or Bash/Linux shell examples. PowerShell is mentioned and used exclusively in code samples and step-by-step instructions, and the 'Next steps' section links only to a PowerShell-based guide. There is no mention or prioritization of Linux or cross-platform tooling, and no examples are given for users on non-Windows systems.

Recommendations:

Provide equivalent Azure CLI examples for all PowerShell commands, especially for key tasks such as referencing Key Vault secrets and configuring Application Gateway.
Include Bash or shell script snippets where appropriate to demonstrate cross-platform automation.
In step-by-step instructions, mention both Azure CLI and PowerShell options, and avoid assuming the user is on Windows.
Update the 'Next steps' section to include links to Azure CLI and/or Bicep/ARM template guides, not just PowerShell.
Where screenshots or UI steps are shown, clarify that the instructions apply regardless of OS, and provide CLI alternatives.
Explicitly state that all operations can be performed from Linux, macOS, or Windows, and ensure parity in documentation coverage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_registry_focus

Summary:

The documentation provides both Windows and Linux troubleshooting steps for Azure Automation Hybrid Runbook Workers, but there is a noticeable Windows bias. Windows examples, tools, and troubleshooting steps are often listed first, and some scenarios (e.g., registry and event log troubleshooting, PowerShell scripts) are Windows-specific or more detailed for Windows. There is heavy reliance on Windows tools (PowerShell, registry edits, event logs), and some troubleshooting guidance is more comprehensive for Windows than for Linux.

Recommendations:

Alternate the order of Windows and Linux instructions to avoid always listing Windows first.
Ensure Linux troubleshooting steps are as detailed and comprehensive as Windows steps, including equivalent commands and log locations.
Where PowerShell or Windows registry steps are given, provide equivalent Linux shell commands or configuration file edits.
For event log troubleshooting, suggest Linux equivalents (e.g., journalctl, syslog) and provide example commands.
Add more Linux-specific troubleshooting scenarios, especially for authentication, permissions, and service management.
Where possible, use cross-platform scripting or tooling, or clearly indicate when a step is platform-specific.
Review all scenarios to ensure Linux users have parity in actionable guidance and examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific instructions, tools, and examples (such as PowerShell cmdlets, environment variable setup, and certificate management) are often presented first or in greater detail. PowerShell is the primary scripting language shown, with Linux/Python alternatives included but less emphasized. Some sections (e.g., credential asset usage, runbook authentication, and starting runbooks via PowerShell) lack Linux-specific examples or focus on Windows paths and tools. Windows UI patterns (like Control Panel navigation) are described in detail, while Linux equivalents are more terse. There are also more detailed code samples and troubleshooting steps for Windows than for Linux.

Recommendations:

Ensure Linux instructions are presented with equal prominence and detail as Windows instructions, including step-by-step guides and code samples.
Provide Linux-specific examples for credential asset usage, runbook authentication, and starting runbooks (e.g., using Bash or Python instead of only PowerShell).
Include Linux-native tools and patterns (such as systemd, cron, or Linux file paths) where appropriate, not just Windows tools like Control Panel or Windows event logs.
When showing PowerShell cmdlets, also provide equivalent Bash or Python scripts for Linux users where possible.
Avoid always listing Windows instructions first; alternate the order or present both platforms side by side.
Expand troubleshooting and logging sections to include more detailed Linux guidance, not just Windows event logs and paths.
Clarify any features that are Windows-only or Linux-only up front, and provide parity where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows bias by prioritizing PowerShell (a Windows-centric technology) in both structure and detail, providing only PowerShell-based code examples, referencing Windows file paths and environment variables, and focusing on Windows-specific tools and workflows. Linux-specific guidance, examples, or parity in explanations are largely absent, especially for PowerShell and graphical runbooks. Python runbook Linux details are minimal and lack practical examples.

Recommendations:

Provide Linux-specific examples and guidance for PowerShell runbooks, especially for scenarios where Linux Hybrid Runbook Workers are supported.
Include Linux file path examples and environment variable usage alongside Windows equivalents.
Clarify which features and limitations apply to Linux Hybrid Runbook Workers versus Windows, and highlight any differences.
Add practical Python runbook examples that demonstrate both Windows and Linux Hybrid Worker usage.
For graphical runbooks, explicitly state Linux limitations and, where possible, suggest alternatives or workarounds for Linux environments.
Balance the order of presentation so that Linux and cross-platform scenarios are not always secondary to Windows.
Where Windows tools or cmdlets are referenced (e.g., C:\modules, .ps1 scripts), provide Linux equivalents or note their absence.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing command-line examples exclusively in Azure PowerShell, with no equivalent Azure CLI (cross-platform) or Bash examples. The PowerShell examples are presented as the only scripting/automation option, and there is no mention of Linux-native tooling or shell environments. Additionally, the structure presents PowerShell before any mention of CLI, and in some cases, CLI is omitted entirely. This may disadvantage users on Linux or macOS who prefer or require cross-platform tools.

Recommendations:

Add Azure CLI examples alongside all PowerShell examples, using Bash syntax where appropriate.
Explicitly mention that both PowerShell and Azure CLI are supported, and provide parity in instructions.
Where automation scripts are shown, offer both PowerShell and Bash/CLI script versions.
Consider including a table or tabbed interface for each command-line example, allowing users to select PowerShell, Azure CLI, or REST API.
Review the order of presentation so that cross-platform tools (Azure CLI) are not always secondary to Windows-centric tools (PowerShell).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation is generally cross-platform, focusing on Visual Studio Code and Azure Functions, which are available on Windows, macOS, and Linux. However, there are subtle signs of Windows bias: troubleshooting steps specifically mention Windows (e.g., default terminal shell not set to WSL Bash), and there are no explicit Linux/macOS-specific instructions or examples. The document references Windows-specific issues before considering Linux/macOS, and does not provide parity troubleshooting or guidance for non-Windows users.

Recommendations:

Add explicit notes or troubleshooting steps for Linux and macOS users, such as common shell or permissions issues.
When mentioning Windows-specific issues (e.g., WSL Bash), also mention potential Linux/macOS terminal issues or configurations.
Ensure that all CLI commands, file paths, and environment setup steps are shown for both Windows and Linux/macOS, or state that the steps are identical if that's the case.
Where possible, include screenshots or terminal output from both Windows and Linux/macOS environments.
Review all included files (e.g., functions-install-core-tools-vs-code.md) to ensure they do not contain hidden Windows bias.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a strong bias towards Windows and PowerShell. PowerShell is consistently presented as the primary or default scripting language, with detailed examples and references to Windows-specific tools (e.g., PowerShell Gallery, Az PowerShell module, .zip packaging for modules). Linux/Python support is mentioned but lacks equivalent depth, examples, or tooling guidance. REST API examples overwhelmingly use PowerShell as the runbook type, and there are no concrete Linux shell or Python-centric examples. Windows packaging conventions are referenced before Linux ones, and the documentation assumes familiarity with Windows/PowerShell patterns.

Recommendations:

Provide parallel, detailed examples for Python runbooks, including REST API payloads and portal workflows.
Include Linux-oriented packaging guidance (e.g., .whl, .tar.gz) and reference Python package repositories (e.g., PyPI) alongside PowerShell Gallery.
When mentioning PowerShell or Windows-specific tools, immediately follow with Linux/Python equivalents (e.g., show how to list installed Python packages in a runbook).
Add explicit Linux/Python runbook creation, update, and test examples, both in the portal and via REST API.
Balance screenshots and walkthroughs to include both PowerShell and Python scenarios.
Avoid assuming PowerShell as the default; clarify that both PowerShell and Python are first-class options, and structure documentation to treat them equally.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. Windows-specific tools and configuration steps (such as Visual Studio, PowerShell, and Windows-specific Azure CLI commands) are often mentioned before or more prominently than their Linux equivalents. Some deployment and debugging instructions are Windows-centric, and Linux-specific guidance is sometimes less detailed or appears after Windows instructions. There are also areas where only Windows or PowerShell examples are given, or where Linux alternatives are not shown or are less emphasized.

Recommendations:

Ensure that for every Windows-specific tool or workflow mentioned (e.g., Visual Studio, PowerShell), the equivalent Linux tool or workflow (e.g., VS Code, Bash, Azure CLI) is given equal prominence and detail.
When presenting CLI commands, provide both Windows (PowerShell/CMD) and Linux (Bash) syntax side by side, or use cross-platform examples where possible.
Avoid listing Windows-first in tabbed sections or lists; alternate the order or present both together.
Expand Linux-specific sections to match the detail and clarity of Windows sections, especially for deployment, debugging, and configuration.
Where PowerShell is referenced, ensure Bash/Azure CLI alternatives are also shown and linked.
Audit all code snippets and setup instructions to ensure Linux users can follow them without ambiguity or missing steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally aims for cross-platform parity, but there are several instances of Windows bias. Windows command-line environments (Cmd, PowerShell) are often listed before or alongside Linux/macOS alternatives, and PowerShell-specific instructions are present. There is also a tendency to refer to 'command prompt' (a Windows term) alongside 'terminal', and some examples (e.g., virtual environment activation) provide more detail for Windows than for Linux/macOS. PowerShell is treated as a first-class language, which is inherently Windows-centric, and Windows-specific tools and patterns (e.g., .venv\scripts\activate, .exe suffixes) are mentioned.

Recommendations:

When listing command-line instructions, consistently present Linux/macOS examples first or in parallel with Windows, rather than defaulting to Windows-first.
Use neutral terminology such as 'terminal' instead of 'command prompt' unless specifically referring to Windows Cmd.
Ensure that all examples and instructions are provided for both Linux/macOS and Windows, with equal detail and clarity.
Where PowerShell is used, clarify its cross-platform availability or provide bash/zsh equivalents where possible.
Avoid using Windows-specific file paths or executable suffixes (like .exe) in generic instructions, or provide platform-specific alternatives.
In sections where multiple tabs are used for OS-specific commands, ensure Linux/macOS is not treated as an afterthought and receives equal prominence.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there are subtle Windows biases. Windows-specific tools, patterns, and examples are sometimes mentioned first or exclusively. Some settings (e.g., WEBSITE_NODE_DEFAULT_VERSION) are marked as Windows-only, but Linux equivalents are not always referenced. PowerShell-specific settings are detailed, but similar depth is not always given for Linux shells or tools. In a few places, examples use Windows-style paths or environment variable syntax without Linux alternatives.

Recommendations:

For every Windows-specific setting or example (e.g., WEBSITE_NODE_DEFAULT_VERSION), explicitly mention the Linux equivalent or clarify if none exists.
When showing environment variable paths or syntax (e.g., %HOME%\typescript), provide the Linux alternative (e.g., $HOME/typescript) alongside.
Where PowerShell is referenced for automation, include Bash/Azure CLI equivalents for Linux users.
In sections discussing reserved characters in setting names (e.g., double-underscore vs. colon), provide explicit Linux and Windows examples for clarity.
Review all examples and ensure that both Windows and Linux paths, commands, and behaviors are shown where relevant.
If a feature or setting is not available on Linux, state this clearly and suggest alternatives if possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there are subtle signs of Windows bias. In command-line examples, both Bash and Windows CMD are provided, but the Windows (CMD) examples are sometimes listed before Bash, and there are no explicit PowerShell examples. There are no Linux-specific tools or troubleshooting steps, and some instructions (e.g., setting JAVA_HOME) do not mention platform-specific nuances. IDE recommendations include cross-platform tools, but Windows-centric tools (like Visual Studio Code) are often mentioned first. There are no Linux- or macOS-specific troubleshooting notes or examples, and some tables list Windows before Linux.

Recommendations:

Ensure Bash (Linux/macOS) examples are always listed before or alongside Windows CMD/PowerShell examples, or clarify that both are equally supported.
Add explicit Linux/macOS troubleshooting notes for steps like setting JAVA_HOME, file permissions, or path separators.
Include Linux/macOS-specific caveats or tips where relevant (e.g., differences in environment variable syntax, file system case sensitivity).
When listing supported platforms or tools, alternate the order or use alphabetical order to avoid implicit prioritization.
Consider adding PowerShell examples only if they add value, but ensure Bash and CMD are always present and equally detailed.
Highlight any platform-specific limitations or behaviors, especially in deployment, logging, or configuration steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation exhibits a mild Windows bias in several areas: Windows terminology ("command prompt") is used alongside or before cross-platform terms ("terminal"), and recommendations for development and publishing workflows often mention Windows scenarios first or specifically. The 'Remote build' section explicitly recommends remote build for Windows users and discourages local builds on Windows, and the phrase 'command prompt' is used instead of 'shell' or 'terminal'. There are also references to Windows-specific patterns (e.g., Visual Studio Code, which is cross-platform but often associated with Windows in Microsoft docs). However, Linux is well represented in hosting and deployment sections, and no critical Linux functionality is missing.

Recommendations:

Replace 'command prompt' with 'terminal' or 'shell', or clarify with 'terminal (Linux/macOS) or command prompt (Windows)'.
When listing development options, avoid putting Windows-specific tools or terminology first unless there is a technical reason.
In the 'Publishing to Azure' section, clarify that both remote and local builds are supported on all platforms, and provide parity in recommendations for Linux/macOS users.
Where possible, provide explicit Linux/macOS command-line examples (e.g., using bash) alongside any Windows-specific instructions.
Review all references to Visual Studio Code to ensure they are presented as cross-platform, and consider mentioning other popular Linux editors or tools if appropriate.
Audit for any subtle language that assumes a Windows environment (e.g., file paths, environment variable syntax) and provide Linux/macOS equivalents where relevant.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing only Windows/PowerShell command examples for Active Directory management, referencing Windows-specific tools and policies (e.g., Group Policy, registry keys), and omitting equivalent Linux or cross-platform methods for managing AD connections. Windows terminology and tools are introduced first and often exclusively, with no mention of Linux-based AD management or integration approaches.

Recommendations:

Provide equivalent Linux command-line examples (e.g., using 'ldapmodify', 'kinit', 'realm', or 'adcli') for managing Kerberos encryption types and AD user properties.
Include references to cross-platform tools (such as Samba, sssd, or realmd) for AD integration and configuration.
Document how to perform AD-related administrative tasks from Linux systems, not just via PowerShell or Windows Group Policy.
Clarify which features or steps are Windows-only and offer Linux alternatives where possible.
Add guidance for Linux administrators on troubleshooting and configuring Azure NetApp Files AD connections from non-Windows environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation mentions both Linux (rsync) and Windows (robocopy) tools for file-based migration, but the examples and tool references are not fully balanced. Robocopy (a Windows tool) is specifically called out for SMB workloads, while rsync is mentioned for NFS. There are no explicit Linux-native SMB migration tool examples (such as smbclient or cifs-utils), and the only SMB example is robocopy, which is Windows-specific. Additionally, the order of presentation sometimes puts Windows tools or patterns first, and there is a lack of parity in example depth for Linux-based SMB migration.

Recommendations:

Add Linux-native SMB migration tool examples (e.g., smbclient, cifs-utils, or Linux rsync with SMB mounts) alongside robocopy for SMB workloads.
Ensure that both Windows and Linux tools are presented together and with equal detail for both NFS and SMB scenarios.
Where possible, provide cross-platform command examples or clarify the OS context for each tool.
Consider including a table or section explicitly comparing migration tool options for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page primarily provides Azure PowerShell commands for feature registration and management, with only a brief mention of Azure CLI as an alternative. There are no Linux shell or Bash examples, and the PowerShell commands are presented first and in detail, which may disadvantage users on Linux or macOS platforms.

Recommendations:

Provide equivalent Azure CLI command examples alongside or before PowerShell commands, as Azure CLI is cross-platform and commonly used on Linux.
Explicitly mention that all operations can be performed from Linux/macOS using Azure CLI, and provide step-by-step CLI instructions.
Include example commands in Bash syntax for Linux users, especially for checking feature registration and status.
Clarify that PowerShell is not required and that the Azure Portal and CLI are fully supported for these operations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page is generally neutral and focused on NFS, which is primarily a Unix/Linux protocol. However, there is a notable Windows bias in the section addressing NFS access from Windows clients: only Windows-specific (PowerShell) commands and tools are provided, with no equivalent Linux examples. The Windows client troubleshooting section appears before any Linux troubleshooting, and the only explicit command-line examples are for Windows/PowerShell. There are no Linux-specific troubleshooting or mounting examples, which may disadvantage Linux users.

Recommendations:

Provide equivalent Linux command-line examples (e.g., mount commands, NFS client configuration) wherever Windows/PowerShell examples are given.
Include Linux troubleshooting steps for common NFS issues, similar to the Windows client troubleshooting section.
When discussing configuration or troubleshooting, present Linux and Windows instructions in parallel or with equal prominence.
Avoid assuming Windows as the default client environment in NFS documentation, given NFS's strong association with Unix/Linux.
Where possible, link to both Linux and Windows documentation for mounting and configuring NFS volumes.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation displays a Windows bias by presenting Windows/Powershell examples and workflows first and in more detail, especially for setting SACLs and registering features. Windows tools and UI steps are described explicitly, while Linux/NFS workflows are referenced but not detailed. There is a lack of parity in step-by-step instructions for Linux environments, and Powershell is the primary CLI example given.

Recommendations:

Provide equivalent, step-by-step instructions for setting Audit ACEs on NFSv4.1 shares from a Linux client, including example commands (e.g., using setfacl or nfs4_setfacl).
Include Linux/Unix CLI examples (such as Azure CLI) alongside or before Powershell examples for feature registration and management.
Balance the order of presentation so that Linux/NFS and Windows/SMB instructions are given equal prominence, or group them under clear headings.
Explicitly mention and link to Linux tools/utilities required for ACL management, and provide troubleshooting tips for common Linux scenarios.
Where screenshots or UI steps are provided for Windows, consider providing equivalent terminal screenshots or command output for Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation is generally balanced in its protocol descriptions, but there are subtle Windows biases. SMB (the Windows protocol) is described as 'officially supported' for Windows and macOS, while Linux SMB (via Samba) is noted as unsupported. Windows terminology and tools (Active Directory, NTFS ACLs, SID translation, NTLM) are referenced as defaults or requirements, and Linux/UNIX equivalents are not always given equal prominence. There are no Linux command-line examples for SMB access or configuration, and the only example command provided is for NFS (rpcinfo), with no equivalent for SMB. The documentation assumes Active Directory as the primary identity provider, with LDAP as a secondary mention.

Recommendations:

Provide explicit Linux/Samba examples for SMB access and configuration, including sample mount commands and troubleshooting steps.
Clarify the support status for Linux SMB clients and provide guidance or best practices for their use, even if not officially supported.
When discussing identity management, give equal detail to LDAP and UNIX/Linux name services as to Active Directory.
Include Linux/UNIX terminology and tools (e.g., idmap, getfacl/setfacl, nsswitch.conf) alongside Windows terms like NTFS and SID.
Where possible, avoid presenting Windows/Active Directory as the default or only supported scenario; instead, present both Windows and Linux/UNIX options in parallel.
Add Linux-focused troubleshooting and configuration sections for dual-protocol environments, including common issues with UID/GID mapping and permissions.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias in several areas. It provides detailed instructions and screenshots for managing LDAP POSIX attributes using Windows tools (Active Directory Users and Computers MMC snap-in), but does not offer equivalent guidance for Linux-based management of LDAP attributes. The only example for editing POSIX attributes is via Windows, and there are no Linux command-line or GUI alternatives mentioned. Additionally, the documentation refers to Windows-specific features and tools (e.g., Windows File Browser, 'net view' command) before or instead of Linux equivalents, and the workflow for managing user attributes is presented solely from a Windows perspective.

Recommendations:

Add instructions and examples for managing LDAP POSIX attributes using Linux tools (e.g., ldapmodify, ldapadd, or graphical LDAP editors like Apache Directory Studio).
Include Linux command-line examples for editing user and group attributes in LDAP directories.
When referencing features like share browsing, mention Linux/UNIX equivalents (e.g., using smbclient or NFS mount commands) alongside Windows tools.
Balance screenshots and step-by-step guides by providing both Windows and Linux workflows where applicable.
Explicitly state that both Windows and Linux administrators can manage dual-protocol volumes and provide parity in guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation presents Windows (SMB) client instructions before Linux (NFS) client instructions, with more detailed steps and screenshots for Windows (including both GUI and command-line methods). Windows-specific tools (File Explorer, dir command) are described in detail, while the Linux section is shorter and only mentions the df command. Additionally, in the REST API section, PowerShell is mentioned explicitly, but there is no mention of Linux shell or curl examples.

Recommendations:

Present Linux and Windows client instructions in parallel or alternate the order in different documentation sections to avoid always listing Windows first.
Provide equivalent detail and screenshots for Linux clients, including both GUI (if applicable, e.g., GNOME Files) and command-line methods.
Include Linux shell or curl examples in the REST API section, not just PowerShell.
Mention and explain common Linux tools (e.g., ls, stat, ncdu) where relevant, similar to how Windows tools are described.
Ensure parity in troubleshooting notes and caveats for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation consistently references Visual Studio Code and GitHub Copilot for testing and using MCP servers, but does not provide any examples or guidance for Linux or cross-platform command-line tools. All instructions and screenshots are based on the Azure Portal (web-based, but often associated with Windows-centric workflows) and Visual Studio Code, with no mention of Linux-native tools, shell commands, or alternative editors. There are no PowerShell-specific commands, but the absence of Linux/CLI parity and the exclusive focus on tools commonly used on Windows (and Mac, but not Linux CLI) indicate a 'windows_first' and 'missing_linux_example' bias.

Recommendations:

Provide equivalent instructions and examples for Linux users, such as using curl or httpie to test the MCP server endpoints.
Include CLI-based examples (e.g., Azure CLI, Bash scripts) for configuring and testing MCP servers, not just portal and VS Code workflows.
Mention and demonstrate how to use open source or cross-platform tools (e.g., Postman, curl) to interact with the MCP server.
Clarify that Visual Studio Code is available on Linux, but also offer alternatives for users who prefer not to use VS Code.
Add a section or callout specifically for Linux users, highlighting any differences or additional steps required.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides a troubleshooting step for clearing the DNS cache that only mentions the Windows command (`ipconfig /flushdns`) and does not provide equivalent instructions for Linux or macOS users. No Linux or cross-platform alternatives are mentioned, and the Windows tool is presented as the default solution.

Recommendations:

Include equivalent DNS cache clearing instructions for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo service nscd restart`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
When mentioning platform-specific commands, explicitly state the platform (e.g., 'On Windows, use...; on Linux, use...; on macOS, use...').
Review the documentation for other potential platform-specific instructions or screenshots and ensure parity for Linux and macOS users.
Consider adding a short section or a table summarizing common troubleshooting commands for all major platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both PowerShell and Azure CLI scripts for granting Microsoft Graph permissions, but the PowerShell example is presented first and in greater detail, which may suggest a preference for Windows-centric tooling. There is no explicit Linux example or mention of Linux-specific considerations, and the PowerShell script uses modules and commands more familiar to Windows users.

Recommendations:

Present Azure CLI examples before PowerShell, as Azure CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide any necessary Linux-specific notes (e.g., shell syntax, environment variables).
If PowerShell is included, clarify that PowerShell Core is available cross-platform, or provide Bash alternatives where possible.
Add a short section or note confirming that all steps are supported on Linux and macOS, not just Windows.
Where screenshots or UI instructions are given, ensure they are not Windows-specific or clarify if the experience is the same across platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While the configuration steps are generally platform-agnostic (using Azure Portal, CLI, Bicep, ARM), the only detailed application code samples for direct certificate access and validation in .NET are for ASP.NET Core and ASP.NET Web Forms—both Windows-centric frameworks. There are no Linux-native web server (e.g., Nginx, Apache) configuration examples, nor are there any command-line examples for Linux (such as using OpenSSL or curl for testing mutual TLS). The documentation assumes the use of the X-ARR-ClientCert header, which is specific to Azure App Service's reverse proxy, but does not discuss how to set up or validate client certificates in a Linux-native environment outside of .NET or Node/Java/Python frameworks.

Recommendations:

Add examples for configuring mutual TLS on Linux-native web servers such as Nginx and Apache, including relevant configuration snippets.
Include Linux command-line examples for testing mutual TLS endpoints (e.g., using curl with client certificates).
Provide parity in code samples for popular Linux-first frameworks (e.g., FastAPI for Python, Ktor for Kotlin, Go net/http).
Clarify that the X-ARR-ClientCert header is Azure-specific and provide guidance for scenarios where apps are hosted on Linux containers or outside Azure App Service.
Ensure that any references to Windows-specific frameworks or tools are balanced with Linux equivalents, or at least mention alternatives.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation provides instructions for cleaning up resources using the Azure portal, which is a graphical interface accessible from any OS, but does not offer command-line examples. There are no examples for Linux users (e.g., Azure CLI commands), and the absence of such examples can be seen as a bias towards Windows users, who are more likely to use the portal or PowerShell. The documentation also does not mention or demonstrate Linux-friendly tools or workflows.

Recommendations:

Add Azure CLI command-line examples for deleting the resource group, which work cross-platform (Windows, Linux, macOS).
Explicitly mention that the Azure portal is OS-agnostic, but provide parity by including both GUI and CLI instructions.
If PowerShell or Windows-specific tools are mentioned elsewhere, ensure equivalent Bash/Linux instructions are present and given equal prominence.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Azure PowerShell and Azure CLI examples for resource creation and role assignment, but consistently lists PowerShell (a Windows-centric tool) before Azure CLI. There are no Linux-specific shell or scripting examples, and the CLI examples use Bash syntax but are not explicitly labeled as Linux-friendly. The portal instructions are platform-agnostic, but the emphasis on PowerShell and its placement before CLI may signal a Windows-first bias.

Recommendations:

Alternate the order of PowerShell and Azure CLI examples, or present Azure CLI examples first, as CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI commands are suitable for Linux, macOS, and Windows, and consider labeling CLI sections as 'Bash/Azure CLI' to clarify Linux compatibility.
Where possible, include Linux-specific notes or troubleshooting tips, especially for authentication or environment setup.
Consider adding a short section or callout for Linux users, highlighting that all Azure CLI commands can be run natively on Linux and providing links to Azure CLI installation instructions for Linux.
If relevant, provide examples using other common Linux tools (e.g., curl, jq) for interacting with Azure REST APIs, or at least acknowledge their use.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation is generally platform-neutral, focusing on Azure Portal UI steps. However, in the troubleshooting section for clearing DNS cache, only the Windows-specific command (`ipconfig /flushdns`) is mentioned, with no equivalent instructions for Linux or macOS users. This presents a subtle 'windows_first' and 'missing_linux_example' bias.

Recommendations:

When providing troubleshooting steps involving system commands (such as clearing DNS cache), include equivalent instructions for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo resolvectl flush-caches`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
Explicitly mention that the instructions apply to all major operating systems, or provide links to platform-specific guidance.
Review other troubleshooting or command-line examples to ensure parity across Windows, Linux, and macOS.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment that is compatible with .NET and Azure App Service, but it does not provide explicit Linux or cross-platform instructions or examples. The workflow references GitHub Codespaces (which is cross-platform) and Azure CLI, but there are no examples or notes for Linux-specific environments, terminal commands, or deployment nuances. There is also an implicit Windows-first bias by focusing on ASP.NET Core and Azure App Service without mentioning Linux hosting or alternative deployment scenarios.

Recommendations:

Include explicit notes that all .NET Core and Azure CLI commands work on Linux, macOS, and Windows, and clarify any OS-specific prerequisites.
Add examples or instructions for running and testing the app locally on Linux (e.g., using bash, Linux file paths, or Linux package managers for .NET SDK installation).
Mention that Azure App Service supports both Windows and Linux hosting plans, and provide guidance for deploying to Linux-based App Service if relevant.
If referencing 'Open in Browser' or other UI actions, clarify how these steps are performed in Linux desktop environments or via command line.
Ensure that all terminal commands are shown in a cross-platform way (e.g., avoid Windows-specific CLI syntax or assumptions about the shell).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes both Windows Command Prompt and PowerShell commands. Linux/macOS instructions are present but always listed last. There are no missing Linux examples, but the ordering and inclusion of multiple Windows-specific shells (cmd, PowerShell) compared to a single Linux shell (bash) demonstrates a subtle Windows-first and PowerShell-heavy bias.

Recommendations:

Alternate the order of OS instructions (sometimes list Linux/macOS first, or use tabs for OS selection).
Group all OS instructions under clearly labeled tabs (Windows, Linux/macOS) to avoid implicit prioritization.
Provide parity in shell instructions: if both cmd and PowerShell are shown for Windows, consider mentioning both bash and zsh for Linux/macOS, or clarify that bash commands work for most shells.
Explicitly state that all platforms are supported equally at the start of the relevant sections.
Consider using cross-platform tools (like Azure CLI) for setup steps where possible, and highlight their usage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides instructions for setting environment variables on Windows (cmd and PowerShell) before mentioning Linux/macOS equivalents. Windows command prompt and PowerShell commands are listed first, and PowerShell is given its own example, which may suggest a Windows-centric approach. However, Linux/macOS instructions are present and correct, and the rest of the guide uses cross-platform Go and Bash commands.

Recommendations:

Present Linux/macOS and Windows instructions in parallel tabs or side-by-side, rather than always listing Windows first.
Avoid giving Windows (cmd/PowerShell) instructions priority over Linux/macOS, especially for Go developers who may be more likely to use Linux/macOS.
Consider using tabbed code blocks for 'Set environment variable' steps, with clear labels for each OS/shell.
Where possible, use cross-platform commands (e.g., Bash) as the default, with Windows-specific instructions as alternatives.
Ensure parity in detail and clarity between Windows and Linux/macOS instructions.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes the use of ASP.NET Core and C#, which are cross-platform, but all instructions and examples are tailored to Visual Studio-style workflows and do not mention Linux or cross-platform development environments. There are no CLI, shell, or Linux-specific instructions or examples, and the Azure Portal UI steps are described without alternatives for command-line or automation scenarios common on Linux. The documentation implicitly assumes a Windows-centric development environment.

Recommendations:

Add equivalent instructions and examples for Linux environments, such as using the Azure CLI or Bash scripts to add Key Vault references and manage App Configuration.
Explicitly mention that the steps apply to all platforms supported by ASP.NET Core, including Linux and macOS.
Provide code snippets or instructions for editing files and running commands in a cross-platform way (e.g., using VS Code, nano, or command-line editors instead of assuming Visual Studio).
Include references to automation and scripting approaches (e.g., az CLI, PowerShell Core, Bash) for managing Azure resources, not just portal-based workflows.
Clarify that the .NET Core SDK and tools are available on Linux and macOS, and provide links or notes for installing and using them on those platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation shows mild Windows bias by consistently listing Windows-centric tools (Visual Studio) before cross-platform or Linux-native tools, especially in C# sections. Visual Studio is highlighted as the primary quickstart and publishing tool for C#, with no mention of Linux-specific editors or workflows. However, most command-line and VS Code instructions are cross-platform, and there are no PowerShell-only examples or missing Linux equivalents.

Recommendations:

When listing development tools or quickstart options, avoid always placing Visual Studio (a Windows-only tool) first. Instead, list cross-platform tools like Visual Studio Code or CLI options before or alongside Visual Studio.
Explicitly mention that Visual Studio Code and Azure Functions Core Tools are fully supported on Linux and macOS, and provide links or notes for Linux users where appropriate.
For C# and other languages, include Linux/macOS-specific instructions or notes in quickstart and publishing sections, especially for workflows that do not require Visual Studio.
Consider adding a table or section summarizing tool support and parity across Windows, Linux, and macOS for each language.
Where Azure CLI or PowerShell are mentioned together, clarify that Azure CLI is cross-platform and PowerShell Core is available on Linux/macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation generally aims for cross-platform parity, explicitly stating support for Linux, macOS, and Windows in most sections. However, there are subtle indications of Windows bias: Visual Studio (a Windows-only IDE) is listed first and most prominently in the C# section, and some instructions (such as changing the port in Visual Studio) are specific to Windows workflows. In the HTTP test tools section, PowerShell (primarily a Windows tool, though now cross-platform) and Microsoft Edge's Network Console (Windows-centric) are listed before curl, which is ubiquitous on Linux. There are no explicit Linux-only examples or tools highlighted, and Linux command-line workflows are not given priority or detailed examples.

Recommendations:

In each language section, list cross-platform tools (such as Visual Studio Code and command-line/terminal) before Windows-only tools like Visual Studio.
When describing environment-specific instructions (e.g., changing ports), provide equivalent steps for Linux/macOS environments or clarify if a step is Windows-specific.
In the HTTP test tools list, give equal or higher prominence to cross-platform and Linux-native tools like curl, httpie, or Postman, and clarify PowerShell's cross-platform availability.
Add explicit Linux/macOS command-line examples or workflows where relevant, especially in sections that currently reference Windows tools or UI.
Where possible, include screenshots or walkthroughs from Linux/macOS environments, not just Windows.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents environment variable setup instructions in the order of Windows CMD, then PowerShell, and finally macOS/Linux, which is a 'windows_first' ordering. However, all platforms are covered and no examples or tools are missing for Linux/macOS.

Recommendations:

Present environment variable setup instructions with Linux/macOS first or in parallel with Windows, to avoid implying Windows is the primary or default platform.
Consider grouping all platform-specific instructions together under a table or clear headings, so no platform appears prioritized.
Ensure future documentation maintains parity by providing examples for all major platforms in a balanced order.

Create pull request

No problematic pages found in this scan. All pages appear to be Linux-friendly! 🐧