Azure Functions
385
Total Pages
248
Linux-Friendly Pages
137
Pages with Bias
35.6%
Bias Rate
Bias Trend Over Time
Pages with Bias Issues
1023 issues found
Showing 376-400 of 1023 flagged pages
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-functions-roslyn-analyzer.md
...functions/durable/durable-functions-roslyn-analyzer.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation page focuses exclusively on configuration steps for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows development environments. There are no examples or instructions for configuring the Roslyn Analyzer in Linux-native editors or via command-line tools, nor is there mention of cross-platform workflows or alternatives for non-Windows users.
Recommendations
- Include instructions for configuring and running the Roslyn Analyzer using cross-platform tools such as the dotnet CLI (e.g., dotnet build, dotnet format) that work on Linux and macOS.
- Mention and provide examples for popular Linux-native editors (such as JetBrains Rider, Vim, or Emacs) or at least clarify how to enable analyzers outside of Visual Studio/VS Code.
- Explicitly state the cross-platform compatibility of the analyzer and provide any necessary steps for Linux/macOS users.
- Add a section on troubleshooting or verifying analyzer operation in CI/CD pipelines, which are often Linux-based.
Create Pull Request
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-add-output-binding-storage-queue-vs.md
...tions/functions-add-output-binding-storage-queue-vs.md
High Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Powershell Heavy
Summary
The documentation is heavily oriented towards Windows and Visual Studio users. All instructions and UI references are specific to Visual Studio, a primarily Windows-based IDE, with no mention of Linux or cross-platform alternatives such as Visual Studio Code or command-line workflows. The use of NuGet Package Manager Console (which is PowerShell-based) is assumed, and there are no CLI or Linux-native instructions provided. While Azure Storage Explorer is mentioned as cross-platform, all step-by-step examples and screenshots are Windows-centric.
Recommendations
- Add parallel instructions for Linux/macOS users, using Visual Studio Code and/or Azure Functions Core Tools CLI.
- Provide command-line alternatives (e.g., dotnet CLI commands for package installation) instead of relying solely on the NuGet Package Manager Console.
- Include screenshots and UI references for cross-platform tools (such as VS Code) where possible.
- Explicitly mention that Visual Studio is only available on Windows, and direct Linux/macOS users to equivalent workflows.
- Ensure all prerequisite steps and tool installations have Linux/macOS guidance, not just Windows.
- Consider splitting the article or adding tabs/sections for Windows (Visual Studio) and cross-platform (VS Code/CLI) workflows.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-java.md
...n/articles/azure-functions/functions-reference-java.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation generally aims for cross-platform parity, but there is a subtle Windows bias in several areas. Command-line examples are always given in both Bash and Windows CMD, but the Windows CMD examples are consistently listed after Bash, which is positive. However, there are no explicit PowerShell examples, but the use of 'command prompt' and 'CMD' tabs may implicitly favor Windows users. There is also a lack of explicit Linux-specific troubleshooting, environment setup, or tool references. Some sections refer to 'command prompt' or 'terminal' generically, but do not provide Linux-specific guidance or troubleshooting, and there are no Linux-specific tools or package manager references. The documentation does not mention WSL, Linux file permissions, or other common Linux development concerns. The Java version support table is split by OS, but otherwise, Linux is not given special attention.
Recommendations
- Add explicit Linux troubleshooting tips (e.g., file permissions, JAVA_HOME setup on Linux, common Linux-specific errors).
- Include references to Linux package managers (apt, yum) for installing Java or Maven, or link to official installation guides for Linux.
- Where 'command prompt' is mentioned, clarify that this refers to Windows, and use 'terminal' for Linux/macOS.
- Consider adding PowerShell examples if CMD is included, or clarify that Bash examples are for Linux/macOS and CMD for Windows.
- Highlight any differences in local development experience between Windows and Linux (e.g., path separators, environment variable syntax).
- Mention WSL as an option for Windows users who want a Linux-like environment.
- Ensure that all tools and workflows described (e.g., Maven, Azure CLI) are confirmed to work on Linux, and note any OS-specific caveats.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-your-first-function-visual-studio.md
...https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-create-your-first-function-visual-studio.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Windows First
Summary
The documentation is heavily oriented towards Windows users by exclusively using Visual Studio (a primarily Windows IDE) for all steps, with no Linux or cross-platform alternatives shown in the main flow. All examples and instructions assume the use of Visual Studio and Windows file management conventions, and there is no mention of Linux tools, command-line alternatives, or how to perform these steps on Linux. The only nod to cross-platform development is a brief mention of a separate Visual Studio Code article, but this is not integrated into the main content.
Recommendations
- Provide parallel instructions or clear pivots for Linux users, such as using Visual Studio Code or the Azure Functions Core Tools CLI.
- Include examples and screenshots for Linux environments, especially for steps like file renaming and running the function locally.
- Mention and link to Linux-compatible tools and workflows (e.g., dotnet CLI, VS Code) directly in the prerequisites and throughout the article.
- Avoid assuming the use of Windows-specific tools or UI patterns (e.g., File Explorer, Visual Studio menus) without offering Linux equivalents.
- Consider adding a platform selection pivot at the top of the article to allow users to choose Windows or Linux instructions.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-core-tools-reference.md
...cles/azure-functions/functions-core-tools-reference.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation page for Azure Functions Core Tools exhibits a moderate Windows bias. It references Windows-specific tools and patterns (such as func.exe and the Microsoft Azure Storage Emulator), mentions PowerShell-specific features, and sometimes provides guidance or notes that are Windows-centric. There is a lack of explicit Linux/macOS examples or parity in tool references, and some features are described with Windows-first language or only mention Windows tools before their Linux equivalents.
Recommendations
- Provide explicit Linux/macOS command-line examples alongside or in place of Windows examples, especially where file paths, shell syntax, or environment differences matter.
- Avoid Windows-first language such as referencing 'func.exe'—use 'func' or 'Azure Functions Core Tools' generically.
- When mentioning tools like the Microsoft Azure Storage Emulator (Windows-only), always mention cross-platform alternatives (e.g., Azurite) and provide usage instructions for Linux/macOS.
- For PowerShell-specific features (such as managed dependencies), clarify their scope and provide equivalent guidance for other shells/runtimes where possible.
- Ensure that all instructions and notes are reviewed for platform neutrality, and add platform-specific notes where behavior or requirements differ.
- Include troubleshooting or environment setup notes for Linux/macOS users, especially for dependencies like Docker, .NET SDK, or file permissions.
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
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by prioritizing Windows tools and patterns, such as Visual Studio and Windows-specific paths, and by providing command-line examples primarily in Windows formats (cmd, PowerShell). There is a lack of explicit Linux/macOS examples or parity in tool installation, file paths, and command usage. Linux equivalents are either omitted or not given equal prominence, which may hinder cross-platform developers.
Recommendations
- Provide Linux/macOS equivalents for all command-line instructions, including bash/zsh examples alongside cmd and PowerShell.
- Include file path examples using both Windows (\) and Unix (/) separators where relevant.
- When referencing tools like Visual Studio, also mention and provide parity for cross-platform alternatives such as Visual Studio Code and the .NET CLI.
- For installation and usage of Azure Functions Core Tools, explicitly document Linux/macOS installation steps and note any differences in behavior or file locations.
- Avoid using Windows-specific environment variable syntax (e.g., %USERPROFILE%) without also showing the Unix equivalent (e.g., $HOME).
- Ensure that all code and configuration examples (such as ReadyToRun <RuntimeIdentifier>) include both Windows and Linux/macOS targets (e.g., win-x86, linux-x64, osx-x64).
- When showing package installation commands, always provide bash (dotnet CLI) and PowerShell examples together, not just Windows-centric ones.
- Audit all references to Windows-only tools or extensions and provide guidance for Linux/macOS users where possible.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-how-to-azure-devops.md
...icles/azure-functions/functions-how-to-azure-devops.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation demonstrates a moderate Windows bias. Windows-based build agents ('windows-latest') are used by default for C# and PowerShell examples, and Windows is often mentioned before Linux. PowerShell is given its own language tab, and Windows-specific deployment types are described as defaults. Linux support is present, especially for Python and JavaScript, but Windows is prioritized in ordering and examples.
Recommendations
- For C# examples, provide both 'windows-latest' and 'ubuntu-latest' YAML samples, or explain when each is appropriate.
- When presenting build and deployment YAML, avoid defaulting to Windows unless required by the language or runtime. Instead, present both Windows and Linux options side by side.
- In language tabs, ensure Linux and macOS development environments are mentioned where relevant (e.g., not just Visual Studio Code on Windows).
- For PowerShell, clarify whether cross-platform PowerShell Core is supported and provide Linux/macOS build agent examples if possible.
- In deployment sections, avoid stating 'the default appType is Windows' without equal emphasis on Linux. Instead, explain both options equally and note the implications.
- Review ordering: mention Linux and Windows together, or alternate which is presented first, to avoid reinforcing Windows as the default.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-infrastructure-as-code.md
...es/azure-functions/functions-infrastructure-as-code.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Examples Prominence
Powershell Heavy
Summary
The documentation generally provides parity between Windows and Linux for Bicep and ARM template examples, but there is a consistent pattern of presenting Windows examples and instructions before Linux equivalents ("windows_first"). In several sections, Windows tabs are listed first, and Windows-specific settings or instructions are described before Linux. The deployment instructions and validation sections feature PowerShell examples prominently, with less emphasis on Bash or cross-platform CLI alternatives ("powershell_heavy"). There are no outright missing Linux examples, but the ordering and prominence favor Windows.
Recommendations
- Alternate the order of Windows and Linux examples/tabs, or present Linux first in some sections to balance prominence.
- Where possible, provide Bash/Azure CLI examples alongside PowerShell, especially in deployment and validation sections.
- Explicitly state that all examples are cross-platform unless noted, and highlight any Linux-specific considerations at the same level as Windows.
- Review tab ordering and ensure Linux is not always secondary.
- In sections where Windows and Linux instructions are nearly identical, consider merging them and calling out differences inline, rather than segregating by OS with Windows first.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-python.md
...articles/azure-functions/functions-reference-python.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation generally maintains good cross-platform parity and emphasizes Linux as the primary hosting environment for Python Azure Functions. However, there are subtle Windows biases: Windows terminology ("command prompt") is often used before or instead of Linux/Unix equivalents ("terminal"), and Windows-specific recommendations (such as using remote build when developing on Windows) are present. The documentation also references Visual Studio Code and Azure Functions Core Tools, which are cross-platform, but the language sometimes prioritizes Windows workflows. There are no explicit PowerShell-only examples or exclusive use of Windows tools, but the ordering and phrasing can give the impression of Windows-first development.
Recommendations
- Use neutral, cross-platform terminology such as "terminal" or "shell" instead of "command prompt" or pair them equally (e.g., "terminal or command prompt").
- When giving recommendations (e.g., for remote build), clarify that the advice applies to both Windows and Linux where appropriate, or explain the rationale for any OS-specific guidance.
- Ensure that all CLI examples use bash/zsh syntax by default, or provide both Windows (cmd/PowerShell) and Linux/macOS (bash) variants where differences exist.
- If referencing Visual Studio Code, clarify that it is available on all major platforms.
- Explicitly mention Linux/macOS support in all tool and workflow descriptions, especially in sections that mention local development or publishing.
- Avoid language that suggests Windows is the default or preferred development environment for Python on Azure Functions.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-java.md
...n/articles/azure-functions/functions-reference-java.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation generally provides both Bash and Windows CMD examples for command-line operations, but consistently lists Windows tools and environments (such as Visual Studio Code, CMD, and Windows-specific Java version support) before Linux equivalents. The Java version support table lists Windows before Linux, and the documentation references Windows-specific settings and tools prominently. There is a lack of explicit Linux shell or environment-specific troubleshooting, and the documentation sometimes assumes familiarity with Windows conventions (such as JAVA_HOME setup and CMD syntax). However, Linux is not entirely omitted, and Bash examples are present, but Windows is given priority in ordering and presentation.
Recommendations
- Alternate the order of Bash and CMD examples, or present Bash (Linux/macOS) first to reflect the prevalence of Java development on non-Windows platforms.
- Explicitly mention Linux and macOS support and troubleshooting steps where environment variables, file paths, or shell commands are discussed.
- Include Linux-specific notes or caveats for environment setup (e.g., JAVA_HOME configuration, permissions, file system differences).
- Where developer environments are listed, do not list Visual Studio Code (a Microsoft product) first by default; consider alphabetical or usage-based ordering.
- When presenting tables (e.g., Java version support), consider listing Linux before Windows or side-by-side, and avoid implying Windows is the primary or default platform.
- Ensure all CLI examples are provided for both Bash and CMD, and consider including PowerShell only if there is a unique difference.
- Add explicit Linux/macOS troubleshooting and setup sections, especially for common issues like permissions, path separators, and shell differences.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-python.md
...articles/azure-functions/functions-reference-python.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation is generally cross-platform and Linux-focused for hosting, but there are subtle Windows biases in the development and publishing workflow sections. Windows/command prompt/PowerShell terminology is used first or exclusively in some places, and Windows is sometimes assumed as the local development environment. There is a lack of explicit Linux/macOS terminal examples, and some guidance is worded as if Windows is the default local OS.
Recommendations
- Provide explicit Linux/macOS terminal/bash examples alongside or before Windows/command prompt/PowerShell examples, especially in sections about local development, publishing, and package management.
- Use neutral terminology such as 'terminal' or 'shell' instead of 'command prompt' when referring to cross-platform command-line usage.
- Clarify instructions that are platform-specific (e.g., file paths, environment variables) and provide both Windows and Linux/macOS variants where relevant.
- In publishing and build guidance, avoid statements like 'Use remote build when you're developing Python apps on Windows' without also addressing Linux/macOS users. Instead, offer guidance for all platforms.
- Where Visual Studio Code is mentioned, also mention other popular cross-platform editors or clarify that VS Code is available on all major OSes.
- Review folder structure and code block language tags (e.g., use 'bash' instead of 'cmd' where appropriate) to ensure parity for Linux/macOS users.
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
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Missing Linux Example
Summary
The documentation page is generally cross-platform in intent, focusing on Visual Studio Code and Azure Functions, which are available on both Windows 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- or macOS-specific instructions or examples. Additionally, there is no mention of Linux terminal commands, shell environments, or potential Linux/macOS-specific issues, and no parity in troubleshooting for those platforms. The tools and workflows described (VS Code, Azure Functions extension, Core Tools) are cross-platform, but the documentation does not demonstrate this with examples or guidance for non-Windows users.
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 users (e.g., default shell settings, terminal configuration).
- Include at least one example or screenshot showing the workflow on Linux or macOS to reinforce cross-platform support.
- Mention any platform-specific prerequisites or installation steps for Azure Functions Core Tools and the VS Code extension.
- Ensure that all instructions and troubleshooting steps are reviewed for platform neutrality, and add clarifying notes where behavior may differ between operating systems.
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
Missing Linux Example
Summary
The documentation demonstrates a moderate Windows bias. While it does mention Linux and provides some Linux-specific configuration details, Windows tools and patterns are often mentioned first or exclusively. For example, instructions for installing Azure Functions Core Tools on Windows are more detailed, and Windows-specific configuration commands are presented before Linux equivalents. Some deployment and debugging instructions focus on Visual Studio (primarily a Windows tool) and PowerShell, with less emphasis or fewer examples for Linux environments. In several places, Linux is only mentioned as an alternative or in a tabbed section, and some CLI examples are not clearly marked as cross-platform.
Recommendations
- Ensure all command-line instructions (e.g., Azure CLI, dotnet CLI) are clearly marked as cross-platform and provide explicit Linux/macOS shell examples where relevant.
- When listing tools or methods (e.g., Visual Studio, Visual Studio Code, Azure CLI, PowerShell), avoid always listing Windows-first tools or experiences. Alternate the order or group by platform.
- Provide equal detail for Linux and macOS workflows, especially for local development, debugging, and deployment. For example, include VS Code and CLI-based debugging instructions for Linux/macOS.
- Where Windows-specific configuration or deployment steps are given, ensure Linux equivalents are presented side-by-side or in parallel tabbed sections.
- Avoid assuming Visual Studio as the default development environment; highlight VS Code and CLI as first-class options.
- Explicitly call out any differences or limitations on Linux/macOS, and provide workarounds or alternatives where possible.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-functions-roslyn-analyzer.md
...functions/durable/durable-functions-roslyn-analyzer.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation page focuses exclusively on configuration instructions for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows environments. The Visual Studio instructions are Windows-specific, and there is no mention of Linux or cross-platform alternatives for configuring or using the Roslyn Analyzer. There are no command-line or editor-agnostic instructions, nor are there examples for Linux users or those using other editors.
Recommendations
- Include instructions for configuring and using the Roslyn Analyzer in cross-platform editors such as JetBrains Rider or via command-line tools (e.g., dotnet CLI).
- Explicitly mention how to enable or disable the analyzer on Linux and macOS, including any differences in workflow.
- Provide examples or links for users who develop on Linux, such as using VS Code on Linux, or integrating Roslyn Analyzer into CI/CD pipelines.
- Clarify that Visual Studio Code is cross-platform, and provide Linux/macOS-specific screenshots or notes where UI or steps differ.
- Add a section on using the analyzer with the dotnet build process, which is platform-agnostic.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-functions-orchestration-versioning.md
.../durable/durable-functions-orchestration-versioning.md
High Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Windows Tools
Summary
The documentation page exclusively provides .NET (C#) code samples and references to Windows-centric tools and patterns (such as host.json and Durable Functions .NET Isolated model), with no mention of Linux-specific considerations, shell commands, or cross-platform scripting. There are no examples or guidance for Linux users, such as Bash commands, Linux file paths, or deployment patterns relevant to Linux environments. The documentation implicitly assumes a Windows/.NET development environment, which may hinder Linux parity and accessibility for non-Windows users.
Recommendations
- Include examples for other supported languages and platforms, such as JavaScript/TypeScript (Node.js), Python, or PowerShell, especially if Durable Functions supports them.
- Provide Linux/Bash command-line examples for configuration file editing, deployment, and orchestration management, alongside or instead of Windows/PowerShell examples.
- Clarify whether orchestration versioning is available and supported on Linux-hosted Azure Functions, and document any platform-specific caveats.
- Reference cross-platform tools and patterns (such as Azure CLI commands) rather than only .NET/Windows-centric approaches.
- Explicitly mention any differences in file paths, environment variables, or deployment steps between Windows and Linux environments.
- Add troubleshooting steps and best practices relevant to Linux users, including how to monitor and manage orchestrations on Linux-based Azure Functions hosts.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-functions-roslyn-analyzer.md
...functions/durable/durable-functions-roslyn-analyzer.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation focuses exclusively on configuration steps for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows environments. The Visual Studio instructions are Windows-specific, and there are no examples or guidance for configuring the Roslyn Analyzer in Linux-native editors or workflows (such as JetBrains Rider, command-line tools, or CI pipelines). There is no mention of Linux or cross-platform command-line usage.
Recommendations
- Add instructions for configuring and running the Roslyn Analyzer using .NET CLI commands (e.g., dotnet build, dotnet format) that work across Windows, Linux, and macOS.
- Include examples for popular Linux-friendly editors such as JetBrains Rider or Vim/Emacs with OmniSharp.
- Mention how to use the analyzer in CI/CD pipelines (e.g., GitHub Actions, Azure Pipelines) that run on Linux agents.
- Clarify that Visual Studio Code is cross-platform and provide Linux/macOS-specific notes or screenshots where relevant.
- Explicitly state that the analyzer works on all platforms supported by .NET and provide parity in setup instructions.
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 exhibits a moderate Windows bias. Windows-specific tools, settings, and instructions are often mentioned before or more prominently than their Linux equivalents. Some examples and configuration steps are Windows-centric, with Linux alternatives either mentioned later, less prominently, or omitted. PowerShell and Visual Studio (Windows) are highlighted as primary tools, while Linux/CLI workflows are less emphasized or lack parity in detail.
Recommendations
- Ensure all instructions and examples that reference Windows tools (e.g., Visual Studio, PowerShell) are immediately accompanied by equivalent Linux/CLI alternatives, not just referenced later or in separate tabs.
- When listing deployment and configuration methods, present Linux/CLI options (e.g., Azure CLI, VS Code, Bash) before or alongside Windows/PowerShell options, not after.
- Add explicit Linux/Bash examples wherever PowerShell or Windows-specific commands are shown, especially for project setup, deployment, and configuration.
- Clarify when a feature or tool is Windows-only, and provide clear Linux alternatives or workarounds.
- Balance the prominence of Visual Studio and Visual Studio Code, highlighting VS Code and CLI as cross-platform first-class options.
- Review all code snippets and ensure that any file paths, environment variables, or configuration steps are shown for both Windows and Linux environments.
- Where tabs are used for OS-specific content, default to the user's OS if possible, or present Linux and Windows equally.
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 demonstrates some Windows bias, particularly in the ordering and inclusion of examples for command-line usage. In several places, Windows-specific shells (Cmd, PowerShell) are presented before or more prominently than Linux/macOS equivalents. PowerShell is treated as a first-class language option, and Windows command-line patterns are detailed alongside or before bash equivalents. However, Linux/macOS instructions are present, and the use of cross-platform tools like curl and azd is consistent.
Recommendations
- Ensure that Linux/macOS examples are always presented first or at least with equal prominence to Windows examples, especially in tabbed code blocks.
- Where possible, use neutral terms like 'terminal' instead of 'command prompt' or clarify that both are supported.
- For PowerShell, clarify its availability on Linux/macOS or provide bash/zsh equivalents where appropriate.
- In sections where multiple shell examples are given, consider defaulting to bash (Linux/macOS) first, as it is more universally available across platforms.
- Audit all code snippets and instructions to ensure that Linux users are not required to mentally translate from Windows-specific instructions.
- Explicitly mention cross-platform compatibility for all tools and commands, and provide troubleshooting tips for common Linux/macOS issues.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-python.md
...articles/azure-functions/functions-reference-python.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation demonstrates a mild Windows bias in several areas. While the overall content is cross-platform and Linux is well-supported (especially for hosting), there are multiple instances where Windows terminology, tools, and workflows are mentioned first or exclusively. Specifically, references to 'command prompt', 'Terminal or command prompt', and the recommendation to use remote build when developing on Windows, as well as the use of 'cmd' in folder structure examples, indicate a Windows-centric perspective. There is also a lack of explicit Linux shell (bash) examples or terminology, and no mention of Linux-specific tools or workflows, even though Azure Functions Python hosting is Linux-only.
Recommendations
- Use neutral or inclusive terminology such as 'terminal' or 'shell' instead of 'command prompt', or mention both (e.g., 'terminal (Linux/macOS) or command prompt (Windows)').
- Provide explicit bash/zsh shell examples alongside or instead of Windows command prompt examples, especially in code blocks and folder structure listings.
- When referencing development environments, list cross-platform options first or in parallel (e.g., 'Terminal (Linux/macOS), Command Prompt or PowerShell (Windows)').
- Clarify that 'cmd' in folder structure listings is for illustration, and provide equivalent bash commands or tree outputs.
- Highlight Linux development workflows and tools (e.g., bash, zsh, Linux package managers) where appropriate, especially since Azure Functions Python apps are hosted on Linux.
- If recommending remote build for Windows users, also provide guidance for Linux/macOS users, and clarify any differences in workflow or recommendations.
- Audit all references to Windows-specific tools (e.g., PowerShell, Command Prompt) and ensure Linux equivalents are mentioned with equal prominence.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-java.md
...n/articles/azure-functions/functions-reference-java.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation provides both Bash and Windows CMD examples for command-line operations, but consistently lists Windows CMD examples immediately after Bash, sometimes with more detail. There are no explicit PowerShell examples, but the presence of 'command prompt' and 'CMD' tabs, and the absence of Linux-specific troubleshooting or environment details, indicate a mild Windows-first bias. There are no Linux-specific tools or troubleshooting sections, and some instructions (e.g., setting JAVA_HOME) do not clarify OS-specific differences. The documentation does not provide parity for Linux-specific issues or workflows, and does not mention WSL or other Linux environments for Windows users.
Recommendations
- Ensure that Bash examples are always presented first, or at least alternate the order with CMD to avoid implicit prioritization.
- Add explicit Linux troubleshooting sections, especially for environment variable setup (e.g., JAVA_HOME), file permissions, and common Linux-specific issues.
- Include PowerShell examples only if they are necessary, and always provide equivalent Bash and CMD examples.
- Clarify in all environment variable and path instructions how they differ between Windows and Linux.
- Mention WSL as an option for Windows users who prefer a Linux-like environment.
- Where IDEs are mentioned, note any OS-specific setup steps or limitations.
- Add a section or note about deploying and running on Linux, including any differences in file system case sensitivity, permissions, or supported features.
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
Cmd Heavy
Powershell Examples
Missing Linux Example
Summary
The documentation generally strives for cross-platform parity, but there are several subtle Windows biases. In command sections, Windows (Cmd) and PowerShell examples are often presented alongside or even before Linux/bash equivalents. Some instructions (such as virtual environment activation for Python) provide more detail for Windows than for Linux/macOS. PowerShell-specific pivots and examples are present, and in some cases, Linux-specific instructions are less prominent or missing (e.g., the use of 'py' instead of 'python3' for venv creation on Windows).
Recommendations
- Ensure that Linux/macOS examples are always presented with equal prominence and detail as Windows examples, ideally listing Linux/bash first where appropriate.
- Where multiple OS-specific tabs are used, ensure that Linux/bash is the default or at least not always listed after Windows.
- For PowerShell and Cmd examples, always provide bash/zsh equivalents, and clarify when a command is cross-platform.
- In sections like virtual environment creation, clarify the differences between 'py' and 'python3', and ensure Linux users are not left to infer steps.
- Audit for any missing Linux-specific troubleshooting or setup steps (e.g., package installation, file permissions) and add them as needed.
- Where possible, use neutral, cross-platform language such as 'terminal' instead of 'command prompt', and avoid assuming Windows as the default environment.
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
Missing Linux Example
Summary
The documentation exhibits some Windows bias, particularly in deployment, configuration, and debugging sections. Windows-specific instructions and tools (such as Visual Studio and PowerShell) are often mentioned before or more prominently than their Linux equivalents. Some examples and CLI commands are provided only for Windows or are Windows-first, with Linux alternatives appearing later or not at all. There are also places where Linux-specific guidance is less detailed or omitted.
Recommendations
- Ensure that all CLI and deployment instructions are presented for both Windows and Linux equally, ideally side-by-side or with clear tabs for each OS.
- When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, Azure CLI, Azure PowerShell), avoid always listing Windows tools first; rotate or group by platform.
- For every PowerShell or Windows-specific example, provide an equivalent Bash/Linux example.
- In debugging and performance optimization sections, explicitly describe Linux workflows and tools, not just Windows (e.g., attach to process, checking architecture, ReadyToRun publishing).
- Where possible, use cross-platform tools (like Azure CLI) as the primary example, and only supplement with platform-specific tools as needed.
- In tables and lists, avoid defaulting to Windows as the primary or only example—ensure Linux is equally represented.
- Review all code snippets and ensure any file paths, commands, or environment variables are cross-platform or have both Windows and Linux variants.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-functions-roslyn-analyzer.md
...functions/durable/durable-functions-roslyn-analyzer.md
High Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Missing Linux Example
Summary
The documentation focuses exclusively on Visual Studio and Visual Studio Code for configuring the Roslyn Analyzer, both of which are primarily associated with Windows development. There are no instructions or examples for configuring the analyzer in Linux-native editors or environments (e.g., JetBrains Rider, command-line tools, or cross-platform build systems). The Visual Studio section is given first and in more detail, reinforcing a Windows-centric perspective.
Recommendations
- Include instructions for configuring and running the Roslyn Analyzer using cross-platform tools such as the dotnet CLI (e.g., dotnet build, dotnet format) that work on Linux.
- Provide examples for popular Linux-friendly editors like JetBrains Rider or Vim/Emacs with OmniSharp.
- Clarify that Visual Studio Code is cross-platform, and provide Linux-specific steps or screenshots if any differences exist.
- Mention how to enable/disable analyzers in CI/CD pipelines or with MSBuild, which are platform-agnostic.
- Add a section explicitly addressing Linux/macOS users and any known differences or limitations.
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 a moderate Windows bias. Visual Studio (a Windows-centric IDE) is consistently listed first in C# development environments, and PowerShell is highlighted as a primary HTTP test tool. Windows-specific tools and workflows (such as Visual Studio and PowerShell) are mentioned before their cross-platform or Linux-native equivalents. While Linux and macOS are acknowledged as supported platforms, Linux-specific tools or workflows are not given equal prominence or detailed examples.
Recommendations
- In the C# environment table, list Visual Studio Code or the command-line/terminal option before Visual Studio, or at least alternate the order to avoid always prioritizing Windows-centric tools.
- When listing HTTP test tools, mention curl (a cross-platform, Linux-native tool) before PowerShell and Edge, and provide example usage for curl.
- Include explicit Linux/macOS terminal commands and examples alongside or before Windows/PowerShell examples throughout the documentation.
- Highlight Linux/macOS-specific development workflows or troubleshooting tips where relevant, not just generic 'supports Linux' statements.
- Where Visual Studio is mentioned, clarify its platform limitations and provide parity guidance for Linux/macOS users (e.g., using VS Code or JetBrains Rider).
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-java.md
...n/articles/azure-functions/functions-reference-java.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation provides both Bash and Windows Command Prompt (Cmd) examples for Maven and Azure CLI commands, but Windows (Cmd) examples are consistently presented alongside or immediately after Bash, sometimes with more prominence. There are no PowerShell-specific examples, but the presence of Windows Cmd tabs and terminology like 'command prompt' may reinforce a Windows-centric perspective. There are no Linux-specific tools or shell examples beyond Bash, and some instructions refer to 'command prompt' (a Windows term) rather than 'terminal' or 'shell'. Additionally, some tables and explanations list Windows before Linux, and there is no mention of Linux-specific troubleshooting or environment nuances.
Recommendations
- Ensure that Bash examples are clearly labeled as suitable for both Linux and macOS, not just 'Bash'.
- Where 'command prompt' is mentioned, clarify with 'command prompt (Windows)' and 'terminal (Linux/macOS)'.
- Consider providing PowerShell examples only if there is unique functionality, otherwise focus on Bash (cross-platform) and clarify compatibility.
- In tables and lists, alternate the order of Windows and Linux, or list Linux first where appropriate.
- Add Linux/macOS-specific troubleshooting tips or notes where environment differences may affect users.
- Explicitly state that all CLI and Maven commands work identically on Linux/macOS unless otherwise noted.
- Where possible, include screenshots or terminal output from both Windows and Linux environments to reinforce parity.