Scan Details - Linux-first Docs for Azure

276

Pages Scanned

58

Pages Flagged

276

Changed Pages

21.0%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:00:07 Scan started

Scan Information

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

Finished At: In Progress

Status: in_progress

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell command-line examples for scripting and automation, with no mention of Azure CLI (which is cross-platform and more commonly used on Linux/macOS). Installation instructions and references are exclusively for PowerShell. There are no Linux- or bash-oriented examples, and the scripting sections assume a Windows/PowerShell environment. The ordering of examples also places PowerShell before ARM templates, and there is no parity for Linux users.

Recommendations:

Add equivalent Azure CLI (az) command examples alongside PowerShell for all scripting and automation tasks.
Include bash shell script examples where appropriate, especially for resource creation and management.
Reference Azure CLI installation guides and usage, not just PowerShell.
Where possible, use cross-platform language in instructions (e.g., 'Open your terminal' instead of 'Open PowerShell').
Clearly indicate that both PowerShell and Azure CLI are supported, and provide links to both sets of documentation.
Consider the order of presentation: present Azure CLI and PowerShell examples together or alternate their order to avoid implicit prioritization.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell examples for custom role creation and assignment, and by referencing Azure PowerShell before (or instead of) cross-platform tools like Azure CLI. There are no equivalent Azure CLI or REST API examples for Linux/macOS users, and the only code sample is in PowerShell. While Azure CLI and REST API are mentioned in passing, practical guidance and examples are absent.

Recommendations:

Provide equivalent Azure CLI examples alongside PowerShell for all role assignment and custom role creation tasks.
Include REST API examples where appropriate, especially for automation scenarios.
When listing tools, mention Azure CLI first or equally with PowerShell to reflect its cross-platform nature.
Add a note clarifying that PowerShell examples are for Windows and that CLI/REST API examples are available for Linux/macOS users.
Ensure that all code samples are available in both PowerShell and Azure CLI to improve accessibility for non-Windows users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page references Azure PowerShell in the 'Next steps' section as the only example for creating an autoscaling, zone redundant application gateway, without mentioning or linking to equivalent Azure CLI (cross-platform) or ARM template instructions. There are no Linux or cross-platform command-line examples or references, and the only tooling mentioned is PowerShell, which is traditionally associated with Windows environments.

Recommendations:

Add links to equivalent Azure CLI tutorials or documentation for creating and managing autoscaling, zone-redundant application gateways.
Include ARM/Bicep template examples for infrastructure-as-code scenarios, which are platform-agnostic.
In the 'Next steps' section, ensure that both PowerShell and CLI options are presented, ideally with CLI listed first or alongside PowerShell to emphasize cross-platform support.
Explicitly mention that Azure CLI and ARM/Bicep templates can be used from Linux, macOS, and Windows, to reinforce platform neutrality.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by presenting Azure PowerShell instructions before Azure CLI, referencing PowerShell-specific cmdlets for status checks (even in the CLI section), and omitting explicit Linux or Bash shell examples. The use of PowerShell is emphasized, and there are no Linux-specific or cross-platform command-line examples beyond the Azure CLI. Additionally, the documentation does not mention or illustrate Linux tools, shells, or workflows, which may hinder parity for Linux users.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples to prioritize cross-platform compatibility.
Ensure all command-line instructions (including status checks) are shown using both Azure CLI and PowerShell, with CLI output examples using 'az feature show' or 'az feature list' instead of PowerShell cmdlets.
Add explicit Bash/Linux shell command examples where relevant, especially for scripting or automation scenarios.
Include notes or sections on how to perform tasks in Linux environments, such as using Bash or other common Linux shells.
Where screenshots or UI steps are shown, clarify that the Azure portal is platform-agnostic, and provide CLI/automation alternatives for headless or Linux-first environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell and CLI as the primary configuration tools, with PowerShell consistently mentioned first. There are no explicit Linux-specific examples, tools, or guidance, and the only configuration walkthrough linked is for PowerShell. The documentation does not mention Bash, Linux shell, or platform-agnostic instructions, which may disadvantage Linux users.

Recommendations:

Provide equivalent Linux/Bash command-line examples alongside PowerShell, especially for configuration tasks.
When referencing configuration tools, mention Azure CLI before or alongside PowerShell, as CLI is cross-platform.
Add links to Linux-focused configuration guides or ensure that the main configuration guide covers both Windows (PowerShell) and Linux (Bash/CLI) workflows.
Clarify that Azure CLI commands can be run on Linux, macOS, and Windows, and provide sample commands in Bash syntax.
Avoid referencing only PowerShell in notes and instructions; always include CLI or REST API alternatives where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias, particularly in the Helm installation section, where Windows installation instructions (including a PowerShell/winget example) are presented before Linux instructions. The use of 'winget' (a Windows-specific package manager) is highlighted, and the PowerShell example is given more prominence. However, Linux instructions are present and functional, and most CLI examples use cross-platform tools (Azure CLI, Helm, kubectl) in Bash syntax.

Recommendations:

Present Linux and Windows installation instructions in parallel tabs or in the same order (Linux first or alphabetically) to avoid prioritizing Windows.
Provide equal detail and prominence to both Windows and Linux installation methods for Helm and other tools.
Include explicit Bash and PowerShell examples for all relevant commands, or clarify that all examples work on both platforms unless otherwise noted.
Avoid highlighting Windows-specific tools (like winget) before cross-platform or Linux-native alternatives.
Add a note clarifying that Azure CLI, Helm, and kubectl commands are cross-platform and can be run on Windows, Linux, or MacOS.

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' and .NET requirements. There are no Linux or cross-platform CLI examples (such as Azure CLI or Bash), nor are Linux-friendly tools (like tcpdump, Wireshark, or curl) mentioned. The order of presentation also puts Windows tools and patterns first, with no Linux parity.

Recommendations:

Provide equivalent Azure CLI (az) and/or Bash commands for checking Application Gateway settings alongside PowerShell examples.
Include Linux-friendly network debugging tools (e.g., tcpdump, Wireshark, curl, or mitmproxy) as alternatives to Fiddler, with basic usage instructions.
Avoid instructions that are specific to Windows environments (e.g., 'Run as administrator', .NET requirements) or provide Linux/macOS alternatives where applicable.
Explicitly state that the troubleshooting steps can be performed on any OS, and ensure screenshots or instructions are not exclusively Windows-centric.
Present cross-platform or Linux examples before or alongside Windows examples to ensure parity.

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 examples for configuring Application Gateway with Key Vault, with no equivalent Azure CLI, Bash, or Linux-oriented instructions. PowerShell is mentioned and used as the primary automation tool, and the 'Next steps' section links exclusively to a PowerShell guide. There are no Linux/Unix shell or cross-platform scripting examples, and the documentation assumes familiarity with Windows-centric tools and workflows.

Recommendations:

