Scan Details - Linux-first Docs for Azure

1517

Pages Scanned

57

Pages Flagged

1517

Changed Pages

3.8%

% Pages Flagged

Scan Information

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

Finished At: 2025-08-09 00:33:08

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. In sections where both Windows and Linux are relevant (such as SKU availability), Windows examples and commands are presented before Linux equivalents. The automation section provides both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric) examples, but PowerShell is given a dedicated section, reinforcing a Windows-centric approach. There are no Linux shell (bash) or scripting examples, and the documentation references Windows-specific patterns and tools (such as Azure PowerShell) without offering parity for Linux-native tools or workflows.

Recommendations:

Present Linux and Windows examples side by side, or alternate which is shown first to avoid implicit prioritization.
Include bash or shell script examples for Linux users, especially in automation sections.
Clarify that Azure CLI is cross-platform and can be used on both Windows and Linux, and consider providing examples of running CLI commands in both environments.
If referencing Azure PowerShell, also mention and link to Linux-compatible alternatives or note PowerShell Core's cross-platform capabilities.
Review screenshots and UI instructions to ensure they are not Windows-specific, or provide Linux/portal equivalents if differences exist.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing only Azure PowerShell examples for command-line operations, with no mention of Azure CLI (which is cross-platform and commonly used on Linux/macOS). All scripting examples use PowerShell cmdlets, and installation instructions reference only Azure PowerShell. There are no Bash or Azure CLI equivalents, and PowerShell is presented before ARM templates. This may disadvantage users on Linux or macOS, who are more likely to use Azure CLI or Bash scripting.

Recommendations:

Add Azure CLI examples alongside PowerShell for all command-line operations, including creating and updating API Management instances with managed identities.
Include installation and authentication instructions for Azure CLI, not just Azure PowerShell.
Present Azure CLI and PowerShell examples in parallel, or alternate their order, to avoid always putting Windows-centric tools first.
Explicitly mention that all operations can be performed from Linux/macOS using Azure CLI, and provide Bash script samples where appropriate.
Review and update links and references to ensure parity between PowerShell and CLI documentation.
Consider adding a section or callout for cross-platform users, highlighting the recommended tools and scripts for Linux/macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation shows mild Windows bias: Windows is mentioned first in availability, and Azure PowerShell (a Windows-centric tool) is given equal prominence to Azure CLI, despite CLI being more cross-platform. There are no Linux shell or Bash script examples, and the portal UI instructions do not clarify OS-specific differences. However, Linux is mentioned in SKU availability and supported scenarios.

Recommendations:

Provide Bash shell script examples alongside PowerShell for automation, especially for Linux users.
When listing availability or features, avoid listing Windows first unless there is a technical reason; consider parallel presentation or alternating order.
Clarify any OS-specific differences in the Azure portal UI steps, if applicable.
Explicitly state that Azure CLI commands work identically on Windows, Linux, and macOS, and recommend CLI for cross-platform automation.
If mentioning PowerShell, clarify that PowerShell Core is available cross-platform, or provide Bash alternatives.
Consider adding a table summarizing feature support for both Windows and Linux to improve parity and clarity.

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 tooling. The mention of Visual Studio deploys 'directly with your ASP.NET app to Windows App Service' without referencing Linux App Service or cross-platform alternatives. There are no Linux command-line or scripting examples, and Kudu (which is more closely associated with Windows environments) is emphasized for diagnostics and logging.

Recommendations:

Add explicit examples and instructions for deploying WebJobs to Linux App Service plans, including using cross-platform tools like Azure CLI, VS Code, or GitHub Actions.
Mention and demonstrate Linux-compatible deployment workflows (e.g., zip deploy via Azure CLI, FTP/SFTP, or GitHub Actions targeting Linux).
Clarify which features or tools (such as Kudu) are available on both Windows and Linux App Service plans, and provide Linux-specific troubleshooting/logging guidance if different.
Balance references to Visual Studio with equivalent cross-platform IDEs or editors (e.g., Visual Studio Code) and provide parity in documentation links.
Ensure that all platform-specific instructions are clearly labeled, and provide alternatives for both Windows and Linux users.

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. It exclusively recommends and documents a PowerShell script for identifying non-Azure endpoints, with no mention of Bash, Azure CLI, or cross-platform alternatives. The instructions for running the script are Windows/PowerShell-centric, and there is no guidance for Linux or macOS users. Elsewhere, while Azure CLI and REST API are referenced (which are cross-platform), the only explicit example of a script-based solution is PowerShell, and it is presented as the default and only option.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for identifying non-Azure Traffic Manager endpoints, or at least reference cross-platform alternatives.
Explicitly mention that the PowerShell script can be run on PowerShell Core (pwsh) on Linux/macOS, if applicable, and provide instructions for those environments.
When referencing scripts or automation, offer both Windows (PowerShell) and Linux/macOS (Bash, Azure CLI) examples side by side.
Review other areas for subtle Windows-first language or tool recommendations, and ensure Linux parity in all actionable guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. It prioritizes ASP.NET and ASP.NET Core (Windows-centric frameworks) in its code samples, providing them before other stacks. The only explicit mention of how to access the client certificate in a framework is for ASP.NET, and the detailed code samples for certificate validation are heavily focused on C# and .NET. There is no mention of Linux-specific tools, shell commands, or configuration patterns, and no examples are given for Linux command-line environments (e.g., Bash). The Azure CLI example is cross-platform, but there are no Linux-specific troubleshooting steps, nor is there any mention of Linux-specific certificate handling nuances. The documentation assumes familiarity with Windows development patterns and tools.

Recommendations:

Add explicit Linux/Bash command-line examples for enabling client certificates and configuring exclusion paths, in addition to Azure CLI.
Provide guidance or examples for accessing and validating client certificates in popular Linux web servers (e.g., Nginx, Apache) when running on App Service for Linux.
Include troubleshooting steps or notes for Linux-specific issues, such as file permissions or environment variable handling.
Balance the order of code samples by presenting cross-platform or Linux-friendly stacks (Node.js, Python, Java) before or alongside Windows-centric frameworks.
Clarify that the Azure CLI is cross-platform and can be used from Bash or other Linux shells.
Mention any differences in client certificate handling between App Service on Windows and App Service on Linux, if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by prioritizing PowerShell scripting in the automation section, mentioning PowerShell before Azure CLI, and lacking explicit Linux or cross-platform command-line examples. There are no Linux-specific instructions or screenshots, and the automation section does not provide Bash or shell script equivalents, which may disadvantage Linux users.

Recommendations:

