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 401-425 of 1023 flagged pages
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 is generally cross-platform and Linux-focused for hosting, but there are subtle Windows biases in development and publishing workflows. Windows terminology ("command prompt"), references to developing on Windows, and recommendations for remote build when developing on Windows are present. There is also a lack of explicit Linux/macOS CLI examples or terminal commands, and no mention of Linux-specific tools or shell environments. The documentation does not provide parity in examples for Linux users, and the language often assumes familiarity with Windows development environments.
Recommendations
- Provide explicit Linux/macOS shell examples (e.g., bash/zsh) alongside any Windows command prompt or PowerShell commands.
- Use cross-platform terminology such as "terminal" instead of "command prompt" or "command line" instead of "command prompt".
- When referencing development environments, mention Linux/macOS terminals and shells (e.g., bash, zsh) in addition to Windows command prompt/PowerShell.
- Include notes or examples for installing prerequisites (such as Azure Functions Core Tools, Python, etc.) on Linux/macOS, not just Windows.
- Clarify that all CLI commands work on Linux/macOS and provide any necessary differences (such as path separators or environment variable syntax).
- Highlight Linux-native workflows and tools where appropriate, especially since Azure Functions Python hosting is Linux-only.
- Avoid recommending remote build only for Windows users; instead, explain the pros and cons for each OS and let users choose based on their workflow.
Create Pull Request
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
Missing Linux Example
Windows First
Summary
The documentation page focuses exclusively on configuration instructions for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows development environments. There are no instructions or examples for configuring the Roslyn Analyzer in Linux-native editors or workflows (such as JetBrains Rider, Vim, or CLI-based setups), nor is there mention of cross-platform command-line usage. The ordering and content implicitly prioritize Windows-centric tools and workflows.
Recommendations
- Add instructions for configuring and running the Roslyn Analyzer using .NET CLI commands (e.g., dotnet build, dotnet format) that work on all platforms, including Linux.
- Include guidance for using the analyzer in other popular cross-platform editors such as JetBrains Rider, Vim, or Emacs.
- Explicitly mention that Visual Studio Code is cross-platform and provide Linux/macOS-specific notes or screenshots where applicable.
- Provide troubleshooting or configuration steps for users developing on Linux or macOS, such as environment variable settings or dependencies.
- Reorder or supplement the documentation to present cross-platform or Linux-friendly options before or alongside Windows-specific 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 instructions, tools, and examples are often presented before or more prominently than their Linux equivalents. Windows tools (such as Visual Studio and PowerShell) are mentioned first or exclusively in several sections, and some CLI commands are shown with Windows-centric parameters or context. There are also places where Linux-specific guidance is less detailed or omitted, and PowerShell is referenced without equal emphasis on Bash or other Linux shells.
Recommendations
- Ensure that all command-line instructions (such as Azure CLI examples) are shown with both Windows (PowerShell/CMD) and Linux (Bash) syntax, using tabs or side-by-side presentation.
- When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, Azure CLI, Azure PowerShell), alternate the order or present them in a neutral way, rather than always listing Windows-first options.
- Provide Linux-specific examples and troubleshooting steps wherever Windows-specific ones are given (e.g., for debugging, deployment, and configuration).
- Explicitly mention Linux support and any differences in behavior, especially in sections about deployment, debugging, and performance optimizations.
- Where PowerShell is referenced, also provide Bash equivalents, and clarify when a step is OS-specific.
- Add more explicit Linux container deployment examples, and ensure parity in instructions for both OSes.
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 aims for cross-platform parity, but there are several subtle Windows biases. In command examples, Windows (Cmd) and PowerShell are often presented before or more prominently than Linux/macOS equivalents. Some sections provide detailed Cmd and PowerShell scripts, while Linux/bash examples are less detailed or missing (e.g., in Java deployment and function invocation). The use of 'command prompt' as a generic term and the inclusion of PowerShell-specific pivots also reinforce a Windows-centric approach. Linux/macOS users may find some steps less clear or less prioritized.
Recommendations
- Ensure that for every Windows (Cmd or PowerShell) example, an equivalent Linux/macOS (bash/sh) example is provided and given equal prominence.
- When listing multiple platforms, alternate the order or present Linux/macOS first in some sections to avoid always prioritizing Windows.
- Use neutral terms like 'terminal' instead of 'command prompt' when referring to the command line.
- Where PowerShell is used, clarify its cross-platform availability or provide bash alternatives.
- Audit all code snippets and pivots to ensure Linux/macOS users are not missing context or steps (e.g., in Java deployment, ensure bash and Cmd examples are equally detailed).
- Consider a summary table or section that explicitly states cross-platform compatibility and any OS-specific caveats.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-app-settings.md
...ain/articles/azure-functions/functions-app-settings.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation generally aims for cross-platform coverage, but there are several instances of Windows bias. Windows-specific tools and patterns (such as PowerShell, Windows environment variable syntax, and Windows-only settings) are mentioned, sometimes without equivalent Linux examples or with Windows examples given first. Some settings and explanations are Windows-centric, and PowerShell is given special attention compared to other shells. In a few places, Linux alternatives are missing or only briefly referenced.
Recommendations
- When providing examples for environment variable paths or values (e.g., AzureWebJobs_TypeScriptPath), include both Windows and Linux formats side by side.
- For settings that are OS-specific (e.g., WEBSITE_NODE_DEFAULT_VERSION), clarify Linux alternatives or explicitly state the Linux equivalent or lack thereof.
- Where PowerShell is referenced for scripting or automation, provide Bash or shell equivalents for Linux users.
- In sections that discuss reserved characters or delimiters (e.g., double-underscore vs. colon), provide explicit Linux behavior and examples, not just Windows.
- Ensure that all sample commands, file paths, and configuration snippets are shown for both Windows and Linux where applicable.
- Review all references to Azure CLI and Azure PowerShell, and ensure Azure CLI (which is cross-platform) is not presented after PowerShell or as an afterthought.
- Where legacy or deprecated settings are Windows-only, clearly mark them as such and suggest Linux alternatives or note the lack thereof.
- For settings that behave differently on Windows and Linux (e.g., WEBSITE_TIME_ZONE), always show both example values and clarify the mapping.
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 mild Windows bias. Windows-specific tools and configuration steps are often mentioned before their Linux equivalents, and some examples or instructions are provided only for Windows or with Windows-centric language. There are also cases where Linux-specific guidance is less detailed or omitted, and Windows tools (such as Visual Studio and PowerShell) are highlighted more prominently than Linux alternatives.
Recommendations
- Ensure all CLI and configuration examples are provided for both Windows and Linux, ideally side-by-side or with clear tabs.
- When listing tools or instructions (e.g., Visual Studio, Visual Studio Code, Azure CLI, Azure PowerShell), present Linux-friendly options (such as Azure CLI and VS Code) before or alongside Windows-centric tools.
- Avoid language that assumes Windows as the default; explicitly mention Linux where applicable.
- For deployment and debugging sections, provide equivalent Linux workflows and commands, not just Windows/PowerShell or Visual Studio instructions.
- Where ReadyToRun or runtime identifier tables are shown, ensure Linux is given equal prominence and detail as Windows.
- For any references to file paths, environment variables, or shell commands, include both Windows and Linux syntax.
- Add more Linux-specific troubleshooting and best practices, especially for local development and deployment.
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
Missing Linux Example
Windows First
Summary
The documentation 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 instructions or examples for configuring the Roslyn Analyzer in Linux-native editors or command-line environments, nor is there mention of cross-platform workflows (e.g., JetBrains Rider, CLI usage, or integration with CI/CD pipelines). The ordering and content implicitly assume a Windows-centric development workflow.
Recommendations
- Add instructions for configuring and running the Roslyn Analyzer using the .NET CLI (dotnet build/analyze) to support Linux and macOS users.
- Include examples or references for popular cross-platform editors such as JetBrains Rider or Vim/Emacs with OmniSharp.
- Clarify that Visual Studio Code is cross-platform and provide explicit steps for Linux/macOS users, including any prerequisites.
- Mention how to use the analyzer in CI/CD pipelines (e.g., GitHub Actions, Azure Pipelines) to ensure parity for non-Windows environments.
- Consider reordering sections or adding a note to indicate cross-platform support and alternatives to Windows-specific tools.
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 provides both Bash and Windows Command Prompt (cmd) examples for CLI operations, but consistently lists Windows/cmd examples immediately after Bash, sometimes with more detail or parity. There is no explicit PowerShell usage, but the presence of 'cmd' tabs and references to 'command prompt' in getting started sections may suggest a slight Windows-first orientation. There are no Linux-specific tools or patterns mentioned, and some sections (such as the initial 'Getting started' table) refer to 'terminal/command prompt' without clarifying Linux vs. Windows. There are no Linux-only examples or guidance, and no mention of Linux-specific troubleshooting or behaviors.
Recommendations
- Ensure that all command-line examples are provided for Bash (Linux/macOS), Windows cmd, and PowerShell where appropriate, and that Bash examples are not treated as secondary.
- In getting started and tooling sections, explicitly mention Linux and macOS support, not just 'terminal/command prompt'.
- Add Linux/macOS-specific notes or troubleshooting tips where behaviors may differ (e.g., file paths, environment variable syntax).
- Where possible, provide parity in screenshots or step-by-step instructions for both Windows and Linux environments.
- Consider adding a section or callout for common Linux/macOS developer workflows, such as using VS Code on Linux, or running Maven from a Unix shell.
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 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.
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 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.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-app-settings.md
...ain/articles/azure-functions/functions-app-settings.md
High Priority
View Details →
Detected 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.
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 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.
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 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.
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, 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.
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 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.
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 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.
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 is generally cross-platform, 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., default terminal shell not set to WSL Bash), and there are no explicit Linux/macOS-specific instructions or examples. The document references Windows-specific issues before considering Linux/macOS, and does not provide parity troubleshooting or guidance for non-Windows users.
Recommendations
- Add explicit notes or troubleshooting steps for Linux and macOS users, such as common shell or permissions issues.
- When mentioning Windows-specific issues (e.g., WSL Bash), also mention potential Linux/macOS terminal issues or configurations.
- Ensure that all CLI commands, file paths, and environment setup steps are shown for both Windows and Linux/macOS, or state that the steps are identical if that's the case.
- Where possible, include screenshots or terminal output from both Windows and Linux/macOS environments.
- Review all included files (e.g., functions-install-core-tools-vs-code.md) to ensure they do not contain hidden Windows bias.
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 and configuration steps (such as Visual Studio, PowerShell, and Windows-specific Azure CLI commands) are often mentioned before or more prominently than their Linux equivalents. Some deployment and debugging instructions are Windows-centric, and Linux-specific guidance is sometimes less detailed or appears after Windows instructions. There are also areas where only Windows or PowerShell examples are given, or where Linux alternatives are not shown or are less emphasized.
Recommendations
- Ensure that for every Windows-specific tool or workflow mentioned (e.g., Visual Studio, PowerShell), the equivalent Linux tool or workflow (e.g., VS Code, Bash, Azure CLI) is given equal prominence and detail.
- When presenting CLI commands, provide both Windows (PowerShell/CMD) and Linux (Bash) syntax side by side, or use cross-platform examples where possible.
- Avoid listing Windows-first in tabbed sections or lists; alternate the order or present both together.
- Expand Linux-specific sections to match the detail and clarity of Windows sections, especially for deployment, debugging, and configuration.
- Where PowerShell is referenced, ensure Bash/Azure CLI alternatives are also shown and linked.
- Audit all code snippets and setup instructions to ensure Linux users can follow them without ambiguity or missing steps.
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 several instances of Windows bias. Windows command-line environments (Cmd, PowerShell) are often listed before or alongside Linux/macOS alternatives, and PowerShell-specific instructions are present. There is also a tendency to refer to 'command prompt' (a Windows term) alongside 'terminal', and some examples (e.g., virtual environment activation) provide more detail for Windows than for Linux/macOS. PowerShell is treated as a first-class language, which is inherently Windows-centric, and Windows-specific tools and patterns (e.g., .venv\scripts\activate, .exe suffixes) are mentioned.
Recommendations
- When listing command-line instructions, consistently present Linux/macOS examples first or in parallel with Windows, rather than defaulting to Windows-first.
- Use neutral terminology such as 'terminal' instead of 'command prompt' unless specifically referring to Windows Cmd.
- Ensure that all examples and instructions are provided for both Linux/macOS and Windows, with equal detail and clarity.
- Where PowerShell is used, clarify its cross-platform availability or provide bash/zsh equivalents where possible.
- Avoid using Windows-specific file paths or executable suffixes (like .exe) in generic instructions, or provide platform-specific alternatives.
- In sections where multiple tabs are used for OS-specific commands, ensure Linux/macOS is not treated as an afterthought and receives equal prominence.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-app-settings.md
...ain/articles/azure-functions/functions-app-settings.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation generally aims for cross-platform parity, but there are subtle Windows biases. Windows-specific tools, patterns, and examples are sometimes mentioned first or exclusively. Some settings (e.g., WEBSITE_NODE_DEFAULT_VERSION) are marked as Windows-only, but Linux equivalents are not always referenced. PowerShell-specific settings are detailed, but similar depth is not always given for Linux shells or tools. In a few places, examples use Windows-style paths or environment variable syntax without Linux alternatives.
Recommendations
- For every Windows-specific setting or example (e.g., WEBSITE_NODE_DEFAULT_VERSION), explicitly mention the Linux equivalent or clarify if none exists.
- When showing environment variable paths or syntax (e.g., %HOME%\typescript), provide the Linux alternative (e.g., $HOME/typescript) alongside.
- Where PowerShell is referenced for automation, include Bash/Azure CLI equivalents for Linux users.
- In sections discussing reserved characters in setting names (e.g., double-underscore vs. colon), provide explicit Linux and Windows examples for clarity.
- Review all examples and ensure that both Windows and Linux paths, commands, and behaviors are shown where relevant.
- If a feature or setting is not available on Linux, state this clearly and suggest alternatives if possible.
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 are subtle signs of Windows bias. In command-line examples, both Bash and Windows CMD are provided, but the Windows (CMD) examples are sometimes listed before Bash, and there are no explicit PowerShell examples. There are no Linux-specific tools or troubleshooting steps, and some instructions (e.g., setting JAVA_HOME) do not mention platform-specific nuances. IDE recommendations include cross-platform tools, but Windows-centric tools (like Visual Studio Code) are often mentioned first. There are no Linux- or macOS-specific troubleshooting notes or examples, and some tables list Windows before Linux.
Recommendations
- Ensure Bash (Linux/macOS) examples are always listed before or alongside Windows CMD/PowerShell examples, or clarify that both are equally supported.
- Add explicit Linux/macOS troubleshooting notes for steps like setting JAVA_HOME, file permissions, or path separators.
- Include Linux/macOS-specific caveats or tips where relevant (e.g., differences in environment variable syntax, file system case sensitivity).
- When listing supported platforms or tools, alternate the order or use alphabetical order to avoid implicit prioritization.
- Consider adding PowerShell examples only if they add value, but ensure Bash and CMD are always present and equally detailed.
- Highlight any platform-specific limitations or behaviors, especially in deployment, logging, or configuration steps.
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 exhibits a mild Windows bias in several areas: Windows terminology ("command prompt") is used alongside or before cross-platform terms ("terminal"), and recommendations for development and publishing workflows often mention Windows scenarios first or specifically. The 'Remote build' section explicitly recommends remote build for Windows users and discourages local builds on Windows, and the phrase 'command prompt' is used instead of 'shell' or 'terminal'. There are also references to Windows-specific patterns (e.g., Visual Studio Code, which is cross-platform but often associated with Windows in Microsoft docs). However, Linux is well represented in hosting and deployment sections, and no critical Linux functionality is missing.
Recommendations
- Replace 'command prompt' with 'terminal' or 'shell', or clarify with 'terminal (Linux/macOS) or command prompt (Windows)'.
- When listing development options, avoid putting Windows-specific tools or terminology first unless there is a technical reason.
- In the 'Publishing to Azure' section, clarify that both remote and local builds are supported on all platforms, and provide parity in recommendations for Linux/macOS users.
- Where possible, provide explicit Linux/macOS command-line examples (e.g., using bash) alongside any Windows-specific instructions.
- Review all references to Visual Studio Code to ensure they are presented as cross-platform, and consider mentioning other popular Linux editors or tools if appropriate.
- Audit for any subtle language that assumes a Windows environment (e.g., file paths, environment variable syntax) and provide Linux/macOS equivalents where relevant.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-app-settings.md
...ain/articles/azure-functions/functions-app-settings.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Missing Linux Example
Summary
The documentation generally aims for cross-platform coverage, but there are several instances of Windows bias. Windows-specific tools, patterns, and terminology (such as environment variable delimiters, file paths, and settings) are often mentioned first or exclusively. PowerShell is referenced in detail, while equivalent Linux shell or Bash examples are missing. Some settings are described as 'Windows only' without parallel Linux guidance, and certain examples (like file paths) use Windows conventions. In a few cases, Linux-specific instructions are present but less prominent or detailed.
Recommendations
- For every Windows-specific example or mention (such as environment variable delimiters, file paths, or settings), provide the Linux equivalent side-by-side or in parallel.
- When referencing PowerShell or Windows tools, also mention and give examples for Bash or Linux CLI usage.
- Avoid using Windows paths (e.g., %HOME%\typescript) without also showing the Linux alternative (e.g., $HOME/typescript).
- Where settings or behaviors differ between Windows and Linux (such as environment variable delimiters or time zone values), clearly document both, not just the Windows case.
- If a setting is 'Windows only', explicitly state what the Linux equivalent is or clarify if there is none.
- Ensure that Linux-specific features (such as linuxFxVersion, Oryx build, etc.) are given equal prominence and detail as Windows-specific features.
- Add Bash/Azure CLI examples wherever Azure PowerShell is referenced for managing settings.
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 Windows, macOS, and Linux. However, there are subtle signs of Windows bias: troubleshooting steps specifically mention Windows (e.g., WSL Bash), and there are no explicit Linux/macOS-specific instructions, caveats, or screenshots. Windows-specific issues are called out, but Linux/macOS users are not directly addressed, and there are no examples or troubleshooting steps tailored for them. All instructions assume a generic environment, but Windows is the only OS called out by name.
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 guidance is given (e.g., about WSL Bash), provide equivalent Linux/macOS advice or clarify if those issues do not apply.
- Include at least one example or screenshot showing the workflow on Linux or macOS to demonstrate parity and inclusivity.
- In requirements and setup sections, explicitly mention that the instructions apply to all supported platforms, and link to platform-specific installation guides for dependencies like Azure Functions Core Tools.
- Review all included files (e.g., functions-install-core-tools-vs-code.md) to ensure they do not contain hidden Windows bias.
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 mild Windows bias. Windows-specific tools and configuration steps are often mentioned before their Linux equivalents, and some CLI examples are Windows-centric. While Linux is supported and mentioned, Linux-specific instructions are sometimes less detailed or appear after Windows instructions. In some cases, Linux examples or notes are missing or less prominent, especially for command-line and deployment scenarios.
Recommendations
- Ensure all CLI and deployment examples are provided for both Windows and Linux, with equal prominence and detail.
- When listing tools or configuration steps (e.g., Azure CLI, PowerShell), present Linux and Windows options side by side or in parallel tabs, rather than listing Windows first.
- Include explicit Linux shell examples (bash/zsh) for all command-line operations, not just Azure CLI commands.
- For sections referencing Visual Studio or Windows-specific tooling, add equivalent instructions for Linux-friendly tools such as VS Code, .NET CLI, and Azure CLI.
- Review all references to configuration settings (e.g., environment variables, file paths) to ensure Linux-specific guidance is included and not just assumed.
- Where possible, avoid language that implies Windows is the default or primary platform; instead, use neutral or cross-platform phrasing.