Scan Details - Linux-first Docs for Azure

1444

Pages Scanned

47

Pages Flagged

1444

Changed Pages

3.3%

% Pages Flagged

Scan Information

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

Finished At: 2025-08-06 00:30:58

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing command-line examples exclusively in Azure PowerShell, which is primarily a Windows-centric tool. There are no examples using Azure CLI (cross-platform) or Bash scripts, and the only command-line installation instructions reference PowerShell. The structure presents PowerShell before ARM templates, and Linux-native or cross-platform tooling is not mentioned. This may hinder Linux users or those preferring non-Windows environments from easily following the instructions.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell command snippets, including resource creation and identity assignment.
Include Bash script examples where appropriate, especially for automation scenarios.
When listing command-line options, present Azure CLI before or alongside PowerShell to avoid the impression of Windows-first bias.
Explicitly mention that Azure CLI is cross-platform and provide links to its installation and usage guides.
Review and update installation instructions to include both PowerShell and Azure CLI, clarifying their platform compatibility.
Consider a dedicated section or tabbed code blocks for each major platform/tool (PowerShell, Azure CLI, ARM template) to ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page exhibits a moderate Windows bias. While it provides Azure CLI examples (which are cross-platform), it also includes Azure PowerShell examples without equivalent Bash or Linux-native alternatives. In sections where both CLI and PowerShell are shown, PowerShell is always presented after CLI, but no explicit Linux shell scripting or command-line examples (other than Azure CLI) are given. The only native OS-level command shown is 'nslookup', which is cross-platform. However, in the context of outbound IPv6 support, the documentation explicitly states that outbound IPv6 is only available for Windows apps, with no Linux support, and does not provide Linux-specific guidance or alternatives.

Recommendations:

For every Azure PowerShell example, provide an equivalent Bash/Linux shell example where possible, especially for common administrative tasks.
Clarify in the outbound IPv6 section whether Linux support is planned or provide a workaround or alternative for Linux users.
Where Azure CLI is shown, consider explicitly noting its cross-platform nature and, if relevant, provide example outputs from both Windows and Linux terminals.
If there are any differences in behavior or limitations between Windows and Linux App Service plans (as with outbound IPv6), summarize these in a comparison table for transparency.
Avoid presenting PowerShell as the only or primary scripting option; ensure parity with Bash or other Linux-native tools where applicable.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page exhibits a moderate Windows bias. Script automation examples are provided for Azure CLI and PowerShell, with PowerShell (a Windows-centric tool) being highlighted with inline code, while no explicit Linux shell (e.g., Bash) or cross-platform scripting examples are shown. The automation section lists PowerShell after Azure CLI, but the code sample is only for PowerShell. There are no explicit Linux command-line or OpenSSL certificate management examples, and no mention of Linux-specific tools or workflows. The documentation does reference a Linux Node.js configuration guide, but only in the context of application code, not certificate management or binding.

Recommendations:

Add explicit Bash or shell script examples for certificate binding and management, especially for automation.
Provide OpenSSL command-line examples for certificate creation and manipulation, as these are common on Linux.
Ensure that all PowerShell examples are paired with equivalent Azure CLI or Bash examples, and present them side-by-side.
Reference Linux-native tools and workflows where appropriate, such as using SCP/SFTP for certificate upload.
Clarify that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows, and provide installation links for non-Windows platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by listing Windows file types and tools (cmd, bat, exe, PowerShell) first and in greater detail, while Linux support is described more generically and with fewer examples. Windows-specific tools and patterns are mentioned explicitly, whereas Linux examples are minimal and lack parity in detail.

Recommendations:

Provide equally detailed lists of supported file types for Linux, including examples for Bash (*.sh*), Python (*.py*), Node.js (*.js*), Java (*.jar*, *.war*), and other common Linux scripting/programming languages.
Include Linux-specific tools or patterns where relevant, such as mentioning shell scripts, Python, Perl, or Ruby scripts.
Ensure that for every Windows example (e.g., PowerShell, cmd), there is a Linux equivalent (e.g., Bash, Python) with comparable detail.
Avoid listing Windows file types and tools first by default; consider presenting both platforms in parallel or in alphabetical order.
Clarify that runtimes for Linux file types are also pre-installed or specify any requirements, matching the detail given for Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows-centric tools and workflows (such as Visual Studio deployment to Windows App Service) and omitting explicit Linux deployment or management examples. References to deployment and development are focused on Visual Studio and Windows App Service, with no mention of Linux-specific approaches or parity in tooling. There are no Linux command-line or deployment examples, and the documentation does not clarify cross-platform differences or provide guidance for Linux users.

Recommendations:

Add explicit examples and instructions for deploying and managing WebJobs on Linux-based App Service plans, including command-line (Azure CLI) and cross-platform tooling.
Mention and demonstrate cross-platform editors and deployment methods (e.g., VS Code, GitHub Actions, Azure CLI) alongside Visual Studio.
Clarify any differences or limitations between Windows and Linux App Service plans regarding WebJobs support and features.
Provide Linux shell (bash) examples for common tasks, not just Windows/PowerShell or Visual Studio workflows.
Ensure that references to Windows-specific tools (e.g., Visual Studio) are balanced with Linux-friendly alternatives and that both are presented equally in documentation and quickstart links.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by presenting Visual Studio and PowerShell-based installation instructions before (and in addition to) cross-platform .NET CLI instructions. There are no explicit Linux or macOS-specific instructions or examples, and the Package Manager Console (PowerShell-based) is highlighted as an alternative to the .NET CLI, which is cross-platform. No Linux-specific tools, terminal commands, or environment considerations are mentioned.

Recommendations:

Explicitly mention that the .NET CLI commands work on Windows, Linux, and macOS, and recommend it as the primary cross-platform method.
Add Linux/macOS-specific instructions or notes, such as using a terminal or shell to run the .NET CLI commands.
Avoid presenting Windows/Visual Studio/PowerShell instructions before cross-platform alternatives; consider listing .NET CLI first and PowerShell/Visual Studio as optional for Windows users.
Include a brief section or note on any platform-specific considerations for Linux/macOS users (e.g., environment variable configuration, shell differences, or prerequisites).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ windowscode_links

Summary:

The documentation demonstrates a mild Windows bias, primarily by referencing Windows-specific concepts and links (such as 'windowscode' in supported file types and CRON expression documentation) across all language pivots. The .NET example, which is often the default or first shown, uses a cross-platform approach (dotnet CLI and bash scripts), but the documentation and links consistently refer to Windows-centric resources. There are no explicit PowerShell examples or exclusive use of Windows tools in the code samples, and most language pivots use bash scripts, suggesting an effort to support Linux scenarios. However, the persistent use of 'windowscode' in documentation links and the lack of explicit Linux/Windows distinctions in file type support or troubleshooting may confuse Linux users or suggest Windows is the primary/assumed environment.

Recommendations:

Update all documentation links (e.g., supported file types, CRON expressions) to either be platform-neutral or provide both Linux and Windows tabs, ensuring Linux users are not directed to 'windowscode' sections by default.
Clarify in the prerequisites and relevant sections whether the instructions apply to both Windows and Linux App Service plans, and highlight any differences or caveats.
Where possible, provide explicit Linux and Windows examples or notes if there are platform-specific steps, especially for packaging, file permissions (e.g., making run.sh executable), and troubleshooting.
Review and update terminology and screenshots to ensure parity and inclusivity for both Windows and Linux users.
Consider adding a section or note about running WebJobs on Linux, including any limitations, best practices, or differences from Windows hosting.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page exhibits a Windows bias by referencing Azure PowerShell as the only example for creating an autoscaling, zone redundant application gateway with a reserved virtual IP address. There are no equivalent instructions or links for Linux users (e.g., Azure CLI, ARM templates, or Bicep). The 'Next steps' section specifically highlights a PowerShell tutorial, implicitly prioritizing Windows tooling and workflows.

Recommendations:

Add equivalent Linux-friendly instructions and links, such as tutorials using Azure CLI, ARM templates, or Bicep, alongside the PowerShell example.
In the 'Next steps' section, provide parallel links for both PowerShell and Azure CLI (and/or ARM/Bicep) to ensure users on all platforms have clear guidance.
Review the documentation for any implicit assumptions about the user's operating system and strive for neutral, cross-platform language and examples.
Consider a table or section comparing how to perform key tasks (like autoscaling configuration) using different tools (PowerShell, CLI, ARM, Bicep) to promote parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration tasks, with no mention of Bash or Linux shell equivalents. The command-line examples use PowerShell syntax exclusively, and the only automation tool referenced is PowerShell. There is no guidance or example for users on Linux/macOS, nor are cross-platform Azure CLI examples provided. The documentation also refers to the Azure PowerShell Gallery as the source for migration scripts, reinforcing a Windows-centric approach.

Recommendations:

Provide Azure CLI (bash-compatible) examples alongside or before PowerShell examples for all command-line tasks, including migration and preview registration.
Mention cross-platform compatibility for tools and scripts, clarifying when a script or tool is Windows-only or works on Linux/macOS.
Reference the Azure CLI as a first-class tool for automation and management, not just PowerShell.
Include links to Linux/macOS setup guides for Azure CLI and PowerShell, if relevant.
Ensure that all code blocks are clearly labeled with the shell or environment they are intended for.
If a PowerShell script is the only migration tool available, provide instructions for running it on Linux/macOS using PowerShell Core, or offer an equivalent Azure CLI script.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell and Windows-centric tools and patterns as the primary or sole method for configuring and viewing TLS policies. There are no explicit Linux or cross-platform command examples, and PowerShell is mentioned before or instead of Azure CLI in several places. The 'Next steps' section links only to a PowerShell-based configuration guide, omitting Linux-friendly or CLI-based alternatives.

Recommendations:

Provide Azure CLI examples alongside PowerShell for all configuration steps, as Azure CLI is cross-platform and widely used on Linux.
Include explicit references and links to Linux/macOS-compatible instructions or documentation, especially in the 'Next steps' section.
When mentioning tools or methods for viewing or configuring policies (e.g., 'refer to the PowerShell, CLI, REST API or the Listeners blade in portal'), ensure CLI is listed first or equally with PowerShell.
Add sample commands for both PowerShell and Azure CLI in relevant sections to ensure parity.
Consider including a section or callout specifically for Linux/macOS users to highlight any differences or additional steps.

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 web debugging, and referencing 'Run as administrator' and .NET versions. There are no Linux or cross-platform alternatives or examples for these tasks, and Windows tools and patterns are mentioned first and exclusively.

Recommendations:

Provide Azure CLI (az) and/or Azure Resource Manager (ARM) REST API examples alongside or instead of PowerShell for configuration checks, as these are cross-platform.
Include examples using Linux-compatible web debugging tools such as mitmproxy, Wireshark, or tcpdump, and provide instructions for their use.
Avoid instructions that are specific to Windows environments (e.g., 'Run as administrator', '.NET 4 installed') unless also providing Linux/macOS equivalents.
When referencing tools, use language like 'for example, Fiddler or mitmproxy' and link to both Windows and Linux tool documentation.
Add screenshots or command-line snippets from Linux environments where appropriate to ensure parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell examples for critical configuration steps, referencing PowerShell and Windows-centric tooling first and exclusively, and omitting equivalent Azure CLI (cross-platform) or Bash scripting examples. There are no Linux-specific instructions or examples, and the 'Next steps' section directs users to a PowerShell-based guide, further reinforcing the bias.