Provide Linux/Bash shell script examples alongside PowerShell in the automation section.
Ensure Azure CLI examples are given equal prominence and detail as PowerShell, and consider listing CLI before PowerShell to avoid 'windows_first' bias.
Include references or links to Linux-specific configuration guides where appropriate, especially in sections that mention language-specific guides.
Add screenshots or instructions that reflect both Windows and Linux environments where user interaction with the OS is relevant.
Review terminology and workflow steps to ensure they are not specific to Windows tools or patterns unless necessary, and clarify when instructions are cross-platform.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing PowerShell instructions and examples first, referencing Visual Studio (a primarily Windows tool) for setup, and using PowerShell-specific modules. While an Azure CLI example is included, the initial focus and tooling are Windows-centric, and there is no explicit mention of Linux environments or parity in tooling/setup.

Recommendations:

Provide explicit Linux/macOS instructions and examples, including shell commands and environment-specific notes.
Mention cross-platform tools (such as VS Code or Azure CLI) before or alongside Windows-specific tools like Visual Studio.
Ensure that all PowerShell scripts have equivalent Bash or shell script examples, and clarify which steps are platform-agnostic.
Highlight any differences or considerations for Linux users, such as authentication methods or environment setup.
Consider reordering examples so that cross-platform or Linux-native instructions are presented before or alongside Windows/PowerShell examples.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell-based CLI examples for per-app scaling, with no equivalent examples for Linux users (e.g., Azure CLI/bash). The use of PowerShell cmdlets and Windows-centric scripting patterns is exclusive, and there is no mention of cross-platform or Linux-native tools. The ordering and focus on PowerShell also implicitly prioritize Windows workflows.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell code snippets, using bash syntax to support Linux and macOS users.
Explicitly mention that both PowerShell and Azure CLI can be used, and provide guidance for both environments.
Where possible, use cross-platform tools and scripting patterns in documentation examples.
Consider including a table or section comparing PowerShell and Azure CLI commands for common per-app scaling tasks.
Review related documentation links to ensure Linux and cross-platform resources are also referenced.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration/unregistration, and by listing Azure PowerShell before Azure CLI and portal in the 'Next steps' section. There are no explicit Linux or Bash examples, and the use of 'Set-AzContext', 'Get-AzProviderFeature', and 'Register-AzProviderFeature' are PowerShell-specific, which may not be familiar to Linux users. The documentation does mention Azure CLI, but the commands shown are actually PowerShell cmdlets, not true Azure CLI (az) commands.

Recommendations:

Provide equivalent Azure CLI (az) command examples alongside or before PowerShell examples, especially for registration, unregistration, and migration tasks.
Clearly distinguish between Azure PowerShell and Azure CLI commands, and ensure that Azure CLI examples use the correct syntax (e.g., 'az feature register' instead of 'Register-AzProviderFeature').
Include Bash shell examples for common tasks to improve accessibility for Linux users.
In the 'Next steps' and other instructional sections, list Azure CLI and portal options before or alongside PowerShell to avoid the perception of Windows-first bias.
Review and update any references to Windows-specific tools or patterns to ensure Linux parity throughout the documentation.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a significant Windows bias. PowerShell is the only command-line example provided for configuring Application Gateway with Key Vault certificates, with no equivalent Azure CLI (cross-platform) or Bash/Linux shell examples. The narrative and examples prioritize Windows-centric tools and workflows (PowerShell, Azure portal), and there is no mention of Linux-specific considerations or parity in the walkthroughs. This may hinder Linux users or those preferring cross-platform automation tools.

Recommendations:

Provide equivalent Azure CLI examples for all PowerShell command sequences, especially for certificate referencing and managed identity configuration.
Include Bash or shell script snippets where relevant, or clarify that Azure CLI commands are cross-platform.
When listing tools or methods (e.g., PowerShell, CLI, ARM templates), avoid listing Windows-specific tools first or exclusively; present Azure CLI and ARM/Bicep as primary, cross-platform options.
Explicitly mention that the steps are applicable on both Windows and Linux, or highlight any OS-specific considerations.
Add a 'Linux/CLI Example' section parallel to the PowerShell example, ensuring Linux users have clear, actionable guidance.

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 settings, exclusively referencing Windows-centric tools like Fiddler for network debugging, and giving installation instructions that assume a Windows environment (e.g., 'Run as administrator' for .exe files). There are no Linux or cross-platform alternatives mentioned for these tasks, and Windows tools and patterns are presented first and exclusively.

Recommendations:

Provide equivalent Azure CLI or Azure Cloud Shell examples for checking Application Gateway settings, as these are cross-platform and work on Linux, macOS, and Windows.
Include Linux-friendly network debugging alternatives to Fiddler, such as tcpdump, Wireshark, or mitmproxy, and provide basic usage instructions for these tools.
When referencing installation steps, include Linux-specific instructions (e.g., using package managers or running tools from the terminal) alongside Windows instructions.
Use neutral language when referring to tools (e.g., 'web debugging tool of your choice') and ensure that screenshots and examples are not exclusively from Windows environments.
Explicitly mention that the troubleshooting steps can be performed from any OS, and provide parity in examples and tool recommendations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell for automation and deployment tasks, particularly in the 'Next steps' section. There are no examples or links for Linux users (e.g., Azure CLI, Bash scripts), and Windows-centric tools are mentioned without Linux equivalents. This can make it harder for Linux users to follow or implement the guidance.

Recommendations:

Include Azure CLI examples and tutorials alongside or before PowerShell examples, especially in the 'Next steps' section.
Provide Bash script samples for common automation tasks.
Ensure that documentation references both Windows and Linux tools equally, or at least in parallel.
Explicitly mention cross-platform options (e.g., Azure CLI works on Windows, Linux, and macOS) when discussing automation or scripting.
Add links to Linux-focused tutorials or documentation where available.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows bias by referencing PowerShell and CLI as the primary configuration tools, with PowerShell mentioned first and linked directly for configuration tasks. There are no explicit Linux or Bash examples, nor are Linux-native tools or workflows mentioned. The guidance and examples are oriented toward Windows administrators, and Linux parity is not addressed.

Recommendations:

Provide explicit Bash/Azure CLI examples alongside or before PowerShell examples for all configuration tasks.
Include references to Linux-native workflows and tools (e.g., Bash shell, Linux command line) in the documentation.
Ensure that links to configuration guides include both PowerShell and Bash/CLI options, not just PowerShell.
Use neutral language when referring to tools (e.g., 'using Azure CLI or PowerShell' instead of 'using PowerShell or CLI'), and avoid always listing Windows tools first.
Add a section or callout for Linux administrators to clarify that all operations can be performed on Linux systems using Azure CLI or REST API.

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 installation instructions (including the use of the Windows-specific 'winget' package manager and a PowerShell code block) are presented before Linux instructions. The Linux installation is provided, but the structure and ordering give Windows precedence. Additionally, the only package manager mentioned by name is 'winget', a Windows tool, with no mention of common Linux package managers (e.g., apt, yum, snap). The rest of the guide uses cross-platform tools (Azure CLI, Helm, kubectl) and Bash syntax, which are generally platform-agnostic, but the explicit Windows-first ordering and tool mention stand out.

