Scan Details - Linux-first Docs for Azure

1515

Pages Scanned

71

Pages Flagged

1515

Changed Pages

4.7%

% Pages Flagged

Scan Information

Started At: 2025-08-11 00:00:07

Finished At: 2025-08-11 00:33:36

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

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing only Azure PowerShell examples for command-line operations, with no mention of Azure CLI (cross-platform) or Bash scripting. The PowerShell approach is presented before ARM templates, and there are no Linux-specific instructions or examples. The installation instructions and sample code reference PowerShell exclusively, which is primarily a Windows tool, though it is now available cross-platform. There is no guidance for users who prefer or require Linux-native tools.

Recommendations:

Add Azure CLI examples alongside PowerShell for all command-line operations, as Azure CLI is widely used on Linux and macOS.
Explicitly mention that PowerShell is available cross-platform, but also provide Bash or shell script equivalents where appropriate.
Where installation of tools is discussed, include instructions for both Windows and Linux environments.
Reorder sections or provide parallel examples so that Linux-friendly approaches (e.g., Azure CLI, Bash) are not always secondary to Windows/PowerShell.
Include notes or links to documentation for using ARM templates and managed identities from Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. While the main instructions are GUI-based (Azure Portal) and thus cross-platform, the 'Automate with scripts' section lists Azure CLI first but provides only a direct PowerShell script example, with no corresponding Bash/Linux shell script or explicit Linux automation guidance. There are no explicit Linux command-line examples, and PowerShell is highlighted via metadata and code inclusion. The page does mention a Linux-specific Node.js configuration guide, but only in passing.

Recommendations:

Provide explicit Bash/Linux shell script examples for automating certificate binding, alongside PowerShell.
Ensure parity in automation examples by including both Azure CLI and PowerShell code blocks directly in the documentation, not just as links.
Review metadata (such as ms.custom: devx-track-azurepowershell) to ensure it does not signal a Windows/PowerShell preference unless justified.
Where scripting is discussed, clarify that Azure CLI is cross-platform and provide usage examples for both Windows and Linux environments.
Consider including a section or callout for Linux users, especially for common tasks like uploading certificates or troubleshooting.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by consistently mentioning Windows scenarios and tools first, providing Azure PowerShell examples (which are most commonly used on Windows), and referencing Windows-specific patterns (such as the distinction between Windows and Linux SKUs) before their Linux equivalents. While Linux is supported and Linux-specific commands are present, Windows is generally foregrounded in explanations and examples.

Recommendations:

Alternate the order of Windows and Linux instructions/examples throughout the documentation, or present them in parallel to avoid the perception of prioritizing one platform.
Provide Bash or shell script automation examples alongside PowerShell, especially in the 'Automate with scripts' section, to ensure parity for Linux users.
When referencing platform-specific features or limitations (such as SKU availability), clearly separate Windows and Linux guidance, and ensure both are equally detailed.
Explicitly mention cross-platform compatibility for tools like Azure CLI, and clarify that PowerShell Core is available on Linux and macOS, or provide Bash equivalents.
In the prerequisites and introductory sections, avoid defaulting to Windows terminology or patterns unless necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. It provides detailed C#/.NET (ASP.NET Core and Web Forms) code samples first and in greater depth compared to other languages. The .NET samples are inherently Windows-centric, and the use of terms and patterns like 'HttpRequest.ClientCertificate' and 'System.Web' are specific to Windows/IIS environments. There is no mention of Linux-specific tools or command-line patterns (e.g., bash, OpenSSL, curl), and the documentation does not provide Linux shell or configuration examples for mutual TLS setup. The Azure CLI and Bicep/ARM examples are cross-platform, but the lack of Linux-focused troubleshooting, validation, or deployment steps (such as using OpenSSL to test mutual TLS) further highlights the bias.

Recommendations:

Add Linux-specific examples for validating mutual TLS, such as using OpenSSL or curl to test client certificate authentication.
Provide equivalent shell (bash) commands for enabling client certificates and configuring exclusion paths, in addition to Azure CLI.
Include troubleshooting steps or validation techniques that are common in Linux environments (e.g., using tcpdump, OpenSSL s_client).
Balance the order of language samples, perhaps starting with a cross-platform language (like Node.js or Python) before Windows-centric .NET.
Explicitly mention that the code samples are cross-platform where applicable, and clarify any Windows-only limitations.
Reference Linux tools and patterns (such as /etc/ssl, certificate stores, or environment variables) where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific terminology and tools (such as Azure PowerShell and references to Windows containers) are introduced before or more prominently than their Linux counterparts. PowerShell scripting is given a dedicated section, but there is no equivalent example for Linux shell scripting (e.g., Bash). While Azure CLI is cross-platform, the documentation does not provide Linux-specific automation or deployment examples, and the PowerShell example uses Windows-centric parameters (e.g., WorkerSize values like 'Small', 'Medium', 'Large'). The portal instructions and screenshots do not clarify whether steps differ for Linux vs. Windows apps, and Linux container scenarios are mentioned only in passing.

Recommendations:

Provide explicit Bash shell scripting examples for Linux users alongside PowerShell examples.
Clarify in portal instructions and screenshots whether steps differ for Linux vs. Windows App Service apps.
When listing automation options, present Azure CLI (cross-platform) before PowerShell, and note that CLI is suitable for both Linux and Windows environments.
Expand on Linux container scenarios with concrete examples or links to Linux-specific guidance.
Where parameters or options differ between Windows and Linux (such as WorkerSize or available SKUs), call out those differences explicitly.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates Windows bias primarily in the guidance for identifying Azure Traffic Manager profiles with unsupported endpoints. It exclusively recommends and documents a PowerShell script for this task, with no mention of Bash, Azure CLI, or cross-platform alternatives. The instructions for running the script assume a Windows/PowerShell environment, and there are no Linux/macOS-specific examples or guidance. Elsewhere, the documentation is more neutral, using REST API and Azure CLI references, but the lack of parity in the Traffic Manager scenario stands out.

Recommendations:

Provide an equivalent Bash or Azure CLI script for identifying Traffic Manager profiles with non-Azure endpoints, or document how to perform this task using cross-platform tools.
Explicitly mention that the PowerShell script can be run on PowerShell Core (pwsh) on Linux/macOS, if applicable, and provide installation instructions if needed.
When referencing scripts or tooling, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) options where possible.
Add notes or examples for users on non-Windows platforms to ensure they can follow all mitigation and identification steps without requiring a Windows environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by presenting installation instructions for the NuGet packages using both the .NET Core CLI and the Visual Studio Package Manager Console (PowerShell), but does not provide explicit Linux or cross-platform alternatives beyond the .NET CLI. The Package Manager Console is a Windows/Visual Studio-specific tool, and its instructions are given equal prominence to the cross-platform .NET CLI, with no mention of Linux-specific environments or editors. There are no references to Linux development environments, nor are there any Linux-specific troubleshooting notes or examples.

Recommendations:

Emphasize the .NET Core CLI as the primary, cross-platform installation method and list it before any Windows-specific tools.
Clearly label the Package Manager Console instructions as 'Windows/Visual Studio only' and consider moving them after the cross-platform instructions.
Add explicit notes or examples for Linux/macOS users, such as using VS Code or JetBrains Rider, and mention that the .NET CLI works on all platforms.
Include troubleshooting tips or environment setup notes for Linux/macOS users, if applicable.
Audit other sections for implicit Windows assumptions (such as file paths, environment variable syntax, etc.) and provide Linux equivalents where needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows-specific tools and workflows, such as Visual Studio deployment to Windows App Service, while lacking explicit Linux deployment examples or references to Linux-compatible tools. The mention of Visual Studio deployment is specifically tied to Windows App Service, and there are no examples or guidance for deploying or managing WebJobs on Linux-based App Service plans. Additionally, tools like Kudu are referenced without clarifying their availability or differences on Linux App Service.

Recommendations:

Add explicit examples and instructions for deploying WebJobs to Linux-based App Service plans, including supported languages, file types, and any limitations.
Include Linux-friendly deployment workflows, such as using Azure CLI, FTP, or Git for Linux App Service, and clarify any differences from Windows.
Mention cross-platform editors and tools (e.g., VS Code, Azure CLI) alongside or before Windows-specific tools like Visual Studio.
Clarify the availability and differences of Kudu and App Service diagnostics on Linux App Service.
Ensure that all references to deployment, monitoring, and troubleshooting cover both Windows and Linux scenarios equally.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell-based CLI examples for configuring per-app scaling, with no equivalent examples for Linux-native tools (such as Azure CLI/bash). The use of PowerShell cmdlets (e.g., New-AzAppServicePlan, Set-AzAppServicePlan, Get-AzWebApp) assumes a Windows or PowerShell Core environment. There are no bash, Azure CLI, or cross-platform scripting examples, and PowerShell is presented as the primary (and only) scripting interface. ARM template examples are platform-neutral, but all interactive/imperative examples are Windows-centric.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands, using bash syntax to ensure Linux parity.
Explicitly mention that PowerShell examples can be run cross-platform using PowerShell Core, but provide native bash/Azure CLI alternatives.
Reorder sections or provide parallel examples so that Linux-native (Azure CLI/bash) and Windows-native (PowerShell) instructions are presented with equal prominence.
Include a note or table summarizing all available automation interfaces (PowerShell, Azure CLI, ARM templates, REST API) and their platform compatibility.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively linking to a PowerShell-based tutorial for creating an autoscaling, zone-redundant Application Gateway. There are no references to Linux CLI (az CLI), Bash, or ARM template examples, and the only automation tool mentioned is Azure PowerShell, which is most commonly used on Windows platforms. This prioritizes Windows tooling and patterns, potentially excluding Linux users or those who prefer cross-platform command-line interfaces.

Recommendations:

Add equivalent examples and tutorials using Azure CLI (az cli), which is cross-platform and widely used on Linux and macOS.
Provide ARM/Bicep template examples for infrastructure-as-code scenarios, ensuring parity for users who prefer declarative provisioning.
When listing 'Next steps' or automation options, mention both PowerShell and CLI/Bash options, or provide a neutral, platform-agnostic example first.
Explicitly state that Azure PowerShell can be used on Linux/macOS, or clarify that other tools are available for non-Windows environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell as the primary method for configuring and retrieving TLS policy details, both in the main text and in the 'Next steps' section. There are no explicit Linux or Bash examples, and the CLI is only mentioned in passing, always after PowerShell. The documentation does not provide parity for Linux users in terms of command-line instructions or tool references.

Recommendations:

Provide explicit Azure CLI (az) command examples alongside or before PowerShell examples for all configuration and retrieval tasks.
Include Bash/Linux shell command examples where relevant, especially for common administrative operations.
When referencing documentation for configuration steps, link to both PowerShell and CLI/Bash guides, or create unified guides that show both approaches.
Avoid mentioning PowerShell first or exclusively; use neutral phrasing such as 'using Azure CLI or PowerShell' and ensure both are equally represented.
Add a section or callout for Linux/macOS administrators, highlighting any differences or additional steps required.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates several Windows-centric biases. In the section on generating wheel files, the Windows (Python 3.8) workflow is described after the Linux (Python 3.10) workflow, but both are present. However, the PowerShell cmdlets for managing Python packages are only shown for Windows/PowerShell, with no equivalent CLI or bash examples for Linux users. The documentation also references Windows-specific architectures (win_amd64) and tools (PowerShell cmdlets) without providing Linux alternatives or parity. There is a lack of Linux-native management examples for package operations, and the PowerShell section is extensive and unbalanced compared to Linux guidance.

Recommendations:

Provide equivalent Azure CLI or Bash examples for all PowerShell cmdlets shown, especially for common package management tasks (add, list, remove, update).
Explicitly mention and demonstrate how Linux users can manage Python packages in Azure Automation, including any differences in tooling or workflow.
Balance the documentation by including Linux-first or cross-platform sections, not just Windows/PowerShell.
When referencing platform-specific architectures (e.g., win_amd64), always provide the Linux equivalent (e.g., manylinux_x86_64) and clarify when each is needed.
Consider a summary table or section that compares Windows and Linux workflows for package preparation and management in Azure Automation.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

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

Recommendations:

Include links to equivalent tutorials using Azure CLI (az), which is cross-platform and works natively 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.
Ensure that 'Next steps' and further reading sections offer parity between Windows and Linux users by linking to both PowerShell and CLI/REST documentation.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell scripts for migration tasks, with no mention of Azure CLI or Linux-native tooling. All migration automation examples and caveats are centered around PowerShell, which is traditionally associated with Windows environments. There are no examples or guidance for Linux users or those preferring cross-platform tools.

Recommendations:

Provide equivalent Azure CLI examples and scripts for migration tasks alongside PowerShell references.
Explicitly mention that migration can be performed from Linux/macOS environments using Azure CLI or PowerShell Core, and provide instructions for those platforms.
Add a section comparing PowerShell and CLI approaches, highlighting any differences or limitations.
Ensure that all automation and scripting guidance is cross-platform, or clearly indicate platform requirements.
Include troubleshooting and support guidance for users on Linux or macOS.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell command-line examples, with no equivalent Azure CLI (cross-platform) or Bash examples. The PowerShell examples are given as the sole scripting/automation method, and there is no mention of Linux-native tools or shell environments. In sections where command-line automation is discussed, PowerShell is prioritized and presented before any mention of Azure CLI, which is only referenced in the introduction and not in the step-by-step instructions.

Recommendations:

Provide Azure CLI (az) command examples alongside PowerShell for all automation and deletion tasks, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash shell script examples where appropriate, especially for tasks that can be automated outside of PowerShell.
Explicitly mention that all steps can be performed from Linux, macOS, or Windows, and clarify any platform-specific requirements.
Reorder sections or provide tabs so that Azure CLI and PowerShell examples are presented equally, rather than prioritizing PowerShell.
Reference Linux-native tools or environments where relevant, and avoid assuming the user is on Windows or using PowerShell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation shows a mild Windows bias, particularly in the Helm installation section, where Windows installation instructions (including a PowerShell/winget example) are presented before Linux instructions. The Windows-specific tool 'winget' is highlighted, and the PowerShell command is shown, while the Linux install is given as a generic bash command. The rest of the documentation is largely cross-platform, using Azure CLI and Helm commands that work on both Windows and Linux, but the ordering and tool emphasis favor Windows.

Recommendations:

Present Linux and Windows installation instructions in parallel tabs or in the same order (Linux first or alphabetical), rather than Windows first.
Provide equal detail for both Linux and Windows installation steps, including package manager options for Linux (e.g., apt, yum, snap) in addition to the curl script.
Avoid highlighting Windows-specific tools (like winget) without mentioning Linux equivalents (e.g., apt, yum, snap, or Homebrew for Linux).
Where possible, use cross-platform commands and clarify when a command is OS-specific.
Explicitly state that all Azure CLI and Helm commands are cross-platform and can be run in Bash, PowerShell, or Azure Cloud Shell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. While the core certificate generation steps use OpenSSL (cross-platform), Windows and PowerShell are prioritized or exclusively featured in several areas: Windows is mentioned first in prerequisites, IIS (Windows web server) is documented before Apache/NGINX, and only Azure PowerShell is shown for Application Gateway configuration with no Azure CLI or ARM template equivalents. The only provided automation script is for PowerShell, and file paths in examples use Windows conventions.

Recommendations:

Provide Azure CLI and/or ARM template examples alongside or before Azure PowerShell for Application Gateway configuration.
List Linux and Windows equally in prerequisites, or mention Linux first when OpenSSL is the primary tool.
Alternate or parallelize web server configuration instructions (e.g., show Apache/NGINX before or alongside IIS).
Include Linux-style file paths in examples, or clarify that file paths are OS-dependent.
Where possible, link to cross-platform documentation for tasks like importing certificates into trusted stores.
Explicitly state that all OpenSSL commands work identically on Linux and Windows, and provide any OS-specific notes if needed.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell as the only command-line example, exclusively referencing Windows-centric tools like Fiddler (with installation instructions that assume Windows), and omitting equivalent Linux or cross-platform alternatives. There are no CLI or Bash examples, and troubleshooting steps focus on Windows workflows, with no mention of Linux-compatible tools or methods.

Recommendations:

Provide Azure CLI (az) or Bash examples alongside PowerShell commands for checking Application Gateway settings.
Mention and provide instructions for using cross-platform or Linux-friendly web debugging tools (e.g., Wireshark, mitmproxy, curl) in addition to Fiddler.
Include Linux-specific steps for collecting and analyzing logs, such as using jq to parse ARM template JSON or using Azure CLI on Linux.
Avoid assuming the user is on Windows (e.g., 'Run as administrator', '.NET 4', 'right click the setup executable') and offer parallel instructions for Linux/macOS environments.
List both Windows and Linux tools and workflows in troubleshooting sections, or explicitly state when a tool is Windows-only and suggest alternatives.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing only Azure PowerShell examples for scripting and automation, referencing PowerShell steps before (or instead of) Azure CLI or cross-platform alternatives, and omitting Linux-specific or cross-platform command-line examples. The 'Next steps' section also directs users to a PowerShell-based guide, reinforcing the bias. There is no mention of Bash, Linux shell, or platform-agnostic scripting for certificate management or deployment.