Provide equivalent Azure CLI (az) command examples alongside PowerShell for all configuration steps, especially for referencing Key Vault secrets and configuring Application Gateway.
Include Bash shell script examples for Linux users where automation is demonstrated.
In the 'Next steps' section, add links to guides for Azure CLI and ARM/Bicep templates, not just PowerShell.
When mentioning tools or automation approaches, present cross-platform options first or in parallel, rather than defaulting to PowerShell.
Explicitly state that all steps can be performed on Linux/macOS using Azure CLI, and provide references or links to relevant documentation.
Where screenshots or UI steps are shown, clarify that the Azure portal is cross-platform, and note any OS-specific considerations if relevant.

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 tasks, with no equivalent Bash or Linux-native CLI examples. The use of 'Set-AzContext', 'Get-AzProviderFeature', and 'Register-AzProviderFeature' in code blocks is PowerShell-specific, and there is no mention of Bash, Linux, or cross-platform CLI usage. Additionally, the tutorial link provided is PowerShell-focused, and there is no explicit guidance for Linux users.

Recommendations:

Provide Azure CLI (bash) examples alongside or before PowerShell examples for all command-line tasks, especially for registration, unregistration, and migration.
Clarify when commands are cross-platform and when they are PowerShell-specific; if using PowerShell, also show the equivalent Bash/Azure CLI syntax.
Include links to Linux-focused tutorials or documentation, or at least ensure parity in the 'Next steps' section.
Avoid assuming PowerShell as the default automation tool; mention both PowerShell and Bash/CLI options in narrative text.
Where scripts are referenced (such as migration scripts), indicate if they are cross-platform or provide Linux-compatible alternatives.

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 tools or cross-platform alternatives (such as Azure CLI or ARM templates), nor are there links to equivalent Linux-focused documentation. This suggests a bias toward Windows and PowerShell users.

Recommendations:

Include links to tutorials or guides that use Azure CLI, which is cross-platform and widely used on Linux and macOS.
When referencing command-line configuration, provide both PowerShell and Azure CLI (or Bash) examples.
Ensure that 'Next steps' sections offer parity by including Linux-friendly options alongside Windows/PowerShell instructions.
Explicitly mention that Application Gateway can be managed from any platform, and provide links to documentation for ARM templates, REST API, or Terraform for infrastructure-as-code scenarios.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell scripts for migration, without mentioning or providing examples for cross-platform tools such as Azure CLI or REST API. There are no Linux or Bash examples, and the only automation path described is via PowerShell, which is traditionally associated with Windows environments.

Recommendations:

Include equivalent Azure CLI examples for all migration steps, as Azure CLI is cross-platform and widely used on Linux and macOS.
Mention REST API options for migration where applicable, to support automation from any OS.
Provide Bash script examples alongside PowerShell, or clarify that PowerShell Core is cross-platform if that is the intended usage.
Explicitly state platform compatibility for all scripts and tools, and offer guidance for Linux/macOS users.
Add a section or FAQ addressing migration for users on non-Windows platforms, including tool recommendations and sample commands.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a moderate Windows bias. Windows tools and patterns (such as IIS and PowerShell) are mentioned before or more prominently than their Linux equivalents. The Azure PowerShell example is provided in detail, while no equivalent Azure CLI (cross-platform) example is given. The instructions for adding the certificate to a web server list IIS first, and the PowerShell section is extensive, reinforcing a Windows-centric approach.

Recommendations:

Provide Azure CLI examples alongside or before Azure PowerShell examples for certificate upload and Application Gateway configuration, as Azure CLI is cross-platform.
When listing web server configuration instructions, alternate the order (e.g., list Apache or NGINX before IIS, or group them together without preference).
Include explicit Linux/macOS instructions for tasks like adding the root certificate to the trusted store (e.g., update-ca-certificates on Linux, Keychain Access on macOS).
Where file paths are shown (e.g., C:\Users\...), include Linux-style paths as well (/home/user/...).
If referencing Windows-specific tools or articles (like the IIS certificate import guide), provide equivalent Linux resources (e.g., for Apache or NGINX certificate installation).
Consider a dedicated section or callout for Linux/macOS users where platform-specific steps differ.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. In several sections, Windows or PowerShell tools and workflows are presented before or more prominently than their Linux equivalents. For example, the Azure PowerShell example is given its own section, while Linux-specific scripting or Bash examples are not provided. The portal UI instructions and screenshots are Windows-centric, and there is no mention of Linux command-line environments beyond the Azure CLI. Additionally, the 'Development tools' and 'Clone app' features are described without clarifying cross-platform parity.

Recommendations:

Provide Bash or Linux shell script equivalents alongside PowerShell examples, especially in automation sections.
Clarify that Azure CLI commands work identically on Linux, macOS, and Windows, and consider including sample shell commands for Linux users.
Balance the order of presentation: when listing tools or commands, alternate or parallelize Windows and Linux instructions.
Include screenshots or instructions for Linux/macOS users where the experience differs, or explicitly state when the experience is the same.
Explicitly mention cross-platform compatibility for features like 'Clone app' and 'Development tools', or note any platform-specific limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias in several ways: Windows SKUs are listed before Linux, PowerShell scripting is given equal prominence to Azure CLI (which is more cross-platform), and there are no Linux shell (bash) or deployment examples outside of the Azure CLI. The use of Windows-centric terminology and tools (e.g., PowerShell, references to Windows-specific app types) is more prominent, and Linux-specific guidance is limited to a single CLI flag. There are no explicit Linux shell or deployment workflow examples, and the documentation does not address Linux-specific considerations for automation or troubleshooting.

Recommendations:

Present Linux and Windows options in parallel, rather than listing Windows first.
Include bash shell script examples for Linux users, not just Azure CLI and PowerShell.
Expand automation sections to show Linux-native scripting (e.g., bash) and workflows.
Add explicit guidance for Linux-specific deployment scenarios, such as custom containers.
Balance terminology and examples so that Linux users see their platform equally represented.
Where PowerShell is mentioned, also mention bash or sh equivalents for parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias primarily in the section addressing Azure Traffic Manager endpoints, where only a PowerShell script is provided for identifying impacted resources. There are no equivalent Bash, Azure CLI, or cross-platform alternatives, and the instructions explicitly reference PowerShell usage (e.g., 'Open PowerShell and navigate to the script location'). This may disadvantage Linux or macOS users who do not have access to PowerShell or prefer native tools. In all other areas, the documentation uses Azure Resource Graph queries and Azure CLI/REST API references, which are cross-platform.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for identifying Traffic Manager profiles with non-Azure endpoints, or at least reference how to run the PowerShell script using PowerShell Core on Linux/macOS.
When referencing scripts, clarify their cross-platform compatibility (e.g., note if the PowerShell script works with PowerShell Core on Linux/macOS).
Offer example commands using Azure CLI or REST API for all scenarios where PowerShell is suggested, ensuring Linux parity.
In step-by-step instructions, avoid assuming the user is on Windows (e.g., 'Open PowerShell') and instead provide generic, platform-neutral guidance or alternatives.

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 examples. The scripting section lists PowerShell after Azure CLI, but only the PowerShell script is shown inline, with no Bash or Linux shell script provided. There is also a lack of explicit Linux tooling or command-line workflow guidance, and the automation focus is on Windows-native scripting environments.

