396
Pages Scanned
20
Pages Flagged
396
Changed Pages
5.1%
% Pages Flagged
Scan Information
Started At: 2025-07-15 00:00:11
Finished At: 2025-07-15 00:07:24
Status: completed
Target Repo: Azure
Current Phase: discovery
Files Queued: 396
Files Completed: 396
Problematic Pages
20 issues found
Storage
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/storage/blobs/immutable-version-level-worm-policies.md
...storage/blobs/immutable-version-level-worm-policies.md
High Priority
View Details →
Detected Bias Types
powershell_heavy
windows_tools
windows_first
Summary
The documentation page demonstrates a mild Windows bias by referencing PowerShell commands (e.g., Remove-AzRmStorageContainer) as the primary example for deleting containers, and by mentioning PowerShell before Azure CLI. There are no explicit Linux shell or Bash examples, and the documentation does not provide parity in command-line examples for Linux users. The focus on PowerShell and the absence of Linux-native command examples may disadvantage Linux administrators.
Recommendations
- Provide equivalent Bash or Linux shell command examples alongside PowerShell commands, especially for common administrative tasks such as deleting containers.
- When referencing command-line tools, mention Azure CLI before or alongside PowerShell, as Azure CLI is cross-platform and widely used on Linux.
- Include explicit notes or examples for Linux users where command syntax or behavior may differ.
- Avoid assuming PowerShell as the default scripting environment; clarify that both PowerShell and Bash/Azure CLI are supported.
- Where possible, provide REST API examples or links, as these are platform-agnostic.
Create Pull Request
API Management
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/api-management/applications.md
...docs/blob/main/articles/api-management/applications.md
High Priority
View Details →
Detected Bias Types
powershell_heavy
missing_linux_example
windows_tools
windows_first
Summary
The documentation page demonstrates a Windows bias by providing only Azure PowerShell scripts for generating OAuth tokens and calling APIs, with no equivalent examples for Linux or cross-platform tools (e.g., curl, bash). The use of PowerShell-specific cmdlets (Invoke-RestMethod, ConvertTo-Json, Write-Host) assumes a Windows environment. There are no CLI or bash/curl examples, and the only automation guidance is Windows-centric. Additionally, the inclusion of Azure PowerShell requirements in prerequisites and the absence of Linux or cross-platform tooling references further reinforce this bias.
Recommendations
- Add equivalent Linux/cross-platform examples using curl and bash for generating tokens and calling APIs.
- Include Azure CLI examples where possible, as it is cross-platform.
- Explicitly mention that the PowerShell examples are for Windows and provide alternative instructions for Linux/macOS users.
- Remove or supplement the Azure PowerShell requirements note with information about using other tools on non-Windows platforms.
- Ensure that all automation and scripting examples are provided in both PowerShell and bash/curl formats to support parity.
App Service
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-configure-premium-v4-tier.md
...s/app-service/app-service-configure-premium-v4-tier.md
High Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
missing_linux_example
Summary
The documentation demonstrates a Windows-first bias by prioritizing Windows terminology, tools, and examples. Azure PowerShell (a Windows-centric tool) is given a dedicated section, while Linux-specific automation (e.g., Bash scripting) is not mentioned. The Azure CLI examples are platform-neutral, but there are no explicit Linux shell or container deployment examples. The documentation refers to the Azure portal UI, which is the same across platforms, but does not provide parity for Linux-native workflows or tools.
Recommendations
- Add explicit Linux shell (Bash) script examples for automating Premium V4 app creation and scaling, in addition to Azure CLI.
- Include examples or references for deploying custom Linux containers, since Premium V4 supports them on Linux.
- Balance the automation section by providing both Azure PowerShell and Bash/CLI script examples, or clarify that Azure CLI commands work cross-platform.
- Mention Linux-native tools or workflows (such as using SSH, SCP, or Docker) where relevant, especially for custom container scenarios.
- Ensure that any references to Windows-specific features or limitations are matched with Linux equivalents or clarifications.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-dotnet-class-library.md
...cles/azure-functions/functions-dotnet-class-library.md
High Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
missing_linux_example
Summary
The documentation page exhibits a moderate Windows bias. Visual Studio (a Windows-centric IDE) is mentioned first and most frequently, with Visual Studio Code and command-line options listed after. Examples for installing packages are provided for Command Prompt and PowerShell, but there are no explicit Bash or Linux shell examples. The ReadyToRun publishing example uses a Windows runtime identifier (win-x86) without showing cross-platform equivalents. The section on Azure Functions Core Tools references the Windows installer (MSI) and Windows-specific paths, with no mention of Linux or macOS installation or file locations. There are no explicit Linux/macOS command-line or tooling examples, and Windows tools/patterns are referenced before or instead of cross-platform alternatives.
Recommendations
- Provide Bash/Linux/macOS equivalents for all command-line examples, including package installation and project setup.
- Include cross-platform runtime identifiers (e.g., linux-x64, osx-x64) in ReadyToRun and publishing examples, or show a table of common options.
- When listing development environments, alternate the order or explicitly state parity between Visual Studio, Visual Studio Code, and CLI, and provide equal depth of guidance for each.
- Reference cross-platform installation instructions for Azure Functions Core Tools, including npm and manual installation for Linux/macOS, and mention relevant file paths for non-Windows systems.
- Add explicit notes or callouts where behaviors or file locations differ between Windows and Linux/macOS.
- Ensure all tooling and workflow sections mention and show examples for both Windows and Linux/macOS users.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-develop-local.md
...in/articles/azure-functions/functions-develop-local.md
High Priority
View Details →
Detected Bias Types
windows_first
windows_tools
powershell_heavy
Summary
The documentation demonstrates some Windows bias by listing Windows-centric tools (Visual Studio, PowerShell) prominently, often before cross-platform or Linux-native alternatives. Visual Studio (Windows-only) is always listed first for C#, and PowerShell is highlighted as an HTTP test tool before more universal tools like curl. While the documentation does mention Linux and macOS support and includes cross-platform tools (VS Code, Core Tools, curl), Windows tools and patterns are often given priority or more detailed coverage.
Recommendations
- When listing development environments, avoid always listing Visual Studio (Windows-only) first. Consider grouping cross-platform tools (VS Code, Core Tools) before Windows-only tools, or clearly marking platform exclusivity.
- In tables and lists, alternate the order of tools or use alphabetical order to avoid implicit prioritization of Windows tools.
- For HTTP test tools, list curl (ubiquitous on Linux/macOS) before PowerShell, or group tools by platform compatibility.
- Where PowerShell is mentioned, also mention Bash or other Linux-native shells for parity.
- Explicitly call out Linux/macOS-specific workflows or tips where relevant, not just in passing.
- Ensure that all example commands and workflows are shown for both Windows and Linux (e.g., both PowerShell and Bash command lines where appropriate).
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/create-first-function-azure-developer-cli.md
...functions/create-first-function-azure-developer-cli.md
High Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
Summary
The documentation generally aims for cross-platform parity, but there are subtle signs of Windows bias. Windows command-line environments (Cmd, PowerShell) are often mentioned explicitly and sometimes before Linux/bash equivalents. PowerShell is given a dedicated programming language pivot, and Windows-specific instructions (such as activating Python venvs) are provided in detail. There is also a tendency to refer to 'terminal or command prompt' rather than just 'terminal', and some examples use Windows-centric terminology or tools.
Recommendations
- Ensure that Linux/bash instructions are always presented before or alongside Windows/Cmd/PowerShell examples, not after.
- Use neutral language such as 'terminal' instead of 'command prompt' unless specifically referring to Windows.
- Where PowerShell is given as a primary example, ensure bash/zsh equivalents are equally prominent.
- For all code snippets, provide both bash and Windows (Cmd/PowerShell) versions side-by-side, and make it clear which is which.
- Review all references to tools and paths (e.g., file paths, activation commands) to ensure Linux and macOS users are not disadvantaged.
- Consider adding explicit notes about cross-platform compatibility and any platform-specific caveats.
Azure Netapp Files
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/disable-showmount.md
.../main/articles/azure-netapp-files/disable-showmount.md
High Priority
View Details →
Detected Bias Types
powershell_heavy
windows_first
missing_linux_example
Summary
The documentation page demonstrates a Windows bias by providing only Azure PowerShell examples for registering and unregistering the feature, mentioning Azure CLI only as an aside without examples, and omitting any Linux shell or cross-platform command-line instructions. The primary workflow is presented using PowerShell, which is most familiar to Windows users.
Recommendations
- Provide equivalent Azure CLI command examples (e.g., 'az feature register', 'az feature show', 'az feature unregister') alongside PowerShell commands, with full syntax and example output.
- Present Azure CLI (cross-platform) commands before or alongside PowerShell to avoid the impression of Windows-first bias.
- Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide guidance for users on those platforms.
- Where possible, include screenshots or terminal output from Linux/macOS environments to reinforce cross-platform support.
Azure Netapp Files
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/faq-nfs.md
...-docs/blob/main/articles/azure-netapp-files/faq-nfs.md
High Priority
View Details →
Detected Bias Types
windows_tools
powershell_heavy
windows_first
missing_linux_example
Summary
The documentation provides a detailed PowerShell example and troubleshooting steps specifically for Windows NFS clients, including a PowerShell command and a Windows mount example. However, there are no equivalent Linux command examples or troubleshooting steps for Linux NFS clients, despite Linux being a primary NFS use case. This creates a Windows bias by prioritizing Windows tools, commands, and scenarios, while omitting Linux-specific guidance.
Recommendations
- Add equivalent Linux troubleshooting guidance for common NFS client issues (e.g., case sensitivity, mount performance).
- Provide Linux command-line examples (e.g., mount commands, NFS client configuration) wherever Windows examples are given.
- Ensure that Linux tools and workflows are mentioned at least as prominently as Windows ones, especially in sections discussing mounting, configuration, and troubleshooting.
- When referencing external documentation, ensure parity by linking to both Windows and Linux guides.
- Consider adding a dedicated FAQ entry for Linux client issues, similar to the Windows client troubleshooting section.
Azure Netapp Files
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/network-attached-storage-protocols.md
...ure-netapp-files/network-attached-storage-protocols.md
High Priority
View Details →
Detected Bias Types
windows_tools
windows_first
missing_linux_example
Summary
The documentation generally provides a balanced overview of both NFS (Linux/UNIX) and SMB (Windows) protocols, but there are subtle Windows biases. Windows tools and terminology (Active Directory, NTFS ACLs, SID translation, Entra ID) are referenced more frequently and with more official support. SMB/Windows scenarios are described as the default or primary use case, while Linux/UNIX (especially Samba/SMB on Linux) is described as unsupported or secondary. There are no Linux-specific command examples for SMB (e.g., using smbclient or mount.cifs), and the only command-line example given is for NFS (rpcinfo). Linux/UNIX tools and patterns are mentioned, but not as prominently or with as much detail as their Windows counterparts.
Recommendations
- Provide Linux-specific SMB usage examples (e.g., mounting SMB shares with mount.cifs, using smbclient) alongside Windows/Active Directory scenarios.
- Clarify support status for SMB/Samba on Linux and provide guidance or references for best-effort interoperability.
- Balance the order of protocol/tool presentation: when discussing dual-protocol or identity management, mention Linux/UNIX (e.g., LDAP, nsswitch) equally or before Windows/Active Directory.
- Include more Linux/UNIX-focused troubleshooting and configuration tips, especially for dual-protocol environments.
- Reference both Windows and Linux tools/utilities for managing permissions and shares (e.g., getfacl/setfacl for NFSv4 ACLs, as well as Windows ACL tools).
Backup
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/backup/microsoft-azure-backup-server-protection-v3-ur1.md
...kup/microsoft-azure-backup-server-protection-v3-ur1.md
High Priority
View Details →
Detected Bias Types
windows_first
missing_linux_example
windows_tools
Summary
The documentation demonstrates a strong Windows bias: all detailed workload examples, backup scenarios, and recovery options are focused on Windows operating systems and Microsoft applications. Linux is only mentioned as a VM guest, with minimal detail and no parity in backup/recovery features (e.g., only entire VM backup, no file-level restore). Windows-specific tools and patterns (NTFS, VSS, ReFS, deduplication, system state, bare metal recovery) are referenced throughout, with no Linux equivalents or alternatives described.
Recommendations
- Provide Linux-specific backup and recovery examples, including supported filesystems, backup types (e.g., file-level, application-aware), and restore options.
- Clarify limitations and feature gaps for Linux workloads, and offer guidance or workarounds where possible.
- Mention Linux tools or patterns (e.g., LVM snapshots, ext4/xfs support, Linux backup agents) where relevant.
- Ensure Linux support is described with the same level of detail as Windows, including supported distributions, backup scenarios, and recovery procedures.
- If certain features are Windows-only, explicitly state this and suggest alternative approaches for Linux environments.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/dotnet-isolated-process-guide.md
...icles/azure-functions/dotnet-isolated-process-guide.md
High Priority
View Details →
Detected Bias Types
windows_first
windows_tools
powershell_heavy
missing_linux_example
Summary
The documentation demonstrates a moderate Windows bias. Windows-specific tools and patterns (such as Visual Studio, PowerShell, and Windows-specific Azure CLI flags) are often mentioned before or instead of their Linux equivalents. Some instructions and examples are Windows-centric, and Linux-specific guidance is often relegated to secondary tabs or not provided with equal detail. There are also several places where only Windows commands or behaviors are described, or where Windows is the default context.
Recommendations
- Ensure that all CLI examples (especially for deployment, configuration, and debugging) are provided for both Windows and Linux, with Linux examples given equal prominence.
- When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, CLI, PowerShell), present cross-platform options first or in parallel, rather than defaulting to Windows-first ordering.
- Where PowerShell is mentioned, also provide Bash or shell equivalents for Linux/macOS users.
- In tables and lists, avoid putting Windows tools or instructions before Linux equivalents unless there is a technical reason.
- For debugging and deployment, include explicit Linux instructions and troubleshooting steps, not just Windows/Visual Studio guidance.
- Review all references to environment variables, file paths, and commands to ensure they are cross-platform or that both Windows and Linux formats are shown.
- Where tabs are used for OS-specific content, ensure the Linux tab is as complete and detailed as the Windows tab.
Storage
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/storage/blobs/immutable-container-level-worm-policies.md
...orage/blobs/immutable-container-level-worm-policies.md
High Priority
View Details →
Detected Bias Types
powershell_heavy
windows_tools
windows_first
Summary
The documentation page demonstrates a Windows bias by referencing PowerShell commands (Remove-AzRmStorageContainer, Remove-AzStorageContainer) as primary examples for control plane and data plane operations, and by mentioning these Windows-centric tools before the Azure CLI equivalents. There are no explicit Linux shell or cross-platform examples, and the focus on PowerShell may disadvantage Linux users.
Recommendations
- Provide equivalent Linux shell (bash) and Azure CLI examples alongside or before PowerShell commands.
- When referencing command-line tools, ensure Azure CLI (which is cross-platform) is given equal or greater prominence than PowerShell.
- Include explicit notes or examples for Linux/macOS users, especially for common administrative tasks.
- Avoid assuming the use of Windows tools or patterns; clarify that all operations can be performed from any OS using Azure CLI or REST API.
- Consider adding a table or section summarizing command syntax for PowerShell, Azure CLI, and REST API to ensure parity.
Digital Twins
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/digital-twins/how-to-ingest-iot-hub-data.md
...n/articles/digital-twins/how-to-ingest-iot-hub-data.md
High Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
missing_linux_example
Summary
The documentation demonstrates a Windows bias by prioritizing Windows-centric development tools (Visual Studio, Visual Studio Code) and workflows, referencing Windows-specific patterns (such as NuGet package manager), and omitting explicit Linux or cross-platform alternatives for key steps. While Azure CLI is used (which is cross-platform), the instructions and examples for creating and publishing Azure Functions are heavily oriented toward Windows development environments, and there is a lack of Linux-specific guidance or troubleshooting. There are also references to shell escaping issues, but these are only briefly mentioned without concrete Linux/Bash examples.
Recommendations
- Add explicit instructions and examples for Linux users, such as using the Azure CLI and dotnet CLI in Bash or other Linux shells for all steps (creating, building, and publishing Azure Functions).
- Include Linux-specific troubleshooting tips, especially for shell escaping and environment differences.
- Provide parity in tool recommendations, such as mentioning JetBrains Rider or other cross-platform IDEs alongside Visual Studio.
- Clarify that the Azure CLI commands work cross-platform, and provide example terminal commands for both Windows (CMD/PowerShell) and Linux (Bash/Zsh).
- Where Visual Studio or NuGet Package Manager is mentioned, also describe how to perform the same actions using the dotnet CLI on Linux.
- Add screenshots or terminal output examples from Linux environments where applicable.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-private-site-access.md
...zure-functions/functions-create-private-site-access.md
Medium Priority
View Details →
Detected Bias Types
windows_first
missing_linux_example
Summary
The documentation demonstrates a Windows bias by exclusively guiding users to create a Windows Server virtual machine, with no mention of Linux alternatives or examples. All screenshots and instructions for VM creation are Windows-centric, and there are no parallel instructions or notes for deploying or accessing the environment using a Linux VM. This may lead Linux users to believe that only Windows is supported or recommended for this scenario.
Recommendations
- Provide parallel instructions and screenshots for creating a Linux-based virtual machine (e.g., Ubuntu Server) alongside the Windows Server steps.
- Explicitly mention that either Windows or Linux VMs can be used for this scenario, and highlight any differences in setup or access.
- Include examples or notes on how to connect to a Linux VM via SSH using Azure Bastion, in addition to RDP for Windows.
- Ensure that any command-line or deployment steps (such as function deployment) include both Windows (PowerShell/Command Prompt) and Linux (Bash) examples where relevant.
- Add a section or callout box clarifying OS-agnostic aspects of the tutorial, reassuring users that the process is not limited to Windows environments.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/how-to-create-function-azure-cli.md
...es/azure-functions/how-to-create-function-azure-cli.md
Medium Priority
View Details →
Detected Bias Types
windows_first
windows_tools
Summary
The documentation generally maintains cross-platform parity, but there are subtle signs of Windows bias. In the Java section, command examples are given for Bash, PowerShell, and Cmd, with Bash listed first but Windows shells (PowerShell, Cmd) included explicitly. File paths in examples use backslashes (\), which are Windows-specific. The mention of 'command prompt' alongside 'terminal' may also suggest a Windows-first mindset. However, Linux tools like jq are mentioned, and most commands are cross-platform.
Recommendations
- Where multiple shell examples are provided, always list Bash (Linux/macOS) first, but ensure all platforms are equally represented.
- Use forward slashes (/) in file paths or clarify when a path is platform-specific.
- When referring to the command line, prefer 'terminal' over 'command prompt' unless specifically referring to Windows.
- Ensure that all scripts and code snippets are tested and work on both Linux and Windows shells.
- Explicitly mention Linux/macOS equivalents for any Windows-specific instructions or tools.
- If referencing PowerShell, also mention Bash or zsh alternatives where appropriate.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/python-memory-profiler-reference.md
...es/azure-functions/python-memory-profiler-reference.md
Medium Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
Summary
The documentation demonstrates a mild Windows bias, particularly in the local development instructions. Windows PowerShell is mentioned first, and Windows-specific commands and paths are presented before their Linux equivalents. The use of 'py -m venv' (Windows) is shown before 'python3 -m venv' (Linux), and the activation command for PowerShell is listed before the Linux shell equivalent. However, Linux alternatives are present, and the documentation does not omit Linux instructions entirely.
Recommendations
- Present Windows and Linux instructions in parallel or in a tabbed format, rather than listing Windows first.
- Use neutral language such as 'In Windows PowerShell, run: ... In Linux shell, run: ...' or provide both commands together.
- Where file paths are shown (e.g., <ProjectRoot>\HttpTriggerAsync\__init__.py), also show the Linux path (<ProjectRoot>/HttpTriggerAsync/__init__.py).
- Avoid phrases like 'Open a Windows PowerShell or any Linux shell as you prefer'—instead, use 'Open a terminal (Windows PowerShell or Linux shell)'.
- Ensure that all examples, screenshots, and outputs are shown for both platforms where differences exist.
Azure Netapp Files
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/faq-data-migration-protection.md
...es/azure-netapp-files/faq-data-migration-protection.md
Medium Priority
View Details →
Detected Bias Types
windows_first
windows_tools
Summary
The documentation demonstrates a mild Windows bias by listing Windows-specific tools (robocopy) before their Linux equivalents (rsync) when discussing SMB and NFS data migration. The only SMB tool mentioned is robocopy, a Windows-native utility, with no Linux or cross-platform SMB alternatives provided. Additionally, the order of presentation (rsync for NFS, robocopy for SMB) subtly prioritizes Windows tools for SMB scenarios.
Recommendations
- Include Linux and cross-platform SMB migration tools (such as smbclient, cifs-utils, or rsync with SMB mounts) alongside robocopy to provide parity for Linux users.
- When listing tools, avoid always presenting Windows tools first; consider alternating order or grouping by platform.
- Provide explicit examples or references for both Windows and Linux environments for all migration scenarios, especially for SMB.
- Clarify that migration can be performed from both Windows and Linux clients, and link to relevant documentation for each platform.
- Add a table or section summarizing migration tool options for both NFS and SMB, clearly indicating which platforms they support.
Azure Netapp Files
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/monitor-volume-capacity.md
...articles/azure-netapp-files/monitor-volume-capacity.md
Medium Priority
View Details →
Detected Bias Types
windows_first
windows_tools
Summary
The documentation presents Windows (SMB) client instructions before Linux (NFS) client instructions, and provides more detailed steps and screenshots for Windows tools (File Explorer, dir command) compared to Linux (only df -h is mentioned). Windows-specific tools and UI interactions are described in greater detail, while Linux instructions are more concise.
Recommendations
- Alternate the order of Windows and Linux sections, or present them in parallel to avoid the impression of prioritizing Windows.
- Provide equally detailed instructions and screenshots for Linux clients, including graphical tools (e.g., GNOME Disks, KDE Dolphin) if relevant.
- Mention Linux tools and commands with the same level of detail as Windows (e.g., explain how to check properties in Linux file managers, or use additional commands like lsblk, ncdu, or graphical utilities).
- Avoid presenting Windows tools and patterns first by default; consider user demographics or usage statistics to inform ordering.
- Ensure parity in troubleshooting notes and caveats for both platforms.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/create-first-function-vs-code-node.md
.../azure-functions/create-first-function-vs-code-node.md
Low Priority
View Details →
Detected Bias Types
windows_first
Summary
The documentation is largely cross-platform and avoids explicit Windows or PowerShell bias in its main instructions, as it focuses on Visual Studio Code and the Azure Functions extension. However, in the Troubleshooting section, there is a Windows-first bias: the only OS-specific advice is for Windows users regarding the default terminal shell, with no equivalent troubleshooting guidance for Linux or macOS users. There are no PowerShell-specific commands, Windows-only tools, or missing Linux examples, but the troubleshooting advice implicitly prioritizes Windows scenarios.
Recommendations
- Add troubleshooting notes for Linux and macOS users, such as common issues with permissions, shell configuration, or dependencies on those platforms.
- Where OS-specific advice is given (e.g., about the default terminal shell), provide equivalent guidance for Linux (e.g., bash/zsh issues) and macOS users.
- Explicitly state that the instructions apply to all supported platforms, and clarify any steps that differ by OS.
- Consider including a table or section listing any known OS-specific issues or differences in workflow.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-first-java-gradle.md
.../azure-functions/functions-create-first-java-gradle.md
Low Priority
View Details →
Detected Bias Types
windows_first
Summary
The documentation specifies 'os = windows' as the default runtime in the Gradle configuration, without mentioning Linux or cross-platform alternatives. This may lead users to assume Windows is the primary or only supported OS, despite Java and Azure Functions supporting Linux. No PowerShell or Windows-specific command-line tools are used, and all shell commands are cross-platform (bash/curl/gradle). However, the lack of explicit Linux parity in the runtime configuration is a subtle Windows-first bias.
Recommendations
- Explicitly mention that both Windows and Linux are supported as runtime OS options in the Gradle configuration.
- Show how to set 'os = linux' in the azurefunctions.runtime block, or provide a table comparing both options.
- Add a note clarifying that the instructions and commands work on both Windows and Linux, and that the default 'os = windows' can be changed as needed.
- If there are any platform-specific considerations (e.g., Java 21 only on Linux), highlight them in context and provide guidance for both platforms.