Recommendations:

Present Linux and Windows installation instructions in parallel tabs or in alphabetical order (Linux first, Windows second, or vice versa, but consistently).
For Helm installation, provide explicit package manager examples for both Windows (winget, choco) and Linux (apt, yum, snap), or link to the official Helm install page for both.
Avoid giving Windows-specific tools (like winget) exclusive mention; if a Windows tool is mentioned, provide Linux equivalents.
Consider using neutral language such as 'On Windows, you can use...' and 'On Linux, you can use...' rather than listing Windows first.
Where possible, use cross-platform shell commands or clarify which commands are for which OS, ensuring parity in detail and clarity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a strong Windows bias by exclusively referencing Azure PowerShell scripts for migration, without mentioning or providing examples for Azure CLI, Bash, or other cross-platform tools. There are no Linux/Unix-specific instructions or examples, and the PowerShell approach is presented as the default and only method for migration tasks.

Recommendations:

Provide equivalent Azure CLI (az) commands and scripts for all migration steps, alongside PowerShell examples.
Explicitly mention that migration can be performed from Linux/macOS environments using Azure CLI or Bash scripts.
Include sample Bash scripts or command-line instructions for Linux users.
Clarify tool parity and recommend cross-platform tools where possible, not just PowerShell.
Reorder examples or explanations to present cross-platform solutions (Azure CLI, REST API) before or alongside PowerShell.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

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

Recommendations:

Include links to equivalent tutorials using Azure CLI (az), which is cross-platform and commonly used on Linux.
Explicitly mention that configuration can be performed using Azure CLI, ARM templates, or REST API, not just PowerShell.
Provide example commands or links for both PowerShell and Azure CLI in the 'Next steps' section.
Consider adding a table or section comparing configuration steps across PowerShell, Azure CLI, and the Azure Portal to ensure parity for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by emphasizing PowerShell and Windows-centric tools and terminology. PowerShell is repeatedly mentioned as the primary automation language, with features like Desired State Configuration (DSC) described specifically in the context of PowerShell. The documentation references Windows tools and services (e.g., Active Directory, SharePoint Server) in common scenarios, and the PowerShell Gallery is highlighted for module management. Linux support is mentioned, but Linux-specific examples, tools, or workflows are largely absent, and Windows terminology is often presented first or exclusively.

Recommendations:

Provide balanced examples for both Windows (PowerShell) and Linux (Python, Bash) runbooks, including sample scripts for each.
Highlight Linux-native tools and scenarios (e.g., systemd, cron, Linux package management) alongside Windows tools in common scenarios.
Expand on configuration management by including Linux configuration frameworks (e.g., Ansible, Chef, native Linux DSC) and clarify how Azure Automation integrates with them.
Reference Linux module/package repositories (e.g., PyPI for Python, native Linux package managers) in addition to the PowerShell Gallery.
Ensure that when listing supported platforms or features, Linux is mentioned with equal prominence and detail as Windows.
Include Linux-specific use cases in the 'Common scenarios' section, such as automating updates, managing Linux services, or integrating with Linux-based monitoring tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation provides a generally cross-platform approach 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 (such as IIS and PowerShell) are mentioned first or exclusively, (2) the Azure PowerShell example is detailed while no equivalent Azure CLI (cross-platform) example is provided, (3) references to file paths and certificate stores use Windows conventions, and (4) instructions for adding certificates to the trusted root store and web server configuration are more explicit for Windows (IIS) than for Linux equivalents (Apache/NGINX).

Recommendations:

Provide Azure CLI examples alongside or before Azure PowerShell examples for uploading certificates to Application Gateway.
Include explicit instructions or links for adding root certificates to trusted stores on Linux (e.g., update-ca-certificates on Ubuntu) and macOS, not just Windows.
When referencing file paths, use cross-platform or Linux examples (e.g., /home/user/contoso.cer) in addition to Windows paths (e.g., C:\Users\...).
Balance server configuration guidance by providing step-by-step instructions or official documentation links for Apache and NGINX (Linux) equivalent to those given for IIS (Windows).
When mentioning editing the hosts file, provide Linux/macOS file locations (/etc/hosts) and editing instructions, not just a generic link.
Consider listing Linux/Apache/NGINX examples before or alongside Windows/IIS examples to avoid 'windows_first' ordering.

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 (including Windows PowerShell and PowerShell Workflow) is presented first and in greatest detail, with numerous examples and troubleshooting steps focused on Windows-specific paths, tools, and cmdlets. Many examples reference Windows file paths (e.g., C:\modules), environment variables, and PowerShell-specific modules. Linux is only mentioned in passing, often as a limitation (e.g., certain runbooks can't run on Linux Hybrid Runbook Workers), and there are no Linux-specific examples or guidance. Python runbooks receive less detailed coverage, and Linux-specific considerations are minimal or absent.

Recommendations:

Provide Linux-specific examples for PowerShell and Python runbooks, including file paths, environment variables, and troubleshooting steps relevant to Linux Hybrid Runbook Workers.
Balance the order of presentation by not always listing Windows/PowerShell options first; consider grouping by cross-platform compatibility or providing parallel sections for Windows and Linux.
Include explicit notes and examples for running runbooks on Linux Hybrid Runbook Workers, including any differences in behavior, limitations, or best practices.
Where Windows tools, paths, or patterns are mentioned (e.g., C:\modules, .ps1 scripts), provide Linux equivalents (e.g., /opt/automation/modules, ./child-runbook.ps1) where applicable.
Expand the Python runbook section to include more parity with PowerShell, such as troubleshooting, best practices, and Linux-specific guidance.
Add a summary table or matrix indicating which runbook types and features are supported on Windows vs. Linux Hybrid Runbook Workers.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing command-line examples exclusively in Azure PowerShell, with no equivalent Azure CLI (cross-platform) or Bash examples. The PowerShell examples are presented as the only scripting/automation option, and the documentation does not mention or demonstrate Linux-native tools or workflows. The structure and tab order also place PowerShell before any mention of CLI, and in some sections, CLI is omitted entirely.

Recommendations:

Add Azure CLI examples (az commands) alongside PowerShell for all automation and deletion tasks, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash script snippets where appropriate, especially for tasks that can be automated outside of PowerShell.
Ensure that CLI and PowerShell examples are presented in parallel tabs, with neither given priority in ordering.
Explicitly mention that all operations can be performed from Linux, macOS, or Windows, and provide guidance for non-Windows users.
Review all sections for references to Windows-specific tools or patterns and add Linux-equivalent instructions where needed.

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. Windows-specific tools and packaging formats (e.g., PowerShell Gallery, .zip for modules, Az PowerShell module) are emphasized, while Linux or cross-platform equivalents receive minimal or secondary mention. Python (the main cross-platform alternative) is mentioned, but examples and guidance are sparse, and Linux-specific details are limited to a brief note about .whl files for Python packages. There are no concrete Linux shell (bash) examples, nor is there parity in tool recommendations or workflows for Linux users.

Recommendations:

Provide equal coverage and examples for both PowerShell and Python runbooks, including REST API payloads for Python.
Include Linux/bash shell examples for managing runtime environments and runbooks, not just PowerShell.
Mention and demonstrate the use of cross-platform tools (e.g., Azure CLI) alongside or before Windows-specific tools like PowerShell Gallery.
Clarify when instructions or file formats are Windows-specific (e.g., .zip for PowerShell modules) and provide Linux equivalents or alternatives.
Add screenshots and walkthroughs for Python runbooks and Linux package management, ensuring visual parity.
Explicitly state support for Linux-based automation scenarios and provide troubleshooting tips relevant to Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows bias in several areas: Windows is mentioned first or exclusively in some sections, especially for Python 3.8; PowerShell cmdlets are provided for package management without Linux CLI or Bash equivalents; and Windows-specific instructions and terminology are used more prominently than Linux ones. Linux examples are present for Python 3.10, but Linux parity is lacking for Python 3.8 and for command-line tooling.

Recommendations:

Provide equivalent Linux/Bash/Azure CLI examples for all PowerShell cmdlets shown, especially for Python 3.8 package management.
When describing how to generate wheel files, present Linux and Windows instructions side by side for both Python 3.8 and 3.10, rather than only Linux for 3.10 and only Windows for 3.8.
Avoid presenting Windows-specific instructions or tools (e.g., PowerShell) before or instead of cross-platform alternatives.
Clarify which steps are platform-specific and offer guidance for both Windows and Linux users throughout.
Where possible, use platform-neutral language and tooling, or clearly indicate when a step is only possible on one OS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_registry_focus

Summary:

The documentation generally provides both Windows and Linux troubleshooting steps for Hybrid Runbook Worker issues, but there is a noticeable Windows bias. Windows examples, tools, and troubleshooting steps are often presented first, with more detailed PowerShell and registry instructions. Windows-specific tools (e.g., PowerShell scripts, registry edits, event logs) are described in detail, while Linux equivalents are sometimes less emphasized or described with less context. Some troubleshooting scenarios and resolutions are Windows-only or provide more granular steps for Windows than for Linux.

Recommendations:

Alternate the order of Windows and Linux instructions throughout the document, or group them together to avoid always presenting Windows first.
Ensure Linux troubleshooting steps are as detailed as Windows steps, including explicit command examples, log file locations, and explanations.
Where Windows registry or event log steps are given, provide equivalent Linux configuration or log file checks, or explicitly state if there is no equivalent.
Include Linux-specific troubleshooting scenarios where applicable, not just Windows-specific ones.
Balance the use of PowerShell examples with Bash or Python script examples for Linux, and provide context for both.
Where possible, use cross-platform tools or commands, or clarify platform-specific differences in a neutral way.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ cmd_heavy

⚠️ powershell_examples

⚠️ missing_linux_example

Summary:

The documentation generally strives for cross-platform parity, but there are several subtle Windows biases. In command sections, Windows (Cmd) and PowerShell examples are often presented alongside or even before Linux/bash equivalents. Some instructions (such as virtual environment activation for Python) provide more detail for Windows than for Linux/macOS. PowerShell-specific pivots and examples are present, and in some cases, Linux-specific instructions are less prominent or missing (e.g., the use of 'py' instead of 'python3' for venv creation on Windows).

Recommendations:

Ensure that Linux/macOS examples are always presented with equal prominence and detail as Windows examples, ideally listing Linux/bash first where appropriate.
Where multiple OS-specific tabs are used, ensure that Linux/bash is the default or at least not always listed after Windows.
For PowerShell and Cmd examples, always provide bash/zsh equivalents, and clarify when a command is cross-platform.
In sections like virtual environment creation, clarify the differences between 'py' and 'python3', and ensure Linux users are not left to infer steps.
Audit for any missing Linux-specific troubleshooting or setup steps (e.g., package installation, file permissions) and add them as needed.
Where possible, use neutral, cross-platform language such as 'terminal' instead of 'command prompt', and avoid assuming Windows as the default environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits some Windows bias, particularly in deployment, configuration, and debugging sections. Windows-specific instructions and tools (such as Visual Studio and PowerShell) are often mentioned before or more prominently than their Linux equivalents. Some examples and CLI commands are provided only for Windows or are Windows-first, with Linux alternatives appearing later or not at all. There are also places where Linux-specific guidance is less detailed or omitted.

Recommendations:

Ensure that all CLI and deployment instructions are presented for both Windows and Linux equally, ideally side-by-side or with clear tabs for each OS.
When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, Azure CLI, Azure PowerShell), avoid always listing Windows tools first; rotate or group by platform.
For every PowerShell or Windows-specific example, provide an equivalent Bash/Linux example.
In debugging and performance optimization sections, explicitly describe Linux workflows and tools, not just Windows (e.g., attach to process, checking architecture, ReadyToRun publishing).
Where possible, use cross-platform tools (like Azure CLI) as the primary example, and only supplement with platform-specific tools as needed.
In tables and lists, avoid defaulting to Windows as the primary or only example—ensure Linux is equally represented.
Review all code snippets and ensure any file paths, commands, or environment variables are cross-platform or have both Windows and Linux variants.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation focuses exclusively on Visual Studio and Visual Studio Code for configuring the Roslyn Analyzer, both of which are primarily associated with Windows development. There are no instructions or examples for configuring the analyzer in Linux-native editors or environments (e.g., JetBrains Rider, command-line tools, or cross-platform build systems). The Visual Studio section is given first and in more detail, reinforcing a Windows-centric perspective.

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.
Provide examples for popular Linux-friendly editors like JetBrains Rider or Vim/Emacs with OmniSharp.
Clarify that Visual Studio Code is cross-platform, and provide Linux-specific steps or screenshots if any differences exist.
Mention how to enable/disable analyzers in CI/CD pipelines or with MSBuild, which are platform-agnostic.
Add a section explicitly addressing Linux/macOS users and any known differences or limitations.

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 bash examples, and the PowerShell examples are presented first and in detail, which may disadvantage users on Linux or macOS platforms.

Recommendations:

Provide equivalent Azure CLI command examples alongside PowerShell, with full syntax and usage context.
Present both PowerShell and CLI examples in parallel or in separate tabs to ensure parity.
Explicitly mention that all commands can be run from any OS where Azure CLI is available, not just Windows.
Include bash shell examples for interacting with Azure CLI, especially for Linux users.
Avoid assuming PowerShell as the default interface; clarify that both PowerShell and CLI are supported and provide equal guidance for both.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a moderate Windows bias. Visual Studio (a Windows-centric IDE) is consistently listed first in C# development environments, and PowerShell is highlighted as a primary HTTP test tool. Windows-specific tools and workflows (such as Visual Studio and PowerShell) are mentioned before their cross-platform or Linux-native equivalents. While Linux and macOS are acknowledged as supported platforms, Linux-specific tools or workflows are not given equal prominence or detailed examples.