Recommendations:

Add a Bash or shell script example for automating certificate binding, similar to the PowerShell example.
Ensure that Azure CLI examples are shown inline, not just linked, and clarify that Azure CLI is cross-platform.
Where scripting is discussed, explicitly mention that all steps can be performed on Linux, macOS, or Windows, and provide parity in example scripts.
If referencing PowerShell, note that PowerShell Core is cross-platform, or provide both Windows PowerShell and Bash alternatives.
Include screenshots or workflow notes for Linux users where UI or file paths may differ.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing PowerShell as the first and most detailed scripting example for assigning Microsoft Graph API permissions, referencing Visual Studio (a Windows-centric IDE) for initial setup, and using PowerShell-specific modules and cmdlets. Although an Azure CLI example is included, the prominence and order of PowerShell examples, as well as the mention of Visual Studio, indicate a preference for Windows tools and workflows.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples to avoid implying PowerShell is the primary or preferred method.
Explicitly mention that all Azure CLI commands work cross-platform (Windows, Linux, macOS) and provide guidance for Linux/macOS users.
Include references to Linux-friendly development environments (e.g., VS Code, command-line deployment) instead of or in addition to Visual Studio.
Review screenshots and UI instructions to ensure they are not Windows-specific or clarify if the steps are identical across platforms.
Add a note or section highlighting parity and any differences in experience for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell examples for per-app scaling, with no equivalent examples for Linux users (such as Azure CLI or Bash). The use of PowerShell cmdlets and Windows-centric scripting patterns may exclude or confuse users who work primarily in Linux environments.

Recommendations:

Add equivalent Azure CLI examples for all PowerShell commands shown, using Bash syntax where appropriate.
Explicitly mention that PowerShell is not required and that Linux/macOS users can use Azure CLI or REST APIs.
Reorder or parallelize examples so that both PowerShell and CLI/Bash approaches are presented together.
Include a note or section on how to perform the same tasks from Linux/macOS environments.
Ensure terminology and instructions are platform-neutral where possible, or clarify when something is Windows-specific.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. Windows-specific features and limitations (such as Windows Containers subnet sizing and Windows Server Active Directory domain join) are discussed in detail, while Linux-specific scenarios receive less attention. There are no Linux command-line examples or explicit Linux configuration walkthroughs. The only explicit Linux mention is in the context of continuous deployment network dependencies, which is brief and not accompanied by broader Linux guidance or parity in examples.

Recommendations:

Add Linux-specific configuration examples, especially for common scenarios such as integrating Linux-based App Service apps with virtual networks.
Provide parity in coverage for Linux containers, including subnet sizing, resource requirements, and limitations, similar to the detailed section for Windows Containers.
Include CLI and scripting examples (e.g., Azure CLI, Bash) for both Windows and Linux environments where relevant.
Highlight any Linux-specific limitations or considerations (e.g., file system mounts, networking behaviors) to ensure users on both platforms are equally informed.
Balance the order of presentation so that Windows and Linux scenarios are introduced together, or alternate which platform is mentioned first.

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) and omitting explicit Linux deployment examples or Linux-native tools. The deployment section mentions Visual Studio deployment specifically for Windows App Service, and there are no Linux-specific instructions or examples. References to Kudu and App Service diagnostics are present, but these are available on both platforms; however, the lack of parity in deployment guidance is notable.

Recommendations:

Add explicit examples and instructions for deploying WebJobs to Linux-based App Service plans, including using cross-platform tools such as Azure CLI, zip deployment, and GitHub Actions.
Clarify in the deployment section which methods are supported on Linux App Service (e.g., Visual Studio deployment is Windows-only, but zip deployment and CI/CD pipelines work on both).
Include references to Linux-compatible development environments (such as VS Code or command-line tools) alongside Visual Studio.
Provide parity in 'Next steps' and scenario links by including Linux-focused guides or notes where applicable.
Explicitly mention any differences or limitations when running WebJobs on Linux App Service, if relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides installation instructions for the required NuGet packages using both the .NET Core CLI and the Visual Studio Package Manager Console (PowerShell-based), but does not mention or show Linux-specific workflows or tools. The order of presentation puts the Windows-centric Visual Studio/PowerShell method after the cross-platform CLI, but the only GUI-based workflow described is for Windows. There is no mention of Linux development environments, nor are there any Linux-specific troubleshooting or usage notes.

Recommendations:

Explicitly mention that the .NET Core CLI commands work on Linux, macOS, and Windows, and recommend them as the primary cross-platform method.
Add a note or section for Linux users, e.g., how to install .NET SDK and run the commands on Linux.
If GUI-based instructions are included for Visual Studio (Windows), consider adding equivalent instructions for Visual Studio Code, which is cross-platform.
Avoid referencing only Windows tools (like Package Manager Console) without mentioning cross-platform alternatives.
Include troubleshooting tips or environment setup notes for Linux users, such as setting environment variables for managed identities.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific instructions, tools, and examples (especially PowerShell and Windows environment variable management) are presented first and in greater detail. PowerShell is the default scripting language throughout, and most code samples are PowerShell-based. Windows tools and paths are referenced explicitly, while Linux equivalents are sometimes less detailed or missing (e.g., credential asset usage, runbook authentication examples, and some folder permissions). Linux instructions are present but often appear after Windows content and sometimes lack parity in depth or clarity.

Recommendations:

Provide Linux examples alongside Windows examples, especially for credential asset usage, runbook authentication, and starting runbooks via CLI (e.g., Bash/Azure CLI).
Balance the order of presentation: alternate or parallelize Windows and Linux sections rather than always presenting Windows first.
Include Linux-specific tools and commands (e.g., Azure CLI, Bash scripts) where PowerShell is used for Windows.
Expand Linux instructions to match the detail level of Windows instructions, particularly for environment variable management, permissions, and troubleshooting.
Where Windows paths or tools are referenced, provide the Linux equivalents in the same context.
Add more Linux-focused troubleshooting and operational guidance, such as log file locations, service management, and common issues.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows PowerShell and Windows-specific tools and patterns throughout. PowerShell (and its Windows-centric features) is consistently presented first and in greater detail than Python or Linux options. Many examples and known issues reference Windows file paths (e.g., C:\modules), environment variables, and cmdlets, with little or no equivalent Linux guidance. Hybrid Runbook Worker support for Linux is mentioned, but practical Linux examples or troubleshooting are missing. Python runbooks receive less detailed coverage, and Linux-specific considerations are often brief or absent.

Recommendations:

Provide Linux-specific examples and troubleshooting steps, especially for PowerShell runbooks running on Linux Hybrid Runbook Workers.
Include Linux file path examples (e.g., /usr/local/modules) alongside Windows paths in scripts and known issues.
Clarify differences in behavior, limitations, and module management between Windows and Linux Hybrid Runbook Workers.
Add parity in code samples: for every PowerShell example, provide a Python example where possible, and vice versa.
Explicitly document any features or cmdlets that are Windows-only, and suggest Linux alternatives or workarounds.
Expand the Python runbook section to include more detailed Linux usage scenarios and troubleshooting.
Reorganize sections to avoid always listing Windows/PowerShell options first; consider grouping by OS or providing parallel guidance.

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 for automation account management, with no equivalent Azure CLI (cross-platform) or Bash examples. The PowerShell sections are prominent and detailed, while Linux-native or cross-platform command-line usage is not addressed. The documentation also refers to Windows-centric tools and patterns, such as PowerShell, without mentioning or prioritizing Linux or cross-platform alternatives.

Recommendations:

Add Azure CLI (az) command examples alongside PowerShell for all automation account management tasks, including deletion and solution removal.
Include Bash shell script examples where appropriate to demonstrate cross-platform usage.
Present Azure CLI examples before or alongside PowerShell to avoid prioritizing Windows tools.
Explicitly mention that Azure CLI is available on Windows, Linux, and macOS, and provide guidance for users on non-Windows platforms.
Review all sections to ensure that Linux and macOS users are not excluded from the documented workflows.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a strong bias toward Windows and PowerShell environments. PowerShell is consistently presented as the primary or default scripting language, with detailed examples and screenshots focused on PowerShell modules and workflows. Windows-specific tools (such as PowerShell Gallery and .zip module packaging) are emphasized, and Linux/Python guidance is minimal, often relegated to brief notes. There are no concrete Linux shell or Python package management examples, and REST API samples are PowerShell-centric. This creates a perception that Windows/PowerShell is the preferred or only fully supported environment.

Recommendations:

Provide equivalent, detailed examples for Python runbooks, including REST API payloads and portal workflows.
Include Linux-specific guidance, such as using .whl files for Python, and clarify how to upload and manage Python packages (with examples).
Balance screenshots and walkthroughs to show both PowerShell and Python scenarios.
Mention Linux/Python options alongside or before Windows/PowerShell options where applicable, rather than as afterthoughts or notes.
Add troubleshooting and best practices sections for Python/Linux runbooks, similar to those for PowerShell.
Reference both PowerShell Gallery and Python Package Index (PyPI) for package sources.
Clarify any differences in supported features or limitations between PowerShell and Python environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by focusing heavily on PowerShell and Windows-centric tools and patterns. PowerShell and DSC (Desired State Configuration, a Windows technology) are mentioned repeatedly, often without equivalent emphasis on Linux-native tools or examples. The 'Modules gallery' and integration with the PowerShell Gallery are highlighted, while Linux-native automation tools or scripting languages (like Bash or Ansible) are not mentioned. Although Linux support is acknowledged, concrete Linux examples, tools, or workflows are missing, and Windows technologies are typically mentioned first or exclusively.

Recommendations:

Provide Linux-specific examples alongside PowerShell, such as Bash or Python scripts for common automation tasks.
Mention Linux-native configuration management tools (e.g., Ansible, Chef, Puppet) where relevant, or clarify integration options.
Balance references to PowerShell Gallery with mentions of Python Package Index (PyPI) or other Linux-relevant repositories.
Include explicit Linux runbook authoring and execution scenarios, not just general statements about 'heterogeneous support'.
When discussing configuration management, note support for Linux DSC or alternatives, and provide links to Linux documentation.
Ensure that examples and scenarios (such as Hybrid Runbook Worker) include both Windows and Linux use cases, with clear step-by-step guides for each.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits several forms of Windows bias. In sections describing how to generate wheel files, Windows is mentioned first and in more detail for Python 3.8, with explicit instructions to use a Windows machine, while the Linux equivalent is only provided for Python 3.10. The PowerShell cmdlets for managing Python packages are presented without any Linux/CLI/az CLI alternatives, reinforcing a Windows-centric approach. There are no examples or guidance for managing packages using Linux-native tools or cross-platform command-line interfaces, and the documentation assumes familiarity with Windows conventions and tooling.

Recommendations:

Provide equivalent Linux-based instructions and examples for all package management tasks, including generating wheel files for Python 3.8.
Include az CLI or REST API examples alongside PowerShell cmdlets to ensure cross-platform accessibility.
Explicitly mention when steps are platform-specific and offer alternatives for other platforms.
Reorder sections or examples so that Linux and Windows are given equal prominence, or present them in parallel tabs.
Clarify which steps are applicable to both Windows and Linux, and avoid assuming the user is on Windows by default.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Windows and Linux for most troubleshooting steps, with separate sections and examples for each OS. However, there is a consistent pattern of presenting Windows instructions, tools, and examples before Linux equivalents (windows_first). Windows-specific tools (such as PowerShell scripts and registry edits) are described in detail, while Linux instructions are sometimes less detailed or lack equivalent troubleshooting guidance (powershell_heavy, windows_tools, missing_linux_example). Some scenarios, such as registry and event log troubleshooting, are only described for Windows, with no Linux counterpart.

Recommendations:

Alternate the order of Windows and Linux instructions throughout the document, or group by OS to avoid implicit prioritization.
Ensure that all troubleshooting scenarios covered for Windows (such as registry, event logs, and credential issues) have Linux equivalents or explicitly state if not applicable.
Provide Linux-native troubleshooting tools or scripts where PowerShell is used for Windows, and offer equivalent command-line examples (e.g., bash, Python).
Where Windows event logs are referenced, suggest equivalent Linux log files (e.g., /var/log/syslog, /var/log/messages) and commands (e.g., journalctl).
For sections that only mention Windows-specific issues (such as UAC or registry permissions), clarify if these are not applicable to Linux, or provide Linux-specific security troubleshooting if relevant.
Review and expand Linux troubleshooting steps to match the depth and clarity provided for Windows, ensuring Linux users have equally actionable guidance.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation is focused exclusively on ASP.NET Core and the Azure portal, both of which are cross-platform, but all code and workflow examples are tailored for .NET developers (typically Windows-centric). There are no Linux-specific instructions, CLI examples, or references to non-Windows development environments. The use of the Azure portal and .NET-centric instructions implicitly prioritize Windows users, and there is no mention of equivalent workflows for Linux or cross-platform command-line tools.

Recommendations:

Provide equivalent examples using Azure CLI and/or Azure PowerShell for all portal-based steps, making it clear these can be run on Linux, macOS, or Windows.
Include a section or callout for Linux/macOS users, highlighting any differences or confirming that all steps are cross-platform.
Mention that ASP.NET Core and the Azure SDKs are cross-platform, and provide explicit instructions or links for setting up the development environment on Linux.
Add sample code or scripts for certificate and secret management using bash scripts or Linux shell commands where appropriate.
Ensure that references to tools or workflows (such as Visual Studio) are balanced with alternatives (such as VS Code, JetBrains Rider, or command-line editors) that are popular on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates some Windows bias, primarily by presenting Windows command-line environments (Cmd, PowerShell) before or alongside Linux/macOS equivalents, and by providing detailed PowerShell-specific instructions and code pivots. While Linux/macOS instructions are present, Windows environments are often given equal or greater prominence, and Windows-specific tools and patterns (e.g., PowerShell, Cmd) are explicitly called out. There are no major missing Linux examples, but the ordering and emphasis suggest a Windows-first perspective.