Recommendations:

Provide equivalent Azure CLI (az) examples alongside PowerShell for all configuration steps, especially for referencing Key Vault secrets and configuring Application Gateway.
Include Bash scripting examples where appropriate to support Linux users.
In sections where PowerShell is referenced, mention Azure CLI as an alternative and provide links to relevant CLI documentation.
Ensure that the 'Next steps' section includes links to both PowerShell and Azure CLI guides for TLS termination with Key Vault certificates.
Review the documentation for any terminology or instructions that assume a Windows environment and generalize them for cross-platform applicability.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias, particularly in the Helm installation section, where Windows instructions (including a PowerShell/winget example) are presented before Linux instructions. The use of Windows-specific tooling (winget) is highlighted, while the Linux section is less detailed. However, the majority of the CLI examples use cross-platform Azure CLI and Bash syntax, and Linux installation is covered.

Recommendations:

Present Linux and Windows instructions in parallel tabs or in the same order throughout the documentation, rather than listing Windows first.
Provide equally detailed installation steps and context for both Windows and Linux users (e.g., mention popular Linux package managers like apt, yum, or snap for Helm).
Avoid emphasizing Windows-specific tools (like winget) without offering equivalent Linux alternatives (such as apt, snap, or direct binary download instructions).
Where possible, use cross-platform shell examples (Bash or Azure CLI) as the default, and only provide OS-specific instructions when necessary.
Explicitly state that all Azure CLI and Helm commands can be run from Linux, macOS, or Windows (with WSL or native shells), to reinforce cross-platform parity.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation page demonstrates bias toward Windows environments by referencing only a PowerShell-based tutorial for next steps, without mentioning or linking to Linux-native tools or CLI examples. There are no Bash, Azure CLI, or Linux shell command examples, and the only configuration guidance points to a PowerShell tutorial, which is most commonly used on Windows.

Recommendations:

Include equivalent Azure CLI (az network application-gateway) examples for configuring redirects, as Azure CLI is cross-platform and widely used on Linux.
Provide Bash shell command examples for common redirection scenarios.
Link to or create tutorials for configuring Application Gateway redirects using Azure CLI and ARM templates, not just PowerShell.
Explicitly mention that PowerShell examples can be run on Linux (if applicable), or clarify platform requirements for each method.
Ensure that references to configuration steps or tutorials are balanced, offering both Windows/PowerShell and Linux/Azure CLI options side by side.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. While the main certificate generation instructions use OpenSSL (cross-platform), Windows-specific tools and patterns are prioritized or highlighted in several places. The Azure PowerShell example is given in detail, with no equivalent Azure CLI (cross-platform) example. The IIS (Windows web server) configuration is presented before Apache and NGINX, and the file path in the PowerShell example uses a Windows-style path. There is also a reference to editing the hosts file with a link that is Windows-centric.

Recommendations:

Add Azure CLI examples alongside or before Azure PowerShell for certificate upload and configuration, as CLI is cross-platform.
Present Linux/Unix web server configuration examples (Apache, NGINX) before or alongside IIS, or clarify that order is not indicative of priority.
Include Linux file path examples in addition to Windows paths in code samples.
Provide explicit instructions or links for editing the hosts file on both Windows and Linux/macOS.
Ensure that any references to tools or steps that are Windows-specific are matched with Linux/macOS equivalents where possible.

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 tasks, without mentioning or providing examples for Azure CLI, Bash, or other cross-platform tools. There are no Linux-specific instructions or examples, and the only automation method discussed is PowerShell, which is most commonly associated with Windows environments.

Recommendations:

Provide equivalent Azure CLI (az) commands or scripts for all migration steps, ensuring Linux and macOS users have clear guidance.
Explicitly mention that migration can be performed from any OS, and clarify any OS-specific prerequisites or limitations.
Include Bash or shell script examples where automation is discussed, or at least reference cross-platform scripting options.
Add a section comparing PowerShell and CLI approaches, helping users choose the best tool for their environment.
Ensure that all documentation references to scripts or tools are inclusive of both Windows and Linux users.

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 instructions, examples, and tools (such as PowerShell and Windows environment variable configuration) are consistently presented before their Linux equivalents. PowerShell-based examples dominate, and Windows-specific tools and paths are referenced in detail, while Linux instructions are often less detailed or presented after Windows. Some sections (e.g., credential asset permissions, runbook authentication examples) lack Linux-specific examples or omit equivalent Linux details.

Recommendations:

Alternate the order of Windows and Linux sections/examples, or present them in parallel tabs to give equal prominence.
Provide Linux-specific code examples wherever PowerShell/Windows examples are given (e.g., use Bash or Python for Linux runbooks).
Include detailed Linux instructions for tasks like environment variable setup, credential asset permissions, and runbook authentication, matching the depth of Windows guidance.
Where Windows tools or paths are referenced (e.g., C:\ paths, Control Panel), provide the Linux equivalents (e.g., /etc/environment, relevant Linux commands).
Add Linux troubleshooting tips and references alongside Windows event log and path information.
Where PowerShell is the only example, consider including a Python or Bash example for Linux users.

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 (a Windows-centric technology) is presented first and in greatest detail, with multiple sections and examples, while Linux-specific considerations are minimal or absent. Many examples and known issues reference Windows file paths (e.g., C:\modules), Windows environment variables, and Windows-specific behaviors. There is little to no guidance or examples for Linux users, especially regarding file paths, environment variables, or troubleshooting on Linux Hybrid Runbook Workers. The documentation also refers to Windows tools and patterns (such as PowerShell Workflow and graphical runbooks) that are not available or supported on Linux, often without clearly highlighting equivalent Linux workflows or limitations up front.