Recommendations:

In the C# environment table, list Visual Studio Code or the command-line/terminal option before Visual Studio, or at least alternate the order to avoid always prioritizing Windows-centric tools.
When listing HTTP test tools, mention curl (a cross-platform, Linux-native tool) before PowerShell and Edge, and provide example usage for curl.
Include explicit Linux/macOS terminal commands and examples alongside or before Windows/PowerShell examples throughout the documentation.
Highlight Linux/macOS-specific development workflows or troubleshooting tips where relevant, not just generic 'supports Linux' statements.
Where Visual Studio is mentioned, clarify its platform limitations and provide parity guidance for Linux/macOS users (e.g., using VS Code or JetBrains Rider).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Bash and Windows Command Prompt (Cmd) examples for Maven and Azure CLI commands, but Windows (Cmd) examples are consistently presented alongside or immediately after Bash, sometimes with more prominence. There are no PowerShell-specific examples, but the presence of Windows Cmd tabs and terminology like 'command prompt' may reinforce a Windows-centric perspective. There are no Linux-specific tools or shell examples beyond Bash, and some instructions refer to 'command prompt' (a Windows term) rather than 'terminal' or 'shell'. Additionally, some tables and explanations list Windows before Linux, and there is no mention of Linux-specific troubleshooting or environment nuances.

Recommendations:

Ensure that Bash examples are clearly labeled as suitable for both Linux and macOS, not just 'Bash'.
Where 'command prompt' is mentioned, clarify with 'command prompt (Windows)' and 'terminal (Linux/macOS)'.
Consider providing PowerShell examples only if there is unique functionality, otherwise focus on Bash (cross-platform) and clarify compatibility.
In tables and lists, alternate the order of Windows and Linux, or list Linux first where appropriate.
Add Linux/macOS-specific troubleshooting tips or notes where environment differences may affect users.
Explicitly state that all CLI and Maven commands work identically on Linux/macOS unless otherwise noted.
Where possible, include screenshots or terminal output from both Windows and Linux environments to reinforce parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation is generally cross-platform and Linux-focused for hosting, but there are subtle Windows biases in development and publishing workflows. Windows terminology ("command prompt"), references to developing on Windows, and recommendations for remote build when developing on Windows are present. There is also a lack of explicit Linux/macOS CLI examples or terminal commands, and no mention of Linux-specific tools or shell environments. The documentation does not provide parity in examples for Linux users, and the language often assumes familiarity with Windows development environments.

Recommendations:

Provide explicit Linux/macOS shell examples (e.g., bash/zsh) alongside any Windows command prompt or PowerShell commands.
Use cross-platform terminology such as "terminal" instead of "command prompt" or "command line" instead of "command prompt".
When referencing development environments, mention Linux/macOS terminals and shells (e.g., bash, zsh) in addition to Windows command prompt/PowerShell.
Include notes or examples for installing prerequisites (such as Azure Functions Core Tools, Python, etc.) on Linux/macOS, not just Windows.
Clarify that all CLI commands work on Linux/macOS and provide any necessary differences (such as path separators or environment variable syntax).
Highlight Linux-native workflows and tools where appropriate, especially since Azure Functions Python hosting is Linux-only.
Avoid recommending remote build only for Windows users; instead, explain the pros and cons for each OS and let users choose based on their workflow.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing Azure PowerShell commands as the primary example for feature registration and status checking, mentioning Azure CLI only secondarily and without explicit command examples. There are no Linux-specific instructions, screenshots, or terminal examples, and the workflow assumes use of the Azure Portal or PowerShell, which are more familiar to Windows users.

Recommendations:

Provide Azure CLI command examples (e.g., 'az feature register', 'az feature show') alongside or before PowerShell examples, with full syntax and sample output.
Explicitly mention that all steps can be performed on Linux, macOS, or Windows, and clarify any platform-specific differences.
Include screenshots or terminal snippets from non-Windows environments where applicable.
Balance the order of presentation so that CLI and PowerShell are given equal prominence, or alternate which is shown first.
Add a section or callout for Linux/macOS users, especially for command-line tasks, to ensure parity and inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows-specific tools (Excel, Notepad), using Windows UI terminology (e.g., 'File > Save As...'), and showing screenshots from Windows applications. There are no instructions or examples for performing equivalent steps on Linux or macOS, such as converting Excel files to tab-delimited text or viewing/editing files. The tutorial assumes access to Microsoft Excel and Notepad, which are not standard on Linux systems, and does not mention or show how to use cross-platform or Linux-native tools for these tasks.

Recommendations:

Provide alternative instructions for Linux and macOS users, such as using LibreOffice Calc or command-line tools (e.g., csvkit, awk, or ssconvert) to convert Excel files to tab-delimited text.
Include screenshots or command-line examples for Linux/macOS environments alongside Windows examples.
Use cross-platform terminology (e.g., 'text editor' instead of 'Notepad') and avoid assuming the presence of Windows-only applications.
Mention that Visual Studio Code is available on all major platforms, and suggest alternatives (e.g., Vim, Emacs, Sublime Text) for users who may not use VS Code.
Where UI navigation is described (e.g., 'File > Save As...'), clarify how to perform the equivalent action in LibreOffice or via command line.
Explicitly state that the tutorial is platform-agnostic and provide parity in setup and data preparation steps for all major operating systems.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell commands are presented prominently and in detail, often before or alongside Azure CLI examples. The registration and feature management sections use PowerShell as the primary example, with Azure CLI mentioned as an alternative. There is no mention of Linux-specific tools, shells, or workflows, and the PowerShell examples assume a Windows environment. The documentation does not provide explicit Linux shell (bash) examples or guidance for Linux users, and the use of PowerShell is assumed as a default for scripting and automation.

Recommendations:

Provide explicit bash/Linux shell examples for all command-line operations, especially for Azure CLI commands.
When referencing PowerShell, clarify that Azure CLI commands can be run natively on Linux/macOS and provide syntax examples in bash.
Reorder sections so that Azure CLI (which is cross-platform) examples appear before PowerShell, or present them in parallel tabs.
Avoid assuming the use of PowerShell as the default scripting environment; mention that both PowerShell and bash are supported for Azure CLI.
Include notes or callouts for Linux/macOS users regarding any platform-specific considerations.
Where possible, use neutral language such as 'command line' or 'terminal' instead of 'PowerShell' when referring to general command execution.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation is generally balanced in its protocol descriptions, but there are subtle Windows biases. SMB is described as 'primarily used with Windows clients', and Windows/Active Directory tools and patterns are referenced more frequently and with more official support than their Linux equivalents. Linux (Samba) SMB support is mentioned as unofficial. There are no concrete Linux command-line examples for SMB, and Active Directory is presented as the default identity management solution, with LDAP as a secondary option. The only example command given is for NFS (rpcinfo), but there are no equivalent SMB/Linux commands or configuration examples.

