Scan Details - Linux-first Docs for Azure

1416

Pages Scanned

47

Pages Flagged

1416

Changed Pages

3.3%

% Pages Flagged

Scan Information

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

Finished At: 2025-08-03 00:28:57

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by exclusively referencing Visual Studio Code (VS Code) and GitHub Copilot for testing and using the MCP server, without mentioning or providing instructions for Linux-native tools or workflows. All example workflows and screenshots are based on the Azure Portal and VS Code, which, while cross-platform, are most commonly associated with Windows environments. There are no examples using Linux command-line tools (such as curl, httpie, or native Linux editors), nor are there any references to PowerShell, but the absence of Linux-specific guidance or alternatives is notable.

Recommendations:

Add examples for testing the MCP server using cross-platform command-line tools such as curl or httpie, which are widely used on Linux.
Explicitly mention that VS Code is available on Linux and macOS, or provide alternative instructions for users who prefer not to use VS Code.
Include sample configuration and usage instructions for Linux-native editors (e.g., nano, vim) for editing configuration files like mcp.json or settings.json.
Provide screenshots or terminal output examples from a Linux environment to demonstrate parity.
Reference Linux package managers or shell commands where relevant (e.g., installing required tools).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell examples for command-line operations, with no mention of Azure CLI or Bash scripting alternatives that are more common on Linux and macOS. The PowerShell instructions are presented before ARM template examples, and there are no Linux-native command-line instructions or references to cross-platform tools. The documentation assumes the use of PowerShell and Windows-centric workflows, omitting equivalent Azure CLI or Bash guidance.

Recommendations:

Add Azure CLI (az) examples alongside or before PowerShell examples for all command-line operations, as Azure CLI is cross-platform and widely used on Linux and macOS.
Explicitly mention that both PowerShell and Azure CLI can be used, and provide guidance for both environments.
Include Bash script examples where appropriate, especially for automation scenarios.
Reorder sections so that cross-platform tools (Azure CLI, ARM templates) are not always presented after Windows-specific tools.
Add a note clarifying that all instructions are applicable on both Windows and Linux, and specify any OS-specific prerequisites if needed.
Where screenshots are shown, consider including those from the Azure Cloud Shell, which is available on all platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing a PowerShell automation example but omitting equivalent Linux/bash scripting examples. The scripting section lists Azure CLI and PowerShell, but only the PowerShell script is shown inline, with no bash or Linux shell script provided. There is also a subtle 'windows_first' ordering, as PowerShell is highlighted and the ms.custom metadata references Azure PowerShell. No Linux-specific tools or workflows are mentioned, and Linux automation is not given equal prominence.

Recommendations:

Provide a bash/Linux shell script example for automating certificate binding, similar to the PowerShell example.
Ensure that Azure CLI examples are shown inline and not just linked, giving them parity with PowerShell.
Avoid listing PowerShell before bash/Azure CLI unless there is a technical reason; consider alternating or grouping by platform.
Add explicit notes or sections for Linux users, especially in automation and scripting contexts.
Review metadata (such as ms.custom) to ensure it does not reinforce a Windows/Powershell-centric approach.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias in several ways: PowerShell examples are provided alongside Azure CLI, but there are no Bash or Linux shell equivalents for PowerShell commands. Outbound IPv6 support is explicitly stated as available only for Windows apps, with no Linux parity. The documentation references Windows-specific tools and patterns (PowerShell, Azure PowerShell module) without offering Linux-native alternatives or clarifying cross-platform compatibility. In some sections, Windows/PowerShell examples are given before or instead of Linux/Bash examples.

Recommendations:

For every Azure PowerShell example, provide a Bash/Linux shell equivalent (e.g., using Azure CLI or REST API with curl).
Clarify in all relevant sections whether commands and features are cross-platform, and if not, provide Linux-specific guidance or workarounds.
Explicitly state the lack of outbound IPv6 support for Linux apps and provide a roadmap or alternatives if possible.
When listing command examples, alternate the order or group them by platform, rather than defaulting to Windows/PowerShell first.
Reference Linux-native tools (e.g., dig, curl, jq) where appropriate, especially in sections about DNS or IP address lookup.
Add a table or section summarizing feature parity and differences between Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing a PowerShell-based tutorial link as the only concrete example for creating an autoscaling, zone-redundant Application Gateway. There are no equivalent CLI or Linux-native instructions referenced, and the only tool-specific guidance is for Azure PowerShell, which is more commonly used in Windows environments.

Recommendations:

Add links to equivalent tutorials using Azure CLI, which is cross-platform and widely used on Linux and macOS.
When referencing tool-based guides, mention both Azure PowerShell and Azure CLI options, ideally listing the CLI option first or alongside PowerShell.
Ensure that Linux and macOS users are explicitly supported in all example workflows and next steps.
Consider including Bash shell script examples or references where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation displays a mild Windows bias, particularly in the Helm installation section, where Windows instructions and tools (winget, PowerShell) are presented before Linux equivalents. The Windows installation method is described in more detail, and the use of Windows-specific package managers is highlighted. However, Linux instructions are present and functional, and most command-line examples are cross-platform (Azure CLI, Bash, Helm, kubectl).

Recommendations:

Present Linux and Windows installation instructions in parallel tabs or sections, giving equal prominence to both platforms.
Provide explicit Bash (Linux/macOS) and PowerShell (Windows) command examples where relevant, especially for Helm and other tooling.
Avoid listing Windows tools (e.g., winget) before Linux equivalents; consider alphabetical or platform-neutral ordering.
Where possible, mention that Azure CLI and Helm commands work identically on both Windows and Linux, and clarify any platform-specific prerequisites.
Ensure that any references to Windows tools are matched with equivalent Linux package manager commands (e.g., apt, yum, snap) for parity.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation page does not provide any platform-specific command-line examples, but the only 'Next steps' link points to a PowerShell-based tutorial, which is primarily a Windows tool. There is no mention of Linux or cross-platform alternatives (such as Azure CLI or ARM templates), and no Linux-specific guidance is provided. This implicitly prioritizes Windows/PowerShell users and may hinder Linux users seeking parity.