Recommendations:

Add Linux-specific examples and troubleshooting steps, especially for Hybrid Runbook Workers running on Linux.
When referencing file paths, provide both Windows and Linux equivalents (e.g., C:\modules and /usr/src/PSModules).
Clearly indicate in tables and introductory sections which runbook types and features are supported on Linux, and highlight Linux limitations or alternatives.
Provide parity in code samples: for every PowerShell example, include a Python example that demonstrates similar automation tasks, especially for cross-platform scenarios.
Avoid assuming Windows as the default environment; explicitly mention when instructions or limitations apply only to Windows.
Include a dedicated section summarizing Linux support, best practices, and known issues for Linux Hybrid Runbook Workers.
Where graphical or workflow features are Windows-only, suggest alternative approaches for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell command-line examples, with no equivalent examples for Azure CLI (which is cross-platform and more commonly used on Linux/macOS). The only scripting examples are in PowerShell, and there are no bash or shell script examples. Portal instructions are platform-agnostic, but the command-line automation focus is exclusively on Windows-centric tools. Azure CLI is mentioned in the introduction but not actually used in any example. This may hinder Linux users or those preferring cross-platform tooling.

Recommendations:

Add equivalent Azure CLI (az) command examples for all PowerShell commands, especially for deleting Automation accounts and removing Log Analytics solutions.
Where scripting is shown (e.g., for automation or batch operations), provide both PowerShell and bash/shell script examples.
When listing command-line options, present Azure CLI examples before or alongside PowerShell to emphasize cross-platform support.
Explicitly mention that all actions can be performed from Linux/macOS using Azure CLI, and provide links to relevant CLI documentation.
Review all sections for references to Windows-only tools or patterns, and ensure Linux parity in instructions and screenshots where applicable.

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. Most examples, screenshots, and REST API payloads focus on PowerShell runbooks and the Az PowerShell module. Windows/PowerShell tools and patterns (e.g., PowerShell Gallery, .zip modules, Get-Module cmdlet) are mentioned and illustrated in detail, while Linux/Python equivalents are either briefly mentioned or omitted. There is little to no parity in examples or guidance for Python (Linux) runbooks, and Linux-specific package management is only referenced in passing.

Recommendations:

Provide equal, step-by-step examples for Python (Linux) runbooks, including screenshots and REST API payloads.
Include explicit instructions and examples for uploading and managing Python packages (e.g., .whl files), similar to the PowerShell/Az module guidance.
Mention and illustrate Linux/Python tools and patterns (e.g., pip, PyPI) where relevant, not just PowerShell Gallery.
Add sample code and output for viewing installed Python packages in a runbook, analogous to the Get-Module example for PowerShell.
Ensure that all notes and guidance referencing PowerShell (e.g., .zip files, Az module) have clear Linux/Python equivalents or caveats.
Balance screenshots and UI walkthroughs to show both PowerShell and Python runbook creation and management.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_centric_scenarios

Summary:

The documentation generally provides parity between Windows and Linux for most troubleshooting steps, with separate sections and commands for each OS. However, there is a noticeable Windows-first bias: Windows examples and paths are consistently listed before Linux equivalents, and some troubleshooting scenarios (especially those involving registry, event logs, and PowerShell scripts) are Windows-specific or more detailed for Windows. Several scenarios and resolutions focus exclusively on Windows tools (e.g., PowerShell scripts, registry edits, event logs), while Linux equivalents are either less detailed or absent. Some advanced troubleshooting and error scenarios are only described for Windows environments.

Recommendations:

Alternate the order of Windows and Linux instructions or group them together to avoid always listing Windows first.
Ensure that all troubleshooting scenarios and resolutions provided for Windows have Linux equivalents, or explicitly state when a scenario is Windows-only.
Expand Linux troubleshooting sections to match the level of detail given for Windows, including log locations, commands, and common issues.
Where PowerShell scripts or Windows event logs are referenced, provide equivalent Bash scripts or Linux log file locations and commands.
Add more Linux-centric troubleshooting scenarios, especially for issues that may be unique to Linux environments.
Clearly indicate in each scenario which OSes are affected, and avoid assuming Windows as the default context.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific tools and configuration steps are often mentioned first or exclusively, such as in deployment, performance optimization, and debugging sections. Some CLI commands and explanations are tailored to Windows, with Linux alternatives either mentioned after or not at all. PowerShell is referenced as a deployment option, but Linux shell or Bash equivalents are not always provided. Visual Studio (a Windows-centric tool) is frequently highlighted, while Linux-native workflows (e.g., VS Code on Linux, Bash scripting) are less emphasized or missing.

Recommendations:

Ensure that every Windows-specific example or command (e.g., PowerShell, Visual Studio) is paired with a Linux equivalent (e.g., Bash, VS Code on Linux).
When listing tools or workflows, alternate the order or present Linux and Windows options side by side, rather than always listing Windows first.
Expand CLI instructions to include both Windows and Linux shell syntax where differences exist.
Include explicit Bash or Linux shell examples for deployment, debugging, and configuration, not just Azure CLI commands.
Highlight cross-platform tools (like VS Code, Azure CLI) more prominently, and clarify when a tool or step is platform-specific.
In performance optimization and deployment sections, provide Linux-specific guidance and examples with equal detail as Windows.

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 Windows-centric tools (though VS Code is cross-platform). There are no instructions or examples for configuring the analyzer in Linux-native environments, such as via command-line tools, editor-agnostic workflows, or popular Linux editors like Vim or Emacs. The configuration steps assume a GUI-based workflow typical of Windows users, and there is no mention of how to enable or disable the analyzer using .NET CLI or through project files directly.