Recommendations:

When presenting command-line instructions, list Linux/macOS (bash) examples first, followed by Windows (Cmd/PowerShell) to reflect the cross-platform nature of modern development.
Avoid giving extra prominence to PowerShell or Cmd unless absolutely necessary; group all OS-specific instructions together and clarify their applicability.
Where possible, use OS-agnostic commands or note any differences succinctly, rather than duplicating large blocks for each platform.
Ensure that Linux/macOS users are not required to mentally filter out Windows-specific terminology or tools.
Consider adding explicit notes or tables summarizing command differences across platforms for clarity.
Review the use of terms like 'command prompt' and clarify that 'terminal' applies to all platforms, not just Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation generally maintains cross-platform parity, but there are subtle Windows biases. Windows-specific instructions (such as .exe suffixes and use of 'set' in cmd) are often mentioned first or in more detail. The documentation refers to Windows conventions (e.g., 'handler.exe') before Linux ones, and Windows-specific build steps are called out with more explicit instructions. There is also a slight assumption of familiarity with Windows tools and patterns, such as referencing 'cmd' and using Windows-style environment variable setting. However, Linux and macOS instructions are present and correct, and the documentation does not omit Linux examples.

Recommendations:

When referring to executable names, mention the Linux version first or present both equally (e.g., 'handler (Linux/macOS) or handler.exe (Windows)').
Group platform-specific instructions together and avoid listing Windows first by default.
For environment variable setting, provide cross-platform commands side by side (e.g., 'export' for Linux/macOS and 'set' for Windows), or use table/tabbed formatting.
Avoid assuming Windows conventions (such as .exe suffix) as the default; clarify when each is needed.
Where possible, use platform-agnostic language and tools, or clearly indicate when a step is platform-specific.
Ensure that all screenshots and terminal outputs include Linux/macOS examples, not just Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific tools and configuration steps are often mentioned first or exclusively, such as in deployment, debugging, and performance optimization sections. PowerShell and Visual Studio are frequently referenced, sometimes without equivalent Linux or cross-platform alternatives. Some CLI examples are provided, but Windows-centric instructions (e.g., netFrameworkVersion, win-x64, Visual Studio) are more prominent and detailed. Linux equivalents are present but often secondary or less emphasized.

Recommendations:

Ensure all tool and deployment instructions are presented for both Windows and Linux, ideally side-by-side or with equal prominence.
Provide Linux-specific examples (e.g., bash scripts, Linux file paths, VS Code workflows) wherever Windows/PowerShell or Visual Studio examples are given.
When referencing configuration settings (like netFrameworkVersion for Windows), always include the Linux equivalent (like linuxFxVersion) in the same context.
Avoid listing Windows tools or workflows (e.g., Visual Studio, PowerShell) before cross-platform or Linux-native tools (e.g., VS Code, Azure CLI, bash).
Expand on Linux container deployment and debugging scenarios to match the detail given for Windows/Visual Studio.
Where possible, use cross-platform language and tools (e.g., Azure CLI, VS Code) as the default or first example, with OS-specific notes as needed.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page focuses exclusively on configuration steps for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows development environments. There are no examples or instructions for configuring the Roslyn Analyzer in Linux-native editors or via command-line tools, nor is there mention of cross-platform workflows or alternatives for non-Windows users.

Recommendations:

Include instructions for configuring and running the Roslyn Analyzer using cross-platform tools such as the dotnet CLI (e.g., dotnet build, dotnet format) that work on Linux and macOS.
Mention and provide examples for popular Linux-native editors (such as JetBrains Rider, Vim, or Emacs) or at least clarify how to enable analyzers outside of Visual Studio/VS Code.
Explicitly state the cross-platform compatibility of the analyzer and provide any necessary steps for Linux/macOS users.
Add a section on troubleshooting or verifying analyzer operation in CI/CD pipelines, which are often Linux-based.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily oriented towards Windows and Visual Studio users. All instructions and UI references are specific to Visual Studio, a primarily Windows-based IDE, with no mention of Linux or cross-platform alternatives such as Visual Studio Code or command-line workflows. The use of NuGet Package Manager Console (which is PowerShell-based) is assumed, and there are no CLI or Linux-native instructions provided. While Azure Storage Explorer is mentioned as cross-platform, all step-by-step examples and screenshots are Windows-centric.

Recommendations:

Add parallel instructions for Linux/macOS users, using Visual Studio Code and/or Azure Functions Core Tools CLI.
Provide command-line alternatives (e.g., dotnet CLI commands for package installation) instead of relying solely on the NuGet Package Manager Console.
Include screenshots and UI references for cross-platform tools (such as VS Code) where possible.
Explicitly mention that Visual Studio is only available on Windows, and direct Linux/macOS users to equivalent workflows.
Ensure all prerequisite steps and tool installations have Linux/macOS guidance, not just Windows.
Consider splitting the article or adding tabs/sections for Windows (Visual Studio) and cross-platform (VS Code/CLI) workflows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page for Azure Functions Core Tools exhibits a moderate Windows bias. It references Windows-specific tools and patterns (such as func.exe and the Microsoft Azure Storage Emulator), mentions PowerShell-specific features, and sometimes provides guidance or notes that are Windows-centric. There is a lack of explicit Linux/macOS examples or parity in tool references, and some features are described with Windows-first language or only mention Windows tools before their Linux equivalents.

Recommendations:

Provide explicit Linux/macOS command-line examples alongside or in place of Windows examples, especially where file paths, shell syntax, or environment differences matter.
Avoid Windows-first language such as referencing 'func.exe'—use 'func' or 'Azure Functions Core Tools' generically.
When mentioning tools like the Microsoft Azure Storage Emulator (Windows-only), always mention cross-platform alternatives (e.g., Azurite) and provide usage instructions for Linux/macOS.
For PowerShell-specific features (such as managed dependencies), clarify their scope and provide equivalent guidance for other shells/runtimes where possible.
Ensure that all instructions and notes are reviewed for platform neutrality, and add platform-specific notes where behavior or requirements differ.
Include troubleshooting or environment setup notes for Linux/macOS users, especially for dependencies like Docker, .NET SDK, or file permissions.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is heavily oriented towards Windows users by exclusively using Visual Studio (a primarily Windows IDE) for all steps, with no Linux or cross-platform alternatives shown in the main flow. All examples and instructions assume the use of Visual Studio and Windows file management conventions, and there is no mention of Linux tools, command-line alternatives, or how to perform these steps on Linux. The only nod to cross-platform development is a brief mention of a separate Visual Studio Code article, but this is not integrated into the main content.

Recommendations:

Provide parallel instructions or clear pivots for Linux users, such as using Visual Studio Code or the Azure Functions Core Tools CLI.
Include examples and screenshots for Linux environments, especially for steps like file renaming and running the function locally.
Mention and link to Linux-compatible tools and workflows (e.g., dotnet CLI, VS Code) directly in the prerequisites and throughout the article.
Avoid assuming the use of Windows-specific tools or UI patterns (e.g., File Explorer, Visual Studio menus) without offering Linux equivalents.
Consider adding a platform selection pivot at the top of the article to allow users to choose Windows or Linux instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias in several ways: Windows-based deployment methods and tools (such as Visual Studio and Visual Studio Code) are consistently mentioned first, and in some cases exclusively, before Linux equivalents. There is a strong emphasis on Windows-specific infrastructure (such as Kudu/SCM site) and deployment methods (like Source Control and Local Git) that are marked as 'Windows-only' in the availability table, with less detail or guidance for Linux users. Examples and instructions often default to Windows-centric tools and patterns, and Linux-specific considerations are sometimes relegated to notes or secondary sections. There are few, if any, Linux-specific command-line examples or explicit parity in walkthroughs.

Recommendations:

Ensure that for every deployment method, both Windows and Linux instructions/examples are provided side-by-side or with equal prominence.
Avoid listing Windows tools (e.g., Visual Studio, Kudu) before cross-platform or Linux-native tools (e.g., Azure CLI, Core Tools, VS Code on Linux). Instead, present cross-platform tools first or in parallel.
Add explicit Linux command-line examples (e.g., bash scripts, Linux CLI usage) where only Windows or PowerShell examples are given.
Clarify in each deployment method section which OSes are supported, and provide alternative guidance for Linux where a method is Windows-only.
Highlight any differences in deployment experience or requirements for Linux users, and provide troubleshooting or best practices specific to Linux environments.
Where possible, avoid using language that implies Windows is the default or preferred environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows tools and patterns, such as Visual Studio and Windows-specific paths, and by providing command-line examples primarily in Windows formats (cmd, PowerShell). There is a lack of explicit Linux/macOS examples or parity in tool installation, file paths, and command usage. Linux equivalents are either omitted or not given equal prominence, which may hinder cross-platform developers.

Recommendations:

Provide Linux/macOS equivalents for all command-line instructions, including bash/zsh examples alongside cmd and PowerShell.
Include file path examples using both Windows (\) and Unix (/) separators where relevant.
When referencing tools like Visual Studio, also mention and provide parity for cross-platform alternatives such as Visual Studio Code and the .NET CLI.
For installation and usage of Azure Functions Core Tools, explicitly document Linux/macOS installation steps and note any differences in behavior or file locations.
Avoid using Windows-specific environment variable syntax (e.g., %USERPROFILE%) without also showing the Unix equivalent (e.g., $HOME).
Ensure that all code and configuration examples (such as ReadyToRun <RuntimeIdentifier>) include both Windows and Linux/macOS targets (e.g., win-x86, linux-x64, osx-x64).
When showing package installation commands, always provide bash (dotnet CLI) and PowerShell examples together, not just Windows-centric ones.
Audit all references to Windows-only tools or extensions and provide guidance for Linux/macOS users where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a moderate Windows bias. Windows-based build agents ('windows-latest') are used by default for C# and PowerShell examples, and Windows is often mentioned before Linux. PowerShell is given its own language tab, and Windows-specific deployment types are described as defaults. Linux support is present, especially for Python and JavaScript, but Windows is prioritized in ordering and examples.

Recommendations:

For C# examples, provide both 'windows-latest' and 'ubuntu-latest' YAML samples, or explain when each is appropriate.
When presenting build and deployment YAML, avoid defaulting to Windows unless required by the language or runtime. Instead, present both Windows and Linux options side by side.
In language tabs, ensure Linux and macOS development environments are mentioned where relevant (e.g., not just Visual Studio Code on Windows).
For PowerShell, clarify whether cross-platform PowerShell Core is supported and provide Linux/macOS build agent examples if possible.
In deployment sections, avoid stating 'the default appType is Windows' without equal emphasis on Linux. Instead, explain both options equally and note the implications.
Review ordering: mention Linux and Windows together, or alternate which is presented first, to avoid reinforcing Windows as the default.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_examples_prominence

⚠️ powershell_heavy

Summary:

The documentation generally provides parity between Windows and Linux for Bicep and ARM template examples, but there is a consistent pattern of presenting Windows examples and instructions before Linux equivalents ("windows_first"). In several sections, Windows tabs are listed first, and Windows-specific settings or instructions are described before Linux. The deployment instructions and validation sections feature PowerShell examples prominently, with less emphasis on Bash or cross-platform CLI alternatives ("powershell_heavy"). There are no outright missing Linux examples, but the ordering and prominence favor Windows.

Recommendations:

Alternate the order of Windows and Linux examples/tabs, or present Linux first in some sections to balance prominence.
Where possible, provide Bash/Azure CLI examples alongside PowerShell, especially in deployment and validation sections.
Explicitly state that all examples are cross-platform unless noted, and highlight any Linux-specific considerations at the same level as Windows.
Review tab ordering and ensure Linux is not always secondary.
In sections where Windows and Linux instructions are nearly identical, consider merging them and calling out differences inline, rather than segregating by OS with Windows first.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there is a subtle Windows bias in several areas. Command-line examples are always given in both Bash and Windows CMD, but the Windows CMD examples are consistently listed after Bash, which is positive. However, there are no explicit PowerShell examples, but the use of 'command prompt' and 'CMD' tabs may implicitly favor Windows users. There is also a lack of explicit Linux-specific troubleshooting, environment setup, or tool references. Some sections refer to 'command prompt' or 'terminal' generically, but do not provide Linux-specific guidance or troubleshooting, and there are no Linux-specific tools or package manager references. The documentation does not mention WSL, Linux file permissions, or other common Linux development concerns. The Java version support table is split by OS, but otherwise, Linux is not given special attention.

Recommendations:

Add explicit Linux troubleshooting tips (e.g., file permissions, JAVA_HOME setup on Linux, common Linux-specific errors).
Include references to Linux package managers (apt, yum) for installing Java or Maven, or link to official installation guides for Linux.
Where 'command prompt' is mentioned, clarify that this refers to Windows, and use 'terminal' for Linux/macOS.
Consider adding PowerShell examples if CMD is included, or clarify that Bash examples are for Linux/macOS and CMD for Windows.
Highlight any differences in local development experience between Windows and Linux (e.g., path separators, environment variable syntax).
Mention WSL as an option for Windows users who want a Linux-like environment.
Ensure that all tools and workflows described (e.g., Maven, Azure CLI) are confirmed to work on Linux, and note any OS-specific caveats.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation generally maintains good cross-platform parity and emphasizes Linux as the primary hosting environment for Python Azure Functions. However, there are subtle Windows biases: Windows terminology ("command prompt") is often used before or instead of Linux/Unix equivalents ("terminal"), and Windows-specific recommendations (such as using remote build when developing on Windows) are present. The documentation also references Visual Studio Code and Azure Functions Core Tools, which are cross-platform, but the language sometimes prioritizes Windows workflows. There are no explicit PowerShell-only examples or exclusive use of Windows tools, but the ordering and phrasing can give the impression of Windows-first development.

Recommendations:

Use neutral, cross-platform terminology such as "terminal" or "shell" instead of "command prompt" or pair them equally (e.g., "terminal or command prompt").
When giving recommendations (e.g., for remote build), clarify that the advice applies to both Windows and Linux where appropriate, or explain the rationale for any OS-specific guidance.
Ensure that all CLI examples use bash/zsh syntax by default, or provide both Windows (cmd/PowerShell) and Linux/macOS (bash) variants where differences exist.
If referencing Visual Studio Code, clarify that it is available on all major platforms.
Explicitly mention Linux/macOS support in all tool and workflow descriptions, especially in sections that mention local development or publishing.
Avoid language that suggests Windows is the default or preferred development environment for Python on Azure Functions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Bash and PowerShell examples for Azure CLI commands, but PowerShell syntax is consistently presented immediately after Bash, and sometimes with explicit 'PowerShell syntax' labels. There are no Windows-only tools or exclusive PowerShell-only steps, but the repeated inclusion and labeling of PowerShell examples may give the impression of Windows being a primary or preferred platform. All tooling (Azure CLI, azd, Visual Studio Code) is cross-platform, but the documentation does not explicitly highlight Linux or macOS parity, nor does it provide Linux-specific troubleshooting or environment notes.

Recommendations:

Alternate the order of Bash and PowerShell examples to avoid always presenting Bash first, or clarify that both are equally supported.
Explicitly mention that all tools and steps are cross-platform, and provide links or notes for Linux/macOS users where relevant (e.g., VS Code installation, azd installation).
Add a short section or note confirming that the workflow is fully supported on Linux and macOS, including any known differences or tips for those environments.
Where possible, include screenshots or terminal output from Linux/macOS environments, not just Windows/PowerShell.
If there are any platform-specific caveats (e.g., file path syntax, permissions), call them out directly.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both Azure CLI and PowerShell examples for programmatic management of access restrictions, but PowerShell examples are often presented before CLI, and advanced scenarios (such as multi-source rules and Azure Front Door restrictions) are shown only with PowerShell. There are no explicit Linux shell or Bash script examples outside of Azure CLI, and PowerShell is a Windows-centric tool, which may disadvantage Linux users. However, the presence of Azure CLI examples (which are cross-platform) mitigates this bias somewhat.

Recommendations:

Ensure that for every PowerShell example, an equivalent Azure CLI example is provided, especially in advanced scenarios (e.g., multi-source rules, Azure Front Door restrictions).
Present Azure CLI examples before PowerShell examples, as CLI is cross-platform and more accessible to Linux users.
Where possible, include Bash script snippets or notes for Linux users, especially for tasks that may require scripting or automation.
Explicitly state that Azure CLI commands work on Linux, macOS, and Windows, and provide links to installation instructions for non-Windows platforms.
Review advanced scenario sections to ensure parity between PowerShell and CLI coverage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation contains a minor Windows bias: in the troubleshooting section, only the Windows-specific command (ipconfig /flushdns) is mentioned for clearing the DNS cache, with no equivalent Linux or macOS instructions. No other OS-specific tools or patterns are referenced, and the rest of the guide is platform-neutral.

Recommendations:

When suggesting DNS cache clearing, 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').
Wherever OS-specific troubleshooting steps are provided, ensure parity by listing commands for all major platforms (Windows, Linux, macOS) or linking to relevant cross-platform documentation.
Consider a short note or table summarizing DNS cache clearing for different operating systems to improve accessibility for non-Windows users.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation only describes how to delete resources using the Azure portal, which is a graphical interface commonly associated with Windows environments. There are no command-line examples provided for Linux users, such as using Azure CLI or Bash scripts, nor is there mention of PowerShell or Windows-specific tools, but the lack of Linux/CLI parity is notable.

Recommendations:

Add Azure CLI command-line examples for deleting the resource group, suitable for Linux/macOS/Windows terminals.
Include Bash script snippets for automation scenarios.
Explicitly mention that the Azure portal is cross-platform, but provide parity with CLI instructions for users who prefer or require non-GUI workflows.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment based on .NET and Azure App Service, with all examples and instructions tailored to ASP.NET Core and related Microsoft tooling. There are no explicit instructions or examples for Linux-based development environments, non-Windows shells, or alternative deployment methods outside of Azure-centric workflows. The use of GitHub Codespaces (which is cross-platform) mitigates some bias, but the overall focus is on Windows/Microsoft technologies, and there is no mention of Linux-specific considerations or parity.

Recommendations:

Add explicit instructions for running the sample app and commands in a Linux shell (e.g., bash) and clarify that the dotnet CLI and azd work cross-platform.
Include notes or examples for deploying to Azure App Service from Linux or macOS environments, such as using Azure CLI in bash or zsh.
Mention that the development and deployment steps are platform-agnostic where applicable, and highlight any differences or prerequisites for Linux users (e.g., installing .NET SDK on Ubuntu).
If any step is Windows-specific (such as using Visual Studio or Windows-only tools), provide equivalent steps for Linux (e.g., using VS Code, nano/vim, or command-line git).
Clarify that Azure App Service supports both Windows and Linux hosting, and provide links or notes for Linux-specific hosting scenarios.

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 given for clearing the DNS cache is the Windows-specific 'ipconfig /flushdns' command. There is no mention of how to perform this action on Linux or macOS, nor are alternative commands or instructions provided for non-Windows users.

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 a cross-platform table or list, or explicitly mention all major platforms.
Review documentation for other subtle Windows-first assumptions, such as screenshots or terminology, and ensure parity for Linux and macOS users where relevant.

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 detailed PowerShell and Windows Command Prompt commands. Linux/macOS instructions are present but listed after Windows, indicating a 'windows_first' ordering and a slight emphasis on Windows tooling.

Recommendations:

Present Linux/macOS and Windows instructions in parallel (side-by-side tabs or equal prominence), or list Linux/macOS first to reflect Go's cross-platform nature.
Avoid giving Windows-specific instructions (cmd, PowerShell) priority over bash equivalents.
Consider using tabbed instructions for each OS shell (cmd, PowerShell, bash/zsh) to avoid implicit prioritization.
Explicitly mention that all steps are cross-platform unless a step is truly OS-specific.
Where possible, use cross-platform commands (e.g., 'env' files, or platform-agnostic tooling) and highlight them.

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 can be seen as a Windows-first and PowerShell-heavy approach. Linux/macOS instructions are present but always listed after Windows. No Linux-specific tools or patterns are missing, but the ordering and emphasis favor Windows users.

Recommendations:

Present Linux/macOS and Windows instructions in parallel (side-by-side tabs or columns), or alternate which platform is listed first to avoid implicit prioritization.
Avoid giving more detailed or multiple options for Windows (e.g., both cmd and PowerShell) unless parity is provided for Linux/macOS (e.g., bash and zsh).
Consider a platform-agnostic approach first (e.g., using cross-platform scripts or highlighting environment variable setup in Go code), then provide platform-specific details as needed.
Explicitly state that all platforms are supported and tested, and encourage contributions or feedback from non-Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by providing Visual Studio (a Windows-centric IDE) instructions for tooling updates and omitting any explicit Linux or cross-platform development environment guidance. There are no examples or notes for Linux users regarding equivalent tools, commands, or workflows (e.g., VS Code, CLI usage, or emulator setup on Linux). All example instructions and environment setup steps implicitly assume a Windows/Visual Studio context.