Recommendations:

Include links to equivalent tutorials using Azure CLI, which is cross-platform and widely used on Linux.
Mention both PowerShell and CLI options when referencing configuration steps or next actions.
Add examples or references for ARM/Bicep templates for users who prefer declarative infrastructure.
Explicitly state that the features can be configured from any platform, and provide parity in documentation structure for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell and Windows-centric tools and workflows (e.g., 'PowerShell', 'Listeners blade in portal') as primary means for configuration and inspection. There are no explicit Linux or cross-platform command-line examples (such as Azure CLI on Bash), and the only configuration walkthrough linked is for PowerShell. Linux users are not given parity in instructions or examples.

Recommendations:

Provide Azure CLI examples using Bash or cross-platform shells alongside PowerShell examples for all configuration steps.
Include explicit references and links to Linux/macOS-compatible instructions and tools, not just PowerShell or the Azure Portal.
When mentioning command-line interfaces, list Azure CLI before or alongside PowerShell to avoid Windows-first ordering.
Ensure that all walkthroughs (such as 'Configure TLS policy versions and cipher suites') have both PowerShell and CLI (Bash) versions, and link to both.
Clarify in notes and tables that all operations can be performed from any OS using Azure CLI, not just from Windows/PowerShell.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing only PowerShell-based command-line examples for configuring Application Gateway with Key Vault certificates, with no equivalent Azure CLI or Bash/Linux shell examples. The guidance and automation steps are presented primarily in the context of PowerShell, which is most familiar to Windows users. References to scripting and automation tools (e.g., 'PowerShell steps', 'use PowerShell', 'Get-Az...') are made before or instead of cross-platform alternatives. There is no mention of Linux-specific workflows or examples, and the 'Next steps' section links only to a PowerShell-based guide.

Recommendations:

Provide equivalent Azure CLI examples for all PowerShell scripts, as Azure CLI is cross-platform and widely used on Linux and macOS.
When referencing scripting or automation, mention both PowerShell and Azure CLI (or Bash) options, and consider presenting CLI examples first or side-by-side.
Include explicit Linux/macOS shell command examples where relevant, especially for certificate management and deployment.
Link to both PowerShell and Azure CLI documentation in the 'Next steps' section.
Avoid language that assumes PowerShell is the default or only automation tool; instead, use neutral phrasing such as 'using PowerShell or Azure CLI'.

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 CLI example for checking Application Gateway settings, exclusively recommending Fiddler (a Windows-centric tool) for network debugging, and referencing 'Run as administrator' for installation. There are no Linux or cross-platform alternatives or examples provided for these troubleshooting steps.

Recommendations:

Provide equivalent Azure CLI (az) commands for checking Application Gateway settings, alongside or instead of PowerShell examples.
Include Linux-friendly network debugging tools such as tcpdump, Wireshark, or mitmproxy, and show basic usage examples.
When referencing installation steps, avoid Windows-specific instructions like 'Run as administrator' unless also providing Linux/macOS equivalents.
Mention cross-platform tools and approaches first, or at least in parallel with Windows-specific ones, to ensure parity.
Clarify that Fiddler is one option and suggest alternatives for non-Windows users.

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, including file paths, log locations, and extension management. However, there is a noticeable Windows-first bias: Windows examples, tools, and troubleshooting steps are often presented before their Linux equivalents, and some scenarios (such as registry and event log troubleshooting) are Windows-specific or more detailed for Windows. PowerShell is heavily used for Windows instructions, while Linux instructions are less detailed or use generic bash commands. Some troubleshooting scenarios are only described for Windows, with no Linux equivalent or guidance.

Recommendations:

Alternate the order of Windows and Linux instructions or present them in parallel to avoid always listing Windows first.
Ensure all troubleshooting scenarios that are Windows-specific have equivalent Linux guidance or explicitly state if not applicable.
Provide Linux-specific troubleshooting steps for authentication, permissions, and log/event analysis (e.g., using journalctl, syslog, or Linux equivalents of Windows Event Viewer).
Where PowerShell scripts are provided for Windows, consider providing bash or Python scripts for Linux where possible.
Expand Linux troubleshooting sections to match the level of detail provided for Windows, especially for advanced issues (e.g., stuck jobs, authentication failures, certificate management).
Where registry or Windows event log steps are given, offer analogous Linux file or configuration locations, or clarify if not relevant.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration/unregistration, with no mention of Bash, Linux, or cross-platform CLI alternatives. The Azure CLI examples shown use PowerShell-style commands (Set-AzContext, Register-AzProviderFeature), which are typically associated with PowerShell rather than the cross-platform az CLI. There are no Linux- or Bash-specific instructions or examples, and the PowerShell approach is presented as the default or only method for key operations.

Recommendations:

Provide equivalent Azure CLI (az) commands for all operations currently shown with Azure PowerShell, especially for migration and preview registration/unregistration.
Clearly distinguish between Azure PowerShell and Azure CLI, and ensure both are represented in code examples.
Add explicit Bash/Linux shell examples where relevant, and clarify that all operations can be performed from non-Windows platforms.
When listing tools or methods (e.g., Azure portal, PowerShell, CLI), do not default to PowerShell first—either list CLI first or present both together.
Include a note or section on cross-platform compatibility, reassuring users that all features and scripts are available on Linux and macOS as well as Windows.

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 and omitting equivalent Azure CLI (cross-platform) or Bash examples. The PowerShell approach is presented as the sole scripting/command-line method, and no Linux-native or cross-platform shell instructions are given. The structure and order of examples also prioritize Windows-centric tools and workflows.