Recommendations:

Add instructions for enabling/disabling the Roslyn Analyzer via the .NET CLI (e.g., using dotnet build or dotnet format commands) that work on all platforms.
Provide examples for configuring the analyzer in editor-agnostic ways, such as editing .editorconfig or .csproj files directly.
Mention how to use the analyzer in popular Linux editors (e.g., Vim, Emacs, JetBrains Rider) or in headless CI environments.
Clarify that Visual Studio Code is cross-platform, and explicitly include Linux and macOS steps/screenshots if applicable.
Include troubleshooting or verification steps that can be performed from the command line, suitable for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates some Windows bias, including presenting Windows-specific details or tools before Linux equivalents, referencing Windows-only settings and paths, and providing more detailed PowerShell/Windows coverage. Linux-specific examples or parity are sometimes missing or less emphasized.

Recommendations:

Ensure all examples that reference environment variable syntax, file paths, or OS-specific settings provide both Windows and Linux equivalents side-by-side.
When mentioning tools like Azure PowerShell, always mention Azure CLI as an equal alternative, and provide CLI examples where possible.
For settings that are OS-specific (e.g., WEBSITE_NODE_DEFAULT_VERSION for Windows), clearly indicate Linux alternatives or explicitly state if there is no equivalent.
In sections where Windows is mentioned first (e.g., double-underscore vs colon in environment variable names), consider presenting both OS behaviors together or starting with a neutral explanation.
Expand Linux-specific guidance, especially around deployment, file paths, and runtime configuration, to match the detail given for Windows.
Where PowerShell is referenced for scripting or automation, provide Bash or shell script equivalents for Linux users.
Review all screenshots and code snippets to ensure Linux users are equally represented.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally strives for cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows-specific instructions (such as for Command Prompt and PowerShell) are presented before or more prominently than Linux equivalents. PowerShell is included as a first-class programming language option, and PowerShell scripting is shown in detail. Some command examples (such as environment variable assignment and activation of Python virtual environments) provide multiple Windows variants (Cmd, PowerShell, Bash), but the Windows options are often listed before Linux/macOS. There are also references to Windows-specific tools and patterns (e.g., .venv\scripts\activate, func.exe host process, Windows (Cmd) tabs), and in some cases, the Linux/macOS instructions are less detailed or appear after Windows instructions.

Recommendations:

Ensure that Linux/macOS instructions are always presented with equal prominence and, where possible, listed before or alongside Windows instructions, rather than after.
For every Windows-specific command or tool (e.g., .venv\scripts\activate, Cmd, PowerShell), provide the Linux/macOS equivalent (e.g., source .venv/bin/activate) in the same section or in a clearly parallel structure.
Avoid language such as 'terminal or command prompt' that subtly centers Windows; instead, use 'terminal' or explicitly mention both environments.
When referencing stopping processes (e.g., func.exe), use cross-platform language (e.g., 'func host process') or clarify the difference for each OS.
Review all code snippets and ensure that Linux/macOS and Windows examples are equally detailed and easy to find.
Consider including a summary table or section at the start that clarifies OS-specific differences, so Linux users can quickly find the relevant instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation is generally cross-platform in intent, focusing on Visual Studio Code and Azure Functions, which are available on Windows, macOS, and Linux. However, there are subtle signs of Windows bias: troubleshooting steps specifically mention Windows (e.g., 'When running on Windows, make sure that the default terminal shell for Visual Studio Code isn't set to WSL Bash'), and there are no explicit Linux/macOS-specific instructions or examples. The document assumes parity but does not confirm or illustrate it, and Windows-specific issues are mentioned without equivalent Linux/macOS troubleshooting. No PowerShell or cmd examples are present, but the lack of Linux-specific notes or terminal commands is a gap.

Recommendations:

Add explicit notes or troubleshooting steps for Linux and macOS users, such as common issues with permissions, shell environments, or dependencies.
Where Windows-specific advice is given (e.g., about WSL Bash), provide equivalent guidance for Linux/macOS terminal environments.
Include at least one example or screenshot from a Linux or macOS environment to reinforce cross-platform support.
If there are platform-specific behaviors or requirements (such as installation steps for Azure Functions Core Tools), link to or summarize them for each OS.
Review included files (e.g., functions-install-core-tools-vs-code.md) to ensure they do not default to Windows-first instructions or screenshots.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates some Windows bias, most notably by listing Windows-centric tools (Visual Studio, PowerShell) before cross-platform or Linux-native alternatives, and by providing more detailed guidance for Windows-specific workflows (e.g., Visual Studio, PowerShell). While cross-platform support is mentioned, Linux-specific tools or examples are not highlighted, and Windows tools are often listed first or exclusively (e.g., Visual Studio, PowerShell Invoke-RestMethod).

Recommendations:

Ensure Linux-native tools (such as curl, HTTPie, or Linux terminal workflows) are listed before or alongside Windows tools in all tool recommendation lists.
Provide explicit Linux/macOS examples and workflows, not just generic 'command prompt or terminal' references.
Highlight Linux/macOS compatible IDEs (e.g., JetBrains Rider, VS Code) equally or before Visual Studio when discussing C# development.
Include Linux-specific troubleshooting tips or environment notes where relevant (e.g., file paths, permissions, dependency installation).
Balance PowerShell examples with Bash or shell script equivalents for command-line operations.
In tables and lists, alternate the order of Windows and Linux tools, or group them by platform to avoid implicit prioritization.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The tutorial exhibits a mild Windows bias by exclusively referencing Microsoft Excel and Notepad for data preparation and preview, and by describing UI steps using Windows-centric terminology (e.g., 'File > Save As...', 'Text (Tab delimited)(*.txt)'). There are no Linux or cross-platform alternatives mentioned for converting Excel files or viewing text files. The recommended development environment is Visual Studio Code, which is cross-platform, but no explicit Linux instructions or screenshots are provided. No PowerShell or Windows command-line tools are used, but the data preparation workflow assumes access to Microsoft Office tools, which are less common on Linux.

Recommendations:

Include instructions or alternatives for Linux users to convert Excel files to tab-delimited text, such as using LibreOffice Calc or command-line tools like csvkit or ssconvert.
Mention cross-platform text editors (e.g., VS Code, Sublime Text, nano) instead of only Notepad for viewing/editing text files.
Clarify that Visual Studio Code is available on Windows, Linux, and macOS, and provide links or notes for Linux installation.
Where UI steps are described (e.g., 'File > Save As...'), add notes for equivalent steps in LibreOffice or Google Sheets.
Add a section or callout box summarizing Linux/macOS-specific setup steps, if any, to ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Bash and Cmd (Windows Command Prompt) examples for most CLI operations, but consistently lists Windows/Cmd examples after Bash. There are no PowerShell-specific examples, but the presence of both Bash and Cmd covers both Linux/macOS and Windows users. However, some sections (such as Java version support) list 'Windows' before 'Linux', and there are no explicit Linux-specific troubleshooting tips or references to Linux tools or shell environments beyond Bash. There is also a lack of explicit mention of Linux distributions or package management, and no Linux-specific caveats or examples (e.g., for environment variables, file paths, or permissions). The documentation does not show exclusive Windows bias, but there is a subtle 'windows_first' ordering and a lack of Linux-specific depth.

Recommendations:

Ensure that Linux and Windows are given equal prominence in tables and examples (alternate order or explicitly state parity).
Add Linux-specific troubleshooting tips or notes, especially for common issues (e.g., file permissions, environment variable export, case sensitivity).
Include references to Linux distributions or package managers when discussing JDK installation or environment setup.
Where file paths or environment variables are discussed, show both Windows and Linux syntax (e.g., JAVA_HOME path examples, export vs set).
Consider adding a section or callout for Linux/macOS users with tips or best practices.
If possible, provide PowerShell examples in addition to Cmd for Windows users, and clarify when Bash examples are suitable for macOS as well as Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation generally aims for cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows terminology ("command prompt") is used before or instead of Linux equivalents ("terminal"), and Windows-specific recommendations are made (e.g., suggesting remote build for Windows users). Visual Studio Code is featured as the primary editor, which is cross-platform, but the language sometimes prioritizes Windows workflows. There are also references to Windows-specific behaviors in the Python standard library section. However, Linux is well represented in hosting and deployment, and explicit Linux-only requirements are called out.

Recommendations:

Use 'terminal' as the primary term, with 'command prompt' as a secondary/parenthetical reference, to avoid Windows-first language.
Wherever 'Visual Studio Code' is mentioned, clarify that it is cross-platform and suggest alternative editors for Linux users if relevant.
When discussing build and deployment, avoid recommending remote build specifically for Windows users; instead, explain the pros and cons for both Windows and Linux.
In the Python standard library section, clarify that standard libraries are available on both Windows and Linux, and avoid implying that Windows is the default.
Add explicit Linux shell (bash/zsh) command examples alongside any Windows command prompt or PowerShell examples, especially in code blocks and setup instructions.
Ensure that any references to tools (e.g., Azure Functions Core Tools) include installation and usage instructions for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing detailed instructions and screenshots for managing LDAP POSIX attributes using Windows-only tools (Active Directory Users and Computers MMC snap-in), and by describing access steps exclusively for Windows systems. There are no equivalent instructions or examples for managing POSIX attributes from Linux or cross-platform tools. Additionally, Windows terminology and tools are mentioned first or exclusively in several sections, while Linux/NFS client configuration is referenced only via a link, without in-page guidance or parity in detail.

Recommendations:

Add equivalent instructions for managing LDAP POSIX attributes using Linux tools (e.g., ldapmodify, ldapadd, or Apache Directory Studio) with example commands and screenshots.
Provide cross-platform guidance for accessing and editing LDAP attributes, including both Windows and Linux environments.
Ensure that examples and tool references are balanced between Windows and Linux, or presented in parallel where possible.
Include in-page, step-by-step instructions for configuring NFS clients on Linux, not just a link to another page.
Where Windows-specific features or tools are discussed, clarify Linux alternatives or note any limitations.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides a detailed PowerShell example and Windows-specific instructions for mounting NFS volumes and troubleshooting performance, but does not provide equivalent Linux command examples or troubleshooting steps. Windows tools and patterns (e.g., Set-NfsClientConfiguration, Mount command with Windows syntax) are mentioned exclusively in the relevant section, and Linux mounting is only referenced via a link, not with inline examples. This creates a bias toward Windows users and leaves Linux administrators without direct, actionable guidance.

Recommendations:

For every Windows-specific example (such as PowerShell commands and mount syntax), provide an equivalent Linux example (e.g., mount command with NFS options, editing /etc/fstab).
When discussing troubleshooting or configuration steps, present Linux and Windows instructions in parallel, or lead with Linux if the context is NFS (which is more commonly used on Linux).
Avoid mentioning only Windows tools or patterns; always include Linux-native tools and workflows, especially for NFS topics.
Where links to further documentation are provided, supplement them with at least one inline Linux example for quick reference.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page is generally cross-platform and avoids explicit Windows or PowerShell bias in its main instructions. However, in the troubleshooting section, when suggesting how to clear the DNS cache, only the Windows-specific command ('ipconfig /flushdns') is mentioned, with no Linux or macOS equivalents. This presents a subtle 'windows_first' and 'missing_linux_example' bias.

Recommendations:

When providing troubleshooting steps involving system commands (such as clearing DNS cache), include equivalent 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 possible, avoid mentioning only Windows tools or commands. If a platform-specific command is necessary, present all major OSes together or link to platform-specific instructions.
Review other sections for similar implicit assumptions about the user's OS, and ensure parity in examples and troubleshooting guidance.

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 examples or instructions for performing the same task using command-line tools such as Azure CLI or Bash, which are more commonly used in Linux environments. This omission may disadvantage Linux users or those who prefer automation and scripting.

Recommendations:

Add instructions and examples for deleting the resource group using Azure CLI (az group delete) with both Windows (PowerShell/CMD) and Linux (Bash) command syntax.
Include sample commands for PowerShell and Bash side by side to ensure parity.
Mention that the Azure portal is cross-platform, but also highlight command-line alternatives for users who prefer scripting or are on non-Windows systems.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation lists Windows hosting options and file/script types before their Linux equivalents, and Windows-specific tools and script types (.exe, .cmd, .bat, .ps1) are mentioned before Linux equivalents (.sh). This ordering and emphasis may suggest a Windows-centric perspective.

Recommendations:

Alternate the order of Windows and Linux hosting options, or list them alphabetically to avoid implicit prioritization.
List script/file types in a neutral or grouped manner (e.g., by function or alphabetically), rather than placing Windows types first.
Explicitly mention Linux tools and patterns (e.g., cron jobs, shell scripts) alongside Windows equivalents.
Provide balanced examples for both Windows and Linux environments where applicable.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both PowerShell and Azure CLI examples for granting Microsoft Graph permissions to a managed identity, but PowerShell is presented first and in more detail. The PowerShell example uses Windows-centric tooling and patterns, which may be more familiar to Windows users. There are no explicit Linux or Bash-specific examples, and the PowerShell script is more verbose and featured than the Azure CLI alternative.

Recommendations:

Present Azure CLI (cross-platform) examples before PowerShell examples to avoid implicit Windows-first bias.
Expand the Azure CLI example with more detailed comments and step-by-step explanations, matching the depth of the PowerShell example.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide Bash shell snippets where appropriate.
If PowerShell is required, clarify that PowerShell Core is cross-platform and provide installation instructions for Linux/macOS users.
Consider adding a table or section that summarizes equivalent commands for Windows (PowerShell), Linux (Bash/Azure CLI), and macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation generally avoids OS-specific instructions, but in the troubleshooting section for clearing DNS cache, it only provides a Windows-specific command (`ipconfig /flushdns`) and does not mention Linux or macOS equivalents. This presents a subtle Windows-first bias and omits guidance for users on other platforms.

Recommendations:

When providing troubleshooting steps like 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`).
Wherever possible, avoid OS-specific instructions unless all major platforms are covered equally.
If screenshots or UI instructions are platform-agnostic (as in this case), ensure any command-line or troubleshooting advice is also cross-platform.
Consider adding a note or table summarizing common DNS cache clearing commands for Windows, Linux, and macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

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. It references GitHub Codespaces and Azure CLI, which are cross-platform, but does not provide any explicit Linux-specific instructions, nor does it mention or demonstrate how to perform the same tasks in a Linux-native environment (e.g., using Linux terminal, editors, or deployment patterns). There are no PowerShell-specific commands, but the overall workflow is Windows/Microsoft-centric, and Linux users are left to infer compatibility.

Recommendations:

Explicitly state that all CLI commands (dotnet, azd) work on Linux, macOS, and Windows, and provide any necessary prerequisites for Linux (e.g., installing .NET SDK, Azure CLI).
Include Linux-specific instructions or notes, such as how to open the app in a browser from a Linux terminal, or how to run and debug the app using common Linux editors (VS Code, Vim, etc.).
Mention how to deploy from a local Linux environment, not just from Codespaces or GitHub Actions.
If referencing file paths, use forward slashes or clarify path conventions for both Windows and Linux.
Add a section or callout confirming that all steps are cross-platform, and link to official .NET and Azure CLI installation guides for Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents configuration options in the order: Azure portal, Azure PowerShell, and then Azure CLI. The PowerShell section is more detailed, with extensive step-by-step scripts and a dedicated cmdlet reference list, while the Azure CLI section is less detailed and lacks equivalent depth. There are no Linux-specific shell (bash) examples or explicit mention of Linux environments, and the CLI section is presented last, after the Windows-centric PowerShell section.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples, as CLI is cross-platform and preferred by many Linux users.
Ensure parity in detail and explanation between PowerShell and CLI sections, including step-by-step breakdowns and command references for CLI.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and consider including bash shell scripting examples where appropriate.
Add a note or section for Linux administrators, highlighting any OS-specific considerations or best practices.
Avoid implying PowerShell is the primary or default automation tool by balancing the order and depth of CLI and PowerShell content.

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

Recommendations:

Present Linux/macOS and Windows instructions in parallel tabbed sections, or alternate which platform is shown first to avoid Windows-first bias.
Reduce the emphasis on Windows-specific tools (e.g., setx, PowerShell) by giving equal prominence to Linux/macOS commands.
Consider providing a single cross-platform example (e.g., using a table or tabs) rather than listing Windows commands first.
Explicitly mention that the Go code and Azure CLI commands are cross-platform, reinforcing parity.
If possible, add troubleshooting notes for both Windows and Linux/macOS environments to further balance the guidance.

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 and PowerShell examples for Windows. Linux/macOS instructions are present but always listed last. There are no missing Linux examples, but the ordering and emphasis slightly favor Windows users.

Recommendations:

Present Linux/macOS and Windows instructions side-by-side or in tabs, rather than always listing Windows first.
Consider leading with Linux/macOS examples, especially since Go development is common on those platforms.
Reduce duplication of Windows instructions (cmd and PowerShell) unless necessary; clarify which is recommended.
Explicitly state that all commands are cross-platform unless otherwise noted, and ensure parity in troubleshooting or advanced sections if added.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is focused exclusively on ASP.NET Core and assumes a Windows/.NET development environment. There are no examples or instructions for Linux or cross-platform development, and all code and prerequisites are tailored to Windows-centric tools and workflows. There is no mention of Linux command-line tools, shell scripts, or how to achieve the same outcome in a non-Windows environment.

Recommendations:

Add explicit instructions or notes for Linux and macOS users, including any differences in environment setup or command-line usage.
Provide equivalent code samples or configuration steps for cross-platform .NET Core applications running on Linux.
Mention and link to documentation for using Azure App Configuration and Key Vault in non-Windows environments.
Clarify that the instructions are applicable to any platform supported by .NET Core, and highlight any platform-specific considerations.
If any Azure CLI or PowerShell steps are required, provide both Bash (Linux/macOS) and PowerShell (Windows) examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation generally provides parity between Windows and Linux examples, especially in Bicep and ARM template code, and clearly separates instructions for each OS using tabs and pivots. However, there are instances of Windows bias: (1) In several sections, Windows examples are presented before Linux equivalents, making Windows the default or primary context ('windows_first'). (2) The only explicit command-line deployment walkthroughs outside of Azure CLI are for PowerShell, with no Bash or Linux-native shell equivalents ('powershell_heavy'). There are no exclusive references to Windows-only tools, but the ordering and command-line focus may subtly favor Windows users.

Recommendations:

Alternate the order of Windows and Linux examples or present Linux first in some sections to avoid always prioritizing Windows.
Provide Bash or Azure CLI (Linux shell) equivalents for all PowerShell deployment walkthroughs, especially in the 'Deploy using PowerShell' section.
Where possible, clarify that all ARM/Bicep templates and Azure CLI commands are fully cross-platform, and highlight any OS-specific caveats.
Consider including a short section or note on using Linux-native tools (e.g., Bash, curl, jq) for template deployment and validation, to better support Linux users.
Ensure that any references to the Azure portal or Visual Studio Code extensions are clearly marked as cross-platform, and mention any OS-specific limitations if they exist.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page exhibits a subtle 'windows_first' bias by referencing Windows-specific App Service plan SKUs (e.g., 'Windows Isolated v2') before any mention of Linux equivalents. There are no explicit Linux examples, nor is there mention of Linux-specific deployment considerations or pricing, even though Azure App Service supports both Windows and Linux workloads. No PowerShell or CLI examples are present, but the only concrete SKU/pricing example is Windows-specific.

Recommendations:

Explicitly mention both Windows and Linux App Service plan SKUs and pricing models where relevant, especially in sections discussing minimum charges or deployment types.
Add notes or examples for Linux-based App Service Environments, including any differences in deployment, configuration, or pricing.
Ensure that screenshots and instructions are inclusive of both Windows and Linux scenarios, or clarify when a step or option is Windows-only.
Where possible, provide parity in documentation for both operating systems, including references to Linux-specific documentation or considerations.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation avoids explicit Windows bias by using cross-platform tools (Azure CLI, AZD, dotnet CLI) and recommending GitHub Codespaces for development. However, it does not mention or show any Linux-specific instructions, terminal environments, or deployment scenarios, nor does it acknowledge running locally on Linux or WSL. All command-line examples are generic and do not reference Windows-specific shells or tools, but there is a lack of explicit Linux parity or validation.

Recommendations:

Explicitly state that all steps and commands work on Linux, macOS, and Windows.
Add a note or section confirming that the tutorial has been tested on Linux and macOS, not just Windows.
Include screenshots or terminal output from a Linux shell (e.g., bash) to reinforce cross-platform compatibility.
Mention that Codespaces provides a Linux-based environment, and clarify that users can also run the sample locally on their own Linux or macOS machines.
If any step has OS-specific caveats (such as file paths or environment variable syntax), provide side-by-side examples for Windows (PowerShell/CMD) and Linux/macOS (bash/zsh).

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents environment variable setup instructions in the order: Windows CMD, PowerShell, then macOS/Linux. This 'Windows-first' ordering may suggest a preference for Windows users, though Linux/macOS instructions are present and complete.

Recommendations:

Present environment variable setup instructions in a neutral or platform-parallel format, such as a table with all platforms side-by-side.
Rotate the order of platform instructions, or begin with the most common platform for the target audience.
Explicitly state that the instructions apply equally to Windows, macOS, and Linux to reinforce cross-platform parity.
Where possible, use cross-platform tools or commands (e.g., Python's os.environ in code) to minimize OS-specific steps.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display explicit Windows bias in terms of command-line examples or tool references (e.g., no PowerShell or Windows-only tools are shown). However, there is a lack of parity for Linux users: there are no examples or instructions for running or configuring Durable Task Scheduler on Linux, nor is there mention of Linux-specific considerations or cross-platform command-line usage. The documentation focuses exclusively on SDK usage (C#, Java, JavaScript, Python) and does not address OS-level setup or differences, which may implicitly bias the content toward users already familiar with Windows or .NET environments.

Recommendations:

Add explicit instructions or notes about running Durable Task Scheduler on Linux, including any prerequisites or differences in setup compared to Windows.
Include cross-platform command-line examples (e.g., Bash, CLI) where relevant, especially for setup or deployment steps.
Mention any Linux-specific considerations, such as environment variables, file paths, or service management.
Clarify that the SDKs and orchestration features are cross-platform (if true), and provide guidance for Linux/macOS users where appropriate.

Create pull request

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