Recommendations:

Provide Linux/Samba command-line examples for accessing SMB shares, not just NFS.
Explicitly mention and provide examples for configuring Linux clients (using Samba/cifs-utils) to access SMB shares, including any caveats.
When discussing identity management, give equal weight to LDAP and Active Directory, and clarify support levels for both.
Avoid language that frames Windows/Active Directory as the default or primary solution; instead, present both Windows and Linux/UNIX approaches side by side.
Where possible, add Linux-focused troubleshooting steps or references for SMB access.
Clarify the support status and best practices for Linux SMB clients, and provide links to relevant documentation.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-centric bias by providing only Windows/PowerShell command examples for Active Directory management, referencing Windows-specific tools and policies (such as Group Policy and registry keys), and omitting equivalent Linux or cross-platform instructions for managing AD connections or Kerberos settings. Windows terminology and tools are introduced first and often exclusively, with little to no mention of how to perform similar tasks from Linux environments.

Recommendations:

Provide equivalent Linux command-line examples (e.g., using 'ldapmodify', 'kadmin', or 'adcli') for managing Kerberos encryption types and AD user properties.
Include instructions or references for configuring Kerberos and LDAP settings from Linux clients, especially for NFS and dual-protocol scenarios.
Mention and link to cross-platform tools (such as Samba, sssd, or realmd) where appropriate.
Balance the order of presentation so that Linux and Windows tools are introduced together, or in a neutral order, rather than always presenting Windows first.
Clarify which steps are required or optional for Linux-based environments, and provide troubleshooting tips for common Linux AD integration issues.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-based tools and workflows, especially in sections about setting SACLs and registering features. Windows (and PowerShell) instructions are provided in detail, while Linux/NFS instructions are either referenced externally or lack step-by-step guidance. Windows terminology and screenshots dominate, and Linux equivalents are not given equal prominence or detail.

Recommendations:

Provide step-by-step Linux/NFS instructions for setting Audit ACEs directly in the documentation, not just as a link.
Include command-line examples for Linux (e.g., using nfs4_setfacl or similar tools) alongside Windows GUI instructions.
When registering features, show both Azure PowerShell and Azure CLI commands side by side, with equal detail and prominence.
Use neutral language and structure (e.g., parallel tabs or sections) to present Windows and Linux workflows equally.
Add Linux screenshots or terminal output examples where appropriate, not just Windows GUI screenshots.
Review all sections to ensure Linux/NFS administrators can follow the documentation without needing to consult external links.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a moderate Windows bias. It provides detailed instructions and screenshots for managing LDAP POSIX attributes using Windows-only tools (Active Directory Users and Computers MMC snap-in), without offering equivalent Linux-based methods. The only explicit example for editing POSIX attributes is via Windows GUI tools, and the section on accessing the Attribute Editor is exclusively for Windows. Linux client configuration is referenced only via a link, with no inline examples or parity in attribute management. Additionally, Windows terminology and tools are mentioned first or exclusively in several sections.

Recommendations:

Include instructions and examples for managing POSIX attributes using Linux tools such as ldapmodify, ldapvi, or command-line utilities (e.g., ldapadd, ldapmodify) alongside the Windows MMC snap-in.
Provide screenshots or command-line examples for editing LDAP attributes from a Linux environment.
Balance the order of presentation so that Linux and Windows tools are introduced together or alternate which is mentioned first.
Clarify that attribute management can be performed from non-Windows systems and provide references or links to relevant Linux documentation.
Where possible, avoid assuming the administrator is using a Windows environment for directory management.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page generally maintains a neutral tone between platforms, but in the section addressing NFS access from Windows clients, only Windows-specific tools and PowerShell commands are provided. There are no equivalent Linux examples or troubleshooting steps for Linux NFS clients, and the Windows example is presented without parity. This creates a subtle Windows bias, especially in the practical guidance for mounting and configuring NFS volumes.

Recommendations:

For every Windows-specific example (such as PowerShell commands and mount instructions), provide equivalent Linux commands (e.g., mount command-line usage, relevant /etc/fstab entries, or troubleshooting steps).
When discussing client-side configuration (such as enabling CaseSensitiveLookup), include Linux-specific configuration tips or common issues and their resolutions.
Ensure that troubleshooting sections address both Windows and Linux clients equally, or clarify when an issue is specific to one platform.
Where possible, present Linux and Windows examples side-by-side, or alternate which platform is presented first to avoid the perception of prioritizing Windows.
Review all sections for implicit assumptions about the client OS and explicitly mention when guidance is platform-specific.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing Azure PowerShell examples as the primary (and only) command-line instructions for feature registration, with Azure CLI commands mentioned only secondarily and without explicit examples. There are no Linux-specific instructions, screenshots, or CLI walkthroughs, and the UI instructions use Windows-centric terminology (e.g., 'right-click'), which may not be as intuitive for Linux users. No Linux shell or cross-platform command-line examples are provided.

Recommendations:

Provide explicit Azure CLI command examples (e.g., 'az feature register ...') alongside PowerShell, not just as a mention.
Include Linux shell (bash) equivalents for all command-line operations.
Use neutral UI language (e.g., 'select the options menu' instead of 'right-click') to avoid Windows-centric terminology.
Add screenshots or instructions that are clearly applicable to both Windows and Linux environments.
Where possible, clarify that all operations can be performed from any supported OS, and link to cross-platform CLI installation guides.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation provides instructions only for deleting resources via the Azure portal, which is a graphical interface commonly associated with Windows users. There are no examples or instructions for performing the same task using command-line tools such as Azure CLI or Bash, which are preferred by many Linux users. This omission may make the documentation less accessible or convenient for Linux users or those who prefer automation.

Recommendations:

Add Azure CLI examples for deleting the resource group, including both Windows (PowerShell) and Linux (Bash) command syntax.
Explicitly mention that the Azure portal is cross-platform, but also provide command-line alternatives for users who prefer not to use the GUI.
Ensure that future documentation includes both GUI and CLI instructions, with equal prominence given to Linux-friendly tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides a troubleshooting step for clearing the DNS cache that only references the Windows command ('ipconfig /flushdns'), without mentioning the equivalent command for Linux or macOS. No Linux or cross-platform alternatives are provided, which may leave non-Windows users without clear guidance.

Recommendations:

Include equivalent DNS cache flush commands 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') alongside the Windows example.
Wherever platform-specific instructions are given, provide parity for major operating systems (Windows, Linux, macOS) or link to external resources with platform-specific guidance.
Review the documentation for other implicit Windows-centric assumptions and ensure cross-platform inclusivity in troubleshooting and automation sections.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment based on .NET and Azure App Service, which are cross-platform, but all examples and instructions are tailored to a workflow that is most familiar to Windows users (e.g., Visual Studio Codespaces, .NET CLI, Azure CLI). There are no explicit Linux or macOS terminal instructions, nor are there any references to Linux-specific tools or deployment patterns. The documentation does not mention or show how to perform these steps on a native Linux environment, nor does it provide parity for Linux users in terms of setup, testing, or deployment.

Recommendations:

Explicitly mention that all steps work on Linux, macOS, and Windows, and provide any necessary prerequisites for Linux users (e.g., installing .NET SDK, Azure CLI).
Add Linux/macOS-specific terminal commands or notes where file paths, environment variables, or tooling may differ (e.g., export vs set for environment variables).
Include screenshots or terminal output from a Linux shell (e.g., bash) to demonstrate parity.
If using Codespaces, clarify that it is a Linux-based environment and highlight any differences from local Windows development.
Mention alternative editors or IDEs commonly used on Linux (e.g., VS Code, JetBrains Rider) if relevant.
Ensure that all deployment and testing steps are validated on Linux and document any platform-specific caveats.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides installation instructions for the required NuGet packages using both the .NET Core CLI and the Visual Studio Package Manager Console. However, the Package Manager Console example is PowerShell-based and references Visual Studio, a Windows-centric tool, and it is presented after the cross-platform .NET CLI example. There are no explicit Linux-only instructions, but the focus on Visual Studio and PowerShell may implicitly favor Windows users.

Recommendations:

Explicitly mention that the .NET Core CLI commands work on Linux, macOS, and Windows, and recommend them as the primary, cross-platform approach.
Clarify that the Package Manager Console is only available in Visual Studio (Windows), and provide alternative instructions for Linux users (e.g., using Visual Studio Code or JetBrains Rider).
Consider removing or de-emphasizing Windows-specific tooling unless there is a Linux equivalent, or at least provide parity in instructions for Linux development environments.
Add a note or section on how to run and debug the sample code on Linux, including any prerequisites or differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents Azure PowerShell examples before Azure CLI examples in all relevant sections, and references to PowerShell cmdlets are repeated even in CLI sections. This ordering and emphasis can be perceived as a Windows-first and PowerShell-heavy bias, as Linux users are more likely to use Azure CLI or Bash. However, the documentation does provide Azure CLI examples and does not exclusively use Windows tools.

Recommendations:

Alternate the order of PowerShell and CLI examples, or present CLI examples first in some sections to better reflect cross-platform usage.
In CLI sections, avoid referencing PowerShell cmdlets (e.g., for viewing registration status, use 'az feature show' instead of 'Get-AzProviderFeature').
Explicitly mention that both PowerShell and CLI are cross-platform, and provide Bash script examples where relevant.
Add a short note or table at the beginning clarifying that all operations can be performed on Windows, Linux, or macOS, and link to platform-specific installation guides for Azure CLI and PowerShell.
Where possible, include ARM/Bicep/Terraform examples alongside imperative commands to further increase platform neutrality.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation is generally cross-platform and avoids explicit Windows-only tooling or PowerShell-heavy instructions. However, in the troubleshooting section about clearing DNS cache, only the Windows-specific command (`ipconfig /flushdns`) is provided, with no mention of Linux or macOS equivalents. This presents a subtle 'windows_first' and 'missing_linux_example' bias, as users on other platforms are not given guidance.

Recommendations:

When mentioning platform-specific commands (such as clearing DNS cache), provide equivalent instructions for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo resolvectl flush-caches`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
Explicitly state that the instructions apply to all platforms, and where differences exist, provide parallel steps for Windows, Linux, and macOS.
Review other troubleshooting or command-line guidance to ensure parity for non-Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents environment variable setup instructions for Windows (Command Prompt and PowerShell) before Linux/macOS, and provides both setx (cmd) and PowerShell commands, which are Windows-specific. Linux/macOS instructions are present but always listed last. There are no missing Linux examples, but the ordering and inclusion of multiple Windows shell variants may subtly prioritize Windows users.

Recommendations:

Alternate the order of platform instructions (sometimes show Linux/macOS first, or group all platforms equally).
Consider grouping all environment variable instructions together in a table or tabbed interface, so no platform is visually prioritized.
Avoid providing multiple Windows shell variants unless truly necessary, or provide equivalent depth for Linux (e.g., bash, zsh, fish).
Explicitly state that all steps are cross-platform except where noted, to reinforce parity.
Where possible, use platform-agnostic language and examples (e.g., 'set the environment variable' rather than 'run this Windows command').

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation is generally cross-platform, focusing on Visual Studio Code and Azure Functions, which are available on both Windows and Linux. However, there is subtle Windows bias in the troubleshooting section, where Windows-specific advice is given (e.g., references to WSL Bash and default terminal shell settings) without equivalent Linux or macOS troubleshooting guidance. There are no explicit PowerShell-heavy examples or exclusive use of Windows tools, but the mention of Windows-specific issues and lack of Linux/macOS parity in troubleshooting is a form of 'windows_first' and 'windows_tools' bias.

Recommendations:

Add troubleshooting steps relevant to Linux and macOS users, such as common issues with permissions, shell environments, or dependencies on those platforms.
Where Windows-specific advice is given (e.g., 'default terminal shell for Visual Studio Code isn't set to WSL Bash'), provide equivalent guidance for Linux/macOS (e.g., ensuring the correct shell is used, or how to resolve common shell-related issues).
Explicitly state that the instructions apply to all supported platforms, and note any platform-specific differences where relevant.
Include links or references to platform-specific setup or troubleshooting guides for Linux and macOS.

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 examples, which may give the impression of Windows prioritization. Linux/macOS instructions are present but always listed last. There are no missing Linux examples, but the ordering and inclusion of multiple Windows-specific command shells (cmd, PowerShell) versus a single Linux shell (bash) is evidence of subtle Windows bias.

Recommendations:

Alternate the order of platform instructions (sometimes list Linux/macOS first, or use tabs for OS selection).
Use tabbed or dropdown UI for platform-specific instructions to give equal prominence to Windows and Linux/macOS.
Where possible, group all OS instructions together rather than listing Windows (cmd, PowerShell) first.
Explicitly mention that all platforms are supported and that the Go code is cross-platform.
Consider providing a table summarizing commands for all platforms for quick reference.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation focuses exclusively on ASP.NET Core and C# examples, which are most commonly associated with Windows development. There are no Linux-specific instructions, shell commands, or cross-platform considerations. All steps assume use of the Azure Portal or .NET/C# tooling, with no mention of Linux command-line tools or alternative frameworks. The prerequisites and code samples are tailored to Windows-centric development environments.

Recommendations:

Include equivalent instructions and code samples for Linux environments, such as using the Azure CLI in Bash to configure Key Vault and App Configuration.
Mention that ASP.NET Core is cross-platform and provide explicit guidance for Linux/macOS users, including any differences in environment setup or deployment.
Add examples or notes for other programming languages or frameworks commonly used on Linux, if relevant.
Clarify that the steps and code samples are applicable on both Windows and Linux, and highlight any OS-specific considerations.
Provide shell script (Bash) alternatives for any steps that can be automated, especially for resource creation and configuration.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias, primarily by listing Windows-centric tools (such as Visual Studio) before cross-platform or Linux-native alternatives, especially in C# sections. Visual Studio is mentioned as the first option for C# development and deployment, which is a Windows-only tool, while cross-platform tools like Visual Studio Code and Azure Functions Core Tools are listed after. There are no explicit Linux or bash-specific examples, and PowerShell is referenced as a language but not as a tooling bias. However, the documentation does not completely exclude Linux or cross-platform workflows, as Azure CLI and Visual Studio Code are included throughout.

Recommendations:

When listing development tools or quickstart options, present cross-platform tools (such as Visual Studio Code and Azure Functions Core Tools) before or alongside Windows-only tools like Visual Studio.
Explicitly mention Linux and macOS compatibility where applicable, especially in sections referencing the 'command prompt' or Azure CLI.
Provide bash or shell command examples alongside any references to 'command prompt', or clarify that instructions apply equally to Linux/macOS terminals.
Consider adding a section or note highlighting Linux development workflows, including any differences or prerequisites for Linux users.
Avoid assuming Visual Studio is the default or primary tool for C# development; instead, present it as one option among several, with clear indications of platform support.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation generally provides parity between Windows and Linux, especially in code examples, which are consistently split into Windows and Linux tabs. However, there is a recurring pattern of presenting Windows examples and explanations before Linux equivalents (windows_first). Additionally, the only explicit command-line deployment walkthroughs outside of Azure CLI are for PowerShell, with no Bash or Linux-native shell examples (powershell_heavy). There are no significant omissions of Linux-specific instructions or tools, but the ordering and emphasis could suggest a subtle Windows bias.

Recommendations:

Alternate the order of Windows and Linux examples/tabs, or present Linux first in some sections to balance perceived priority.
Add Bash or Linux shell equivalents for PowerShell deployment examples, especially in the 'Deploy using PowerShell' section. For example, provide Azure CLI commands in Bash for creating resource groups and deploying templates.
Where possible, clarify that all ARM/Bicep deployment methods (CLI, PowerShell, Portal) are cross-platform, and highlight any Linux-specific considerations or best practices.
In sections where both Windows and Linux are supported, ensure introductory text does not default to Windows terminology or examples before mentioning Linux.
Consider adding a short note at the top or in relevant sections affirming full Linux support and linking to Linux-specific troubleshooting or guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation presents Windows (SMB) client instructions before Linux (NFS) client instructions, and provides more detailed, step-by-step guidance for Windows users (including both GUI and command-line methods), while Linux instructions are more concise and limited to a single command-line example. Windows-specific tools and workflows (File Explorer, 'dir' command) are described in detail, whereas Linux alternatives are not as thoroughly covered.

Recommendations:

Present Linux and Windows client instructions in parallel or alternate the order in different sections to avoid always listing Windows first.
Expand the Linux section to include both GUI (if applicable, e.g., GNOME Files or KDE Dolphin) and command-line methods, mirroring the detail given to Windows.
Provide equivalent Linux command-line examples for all Windows command-line examples (e.g., show both 'dir' and 'df -h' in a side-by-side table).
Mention relevant Linux tools and patterns (such as file manager properties dialogs) where appropriate.
Ensure that references to REST API usage do not only mention PowerShell, but also provide examples for Bash/cURL or Python.
Review screenshots and illustrations to ensure both platforms are visually represented equally.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily featuring Azure PowerShell commands for feature registration and status checking, with Azure CLI (cross-platform) commands mentioned only secondarily and in less detail. There are no Linux-specific examples or guidance, and the initial instructions assume familiarity with PowerShell, which is more common on Windows.

Recommendations:

Provide Azure CLI command examples alongside (or before) PowerShell examples for all steps, not just as a note.
Explicitly mention that both PowerShell and CLI are supported on Windows, Linux, and macOS, and provide installation links for each.
Include example shell prompts (e.g., bash) to show parity for Linux/macOS users.
Ensure that any screenshots or UI references do not assume a Windows environment.
Consider reordering examples to present Azure CLI first, as it is more universally cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page demonstrates a subtle Windows bias by referencing 'Windows Isolated v2' as the minimum charge in the 'Regional deployment' section, without mentioning Linux equivalents or clarifying Linux support. No explicit Linux examples, tools, or deployment patterns are provided, and the only OS-specific reference is to Windows, which is mentioned first and exclusively.

Recommendations:

Clarify whether Linux-based App Service plans are supported in each deployment type, and if so, mention them alongside Windows.
If there are differences in pricing or minimum instance requirements for Linux plans, document these explicitly.
Include examples or notes relevant to Linux deployments where applicable, such as Linux-specific considerations for App Service Environment.
Review the documentation for other subtle OS-specific terminology or defaults and ensure parity in coverage for both Windows and Linux.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core provider libraries first and in greatest detail, with their samples and release notes highlighted before those for Java, Python, JavaScript, and Go. This ordering and emphasis reflects a 'windows_first' bias, as .NET and ASP.NET Core are primarily associated with Windows development. There are no explicit PowerShell examples or Windows-only tools mentioned, but the prioritization of Windows-centric frameworks may make Linux or cross-platform users feel secondary.

Recommendations:

Reorder the provider libraries table to alternate or group by language family (e.g., .NET, Java, Python, JavaScript, Go) or by popularity, rather than always listing .NET/.NET Framework first.
Explicitly mention the cross-platform support of .NET Core and .NET 5+ to clarify that these libraries are not Windows-only.
Add a note or section highlighting Linux and container-native usage patterns, especially for Java, Python, and Go.
Ensure that sample links and documentation for non-Windows platforms are as prominent and detailed as those for .NET.
Consider including a brief statement about the parity of features and support across platforms, and encourage feedback from Linux and macOS users.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents environment variable setup instructions in the order of Windows (cmd), then PowerShell, and only afterwards macOS/Linux. This ordering prioritizes Windows users and may give the impression that Windows is the primary or preferred platform. However, all platforms are covered and examples are provided for each.

Recommendations:

Present environment variable setup instructions in a neutral or rotating order (e.g., Linux/macOS first, or group by shell type rather than OS).
Consider using tabs or collapsible sections for platform-specific instructions to give equal prominence to all platforms.
Explicitly state that the instructions apply equally to Windows, Linux, and macOS to reinforce cross-platform parity.
Ensure that any future examples or troubleshooting steps also provide parity across platforms, not just in environment variable setup.

Create pull request

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