Recommendations:

Add explicit instructions for Linux and macOS users, including how to set up the development environment using VS Code or the .NET CLI.
Provide alternative steps for updating Azure Functions tools outside of Visual Studio (e.g., using the Azure Functions Core Tools CLI).
Mention cross-platform emulator options and how to configure or avoid conflicts on Linux/macOS.
Include notes or examples for common Linux development patterns, such as using terminal commands for project creation, dependency management, and running the emulator.
Clarify that .NET Aspire and Azure Functions development is supported on Windows, Linux, and macOS, and link to platform-specific setup guides where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by exclusively guiding users to create a Windows Server virtual machine, with no mention of Linux alternatives. All VM creation steps, screenshots, and instructions are tailored for Windows Server, and there are no examples or guidance for deploying or accessing the function app from a Linux VM. This may lead Linux users to believe that only Windows is supported or recommended for this scenario.

Recommendations:

Provide parallel instructions and screenshots for creating a Linux-based virtual machine (e.g., Ubuntu) alongside the Windows Server example.
Explicitly mention that either Windows or Linux VMs can be used for this scenario, and highlight any differences in setup or access.
Include a note or section on how to connect to and use a Linux VM via Azure Bastion, including SSH access instructions.
Where relevant, provide command-line examples (e.g., using curl or wget) for invoking the function from within a Linux VM.
Ensure that all steps referencing the VM (such as browser access or deployment) clarify that the process is similar for both Windows and Linux environments.

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) first in several places, especially for C#. Visual Studio is a Windows-only IDE, and its mention precedes cross-platform or Linux-friendly tools like Visual Studio Code or command-line options. There are no explicit Linux-specific examples or tools highlighted, and the documentation does not provide parity in mentioning Linux-native workflows or editors. However, the use of Azure Functions Core Tools and Visual Studio Code (both cross-platform) is present, and PowerShell is only referenced in the context of the PowerShell language, not as a system shell.

Recommendations:

When listing development tools or quickstart options, avoid always listing Visual Studio (Windows-only) first. Instead, either list cross-platform tools first (e.g., Visual Studio Code, Azure Functions Core Tools) or clarify platform compatibility.
Explicitly mention that Visual Studio Code and Azure Functions Core Tools are fully supported on Linux and macOS, and provide links or notes for Linux users.
Where 'command prompt' is mentioned, clarify that this refers to any terminal (e.g., Bash, zsh, PowerShell, Command Prompt) and provide Linux/macOS-specific terminal instructions or examples where appropriate.
Consider including a section or callout for Linux/macOS users, highlighting any differences or additional steps required for those platforms.
If possible, add examples or references to popular Linux editors (e.g., Vim, Emacs) or workflows, or at least acknowledge their use.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by referencing Windows-centric tools and workflows (such as Visual Studio and .csproj configuration) before mentioning cross-platform or Linux-specific alternatives. In particular, the section on pinning to a specific minor version explicitly states that the process differs between Windows and Linux, but does not provide the Linux-specific instructions or examples. Additionally, the local development section focuses on Visual Studio (a primarily Windows tool) and only later mentions Visual Studio Code and Azure Functions Core Tools, which are cross-platform.

Recommendations:

When mentioning that pinning to a specific minor version differs between Windows and Linux, provide explicit Linux instructions or examples alongside the Windows ones.
Balance the order of tool mentions: introduce cross-platform tools (like Azure Functions Core Tools and Visual Studio Code) before or alongside Windows-specific tools (like Visual Studio).
Wherever project file examples are given (such as .csproj for Visual Studio), consider also providing equivalent instructions or examples for non-Windows environments (such as command-line or VS Code workflows).
Ensure that all platform-specific differences are clearly documented with equal detail for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation references a minimum charge for 'one instance of Windows Isolated v2' in the App Service plan before mentioning any Linux equivalent, and does not clarify Linux-specific pricing or deployment details. There are no explicit Linux examples or references, and the only OS-specific mention is for Windows, which may suggest a Windows-first bias.

Recommendations:

Include information about Linux-based App Service plans, including any minimum charges or differences in deployment and scaling.
Clarify whether the minimum instance charge applies to Linux as well as Windows, or provide Linux-specific pricing details.
Add examples or notes that address both Windows and Linux scenarios where relevant.
Review the documentation for other subtle OS-specific assumptions and ensure parity in guidance for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page demonstrates a 'windows_first' bias by listing .NET/.NET Framework and related Microsoft technologies (which are most commonly associated with Windows) at the top of the provider libraries table, with Linux-native or cross-platform-first frameworks (like Python, JavaScript, Go) listed later. There are no explicit Linux or Unix-specific examples, tools, or patterns mentioned, but the ordering and emphasis on Microsoft-centric stacks may implicitly prioritize Windows environments.

Recommendations:

Reorder the 'Configuration Provider Libraries' table to alternate or group by language family or platform neutrality, rather than leading with .NET/Microsoft technologies.
Explicitly mention cross-platform compatibility for each provider, highlighting Linux support where applicable.
Add a section or note clarifying that all listed providers are supported on Linux and provide links to Linux-specific setup or usage guides if available.
Where possible, provide sample links or usage notes that demonstrate running these providers in Linux environments (e.g., with Docker, on Ubuntu, etc.).

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation provides environment variable setup instructions in the order: Windows CMD, PowerShell, then macOS/Linux. This ordering prioritizes Windows users, which may suggest a subtle Windows-first bias. However, all major platforms are represented, and no examples or tools are exclusive to Windows.

Recommendations:

Present environment variable setup instructions in a neutral order, such as grouping Windows and Linux/macOS together or listing Linux/macOS first.
Consider using tabbed code blocks or clear headings for each platform to avoid implying priority.
Ensure parity in instructions and examples for all supported platforms throughout the documentation.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation specifies 'os = windows' as the default in the Gradle configuration example, which may lead users to assume Windows is the primary or preferred deployment target. There are no explicit PowerShell or Windows command-line examples, and all shell commands use Bash syntax, which is cross-platform. However, the documentation does not mention or show how to set up for Linux or macOS, nor does it clarify the implications of the 'os' setting or provide parity for non-Windows environments.

Recommendations:

Explicitly mention that the Gradle 'os' setting can be changed to 'linux' or 'windows', and explain the implications of each.
Provide an example Gradle configuration for Linux (e.g., 'os = "linux"') and note when/why to use it.
Clarify that all command-line examples work on Linux, macOS, and Windows (with appropriate shells), or provide platform-specific notes if there are differences.
Highlight that Java 21 is currently supported on Linux only, and provide guidance for users on other platforms.
Consider adding a short section or callout for macOS/Linux users, especially regarding environment variable setup and any platform-specific steps.

Create pull request

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