Recommendations:

Provide equivalent Azure CLI (az) examples alongside PowerShell for all automation steps, especially for referencing Key Vault secrets and configuring Application Gateway.
Include Bash/Linux shell script examples for certificate management and deployment tasks.
In sections where PowerShell is referenced, mention Azure CLI and provide links or inline examples for both platforms.
Update the 'Next steps' section to include links to CLI and ARM/Bicep template guides, not just PowerShell.
Explicitly state that all steps can be performed on both Windows and Linux, and clarify any platform-specific requirements.
Where screenshots or UI steps are shown, clarify that the Azure portal is cross-platform and accessible from any OS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a strong Windows and PowerShell bias. PowerShell (including Windows PowerShell and PowerShell Workflow) is presented first and in the most detail, with extensive examples and troubleshooting focused on Windows paths, tools, and cmdlets. Many examples and limitations reference Windows-specific file paths (e.g., C:\modules), environment variables, and behaviors. There is little to no Linux-specific guidance, examples, or troubleshooting, and Linux is only mentioned in passing (e.g., 'can run on Linux Hybrid Worker'), without concrete examples or parity in troubleshooting. Python runbooks receive less coverage, and Linux-specific details are minimal.

Recommendations:

Provide Linux-specific examples for PowerShell runbooks, especially for Hybrid Runbook Workers running on Linux (e.g., file paths, environment variables, module locations).
Include troubleshooting steps and known issues relevant to Linux environments, not just Windows (e.g., what to do if a module path is /usr/local/share/powershell/Modules).
Balance the order and prominence of runbook types: consider presenting Python and PowerShell equally, or at least avoid always listing Windows/PowerShell first.
Where Windows-specific tools or patterns are mentioned (e.g., C:\modules, .ps1 script execution), provide Linux equivalents (e.g., /opt/automation/modules, ./child-runbook.ps1 with Linux path syntax).
Expand the Python runbook section to include more parity with PowerShell, such as common troubleshooting, best practices, and examples for both Windows and Linux Hybrid Workers.
Explicitly call out any differences or additional steps required for Linux Hybrid Runbook Workers throughout the documentation, not just in limitations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration, without providing equivalent Azure CLI (cross-platform) or Bash examples. The only command-line examples use PowerShell syntax, and the migration script is specifically described as an Azure PowerShell script. There is no mention of Linux or Bash alternatives, and the PowerShell approach is presented as the default or only method.

Recommendations:

Provide Azure CLI (az) command examples alongside PowerShell for all operations, especially for migration and preview registration/unregistration.
Clarify that Azure CLI commands are cross-platform and can be used on Windows, Linux, and macOS.
Where PowerShell scripts are referenced, link to or provide equivalent Bash/CLI scripts if available.
In 'Next steps', include links to tutorials or modules that use Azure CLI or Bash, not just PowerShell.
Avoid presenting PowerShell as the default or only automation method; mention both PowerShell and CLI equally, or lead with CLI for cross-platform inclusivity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily through its heavy emphasis on PowerShell and Windows-centric tools and terminology. PowerShell is repeatedly mentioned as the primary automation language, and features like Desired State Configuration (DSC) are described in the context of PowerShell. The modules gallery and runbook examples focus on PowerShell, with only brief mentions of Python. There is a lack of Linux-specific examples, tools, or workflows, and Windows tools and patterns are referenced before or instead of Linux equivalents. While the page claims heterogeneous support, practical Linux parity is not demonstrated.

Recommendations:

Include Linux-specific examples for runbooks, such as Bash or Python scripts managing Linux resources.
Highlight Linux-native automation tools or integration patterns (e.g., Ansible, shell scripting) alongside PowerShell.
Provide equal coverage of Linux configuration management options, not just PowerShell DSC.
Showcase Linux scenarios in common use cases, such as automating package updates, managing systemd services, or configuring SSH.
Reference Linux module repositories (e.g., PyPI for Python, or community Bash scripts) in addition to the PowerShell Gallery.
Ensure that when listing features or capabilities, Linux and Windows are presented with equal prominence and detail.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page is generally cross-platform in intent, focusing on Visual Studio Code and Azure Functions, which are available on both Windows and Linux. However, there are subtle signs of Windows bias: troubleshooting steps specifically mention Windows (e.g., 'When running on Windows, make sure that the default terminal shell for Visual Studio Code isn't set to WSL Bash'), and there are no explicit Linux- or macOS-specific instructions or examples. Additionally, there is no mention of Linux terminal commands, shell environments, or potential Linux/macOS-specific issues, and no parity in troubleshooting for those platforms. The tools and workflows described (VS Code, Azure Functions extension, Core Tools) are cross-platform, but the documentation does not demonstrate this with examples or guidance for non-Windows users.

Recommendations:

Add explicit notes or troubleshooting steps for Linux and macOS users, such as common issues with permissions, shell environments, or dependencies.
Where Windows-specific advice is given (e.g., about WSL Bash), provide equivalent guidance for Linux/macOS users (e.g., default shell settings, terminal configuration).
Include at least one example or screenshot showing the workflow on Linux or macOS to reinforce cross-platform support.
Mention any platform-specific prerequisites or installation steps for Azure Functions Core Tools and the VS Code extension.
Ensure that all instructions and troubleshooting steps are reviewed for platform neutrality, and add clarifying notes where behavior may differ between operating systems.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. Windows instructions, tools, and examples (especially PowerShell) are presented first and in greater detail, with more explicit step-by-step guidance. PowerShell cmdlets and Windows-specific paths/tools are emphasized throughout, while Linux equivalents are sometimes less detailed or omitted. Some advanced scenarios, such as using credential assets for Hybrid Worker credentials, are only supported or documented for Windows. Example scripts and code samples are almost exclusively PowerShell/Windows-centric, with minimal or no Bash/Linux scripting shown for equivalent tasks.

Recommendations:

Present Linux and Windows instructions/examples in parallel or in separate, equally detailed sections, rather than always listing Windows first.
Provide Bash or Python script examples for Linux wherever PowerShell examples are given for Windows (e.g., starting a runbook, managing credentials, signing runbooks).
Where features are Windows-only (such as Hybrid Worker credentials), explicitly state this early and suggest Linux alternatives or workarounds if possible.
Add more detailed Linux-specific troubleshooting, configuration, and environment setup steps, matching the granularity given for Windows.
Reference Linux tools and patterns (e.g., systemd, log locations, environment variable management) as prominently as Windows tools.
Where PowerShell is used cross-platform, clarify how to install and use it on Linux, and provide Linux-specific code samples (e.g., file paths, environment variables).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While it does mention Linux and provides some Linux-specific configuration details, Windows tools and patterns are often mentioned first or exclusively. For example, instructions for installing Azure Functions Core Tools on Windows are more detailed, and Windows-specific configuration commands are presented before Linux equivalents. Some deployment and debugging instructions focus on Visual Studio (primarily a Windows tool) and PowerShell, with less emphasis or fewer examples for Linux environments. In several places, Linux is only mentioned as an alternative or in a tabbed section, and some CLI examples are not clearly marked as cross-platform.

Recommendations:

Ensure all command-line instructions (e.g., Azure CLI, dotnet CLI) are clearly marked as cross-platform and provide explicit Linux/macOS shell examples where relevant.
When listing tools or methods (e.g., Visual Studio, Visual Studio Code, Azure CLI, PowerShell), avoid always listing Windows-first tools or experiences. Alternate the order or group by platform.
Provide equal detail for Linux and macOS workflows, especially for local development, debugging, and deployment. For example, include VS Code and CLI-based debugging instructions for Linux/macOS.
Where Windows-specific configuration or deployment steps are given, ensure Linux equivalents are presented side-by-side or in parallel tabbed sections.
Avoid assuming Visual Studio as the default development environment; highlight VS Code and CLI as first-class options.
Explicitly call out any differences or limitations on Linux/macOS, and provide workarounds or alternatives where possible.

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 environments. Most examples, screenshots, and instructions focus on PowerShell runbooks and modules, with detailed steps for PowerShell and only minimal, secondary mentions of Python (Linux) environments. Windows-specific tools (e.g., PowerShell Gallery, Az PowerShell module) are referenced throughout, and there is a lack of Linux-native or cross-platform examples, especially for Python runbooks. The documentation structure and examples consistently present PowerShell/Windows options first or exclusively, with Linux/Python support mentioned as an afterthought.

Recommendations:

Provide equal, parallel examples for both PowerShell (Windows) and Python (Linux) runbooks, including REST API payloads and portal workflows.
Include screenshots and instructions for creating and managing Python runbooks and environments, not just PowerShell.
Reference Linux-native tools and package formats (e.g., pip, .whl, PyPI) alongside PowerShell Gallery and .nupkg.
Clarify when instructions or features are Windows/PowerShell-specific versus cross-platform.
Add explicit examples and guidance for managing Python packages (including troubleshooting and best practices) in the same detail as for PowerShell modules.
Reorganize sections to avoid always listing PowerShell/Windows options first; consider side-by-side or tabbed presentation for PowerShell and Python/Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally provides parity between Windows and Linux for most troubleshooting steps, with separate sections and commands for each OS. However, there is a noticeable Windows bias: Windows examples and tools (such as PowerShell scripts, registry edits, and event logs) are often mentioned first or in more detail, and some troubleshooting scenarios (e.g., registry or event log checks) are Windows-specific or lack Linux equivalents. The documentation also references Windows-specific tools and patterns (e.g., PowerShell scripts, registry keys, Microsoft-SMA event logs) more frequently and in greater depth than their Linux counterparts.

Recommendations:

Ensure that for every Windows-specific troubleshooting step (e.g., checking registry keys, using PowerShell scripts, reviewing event logs), there is a clear Linux equivalent or an explicit statement if no equivalent exists.
Alternate the order of Windows and Linux instructions to avoid always listing Windows first.
Expand Linux troubleshooting sections to match the detail provided for Windows, including log locations, service management, and common issues.
Where Windows event logs are referenced, provide guidance on equivalent Linux log files (e.g., syslog, journalctl) or clarify if no direct equivalent exists.
For steps involving PowerShell, provide bash or Python script equivalents for Linux where possible.
Review all scenarios to ensure Linux is not treated as an afterthought and that Linux administrators have actionable, detailed guidance.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page focuses exclusively on configuration instructions for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows environments. The Visual Studio instructions are Windows-specific, and there is no mention of Linux or cross-platform alternatives for configuring or using the Roslyn Analyzer. There are no command-line or editor-agnostic instructions, nor are there examples for Linux users or those using other editors.

Recommendations:

Include instructions for configuring and using the Roslyn Analyzer in cross-platform editors such as JetBrains Rider or via command-line tools (e.g., dotnet CLI).
Explicitly mention how to enable or disable the analyzer on Linux and macOS, including any differences in workflow.
Provide examples or links for users who develop on Linux, such as using VS Code on Linux, or integrating Roslyn Analyzer into CI/CD pipelines.
Clarify that Visual Studio Code is cross-platform, and provide Linux/macOS-specific screenshots or notes where UI or steps differ.
Add a section on using the analyzer with the dotnet build process, which is platform-agnostic.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page exclusively provides .NET (C#) code samples and references to Windows-centric tools and patterns (such as host.json and Durable Functions .NET Isolated model), with no mention of Linux-specific considerations, shell commands, or cross-platform scripting. There are no examples or guidance for Linux users, such as Bash commands, Linux file paths, or deployment patterns relevant to Linux environments. The documentation implicitly assumes a Windows/.NET development environment, which may hinder Linux parity and accessibility for non-Windows users.

Recommendations:

Include examples for other supported languages and platforms, such as JavaScript/TypeScript (Node.js), Python, or PowerShell, especially if Durable Functions supports them.
Provide Linux/Bash command-line examples for configuration file editing, deployment, and orchestration management, alongside or instead of Windows/PowerShell examples.
Clarify whether orchestration versioning is available and supported on Linux-hosted Azure Functions, and document any platform-specific caveats.
Reference cross-platform tools and patterns (such as Azure CLI commands) rather than only .NET/Windows-centric approaches.
Explicitly mention any differences in file paths, environment variables, or deployment steps between Windows and Linux environments.
Add troubleshooting steps and best practices relevant to Linux users, including how to monitor and manage orchestrations on Linux-based Azure Functions hosts.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally provides both Bash and Windows CMD examples for command-line operations, but consistently lists Windows tools and environments (such as Visual Studio Code, CMD, and Windows-specific Java version support) before Linux equivalents. The Java version support table lists Windows before Linux, and the documentation references Windows-specific settings and tools prominently. There is a lack of explicit Linux shell or environment-specific troubleshooting, and the documentation sometimes assumes familiarity with Windows conventions (such as JAVA_HOME setup and CMD syntax). However, Linux is not entirely omitted, and Bash examples are present, but Windows is given priority in ordering and presentation.

Recommendations:

Alternate the order of Bash and CMD examples, or present Bash (Linux/macOS) first to reflect the prevalence of Java development on non-Windows platforms.
Explicitly mention Linux and macOS support and troubleshooting steps where environment variables, file paths, or shell commands are discussed.
Include Linux-specific notes or caveats for environment setup (e.g., JAVA_HOME configuration, permissions, file system differences).
Where developer environments are listed, do not list Visual Studio Code (a Microsoft product) first by default; consider alphabetical or usage-based ordering.
When presenting tables (e.g., Java version support), consider listing Linux before Windows or side-by-side, and avoid implying Windows is the primary or default platform.
Ensure all CLI examples are provided for both Bash and CMD, and consider including PowerShell only if there is a unique difference.
Add explicit Linux/macOS troubleshooting and setup sections, especially for common issues like permissions, path separators, and shell differences.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a moderate Windows bias. PowerShell (Azure PowerShell) commands are emphasized throughout, with feature registration and status checks shown first and in more detail than their Azure CLI equivalents. The PowerShell tab is present alongside CLI, REST, and Portal, but PowerShell is often referenced first in feature registration steps. There are no explicit Linux shell (bash) examples, and the CLI examples are not always as detailed as the PowerShell ones. The documentation also references Windows-centric tools and concepts (e.g., PowerShell, Azure PowerShell modules) more prominently than Linux-native equivalents.

Recommendations:

Ensure that Azure CLI (bash/shell) examples are provided with equal detail and prominence as PowerShell examples, especially for feature registration and status checks.
When listing command-line options (PowerShell, CLI, REST), alternate the order or present CLI first to avoid 'windows_first' bias.
Explicitly mention that Azure CLI commands can be run natively on Linux/macOS and provide bash-style command snippets where appropriate.
Add a short section or note clarifying cross-platform support, including that all Azure CLI commands work on Linux, macOS, and Windows.
Where PowerShell is referenced, also provide equivalent bash/Unix shell commands for common administrative tasks (e.g., using az CLI for registration/status).
Review screenshots and UI references to ensure they are not Windows-specific unless necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is generally cross-platform and Linux-focused for hosting, but there are subtle Windows biases in the development and publishing workflow sections. Windows/command prompt/PowerShell terminology is used first or exclusively in some places, and Windows is sometimes assumed as the local development environment. There is a lack of explicit Linux/macOS terminal examples, and some guidance is worded as if Windows is the default local OS.

Recommendations:

Provide explicit Linux/macOS terminal/bash examples alongside or before Windows/command prompt/PowerShell examples, especially in sections about local development, publishing, and package management.
Use neutral terminology such as 'terminal' or 'shell' instead of 'command prompt' when referring to cross-platform command-line usage.
Clarify instructions that are platform-specific (e.g., file paths, environment variables) and provide both Windows and Linux/macOS variants where relevant.
In publishing and build guidance, avoid statements like 'Use remote build when you're developing Python apps on Windows' without also addressing Linux/macOS users. Instead, offer guidance for all platforms.
Where Visual Studio Code is mentioned, also mention other popular cross-platform editors or clarify that VS Code is available on all major OSes.
Review folder structure and code block language tags (e.g., use 'bash' instead of 'cmd' where appropriate) to ensure parity for Linux/macOS users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific tools (Visual Studio, PowerShell, Chocolatey, Winget) are prominently featured, and Windows installation methods are often listed before or in more detail than Linux/macOS equivalents. PowerShell is used for manual installation examples, and Visual Studio (Windows-only) is given equal or greater prominence than cross-platform editors. While Linux and macOS instructions are present and reasonably detailed, Windows tools and patterns are more heavily emphasized.

Recommendations:

Ensure that Linux and macOS installation instructions are always presented before or alongside Windows instructions, not after.
Provide Bash or shell-based manual installation examples before PowerShell examples, and ensure parity in detail and troubleshooting.
Balance the prominence of Visual Studio (Windows-only) with Visual Studio Code (cross-platform) in authoring recommendations.
List cross-platform package managers (e.g., Homebrew for macOS/Linux) with equal visibility to Windows package managers (Chocolatey, Winget).
Where possible, use cross-platform commands and terminology (e.g., 'terminal' instead of 'command shell') and avoid assuming Windows as the default environment.
Explicitly mention any differences or limitations for Linux/macOS users in relevant sections, not just in notes or warnings.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing detailed, step-by-step instructions for setting SACLs using Windows GUI tools, while the Linux/NFS equivalent is referenced only via a link with no inline steps. Feature registration examples are shown first in Azure PowerShell, with Azure CLI (cross-platform) only mentioned in passing. Windows tools and workflows are described in detail, whereas Linux workflows are not directly documented.

Recommendations:

Provide explicit, step-by-step instructions for setting Audit ACEs on NFSv4.1 volumes from a Linux client, similar to the detailed Windows GUI instructions.
Include Linux command-line examples (e.g., using setfacl or nfs4_setfacl) for configuring audit ACEs, not just a link.
Present Azure CLI commands before or alongside PowerShell examples to promote cross-platform parity.
Balance the documentation by ensuring both Windows and Linux workflows are equally detailed and accessible.
Add screenshots or command output examples for Linux where appropriate, mirroring the Windows experience.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation exhibits a moderate Windows bias. It provides detailed instructions and screenshots for managing LDAP POSIX attributes using Windows-only tools (Active Directory Users and Computers MMC snap-in), without offering equivalent Linux-based methods. The only explicit example for editing POSIX attributes is via Windows GUI tools, and the section on accessing the Attribute Editor is entirely Windows-centric. Linux/NFS client configuration is referenced only via a link, with no in-page guidance or parity in attribute management. Additionally, the order of presentation often places Windows/SMB concepts and tools before their Linux/NFS counterparts.

Recommendations:

Add equivalent instructions and examples for managing POSIX attributes using common Linux tools (e.g., ldapmodify, ldapvi, or command-line utilities).
Provide screenshots or command examples for editing LDAP attributes from a Linux environment.
When describing dual-protocol concepts, alternate or balance the order in which Windows and Linux/NFS tools and workflows are presented.
Include a table or section summarizing both Windows and Linux methods for common administrative tasks (e.g., managing LDAP attributes, mounting volumes, troubleshooting access).
Ensure that all configuration steps that are shown for Windows are also shown for Linux where applicable, especially for environments where Windows tools are not available.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing Azure PowerShell commands as the primary example for feature registration, mentioning Azure CLI only as an alternative in text. There are no explicit Linux shell or cross-platform command-line examples, and the UI instructions use Windows-specific terminology (e.g., 'right-click'), which may not be as intuitive for Linux users or those using non-Windows environments. No Linux-specific tools or workflows are mentioned.

Recommendations:

Provide Azure CLI command examples (e.g., 'az feature register', 'az feature show') alongside PowerShell examples in code blocks, not just as a textual mention.
Include bash shell examples for relevant CLI commands to ensure Linux parity.
Avoid Windows-centric UI terminology like 'right-click' or clarify how to perform equivalent actions in web interfaces or on non-Windows platforms.
Where possible, use neutral language and screenshots that are not specific to Windows UI conventions.
Explicitly state that all CLI and portal actions are cross-platform unless there are platform-specific limitations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing only Windows/PowerShell command examples (e.g., Get-ADUser, Set-ADUser), referencing Windows-specific tools and policies (Group Policy, Windows Registry), and focusing on Active Directory Domain Services (AD DS) and Microsoft Entra Domain Services without mentioning or providing equivalent Linux/Unix tools or workflows. Azure CLI is mentioned, but only as an alternative to PowerShell for Azure resource management, not for AD operations. There are no examples or guidance for managing AD connections from Linux environments or using cross-platform tools.

Recommendations:

Provide equivalent Linux/Unix command-line examples (e.g., using ldapsearch, kinit, or samba-tool) for managing Kerberos encryption types and LDAP settings.
Mention and document how to perform relevant AD/LDAP operations from Linux-based systems, including joining domains, setting encryption types, and troubleshooting.
When referencing Windows tools (e.g., PowerShell, Group Policy), also reference cross-platform or Linux-native alternatives where possible.
Structure sections so that cross-platform or Linux options are presented alongside Windows options, not only as afterthoughts or not at all.
Clarify which steps or features are platform-agnostic and which are Windows-specific, to help non-Windows administrators understand their options.
Include troubleshooting tips and best practices for Linux/NFS clients in mixed environments, especially for Kerberos and LDAP integration.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing Azure PowerShell commands as the primary example for feature registration and status checking, mentioning Azure CLI only as an alternative in text without examples. No Linux/bash-specific command examples are given, and the initial command-line workflow assumes PowerShell usage, which is most common on Windows. This may disadvantage Linux/macOS users who typically use Azure CLI or bash scripts.

Recommendations:

Provide Azure CLI (az) command examples alongside or before PowerShell examples for all command-line steps, especially for feature registration and status checking.
Explicitly mention that both Azure PowerShell and Azure CLI are cross-platform, and clarify which shell is being used in each example.
Where possible, include bash script snippets or Linux/macOS terminal screenshots to demonstrate parity.
Consider reordering examples to present Azure CLI first, as it is more commonly used on Linux/macOS.
Add a note or section on how to perform all steps using the Azure CLI for users on non-Windows platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally presents Windows/SMB concepts and tools before or with more detail than Linux/NFS equivalents. Windows terminology (NTFS, SID, Active Directory, NTLM) is used extensively and often explained in more depth, while Linux/UNIX tools and patterns (e.g., Samba, POSIX ACLs, LDAP integration) are mentioned but not elaborated or officially supported. There are no Linux command-line examples or configuration snippets, and Linux/UNIX support is sometimes described as unofficial or less robust.

Recommendations:

Provide Linux/UNIX command-line examples (e.g., mounting NFS/SMB shares, configuring idmapd, using Samba) alongside or before Windows examples.
Expand explanations of Linux/UNIX concepts (e.g., POSIX ACLs, nfs-utils, LDAP integration) to match the depth given to Windows/SMB/NTFS topics.
Clarify official support status for Linux/UNIX SMB clients and provide troubleshooting guidance for common scenarios.
Balance terminology by introducing Linux/UNIX equivalents (e.g., POSIX permissions, UIDs/GIDs, nsswitch.conf) when Windows-specific terms are used.
Include links to relevant Linux/UNIX documentation and best practices, not just Windows/Active Directory resources.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page primarily uses 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 examples are presented first and in detail, which may disadvantage Linux users or those who prefer CLI tools.

Recommendations:

Provide explicit Azure CLI command examples alongside PowerShell, with full syntax and usage (e.g., 'az feature register --namespace Microsoft.NetApp --name ANFDisableShowmount').
Present CLI and PowerShell examples in parallel or in separate tabs to give equal prominence to both Windows and Linux users.
Include a note or section on how to perform these actions from a Linux environment, possibly including Bash scripting examples.
Avoid assuming PowerShell as the default interface; clarify that both PowerShell and CLI are supported and provide equal guidance for both.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. In the 'Ways to create snapshots' section, PowerShell is listed as a primary tool alongside the Azure portal, REST API, and Azure CLI, but there is no mention of Linux-specific command-line examples or tools. The scripting example linked is for SQL Server (a Windows-centric workload), and there are no explicit Linux shell (bash) or automation examples. While the documentation is generally platform-agnostic in its conceptual explanations, the operational guidance and tooling references lean toward Windows and PowerShell, with Linux parity not explicitly addressed.

Recommendations:

Include Linux/bash command-line examples for snapshot creation and management, especially using Azure CLI.
Provide sample scripts for Linux environments (e.g., bash scripts) alongside PowerShell examples.
When listing tools, avoid listing PowerShell before Azure CLI or REST API, or clarify that both Windows and Linux environments are supported equally.
Add references or links to Linux-specific documentation or community resources for managing Azure NetApp Files snapshots.
Ensure that automation and scripting guidance is balanced between Windows (PowerShell) and Linux (bash, shell scripting) environments.

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 tools (PowerShell, Windows mount command) are mentioned, and no equivalent Linux example is provided. The Windows client troubleshooting section appears before any Linux-specific troubleshooting, and there is no parity in terms of Linux client configuration advice or examples.

Recommendations:

For every Windows-specific example (such as enabling CaseSensitiveLookup or mounting NFS volumes), provide an equivalent Linux example (e.g., using mount options or editing /etc/nfsmount.conf).
If troubleshooting steps are given for Windows clients, provide a corresponding section for Linux clients, covering common issues and their solutions.
Ensure that Linux tools and commands are mentioned with equal prominence and detail as their Windows counterparts.
Consider reordering sections so that Linux examples appear before or alongside Windows examples, especially since NFS is more commonly used on Linux.
Add explicit Linux client configuration advice for performance tuning, mounting, and troubleshooting, similar to the detail given for Windows clients.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ windows_heavy_examples

Summary:

The documentation for Azure NetApp Files demonstrates a moderate Windows bias. Features and enhancements related to Windows technologies (such as SMB, Active Directory, Windows File Explorer, and Windows-specific tools) are frequently mentioned, often before or in more detail than their Linux/NFS equivalents. Many feature descriptions focus on Windows-centric use cases (e.g., FSLogix, Citrix, SQL Server on Windows, Windows client behaviors), and some features are described primarily in terms of their impact on Windows environments. While Linux/NFS features are present and some Linux tools (like AzAcSnap) are mentioned, Windows terminology and workflows are more prominent and sometimes prioritized.

Recommendations:

Ensure that for every Windows/SMB/Active Directory example or feature description, an equivalent Linux/NFS/LDAP example or use case is provided, ideally with parity in detail and placement.
When describing features that apply to both Windows and Linux (e.g., dual-protocol, quotas, snapshots), present both perspectives equally, and avoid defaulting to Windows terminology (such as referencing Windows File Explorer without mentioning Linux file browsers or CLI tools).
Add Linux/NFS-focused scenarios and examples where missing, especially for features currently described only in Windows/SMB/Active Directory terms (e.g., access-based enumeration, non-browsable shares, file access logs).
Where Windows tools or workflows are referenced (e.g., PowerShell, Windows File Explorer), include Linux equivalents (e.g., shell commands, Linux file managers) side-by-side.
Review the order of protocol mentions (e.g., NFS vs. SMB) to avoid always listing Windows/SMB first, and alternate or balance their presentation.
Highlight Linux-native tools and integration points (e.g., NFSv4.1 Kerberos, POSIX ACLs, Linux client behaviors) with the same prominence as Windows features.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page provides an example that loads and deploys a PowerShell script (myscript.ps1) using the 'AzurePowerShell' deployment script kind, but does not provide equivalent examples for Linux shell scripts or Bash. There is a focus on Windows tooling (PowerShell) without mention of Linux-native alternatives, and no Linux/Bash script examples are given.

Recommendations:

Add parallel examples that demonstrate loading and deploying Bash or shell scripts (e.g., myscript.sh) using the 'AzureCLI' deployment script kind.
Explicitly mention that the file loading functions are cross-platform and can be used with both Windows (PowerShell) and Linux (Bash) scripts.
Where PowerShell is referenced, provide Linux/Bash alternatives either alongside or before the Windows example to ensure parity.
Clarify in remarks or examples that file paths and encodings are compatible with both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While it claims support for both Azure CLI (Linux) and Azure PowerShell (Windows), there is a consistent pattern of presenting PowerShell examples and tooling either before or alongside CLI/Linux equivalents, sometimes with more detail. Script deployment and management examples are often shown with Azure PowerShell commands, and there is no explicit example of running a native Linux shell script outside of Azure CLI context. Additionally, the deployment instructions for running Bicep files use Azure PowerShell exclusively, with no Bash or cross-platform CLI alternative provided. The documentation also references Windows-centric tools and patterns (e.g., PowerShell, Connect-AzAccount) more prominently than Linux-native equivalents.

Recommendations:

Provide Bash or shell script examples for deploying Bicep files, not just Azure PowerShell.
When listing management commands (e.g., for deploying, monitoring, or troubleshooting), present Azure CLI (Linux/cross-platform) examples before or alongside PowerShell, not after.
Include explicit Linux-native script examples (e.g., Bash scripts) outside of the Azure CLI context, demonstrating how to interact with the deployment script resource from a Linux environment.
Balance the use of PowerShell and CLI examples throughout the documentation, ensuring that Linux users see their workflows represented equally.
Reference Linux-native authentication patterns (e.g., az login) with equal prominence as Connect-AzAccount.
Where possible, clarify that both Windows and Linux environments are supported, and provide parity in troubleshooting and development environment setup instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell-specific instructions and links (such as the export process), mentioning Azure PowerShell before Azure CLI, and omitting explicit Linux or cross-platform command examples. There are no CLI or Bash examples, and the export instructions point to a PowerShell-centric guide.

Recommendations:

Provide Azure CLI examples alongside or before PowerShell instructions for exporting blueprint definitions and configuring deployment stacks.
Update links and references to include both PowerShell and CLI documentation, or provide a cross-platform export workflow.
Explicitly mention that all steps can be performed on Linux/macOS using Azure CLI, and provide relevant command examples.
Ensure that tool and workflow recommendations are platform-neutral unless a feature is truly Windows-only.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation exclusively demonstrates the use of Azure PowerShell (via 'kind: AzurePowerShell', 'azPowerShellVersion', and a PowerShell scriptContent) for deployment scripts, with no mention or example of Bash or Linux-native scripting. There are no Linux/Bash equivalents or cross-platform guidance, and the PowerShell approach is presented as the default/only method.

Recommendations:

Provide parallel examples using 'kind: AzureCLI' and Bash scripting in the deployment script resource.
Explicitly mention that both PowerShell and Bash are supported, and link to documentation for both.
Show how to set 'azCliVersion' and provide a sample Bash scriptContent for Linux users.
Consider a section comparing PowerShell and Bash usage, and when to use each.
Ensure that any references to tooling or scripting are balanced between Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ osplatform_windows_only

Summary:

The documentation page is generally neutral regarding platform-specific instructions, as it focuses on JSON schema and ARM template validation. However, there is a subtle Windows bias in the examples: several JSON snippets specify "osPlatform": "Windows" without mentioning Linux or providing Linux examples. Controls such as Microsoft.Compute.CredentialsCombo, Microsoft.Compute.UserNameTextBox, and Microsoft.Compute.SizeSelector are shown only with Windows as the osPlatform. No Linux or cross-platform examples are provided, and there is no discussion of Linux-specific considerations or parity.

Recommendations:

Include examples where "osPlatform" is set to "Linux" or both "Windows" and "Linux" to demonstrate cross-platform support.
Add notes or examples that highlight any differences or considerations when targeting Linux VMs in createUiDefinition.json.
Where possible, provide parallel examples for both Windows and Linux, especially for controls like credentials, username, and VM size selectors.
Clarify in the documentation whether the test toolkit and controls are equally applicable to Linux, and if not, specify any limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Azure CLI (Bash) and Azure PowerShell examples throughout, but there is a subtle Windows bias. PowerShell is consistently presented as an equal alternative to Bash/CLI, and in some cases, Windows-specific tools and APIs (such as Connect-AzAccount and CommandLineToArgvW) are referenced without Linux equivalents or context. The documentation also references Windows-centric patterns (e.g., PowerShell error handling, Start-Sleep) and APIs before or more prominently than their Linux/Bash counterparts. There are no explicit Linux-only examples or guidance, and the documentation assumes familiarity with PowerShell and Windows scripting conventions.

Recommendations:

Where Windows-specific APIs or tools are mentioned (e.g., Connect-AzAccount, CommandLineToArgvW), provide equivalent Linux/Bash context or explain their relevance for cross-platform users.
When discussing error handling, provide Bash/Linux best practices (e.g., set -e, trap) alongside PowerShell's $ErrorActionPreference.
Clarify that both Bash (for Azure CLI) and PowerShell (for Azure PowerShell) are supported equally, and avoid implying that PowerShell is the default or preferred scripting environment.
Include explicit notes or examples for Linux users where behaviors may differ (e.g., file paths, environment variable access, script extensions).
Consider adding a section or callout for cross-platform scripting tips, highlighting any differences or caveats for Linux vs. Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page is generally cross-platform and avoids explicit Windows or PowerShell bias in its main instructions. However, in the troubleshooting section, the only example given for clearing the DNS cache is the Windows-specific 'ipconfig /flushdns' command. There is no mention of the equivalent commands for Linux or macOS, nor are any Linux-specific tools or patterns referenced elsewhere on the page.

Recommendations:

When providing troubleshooting steps involving system commands (such as clearing DNS cache), include equivalent commands 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').
Review the documentation for other subtle platform-specific references and ensure parity by including cross-platform instructions or notes.
Consider adding a brief note or table in troubleshooting sections that lists common DNS cache flush commands for Windows, Linux, and macOS.
Continue to avoid platform-specific screenshots or UI references unless absolutely necessary, and if used, provide alternatives or clarifications for other 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 to a managed identity, 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, although the Azure CLI example is cross-platform.

Recommendations:

Present Azure CLI examples before PowerShell, as Azure CLI is cross-platform and more accessible to Linux users.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows to reassure non-Windows users.
Add Bash shell examples or clarify that the Azure CLI script is intended for Bash (Linux/macOS) environments.
If PowerShell is included, consider also including Bash or shell script equivalents for any non-Azure CLI steps.
Review the language throughout the documentation to ensure it does not assume a Windows environment or tooling.

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. This presents a subtle 'windows_first' and 'missing_linux_example' bias.

Recommendations:

Include equivalent DNS cache clearing 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`).
When providing OS-specific troubleshooting steps, present all major platforms together or in a tabbed/sectioned format to ensure parity.
Review other troubleshooting or command-line instructions to ensure cross-platform coverage.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation describes resource cleanup using the Azure portal, which is platform-agnostic, but omits command-line examples. There are no CLI (Azure CLI, Bash, or PowerShell) instructions provided, which is a missed opportunity for Linux parity. Historically, Azure docs often provide PowerShell examples first or exclusively, but in this case, neither PowerShell nor Bash/Azure CLI examples are present. However, the lack of any CLI example can be seen as a subtle bias, as Windows users are more likely to use the portal, while Linux users often prefer CLI.

Recommendations:

Add Azure CLI and/or Bash command examples for deleting the resource group, such as 'az group delete --name <resource-group-name>'.
If providing PowerShell examples, ensure Bash/Azure CLI equivalents are given with equal prominence.
Explicitly mention that the portal instructions apply equally to all platforms, but provide CLI alternatives for users who prefer automation or non-GUI workflows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation assumes a development environment (GitHub Codespaces) that is cross-platform, but all examples, tools, and workflows are specific to .NET and Azure App Service, which are traditionally more Windows-centric. There are no explicit Linux or cross-platform command-line examples, nor any mention of Linux-specific tools, deployment patterns, or troubleshooting. The workflow assumes familiarity with .NET and Azure-centric tools, with no alternative instructions for Linux-native environments or non-Windows editors/terminals.

Recommendations:

Explicitly mention that all steps can be performed on Linux, macOS, and Windows, and clarify any OS-specific requirements.
Include example commands for common Linux shells (e.g., bash/zsh) where relevant, especially for deployment or environment variable configuration.
If using GitHub Codespaces, note that it runs on Linux by default, and provide troubleshooting tips for local Linux development.
Add a section or callout for developers working on Linux locally (outside Codespaces), including how to install .NET SDK, run the app, and deploy using CLI tools.
Ensure that all instructions (such as opening the browser, copying URLs, or running dotnet commands) are clear for users on Linux and macOS as well as Windows.
If any step is different on Linux (e.g., environment variable syntax, file paths), provide the Linux equivalent.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias by listing Azure PowerShell instructions before Azure CLI in both the feature registration and unregistration sections. PowerShell is a Windows-centric tool, while Azure CLI is cross-platform and more commonly used on Linux. However, both PowerShell and CLI examples are provided, and there are no exclusive references to Windows-only tools or patterns elsewhere. There are no missing Linux examples, but the ordering and emphasis subtly prioritize Windows/PowerShell.

Recommendations:

Alternate the order of PowerShell and CLI instructions in different sections, or list Azure CLI first to reflect its cross-platform nature.
Explicitly mention that both Azure CLI and PowerShell are supported on Windows, Linux, and macOS, and provide installation links for each.
Where possible, include Bash shell script snippets or references to Linux-native tooling (e.g., curl for REST API calls) to further demonstrate Linux parity.
Clarify that all portal and CLI steps are fully supported on Linux, and avoid implying PowerShell is the primary or preferred method.
Consider adding a short section or note highlighting cross-platform support and recommending tools for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents configuration options in the order: Azure portal, Azure PowerShell, and then Azure CLI. The PowerShell section is detailed and appears before the Azure CLI section, which may signal a preference for Windows-centric tooling. There are no Linux-specific examples, nor is there mention of Linux shell scripting or tooling. The CLI section is present and complete, but PowerShell is given prominence by being listed and described before CLI, which is more cross-platform. No Linux-specific guidance or troubleshooting is provided.

Recommendations:

Present Azure CLI examples before PowerShell, as CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI commands can be run on Linux, macOS, and Windows, and provide any Linux-specific notes if needed (e.g., shell differences, permissions).
Add a short section or note for Linux users, highlighting any OS-specific considerations or best practices.
If possible, provide bash script examples or references for automation on Linux.
Ensure that documentation language and ordering do not imply PowerShell is the default or preferred method, especially for cross-platform scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and provides detailed PowerShell and Windows Command Prompt commands. While Linux/macOS instructions are present, Windows tools and patterns are consistently mentioned first, which may signal a subtle Windows-first bias.

Recommendations:

Present Linux/macOS and Windows instructions in parallel (side-by-side tabs or equal prominence), or alternate which platform is shown first.
Avoid giving Windows (cmd/PowerShell) instructions before Linux/macOS unless there is a technical reason.
Where possible, use cross-platform commands (e.g., only bash, or note platform differences in a neutral way).
Consider providing a table or tabbed interface for environment variable setup, with equal visibility for all platforms.
Review for any other subtle prioritization of Windows tools or patterns, and ensure Linux/macOS users receive equally detailed guidance.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is focused exclusively on ASP.NET Core and C# usage, with all code samples and instructions tailored to this stack. There are no examples or instructions for Linux environments, non-Windows development, or cross-platform command-line usage. The workflow assumes use of the Azure Portal and .NET tooling, which are available cross-platform, but the absence of explicit Linux or CLI examples and the focus on ASP.NET Core may implicitly prioritize Windows users.

Recommendations:

Add explicit instructions or notes clarifying that ASP.NET Core and the Azure SDK are cross-platform, and that the steps apply equally on Linux and macOS.
Include examples of how to perform relevant steps using the Azure CLI or Azure PowerShell, and clarify that these tools are available on all major platforms.
Provide sample code or terminal commands for Linux/macOS environments, such as how to navigate to the project directory, edit files, or run the application.
Mention any platform-specific considerations (if any) for Linux users, such as environment variable configuration or certificate handling.
Balance the documentation by including at least one Linux/macOS terminal example alongside any Windows-centric instructions.

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 explicit PowerShell and Windows Command Prompt examples. While Linux/macOS examples are present, Windows instructions are consistently listed first, and there is more detail about Windows-specific behaviors (such as needing to restart the command prompt after setx). No Linux tools are omitted, but the ordering and emphasis favor Windows users.

Recommendations:

Alternate the order of platform instructions so that Linux/macOS examples are sometimes presented first, or group all platform instructions together without prioritizing Windows.
Use platform-agnostic language where possible (e.g., 'Set the environment variable using your shell').
Add notes about shell session persistence for both Windows and Linux/macOS (e.g., mention that 'export' only affects the current shell session).
Consider using tabbed or collapsible sections for platform-specific instructions to avoid implicit prioritization.
Ensure parity in detail for all platforms (e.g., if you mention restarting the shell for setx on Windows, mention that 'export' is session-scoped on Linux/macOS).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation generally provides cross-platform instructions, but there are subtle signs of Windows bias. In several places, Windows command-line (Cmd) instructions are listed before Linux/macOS equivalents, and PowerShell is given its own dedicated section with examples, even when not strictly necessary. However, Linux/macOS instructions are present and functional, and the use of 'terminal or command prompt' is inclusive. The documentation does not omit Linux examples, but the ordering and emphasis sometimes favor Windows tools and patterns.

Recommendations:

When providing command examples for multiple platforms, consider listing Linux/macOS instructions first or side-by-side with Windows, rather than defaulting to Windows-first ordering.
Avoid giving PowerShell its own section unless it is truly necessary for the scenario; otherwise, group shell instructions by platform (e.g., Bash, Cmd, PowerShell) in a parallel structure.
Ensure that all references to 'terminal or command prompt' clarify that any shell (Bash, Zsh, etc.) is supported, not just Windows Command Prompt or PowerShell.
Where possible, use platform-agnostic commands or highlight differences only when strictly necessary.
Review the use of file paths and environment activation commands to ensure Linux and macOS users are not confused by Windows-centric syntax.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias, primarily by listing Windows-centric tools (Visual Studio, PowerShell, Microsoft Edge Network Console) before cross-platform or Linux-native alternatives. Visual Studio, a Windows-first IDE, is consistently mentioned as the primary environment for C# development, with Visual Studio Code and command-line options listed after. In the HTTP test tools section, PowerShell and Microsoft Edge are highlighted before curl, a ubiquitous Linux tool. However, the documentation does acknowledge Linux and macOS support in most places and provides parity in instructions for Visual Studio Code and Core Tools.

Recommendations:

When listing development environments, avoid always listing Visual Studio (Windows-only) first; consider listing cross-platform options (like Visual Studio Code and Core Tools) before or alongside Windows-only tools.
In tool recommendations (such as HTTP test tools), list cross-platform and Linux-native tools (e.g., curl, HTTPie) before or alongside Windows-specific tools like PowerShell and Microsoft Edge.
Where possible, provide explicit Linux/macOS command-line examples or notes, especially in sections referencing command prompts or terminals.
Highlight Linux/macOS support more prominently in introductory sections, not just in table descriptions.
Include links or references to Linux package managers or installation instructions for Core Tools and Azurite.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing Azure PowerShell commands as the primary example for feature registration and status checking, with Azure CLI (cross-platform) only mentioned secondarily in a brief note. No Linux- or bash-specific examples are given, and the initial focus is on PowerShell, which is more commonly used on Windows.

Recommendations:

Provide Azure CLI (az) command examples alongside or before PowerShell examples for all steps, especially for feature registration and status checking.
Explicitly mention that all steps can be performed from Linux/macOS using Azure CLI, and provide bash-friendly command snippets.
Where possible, use generic Azure Portal instructions or cross-platform tools as the primary example, or present both PowerShell and CLI in parallel.
Add a note clarifying that PowerShell is not required and that Linux/macOS users can use the CLI for all operations.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses exclusively on C# and .NET examples, with all code samples and configuration references tailored to those environments. There is no mention of platform-specific tools, but the absence of any Linux- or cross-platform-specific instructions, shell commands, or examples (such as Bash, Linux file paths, or environment variable handling) creates an implicit Windows/.NET-first bias. Additionally, the only mention of local development references 'local.settings.json', which is not explained for Linux environments.

Recommendations:

Add examples using other languages and platforms, such as Python or JavaScript, and demonstrate how binding expressions work in those environments.
Include instructions or notes on how to manage app settings and environment variables in Linux/macOS environments, such as using Bash or exporting variables.
Provide parity in code samples by including both Windows (PowerShell/C#) and Linux (Bash/Python/JavaScript) equivalents where applicable.
Clarify that 'local.settings.json' is used cross-platform, and provide guidance for editing and managing it on Linux/macOS.
Where file paths or environment-specific details are mentioned, include both Windows and Linux/macOS conventions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Windows and Linux examples for most ARM/Bicep template scenarios, using tabbed sections for parity. However, in several key areas, Windows is presented first (e.g., in hosting plan and function app resource definitions), and PowerShell is the only scripting/deployment example shown in the 'Deploy using PowerShell' section, with no Bash or Linux-native shell equivalents. There are also more references to Windows-specific settings and behaviors, and some sample links default to Windows Consumption plans.

Recommendations:

Alternate the order of Windows and Linux examples in tabbed sections, or present Linux first in some cases to balance visibility.
Add Bash/Azure CLI script examples for deployment (especially in the 'Deploy using PowerShell' section) to support Linux users.
Ensure that all sample links and references are available for both Windows and Linux, and not defaulting to Windows plans.
Where Windows-specific settings are discussed, ensure equivalent Linux settings are equally described and linked.
In summary tables and introductory text, avoid language that implies Windows is the default or primary platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation presents Windows (SMB) client instructions before Linux (NFS) client instructions, and provides more detailed, step-by-step guidance for Windows users (including GUI and command-line options with screenshots), while the Linux section is shorter and only mentions the 'df -h' command. Windows-specific tools (File Explorer, 'dir' command) are highlighted, and the REST API section references PowerShell specifically, but does not mention Linux scripting equivalents.

Recommendations:

Present Windows and Linux client instructions in parallel or alternate the order in different sections to avoid always listing Windows first.
Expand the Linux section to include both GUI (if applicable, e.g., GNOME Files or KDE Dolphin) and command-line options, with equivalent screenshots.
In the REST API section, mention and provide examples for both PowerShell (Windows) and Bash/cURL (Linux/macOS) usage.
Where Windows tools are mentioned (e.g., File Explorer, 'dir'), provide Linux equivalents (e.g., file manager properties, 'ls', 'stat') for parity.
Ensure that all command examples and screenshots are balanced between Windows and Linux environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation primarily uses Azure PowerShell commands for feature registration and status checking, with Azure CLI (cross-platform) only mentioned secondarily and without example commands. No Linux-specific or bash examples are provided, and the initial focus is on PowerShell, which is more familiar to Windows users.

Recommendations:

Provide Azure CLI (az) command examples alongside PowerShell examples, not just as a mention or link.
Present CLI and PowerShell examples in parallel, or lead with CLI for better cross-platform parity.
Explicitly note that all operations can be performed from Linux, macOS, or Windows using Azure CLI.
Include bash shell snippets where appropriate to demonstrate Linux workflows.
Review other sections for similar bias and ensure equal treatment of cross-platform tools.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page exhibits a subtle 'windows_first' bias by referencing Windows-specific SKUs (e.g., 'Windows Isolated v2') as the default or minimum charge in the App Service plan, without mentioning Linux equivalents or clarifying Linux support. There are no command-line examples, but the only platform-specific mention is Windows, and Linux is not addressed at all.

Recommendations:

Explicitly mention Linux support and pricing models where Windows-specific SKUs are referenced. For example, clarify whether there is a Linux Isolated v2 SKU and its minimum charges.
If App Service Environment supports both Windows and Linux, provide parity in documentation by describing both options equally.
Where platform-specific behavior or pricing applies, add a comparative table or note to help users understand differences between Windows and Linux deployments.
Include Linux-specific considerations or links to Linux documentation if relevant.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation provides environment variable setup instructions in the order: Windows (cmd), PowerShell, then macOS/Linux (bash). This ordering gives Windows precedence, which may suggest a subtle Windows-first bias. However, all major platforms are covered and no examples or tools are missing for Linux/macOS.

Recommendations:

Present environment variable setup instructions in a neutral or rotating order (e.g., Linux/macOS first, or group by shell type rather than OS).
Explicitly state that the instructions apply equally to all platforms, and consider using a tabbed or collapsible UI for platform-specific commands to avoid implicit prioritization.
Ensure future documentation consistently provides parity in examples and tool references for all major platforms.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display overt Windows bias in terms of command-line examples or tool references. However, it lacks any platform-specific operational guidance or examples (such as shell commands, deployment steps, or environment setup) for either Windows or Linux. This omission is notable because, in sections where PowerShell is mentioned as a pivot, there are no actual PowerShell-specific examples or instructions—nor are there any for Linux (e.g., Bash). The documentation is focused on SDK usage in various programming languages, but does not provide parity for Linux users in terms of platform-specific instructions or examples.

Recommendations:

If platform-specific pivots (such as PowerShell) are included, ensure that equivalent Linux (e.g., Bash) pivots and examples are also provided.
If operational steps (such as deployment, environment setup, or CLI usage) are required, provide both Windows and Linux examples, or clarify that the steps are platform-agnostic.
Remove empty or placeholder pivots (such as the PowerShell pivot with no content) or fill them with meaningful content for both Windows and Linux users.
Explicitly state in the documentation when features or instructions are platform-independent to avoid confusion.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation mentions Azure PowerShell before Azure CLI when discussing supported versions for the 'count' property, and the 'Next steps' section links to PowerShell deployment instructions without mentioning Linux/CLI alternatives. There are no explicit Linux/CLI examples or parity in deployment guidance.

Recommendations:

List Azure CLI before or alongside Azure PowerShell when discussing supported tools and versions.
In the 'Next steps' section, add a link to 'Deploy resources with ARM templates and Azure CLI' alongside the PowerShell link.
Wherever deployment tooling is mentioned, ensure both CLI and PowerShell are referenced equally, and provide examples or links for both.
Consider including a brief note or example for deploying ARM templates using Azure CLI, especially for Linux/macOS users.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation provides high-level steps for disaster recovery testing with Azure NetApp Files but does not include any platform-specific examples or commands. However, it omits explicit examples or guidance for both Windows and Linux environments, with a slight implicit bias due to the lack of Linux-specific mounting or operational instructions, which are often necessary for cross-platform parity.

Recommendations:

Include explicit examples for mounting/unmounting Azure NetApp Files volumes on both Windows (using SMB/NFS with PowerShell or GUI) and Linux (using NFS with mount commands).
Reference both Windows and Linux tools or commands where applicable, especially in steps involving VM preparation, volume mounting, and application testing.
Provide links to platform-specific documentation for mounting Azure NetApp Files volumes on Windows and Linux.
Clarify that the workflow applies to both Windows and Linux VMs, and highlight any platform-specific considerations.

Create pull request

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