Recommendations:

Add Azure CLI examples (az automation account delete, etc.) alongside PowerShell for all command-line operations.
Include Bash shell snippets where appropriate to demonstrate cross-platform usage.
Present Azure CLI examples before or alongside PowerShell to avoid a 'Windows-first' impression.
Explicitly mention that PowerShell examples are platform-agnostic only if they are tested on Linux/macOS, or clarify any platform-specific limitations.
Where possible, provide REST API examples using curl or similar cross-platform tools.
Review screenshots and UI instructions to ensure they are not overly Windows-specific if accessed via browser.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

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

Recommendations:

Provide equivalent Azure CLI (az) examples and scripts for migration tasks, alongside PowerShell.
Explicitly mention that migration can be performed from Linux/macOS environments using Azure CLI or cross-platform PowerShell Core.
Include Bash script examples or references for common migration tasks.
Clarify any limitations or differences when using Linux/macOS versus Windows for migration.
Add a section or note about cross-platform support and tooling options for users not on Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally provides cross-platform guidance for certificate generation using OpenSSL, which is available on both Windows and Linux. However, there is a noticeable Windows bias in several areas: (1) Windows tools and patterns (IIS, PowerShell, Windows file paths) are mentioned before or more prominently than their Linux equivalents; (2) The Azure PowerShell example for uploading certificates is provided, but there is no equivalent Azure CLI (cross-platform) example; (3) The IIS section is listed before Apache and NGINX, and the PowerShell script uses Windows-style file paths.

Recommendations:

Add Azure CLI examples alongside or before Azure PowerShell for certificate upload and configuration, as CLI is cross-platform.
When referencing web servers, alternate the order (e.g., list Apache or NGINX before IIS, or group them without implied priority).
Include Linux-style file paths in examples (e.g., /home/user/contoso.cer) or note that file paths should be adapted to the user's OS.
Explicitly state that all OpenSSL commands work identically on Linux and Windows, and provide any OS-specific caveats if needed.
Where possible, provide screenshots or instructions for both Windows and Linux environments (e.g., adding root certificates to trusted stores).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a strong Windows and PowerShell bias. PowerShell (and specifically Windows PowerShell) is presented as the primary and recommended runbook type, with extensive detail and examples provided only for PowerShell. Windows-specific paths (e.g., C:\modules), environment variables, and tools are referenced throughout, while Linux equivalents are rarely mentioned or are only briefly addressed. There are no Linux-specific code examples, and Linux support is often described in terms of limitations or as an afterthought. Python runbooks receive less coverage and lack parity in example depth compared to PowerShell. Hybrid Runbook Worker support for Linux is mentioned but not illustrated with practical examples.

Recommendations:

Provide Linux-specific examples for both PowerShell (PowerShell Core) and Python runbooks, including file paths, environment variables, and troubleshooting steps relevant to Linux environments.
Avoid referencing Windows paths (e.g., C:\modules, C:\usr\src\PSModules) exclusively; include Linux path examples (e.g., /usr/src/PSModules) wherever file system access is discussed.
Balance the depth of examples and troubleshooting between PowerShell and Python runbooks, ensuring Python users (especially on Linux) have equivalent guidance.
When discussing environment variables or configuration (such as PYTHON_2_PATH), include Linux shell equivalents and usage patterns.
Explicitly call out Linux support and limitations in each runbook type section, and provide clear guidance for Linux Hybrid Runbook Worker scenarios.
Where Windows-only features or limitations exist, clearly label them as such and, where possible, suggest Linux alternatives or workarounds.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows/PowerShell bias by focusing primarily on PowerShell examples, tools, and workflows. PowerShell is consistently mentioned first, with detailed steps and REST API payloads centering on PowerShell runbooks and modules (e.g., Az PowerShell, Get-Module). Linux/Python support is referenced but lacks equivalent depth, examples, or tooling guidance. There are references to Linux (e.g., Python .whl files for cp310 Linux OS), but no Linux shell or CLI examples, and the documentation assumes familiarity with Windows/PowerShell-centric patterns.

Recommendations:

Provide equivalent Linux/Python examples for all workflows, including REST API payloads and portal steps.
Include examples using Azure CLI and bash for managing runtime environments and runbooks, not just PowerShell.
When listing scripting languages or runtime options, alternate the order or explicitly state parity between PowerShell and Python.
Offer guidance on using Linux-native packaging (e.g., .tar.gz, pip) and troubleshooting for Python/Linux environments.
Add screenshots and walkthroughs for Python runbooks and Linux-based runtime environments, not just PowerShell.
Reference Linux tools and patterns (e.g., bash, shell scripts) alongside Windows/PowerShell tools.
Clarify which features or modules are exclusive to PowerShell/Windows and which are available for Python/Linux, to set clear expectations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally attempts to be cross-platform, but there are several areas where Windows-specific tools, shells, or patterns are given prominence or appear before Linux/macOS equivalents. PowerShell and Windows Command Prompt (Cmd) are often featured, sometimes before bash or Linux-native instructions. In addition, the use of 'command prompt' as a generic term can be confusing for Linux users, and some sections (such as virtual environment activation) provide more detailed or multiple Windows options compared to Linux/macOS.

Recommendations:

Ensure that Linux/macOS instructions are always presented alongside Windows instructions, and avoid listing Windows options first by default.
Use neutral terminology such as 'terminal' instead of 'command prompt' when referring to the shell, or clarify when a step is OS-specific.
Where multiple shell options are shown (e.g., bash, Cmd, PowerShell), always include Linux/macOS bash first, or present all options in parallel tabs.
For PowerShell-specific examples, provide equivalent bash or shell commands for Linux/macOS users where possible.
Review all code snippets and instructions to ensure parity in detail and clarity for both Linux/macOS and Windows users.
Consider adding a short section at the start clarifying that all steps are supported on Linux, macOS, and Windows, and that examples are provided for each.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. In several places, Windows-specific tools, paths, or behaviors are mentioned before or instead of Linux equivalents. For example, the use of Windows-style environment variable syntax (e.g., %HOME%\typescript), the explicit mention of Windows-only settings (e.g., WEBSITE_NODE_DEFAULT_VERSION), and the use of Windows paths (e.g., d:\home\data\SitePackages) without always providing Linux alternatives. Some instructions and examples are Windows-centric or lack Linux-specific guidance, even though Azure Functions is cross-platform.

Recommendations:

For every Windows-specific example or path (e.g., %HOME%\typescript, d:\home\data\SitePackages), provide the Linux equivalent (e.g., $HOME/typescript, /home/site/wwwroot/SitePackages).
When describing OS-specific behaviors (such as environment variable delimiters), always mention Linux behavior first or equally, and clarify differences explicitly.
For settings that are Windows-only (e.g., WEBSITE_NODE_DEFAULT_VERSION), clearly state the Linux alternative or note if not applicable.
When referencing tools (e.g., Azure PowerShell), mention Azure CLI alongside it, and provide CLI examples where possible.
Audit all sample values and code snippets to ensure parity between Windows and Linux, especially for file paths and environment variable syntax.
Add explicit Linux examples for local development and deployment scenarios, not just references to local.settings.json.
Review and update legacy references (such as d:\ paths) to clarify their relevance for Windows only, and provide Linux context.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. Windows-specific tools and configuration steps are often mentioned before their Linux equivalents, and some instructions (such as ReadyToRun and debugging) provide more detail or default to Windows scenarios. Azure PowerShell and Visual Studio (Windows-only) are listed as primary options for resource creation and deployment, while Linux-specific workflows and tools are less emphasized or only mentioned after Windows. Some CLI examples default to Windows, and Linux-specific nuances are not always explained in equal depth.

Recommendations:

Ensure that all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
When listing tools or workflows (e.g., Visual Studio, PowerShell), always include Linux-friendly alternatives (e.g., VS Code, Azure CLI, Bash scripts) and avoid listing Windows options first by default.
For sections like ReadyToRun, debugging, and deployment, provide Linux-specific instructions and troubleshooting tips alongside Windows ones, not just as afterthoughts or in separate tabs.
Highlight cross-platform tools (such as Azure CLI and VS Code) as primary options, and clarify when a tool is Windows-only.
Where PowerShell is mentioned, provide Bash or shell equivalents for Linux users.
Audit all code snippets and command-line instructions to ensure Linux users can follow along without ambiguity or extra research.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias by listing Windows-centric tools (Visual Studio, PowerShell) before cross-platform or Linux-native alternatives, and by providing more detailed instructions and references for Windows-specific development environments. While the document does mention Linux and macOS support in several places and includes cross-platform tools like Visual Studio Code and Core Tools, Windows tools and patterns (such as Visual Studio and PowerShell) are often mentioned first or given more prominence. There are also more detailed instructions for changing settings in Visual Studio (a Windows-first IDE), and PowerShell is listed as a recommended HTTP test tool before Linux-native alternatives like curl.

Recommendations:

Ensure that Linux and macOS development environments are given equal prominence to Windows tools in all tables and lists (e.g., mention Visual Studio Code and CLI before or alongside Visual Studio).
Provide Linux/macOS-specific instructions or examples where Windows-specific instructions are given (e.g., changing ports or settings in Visual Studio).
When listing HTTP test tools, list cross-platform or Linux-native tools (such as curl or HTTPie) before or alongside Windows tools like PowerShell.
Explicitly mention Linux/macOS terminal usage and provide example commands where relevant, not just 'command prompt or terminal'.
Where possible, include screenshots or walkthroughs for Linux/macOS environments, not just Windows/Visual Studio.
Avoid assuming Visual Studio is the default or primary development environment; clarify that Visual Studio Code and CLI are first-class options on all platforms.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation page focuses exclusively on C# and .NET examples, with all code samples and explanations tailored to these technologies. There are no examples or references to Linux-specific tools, shell commands, or cross-platform development environments. The only mention of local development refers to 'local.settings.json', which is not platform-specific, but all code and context are .NET-centric. There is a placeholder for a JavaScript example, but it is not provided. No Linux shell, bash, or non-Windows development workflows are mentioned, and the documentation implicitly assumes a Windows/.NET development environment.

Recommendations:

Add equivalent examples for JavaScript, Python, and other supported languages, especially for Linux/macOS users.
Include instructions or notes about using Azure Functions on Linux and macOS, such as differences in local development or deployment.
Provide shell (bash) command examples for managing app settings or local development, alongside any PowerShell or Windows-specific instructions.
Ensure that any references to file paths, environment variables, or tooling are cross-platform or include both Windows and Linux/macOS variants.
Complete the TODO for JavaScript examples and consider adding Python examples where relevant.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-centric bias by providing only PowerShell commands for Active Directory configuration, referencing Windows-specific tools and registry keys, and omitting equivalent Linux/Unix commands or tools for managing Kerberos, LDAP, or AD integration. Windows terminology and tools are used exclusively or introduced before any mention of cross-platform or Linux alternatives. There are no examples or guidance for Linux-based AD management or Kerberos configuration, despite the relevance for NFS and dual-protocol volumes.

Recommendations:

Provide equivalent Linux/Unix command-line examples (e.g., using 'kadmin', 'ldapmodify', or 'realm' for Kerberos and LDAP configuration) alongside PowerShell commands.
Reference cross-platform tools and procedures for managing AD integration, such as Samba, SSSD, or MIT Kerberos, especially for NFS and dual-protocol scenarios.
Avoid Windows-specific registry and Group Policy references without mentioning how similar settings can be managed on Linux systems.
Include explicit sections or notes for Linux administrators, especially where NFS, Kerberos, or LDAP integration is discussed.
Balance the order of presentation so that Linux and Windows methods are introduced together, or provide parallel instructions for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Bash and Windows CMD examples for Maven and Azure CLI commands, but consistently lists Windows CMD examples after Bash, which is a positive sign. However, there are some subtle signs of Windows bias: (1) The documentation refers to 'command prompt' alongside 'terminal', which is a Windows-centric term; (2) The use of 'cmd' tabs and examples is prevalent, but there are no explicit PowerShell examples, which is good; (3) In the Java versions table, Windows is listed before Linux, and for Functions 2.x, Linux support is marked as 'n/a' without further explanation; (4) Some instructions refer to 'command prompt, Bash, or Terminal', but do not always clarify Linux-specific nuances; (5) There are no Linux-specific troubleshooting or environment setup notes, and the documentation does not mention WSL or common Linux distributions.

Recommendations:

Clarify that 'command prompt' refers to Windows and 'terminal' to Linux/macOS, or use 'terminal' as a generic term.
Wherever possible, provide parity in troubleshooting steps for both Windows and Linux, especially for environment variables and file paths.
In tables (such as Java version support), consider listing Linux before or alongside Windows, or alphabetically, to avoid implicit prioritization.
Add Linux-specific notes where relevant, such as differences in environment variable setup, file permissions, or common issues on Linux.
Consider including at least one example using PowerShell (if relevant), but ensure Bash and Linux-native instructions are always present and up-to-date.
Explicitly mention support for WSL (Windows Subsystem for Linux) if applicable, and provide guidance for users on that platform.
Where 'n/a' is used in tables (e.g., Functions 2.x on Linux), provide a brief explanation for the lack of support.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a subtle Windows bias in several areas. References to 'command prompt' and 'Terminal or command prompt' are used throughout, which implicitly prioritizes Windows terminology over cross-platform or Linux-native terms (such as 'shell' or 'terminal'). In the publishing section, remote build is recommended specifically for users developing on Windows, and local build is discouraged for Windows users, but there is no explicit guidance for Linux/macOS users. The documentation also references Visual Studio Code and Azure Functions Core Tools, which are cross-platform, but does not mention Linux-specific shells or package managers. There are no explicit PowerShell-only examples, but the overall pattern is to mention Windows/Windows tools and terminology first or exclusively.

Recommendations:

Replace 'command prompt' with 'terminal' or 'shell', or use 'terminal (command prompt on Windows)' to clarify cross-platform usage.
When discussing publishing and build options, provide explicit instructions and recommendations for Linux/macOS users, not just Windows.
Where tools are referenced (e.g., Visual Studio Code, Azure Functions Core Tools), clarify their cross-platform availability and provide Linux/macOS installation links or notes.
Include Linux/macOS-specific notes or examples where relevant, such as using Bash, zsh, or common Linux file paths.
Avoid phrases like 'develop locally on Windows' without also mentioning Linux/macOS, or add parallel statements for those platforms.
Review all code snippets and command-line instructions to ensure they are platform-neutral (e.g., use $ for shell prompts, avoid Windows path separators unless necessary).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally presents Windows/SMB concepts and terminology before or with more detail than Linux/NFS equivalents, especially in the SMB section. Windows tools and patterns (Active Directory, NTFS ACLs, Kerberos/NTLM, SID translation) are referenced as defaults, while Linux/Samba support is described as unofficial. There are no Linux command-line examples for SMB access or identity mapping, and Linux tools for SMB (e.g., smbclient, mount.cifs) are not mentioned. The NFS section is more Linux-focused, but the SMB section lacks Linux parity.

Recommendations:

Provide Linux command-line examples for accessing SMB shares (e.g., using smbclient or mount.cifs) alongside Windows examples.
Mention and briefly describe Samba and its configuration for Linux clients, including any caveats or best practices for interoperability with Azure NetApp Files.
Clarify the support status for Linux SMB clients, and provide guidance or links for troubleshooting common interoperability issues.
When discussing identity management and permissions, include Linux/Samba equivalents (e.g., mapping POSIX users/groups to SMB SIDs, using winbind or sssd).
Balance the order of presentation so that Linux and Windows tools/concepts are introduced together, or alternate which is presented first in each section.
Add references to Linux documentation for SMB and NFS, not just Windows/NTFS/Active Directory.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias in several areas. It provides detailed instructions and screenshots for managing LDAP POSIX attributes using Windows-only tools (Active Directory Users and Computers MMC snap-in), without mentioning or providing equivalent Linux-based methods. The only explicit example for editing POSIX attributes is via Windows, and there are no Linux or cross-platform alternatives shown. Additionally, the order of presentation and terminology often assumes a Windows-centric environment, with Windows tools and workflows described first or exclusively.

Recommendations:

Include equivalent Linux-based instructions for managing LDAP POSIX attributes, such as using ldapmodify, ldapadd, or graphical tools like Apache Directory Studio.
Provide examples or references for configuring and managing dual-protocol volumes from Linux clients, including attribute management and troubleshooting.
Balance the documentation by presenting both Windows and Linux workflows side by side, especially in sections that currently only mention Windows tools.
Add screenshots or command-line examples for Linux environments where appropriate, to ensure parity and inclusivity for non-Windows administrators.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. In sections describing how to create and manage snapshots, Windows-oriented tools (PowerShell) are mentioned explicitly and often before or instead of Linux equivalents. There are no explicit Linux shell (bash) or scripting examples, and the documentation does not mention Linux-native tools or provide Linux-specific guidance, despite Azure NetApp Files being commonly used in Linux environments (e.g., NFS volumes).

Recommendations:

When listing management tools, mention Azure CLI and REST API before or alongside PowerShell, as these are cross-platform and commonly used in Linux environments.
Provide explicit Linux shell (bash) command examples for snapshot management, especially when referencing scripting or automation.
Include references or links to Linux-native tools or workflows (e.g., using cron jobs with Azure CLI for automated snapshots).
When discussing client-side restore operations, include both Windows (SMB) and Linux (NFS) client examples, showing how to access and restore files from snapshots on each platform.
Ensure that any scripting guidance is cross-platform, or provide parallel examples for both PowerShell and bash.
Review the order of tool mentions to avoid always listing Windows/PowerShell first, especially in summary or introductory lists.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation 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 cross-platform examples, and the PowerShell examples are presented first and in detail, which may disadvantage Linux users.

Recommendations:

Provide explicit Azure CLI command examples alongside PowerShell for all steps, not just as a note.
Include Linux shell (bash) command examples where relevant, especially for NFS-related operations.
Present CLI and PowerShell examples in parallel or in separate tabs to avoid prioritizing Windows tools.
Clarify that all operations can be performed from any OS using Azure CLI, not just from Windows/PowerShell environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Azure CLI (Bash) and Azure PowerShell examples for all major scenarios, which is positive for cross-platform parity. However, there are subtle signs of Windows bias: (1) Windows/PowerShell tools and patterns are mentioned first in several places, such as the use of CommandLineToArgvW (a Windows API) for argument parsing and Connect-AzAccount for authentication; (2) PowerShell is given equal or greater prominence than Bash/CLI, despite Bash being more common on Linux; (3) Some explanations and troubleshooting tips reference PowerShell-specific constructs (like $ErrorActionPreference and Start-Sleep) before or instead of Bash equivalents; (4) The documentation references Windows-specific APIs and tools (e.g., CommandLineToArgvW) without always providing Linux context.

Recommendations:

When describing argument parsing, mention both Windows (CommandLineToArgvW) and the equivalent Linux/Bash parsing mechanisms, or clarify that the underlying container is Linux-based and explain how arguments are parsed in that context.
When referencing authentication (e.g., Connect-AzAccount), provide equivalent CLI/Bash commands for Linux users, such as 'az login --identity'.
For error handling and troubleshooting, provide Bash equivalents to PowerShell constructs (e.g., explain 'set -e' and 'trap' in Bash alongside $ErrorActionPreference in PowerShell).
When listing system environment variables or output handling, clarify any differences in behavior between Linux (Bash) and Windows (PowerShell) shells.
Wherever possible, present CLI/Bash examples before PowerShell, or alternate the order, to avoid reinforcing a Windows-first perspective.
Review all references to Windows-specific APIs or tools and ensure Linux users are not left without context or alternatives.

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 instructions are often more detailed or appear before Linux/macOS equivalents. PowerShell is used for manual installation on Windows, and the Visual Studio workflow is described in detail, while Linux and macOS workflows are less emphasized. However, Linux and macOS installation steps are present and reasonably complete.

Recommendations:

Ensure parity in detail and order: Present Linux, macOS, and Windows installation instructions in the same level of detail and in a consistent order (e.g., always Linux, macOS, then Windows, or vice versa, but consistently).
Add Linux/macOS equivalents for Windows tools: Where Windows-specific tools like Chocolatey or Winget are mentioned, consider mentioning Homebrew for macOS and common package managers for Linux (e.g., apt, yum, or snap) if available.
Balance editor recommendations: Visual Studio is Windows-only; consider highlighting cross-platform editors (e.g., Visual Studio Code) more prominently and clarify platform limitations of Visual Studio.
Provide shell examples for all platforms: Where PowerShell is used for Windows, ensure Bash or shell equivalents are provided for Linux/macOS where relevant.
Avoid Windows-first ordering: When listing installation options or steps, avoid always listing Windows first unless there is a strong user base justification; consider rotating or alphabetizing.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing PowerShell-specific instructions and links (such as 'import-export-ps.md'), and by mentioning Azure PowerShell before Azure CLI when discussing configuration. There are no explicit Linux or cross-platform CLI examples or references, and no mention of Bash or Linux-specific workflows.

Recommendations:

Provide equivalent Azure CLI (cross-platform) instructions and links alongside or before PowerShell references.
Update references such as 'import-export-ps.md' to include or point to CLI-based export/import documentation.
Explicitly mention that all steps can be performed on Linux, macOS, and Windows, and provide sample commands for each where applicable.
Ensure that tool-agnostic language is used when possible, and avoid defaulting to Windows/PowerShell-centric terminology.
Add a section or callout for Linux/macOS users, highlighting any differences or confirming parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page is generally neutral and focused on NFS, which is predominantly a Linux/UNIX protocol. However, in the section addressing Windows client performance, only Windows-specific tools and PowerShell commands are provided, with no equivalent Linux examples for mounting or configuration. This introduces a subtle Windows bias by assuming or prioritizing Windows client scenarios in a Linux-centric context.

Recommendations:

When providing Windows-specific commands (such as PowerShell for enabling CaseSensitiveLookup), also provide equivalent Linux commands or configuration steps for common Linux NFS client scenarios.
For mount examples, include both Windows and Linux command-line examples side by side, especially since NFS is more commonly used in Linux environments.
If discussing client-side configuration or troubleshooting, ensure parity by addressing both Windows and Linux clients, or clarify when a scenario is Windows-specific.
Consider reordering or grouping examples so that Linux (the primary NFS use case) is presented first, or at least equally, before Windows-specific guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing detailed, step-by-step instructions for setting SACLs using Windows GUI tools, while the equivalent Linux (NFSv4.1) instructions are minimal and defer to another page. PowerShell is used as the primary example for feature registration, with Azure CLI only mentioned secondarily. There are no Linux command-line examples for managing ACLs or auditing, and Windows tools and workflows are described in more detail and appear first.

Recommendations:

Provide equivalent, step-by-step instructions for setting Audit ACEs on NFSv4.1 volumes from a Linux host, including example commands (e.g., using setfacl or nfs4_setfacl).
Present Azure CLI commands before or alongside PowerShell commands for feature registration, to avoid implying Windows is the default platform.
Include screenshots or terminal output examples for Linux-based workflows, similar to the Windows GUI screenshots.
Explicitly mention and link to Linux tools for managing ACLs and auditing, not just refer to another documentation page.
Balance the order of presentation so that Linux and Windows instructions are given equal prominence, or use tabs to separate platform-specific instructions.

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 under 'Test the DNS resolution', only the Windows-specific command ('ipconfig /flushdns') is provided for clearing the DNS cache, with no mention of Linux or macOS equivalents. This subtly prioritizes Windows users and omits guidance for those on other platforms.

Recommendations:

When providing OS-specific commands (such as clearing DNS cache), include equivalent instructions for Linux (e.g., 'sudo systemd-resolve --flush-caches' or 'sudo service nscd restart') and macOS (e.g., 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder').
Wherever possible, avoid referencing only Windows tools or commands in troubleshooting or automation sections.
Consider adding a short note or table listing common DNS cache flush commands for Windows, Linux, and macOS to ensure parity.
Review other sections for subtle platform assumptions and ensure all users are equally supported.

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, the only example for clearing DNS cache is for Windows (`ipconfig /flushdns`), with no mention of Linux or macOS equivalents. This presents a subtle 'windows_first' and 'missing_linux_example' bias.

Recommendations:

When providing command-line troubleshooting steps (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`).
If referencing OS-specific tools or commands, present them in parallel (Windows, Linux, macOS) or link to official documentation for each platform.
Review other troubleshooting or advanced sections to ensure parity in examples and instructions for all major operating systems.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment using GitHub Codespaces and .NET, but does not provide explicit Linux or cross-platform command-line examples. It references the Azure Developer CLI (azd) and dotnet CLI, which are cross-platform, but omits any mention of Linux-specific workflows, shell commands, or deployment patterns. There are no Windows-specific tools or PowerShell commands, but the lack of Linux/Unix shell examples and the assumption of a browser-based or Visual Studio Code workflow may disadvantage Linux users.

Recommendations:

Explicitly mention that all CLI commands (dotnet, azd) work on Linux, macOS, and Windows.
Provide example shell commands for Linux/macOS users (e.g., using bash instead of assuming a codespace terminal).
Clarify that the tutorial does not require Windows or Visual Studio, and can be completed entirely on Linux or macOS.
Include notes or callouts for Linux users regarding file paths, environment variables, and browser access.
If referencing GitHub Codespaces, mention that it is a Linux-based environment and suitable for all platforms.

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 more detailed, with extensive example scripts and a dedicated cmdlet reference, while the Azure CLI section is less detailed and lacks a similar command reference. There are no Linux-specific shell examples (e.g., Bash), and the CLI examples are not explicitly shown in a Linux context. There is no mention of Linux tools or workflows, and the documentation implicitly assumes familiarity with Windows-centric tools (PowerShell) by providing them before CLI.

Recommendations:

Present Azure CLI examples before PowerShell, or provide both in parallel tabs to avoid implying a Windows-first workflow.
Expand the Azure CLI section to include a comprehensive command reference similar to the PowerShell cmdlet reference.
Add explicit Bash/Linux shell examples or notes clarifying that Azure CLI commands work cross-platform, including on Linux and macOS.
Where possible, mention that Azure CLI is the recommended cross-platform tool for scripting and automation, especially for Linux users.
Ensure parity in detail and troubleshooting notes between PowerShell and CLI sections.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows Command Prompt and PowerShell before mentioning Linux/macOS, and gives explicit PowerShell examples. While Linux/macOS commands are included, Windows instructions are consistently presented first, and PowerShell is given equal prominence to Bash, which may suggest a slight Windows bias.

Recommendations:

Alternate the order of platform instructions, sometimes listing Linux/macOS first.
Group all platform-specific instructions under clearly labeled headings, or use tabs to avoid implicit prioritization.
Consider reducing the prominence of PowerShell unless there are unique steps required for Windows users.
Where possible, provide cross-platform commands (e.g., using env files or cross-platform tools) to minimize OS-specific instructions.
Explicitly state that all steps are supported on Linux/macOS and Windows, to reinforce parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes both setx (cmd) and PowerShell commands, which may give the impression of Windows being the primary platform. Linux/macOS instructions are present but appear after Windows examples. There are no missing Linux examples, but the ordering and inclusion of multiple Windows-specific shells (cmd, PowerShell) before Linux can be seen as a subtle Windows bias.

Recommendations:

Present Linux/macOS and Windows instructions in parallel (side-by-side tabs or clearly separated sections) rather than listing Windows first.
Consider listing Linux/macOS first, as Go developers often use these platforms.
If showing multiple Windows shells (cmd, PowerShell), also mention common Linux shells (bash, zsh) for parity, or consolidate Windows instructions to reduce perceived bias.
Explicitly state that all commands are cross-platform unless otherwise noted.
Ensure that any troubleshooting or advanced sections do not assume Windows as the default environment.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is focused exclusively on ASP.NET Core and C# (.NET) development, which is traditionally associated with Windows environments. There are no examples or instructions for Linux or cross-platform scenarios, such as running the app on Linux, using Linux-based tools, or deploying in a non-Windows environment. All code and setup instructions assume a Windows-centric workflow, and there is no mention of Linux-specific considerations or parity.

Recommendations:

Include explicit instructions or notes for running the ASP.NET Core app on Linux (e.g., Ubuntu) and macOS, such as using the dotnet CLI on those platforms.
Add examples or references for deploying and managing the application in Linux environments, including any differences in environment variables, file paths, or permissions.
Mention that ASP.NET Core is cross-platform and can be run on Windows, Linux, and macOS, and provide links to relevant documentation for non-Windows users.
If any Azure CLI or scripting is required, provide both PowerShell (Windows) and Bash (Linux/macOS) examples.
Clarify that the Azure portal steps are platform-agnostic, but any local development steps should consider cross-platform compatibility.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page focuses exclusively on using Visual Studio Code and its Azure Functions extension, without providing any OS-specific instructions or examples. However, it implicitly assumes a Windows environment by referencing keyboard shortcuts (e.g., F1) and does not mention or show any Linux- or macOS-specific guidance, terminal commands, or troubleshooting. There are no CLI or shell examples, and no mention of Linux-specific tools or patterns. This results in a lack of parity for Linux users who may use different workflows or encounter different issues.

Recommendations:

Explicitly state that the instructions apply equally to Windows, Linux, and macOS, or provide OS-specific notes where behavior differs.
Include alternative instructions or notes for Linux/macOS users, such as terminal commands, keyboard shortcuts (e.g., Cmd vs Ctrl), and common troubleshooting steps.
Provide at least one example of running or deploying the function using a Linux shell or terminal, especially for steps that may differ (e.g., file paths, environment variables).
Mention any Linux prerequisites or dependencies if applicable (e.g., installing Azure Functions Core Tools on Linux).
Ensure that referenced tools and extensions are available and supported on Linux, and provide links or instructions for Linux installation where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates mild Windows bias by listing the Windows tool (robocopy) for SMB migration before mentioning Linux/Unix alternatives, and by referencing robocopy as the primary example for SMB workloads. There are no explicit Linux SMB tool examples (such as smbclient or Linux-native copy commands for SMB), and the only Linux example given is rsync for NFS. The documentation does not provide command-line examples for either platform, but the pattern of mentioning Windows tools first and exclusively for SMB suggests a subtle bias.

Recommendations:

Include Linux-native SMB migration tools (e.g., smbclient, cifs-utils, or standard cp/mv commands mounted via CIFS) alongside robocopy when discussing SMB data migration.
Alternate the order of tool presentation (sometimes listing Linux tools first) to avoid the appearance of platform preference.
Provide example commands for both Windows and Linux environments for common migration scenarios.
Explicitly state that both Windows and Linux clients can access and migrate data to SMB shares, and reference documentation for both.
Consider a table comparing migration tools across platforms (Windows, Linux, macOS) for both NFS and SMB.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation presents Windows (SMB) client instructions and screenshots before Linux (NFS) client instructions, and provides more detailed step-by-step guidance for Windows users (e.g., File Explorer navigation, screenshots). Windows tools and UI patterns (File Explorer, 'dir' command) are described in detail, while the Linux section is briefer and only mentions the 'df -h' command. There is no PowerShell-heavy bias, and Linux is not omitted, but the ordering and depth favor Windows.

Recommendations:

Present Linux and Windows client instructions in parallel or alternate the order in different sections to avoid always listing Windows first.
Provide equally detailed, step-by-step instructions and screenshots for Linux users (e.g., show terminal navigation, example 'df -h' output, and how to interpret it).
Mention common Linux desktop environments/tools (such as GNOME Files or KDE Dolphin) for users who may use graphical interfaces, similar to File Explorer on Windows.
Clarify that both SMB and NFS monitoring are equally supported, and consider a table comparing commands and outputs side-by-side for both platforms.
Ensure that any references to REST API or CLI usage include example commands for both Windows and Linux shells where relevant.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents environment variable setup instructions in the order: Windows CMD, PowerShell, then macOS/Linux, which may subtly prioritize Windows users. However, all platforms are covered and there are no missing Linux examples or exclusive use of Windows tools.

Recommendations:

Present environment variable instructions for all platforms together, or start with a neutral (e.g., bash) example.
Consider using a tabbed or side-by-side format for platform-specific commands to give equal prominence to Windows, macOS, and Linux.
Explicitly state that the instructions apply to all major platforms to reinforce cross-platform parity.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display explicit Windows bias in terms of using Windows-specific tools, PowerShell, or Windows-first patterns. However, it lacks any mention of Linux-specific instructions, tools, or examples. There are no shell/terminal commands, deployment instructions, or troubleshooting steps for either Windows or Linux, but the absence of any Linux context or parity checks (such as bash examples, Linux environment notes, or cross-platform deployment guidance) constitutes a subtle bias by omission.

Recommendations:

Add explicit notes or examples for Linux environments, such as how to configure Durable Task Scheduler on Linux hosts.
If there are any OS-specific steps (e.g., environment variables, file paths, service management), provide both Windows and Linux variants.
Include bash or shell command equivalents where appropriate, especially if PowerShell or Windows CLI examples are ever added.
Clarify that the SDKs and features work identically on both Windows and Linux, or note any differences.
Consider adding a section or callout on cross-platform support and any known issues or best practices for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation is generally cross-platform and avoids explicit Windows bias in its main instructions, focusing on Visual Studio Code and Azure Functions tooling, which are available on all major platforms. However, in the Troubleshooting section, there is a Windows-specific note ('When running on Windows, make sure that the default terminal shell for Visual Studio Code isn't set to WSL Bash.') that places Windows considerations before Linux/WSL ones and does not mention equivalent issues or solutions for Linux or macOS users. There are no PowerShell-specific commands, Windows-only tools, or missing Linux/macOS examples, but the troubleshooting advice is Windows-centric.

Recommendations:

In the Troubleshooting section, provide equivalent troubleshooting steps for Linux and macOS users, such as checking the default terminal shell or addressing common issues specific to those platforms.
When mentioning Windows-specific advice, also mention if similar issues can occur on Linux/macOS, or clarify that the advice is only relevant for Windows users.
Consider adding a note at the start of the troubleshooting table indicating that solutions are applicable to all platforms unless otherwise specified, and explicitly call out platform-specific steps.
Review included files (INCLUDEs) to ensure they do not introduce additional Windows bias, such as only referencing Windows paths or commands.

Create pull request

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