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 351-375 of 1023 flagged pages
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 Windows CMD is often listed second, which is good. However, there is no explicit mention of PowerShell, which is positive. Some terminology (e.g., 'command prompt') is Windows-centric, and there are no explicit Linux-specific troubleshooting steps or environment notes. The documentation does not provide Linux-specific examples or highlight differences in behavior between Windows and Linux environments, especially in areas like file paths, environment variables, or deployment nuances. The 'Java versions' table does list both Windows and Linux, but Windows is listed first. There is also a lack of explicit Linux tooling or troubleshooting guidance.
Recommendations
- When referencing terminals, use neutral terms like 'terminal' or 'shell' instead of 'command prompt', or explicitly mention both (e.g., 'terminal or command prompt').
- Wherever Bash and CMD examples are given, consider listing Bash first to reflect the prevalence of Linux/macOS among Java developers.
- Add Linux-specific notes or troubleshooting steps where relevant, especially for environment variables, file paths, and deployment behaviors.
- If there are any differences in local development, deployment, or logging between Windows and Linux, explicitly document them.
- Consider including a section or callout for Linux users, highlighting any OS-specific caveats or best practices.
- Ensure that all screenshots, if any, are not Windows-only, or provide Linux equivalents.
Create Pull Request
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, but there are subtle signs of Windows bias. In several places, Windows terminology ("command prompt") is used alongside "terminal" without explicit mention of Linux or macOS. The recommended development tools (Visual Studio Code, Azure Functions Core Tools) are cross-platform, but the documentation sometimes refers to 'command prompt' (a Windows term) and suggests remote build is recommended 'when developing Python apps on Windows', without giving equal emphasis to Linux/macOS workflows. There are also references to Windows-specific behaviors in the Python standard library section, and the folder structure examples use Windows-style command prompt code blocks (```cmd), which may be less familiar to Linux users.
Recommendations
- Explicitly mention Linux and macOS alongside Windows when referring to terminals or development environments (e.g., 'terminal (Linux/macOS) or command prompt (Windows)').
- When recommending remote build for Windows users, also provide guidance for Linux/macOS users, including any platform-specific considerations.
- Use neutral or platform-appropriate code block labels (e.g., 'shell' or 'bash' instead of 'cmd') for folder structure and command-line examples.
- Where Windows-specific behaviors are described (such as in the Python standard library section), provide equivalent notes for Linux/macOS users.
- Ensure that all instructions, especially for publishing and package management, are equally detailed for Linux/macOS as for Windows.
- Consider adding explicit Linux/macOS command-line examples (e.g., using bash/zsh) where only generic or Windows-oriented instructions are given.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/storage-considerations.md
...ain/articles/azure-functions/storage-considerations.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Windows Tools
Summary
The documentation demonstrates a moderate Windows bias. Windows-specific plans and behaviors are often mentioned before Linux equivalents, and PowerShell examples are provided alongside (or before) CLI examples. Some features and settings are described as 'Windows only' without always providing equivalent Linux guidance. In several sections, Linux-specific instructions or parity are either missing or only briefly mentioned, and Windows tools (like Visual Studio and PowerShell) are referenced more prominently than Linux alternatives.
Recommendations
- Ensure that all examples and configuration instructions are provided for both Windows and Linux environments, with equal prominence.
- When referencing tools like Visual Studio or PowerShell, also mention and provide examples for common Linux tools (e.g., VS Code, Bash, Azure CLI).
- Avoid labeling features as 'Windows only' without clearly describing the Linux equivalent or explicitly stating the lack of parity.
- Present cross-platform examples (CLI, Bash, PowerShell) side-by-side or in tabs, and avoid defaulting to Windows-first ordering.
- Expand on Linux-specific deployment and configuration scenarios, especially where behaviors differ from Windows.
- Audit for any missing Linux examples, especially in sections discussing storage configuration, scaling, and mounting file shares.
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
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation displays some Windows bias, particularly in the Java section, where command examples are provided for Bash, PowerShell, and Cmd, with PowerShell and Cmd (Windows shells) given equal prominence to Bash. The use of 'command prompt' and 'PowerShell' is frequent, and Windows-specific tools and patterns (such as .cmd and PowerShell tabs) are included. However, the main workflow is generally cross-platform, and Linux tools like jq are mentioned in prerequisites. Still, Windows shells and terminology are often foregrounded or given equal weight, rather than Linux-first or Linux-equal treatment.
Recommendations
- In command examples, list Bash (Linux/macOS) first, followed by PowerShell and Cmd, to reflect the prevalence of Linux in cloud development.
- Where possible, use neutral terms like 'terminal' instead of 'command prompt' or 'PowerShell', unless the example is truly Windows-specific.
- For Java, consider providing a single cross-platform Maven command (with notes for quoting differences if needed), or clearly indicate which shell is most common for cloud developers.
- Ensure that all shell-specific instructions are balanced and that Linux/macOS users are not required to adapt Windows-centric instructions.
- Highlight Linux/macOS compatibility in prerequisites and throughout the workflow, especially for tools like Azure CLI and Azure Functions Core Tools.
- Where Windows-specific tools or patterns are mentioned (e.g., .cmd, PowerShell), provide Linux/macOS equivalents or clarify when they are not needed.
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
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation demonstrates some Windows bias, particularly in the Java section where PowerShell and Cmd examples are given equal prominence to Bash, and Windows-specific patterns (e.g., referencing Cmd, PowerShell, and Windows-style paths) are present. The general instructions refer to 'command prompt' alongside 'terminal', and some file path examples use backslashes. However, Linux tools like jq and Bash are mentioned, and most CLI examples are cross-platform. There are no outright missing Linux examples, but Windows tools and patterns are sometimes mentioned first or exclusively.
Recommendations
- Ensure that Bash/Linux examples are always presented first or at least equally alongside Windows (PowerShell/Cmd) examples.
- Avoid using Windows-style paths (backslashes) in generic instructions; use forward slashes or note both styles.
- Where possible, use 'terminal' as the default term, and only mention 'command prompt' or 'PowerShell' when specifically relevant.
- In tables or multi-tabbed code blocks, default to Bash or provide clear parity between Bash and Windows shells.
- Review all file references and code snippets to ensure they are cross-platform, and explicitly call out any OS-specific differences.
- Where Windows tools or patterns are mentioned, ensure Linux equivalents are also referenced and given equal prominence.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-bindings-signalr-service.md
.../azure-functions/functions-bindings-signalr-service.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Missing Linux Example
Summary
The documentation page exhibits a subtle Windows bias. While it covers multiple programming languages, the installation instructions and environment variable conventions are presented in a way that implicitly assumes Windows as the default environment. For example, the use of double underscores (`__`) in environment variable names aligns with Windows conventions, while the Linux/UNIX convention of using colons (`:`) is only mentioned in a note. There are no explicit Linux shell (bash) or cross-platform CLI examples, and PowerShell is listed as a primary language pivot, but Linux-specific instructions or examples are missing.
Recommendations
- Provide explicit Linux/bash examples for environment variable configuration, such as using colons (`:`) in shell exports.
- Include cross-platform CLI instructions (e.g., Azure CLI commands) for installing extensions and setting environment variables.
- Add a section or note at the beginning clarifying environment variable naming differences between Windows and Linux, with examples for both.
- Ensure that PowerShell is not presented as the default or only scripting example; include bash/zsh equivalents where relevant.
- List Linux and Windows instructions side-by-side when discussing local development, configuration, or tooling.
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, settings, and commands are often mentioned before or more prominently than their Linux equivalents. Some CLI examples and configuration instructions are Windows-centric or lack explicit Linux parity. PowerShell and Visual Studio are highlighted as primary tools, with less emphasis on Linux-native workflows or editors. In some areas, Linux instructions are present but less detailed or appear after Windows instructions.
Recommendations
- Ensure all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
- Where PowerShell or Windows-specific tools are mentioned, provide equivalent Bash or Linux-native commands and workflows.
- In tables and lists, avoid listing Windows tools or editors first by default; alternate or group by platform.
- Expand Linux-specific guidance, especially for deployment, debugging, and environment configuration.
- Highlight cross-platform tools (such as VS Code, Azure CLI, and .NET CLI) before platform-specific ones.
- Where Visual Studio is mentioned, ensure parity with VS Code and CLI-based workflows for Linux users.
- Review all code and command snippets to ensure they are either cross-platform or have clear Linux alternatives.
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
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation shows some Windows bias, particularly in the Java section where command examples are presented for Bash, PowerShell, and Cmd, with PowerShell and Cmd (Windows shells) given equal prominence to Bash (Linux/macOS). The Java Maven archetype instructions list Bash first, but Windows shells are not clearly deprioritized. There are also references to Windows-style paths (e.g., '\src\main\java\com\fabrikam'), and the use of 'command prompt' terminology, which is more common in Windows contexts. While most CLI examples are cross-platform, the documentation does not always clarify Linux-specific nuances, and some steps (like stopping the function host) use Windows-centric key combinations (Ctrl+C and 'choose y'), which may differ on Linux. There are no explicit Linux-only examples or troubleshooting tips, and some tools (like jq) are mentioned as available in Azure Cloud Shell but not directly addressed for local Linux environments.
Recommendations
- For every example that lists PowerShell or Cmd, ensure Bash or sh is listed first and clearly marked as the default for Linux/macOS users.
- When referencing file paths, use POSIX-style paths (forward slashes) or provide both Windows and Linux/macOS path formats.
- Avoid using 'command prompt' as a generic term; instead, use 'terminal' or specify 'Windows Command Prompt' when appropriate.
- Provide explicit Linux/macOS troubleshooting notes where behaviors may differ (e.g., process termination, permissions, environment variables).
- Clarify installation and usage of tools like jq for Linux users, not just in the context of Azure Cloud Shell.
- Include a section or callouts for common Linux/macOS issues or tips, such as case sensitivity, shell differences, or required dependencies.
- Ensure that all scripts and code snippets are tested and work as-is on both Windows and Linux/macOS platforms.
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 page exhibits a mild Windows bias. While it covers both Windows and Linux scenarios, Windows-specific tools, settings, and examples are often mentioned first or in more detail. Some deployment and configuration instructions are Windows-centric, and Linux equivalents are sometimes less prominent or missing. PowerShell is referenced as an option, but Linux shell examples are less emphasized. In performance and deployment sections, Windows commands and settings are presented before Linux, and ReadyToRun instructions focus on Windows before Linux. Some CLI commands and explanations are tailored to Windows users, with Linux guidance added as an afterthought or in a separate tab.
Recommendations
- Ensure that all command-line examples (e.g., Azure CLI, dotnet publish) are shown for both Windows and Linux, with equal prominence.
- When listing tools or methods (e.g., Visual Studio, Visual Studio Code, Azure CLI, PowerShell), avoid listing Windows-specific tools first by default; alternate order or group by platform.
- Provide Linux shell (bash) equivalents for any PowerShell or Windows Command Prompt examples.
- In sections like ReadyToRun and deployment, present Linux and Windows instructions side-by-side or in parallel tabs, not with Windows first.
- Where platform-specific settings are required (e.g., netFrameworkVersion vs. linuxFxVersion), make sure both are described with equal detail and visibility.
- Explicitly mention any differences or limitations for Linux users up front, not only in footnotes or after Windows instructions.
- Review all code snippets and ensure none assume a Windows file system or path structure unless platform-specific.
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
Cmd Examples
Missing Linux Tool Examples
Summary
The documentation provides both Bash and Windows CMD examples for command-line operations, but Windows CMD examples are consistently presented alongside Bash, rather than prioritizing Linux-specific shell environments (e.g., zsh, fish). There is no evidence of exclusive use of Windows tools or PowerShell, nor are Windows-specific patterns or tools mentioned before Linux equivalents. However, the documentation does not include Linux-specific troubleshooting, nor does it mention Linux-only tools or workflows (such as systemd, journalctl, or Linux file paths). The examples and instructions are generally cross-platform, but the presence of CMD examples and lack of Linux-specific tool references indicate a mild Windows-first bias.
Recommendations
- Add explicit Linux troubleshooting steps and references to common Linux tools (e.g., journalctl for logs, systemd for service management).
- Include Linux-specific examples for environment variable configuration and file system paths.
- Consider prioritizing Bash or POSIX shell examples, and move CMD examples to secondary tabs or footnotes.
- Mention differences in local development environments (e.g., how to install Maven/Java on Linux vs. Windows).
- Provide guidance for Linux package management (apt, yum) for installing prerequisites.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-bindings-register.md
...rticles/azure-functions/functions-bindings-register.md
High Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation provides examples and instructions that reference PowerShell and Windows-centric tools (such as Visual Studio and Visual Studio Code) and does not offer equivalent Linux-specific guidance or examples. The use of PowerShell as a pivot language and the absence of Linux command-line examples or references to Linux-native editors (such as VS Code on Linux or CLI workflows) indicate a bias toward Windows environments. There are no explicit instructions for Linux users on installing extensions or managing project files.
Recommendations
- Add explicit Linux/macOS examples for installing and managing extensions, including CLI commands and file operations.
- Reference cross-platform editors (such as VS Code on Linux/macOS) and provide parity with Visual Studio instructions.
- Include bash/zsh shell examples alongside PowerShell where CLI commands are shown.
- Clarify that Azure Functions Core Tools and related workflows are cross-platform, and provide troubleshooting or setup notes for Linux users.
- Where project file editing is required, show how to do this using Linux-native tools (nano, vim, etc.) or VS Code on 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 page is generally cross-platform and Linux-focused for hosting, but there is evidence of Windows bias in development and publishing workflows. Windows tools and patterns (such as Visual Studio Code and command prompt) are mentioned first or exclusively in several places, and remote build is recommended specifically for Windows users. There is also a tendency to refer to 'command prompt' generically, which is a Windows-specific term, and PowerShell/Windows-centric workflows are implied in publishing and development instructions. Linux equivalents (such as bash, terminal, or shell) are not always mentioned, and guidance for Linux users is less explicit.
Recommendations
- Use neutral terminology such as 'terminal' or 'shell' instead of 'command prompt', and clarify when instructions apply to both Windows and Linux.
- Provide explicit Linux/bash examples alongside Windows/command prompt examples, especially for publishing and development workflows.
- When recommending remote build for Windows users, also provide guidance for Linux/Mac users and clarify any differences.
- Mention Linux tools and patterns (e.g., bash, zsh, Linux package managers) where appropriate, and ensure parity in instructions.
- Ensure that all references to development environments (e.g., Visual Studio Code, Azure CLI) include cross-platform installation and usage notes.
- Review all sections for implicit Windows assumptions and add Linux-specific notes or examples where missing.
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 mild Windows bias. Windows-specific tools and configuration steps (such as Visual Studio, PowerShell, and Windows-specific CLI commands) are often mentioned first or exclusively, with Linux equivalents sometimes only referenced later or in passing. Some deployment and configuration examples (e.g., ReadyToRun, runtime identifiers, and debugging) provide more detail for Windows than Linux, and PowerShell is listed as a primary automation option without equal emphasis on Bash or Linux scripting. In a few cases, Linux-specific instructions are present but less prominent or lack parity in detail.
Recommendations
- Ensure that all command-line examples (e.g., Azure CLI, deployment, debugging) include both Windows and Linux syntax and context, ideally side-by-side or in clearly marked tabs.
- When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, PowerShell), always include Linux-native or cross-platform alternatives (e.g., Bash, zsh, JetBrains Rider) with equal prominence.
- For sections like ReadyToRun and runtime identifiers, provide Linux examples and explanations with the same level of detail as Windows.
- Avoid listing Windows tools or workflows first by default; alternate the order or use neutral/cross-platform ordering.
- Where PowerShell is mentioned, also mention Bash or other common Linux shells for scripting and automation.
- In debugging and deployment sections, ensure Linux workflows are fully documented and not just referenced as an afterthought.
- Audit all code snippets and configuration examples to ensure Linux users are not required to infer steps from Windows-centric instructions.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference.md
...b/main/articles/azure-functions/functions-reference.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation demonstrates a mild Windows bias by listing Windows-centric tools (Visual Studio, PowerShell) before cross-platform or Linux-native equivalents, especially in C# and deployment sections. Visual Studio (Windows-only) is often mentioned first, and PowerShell is given its own language pivot, which can imply a Windows-first development workflow. However, Linux-compatible tools (Azure CLI, Visual Studio Code, Maven, Gradle) are also documented and available, and there are no outright missing Linux examples.
Recommendations
- When listing tools or workflows, avoid always listing Visual Studio (Windows-only) first; instead, alternate or group cross-platform tools (e.g., Visual Studio Code, Azure CLI) before or alongside Windows-specific tools.
- Explicitly mention that Azure CLI and Visual Studio Code are cross-platform and supported on Linux and macOS, to reinforce parity.
- Where PowerShell is referenced, consider also mentioning Bash or shell equivalents for Linux users, or clarify when PowerShell Core (cross-platform) is supported.
- In deployment and quickstart sections, provide explicit Linux/macOS command-line examples or links, not just 'command prompt', which can be ambiguous.
- Review language in all sections to ensure it does not implicitly assume a Windows environment (e.g., avoid 'command prompt' in favor of 'terminal' or specify OS where relevant).
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 biases. Windows command-line examples (Cmd) are consistently presented alongside Bash, but Cmd is always listed second, which is a minor 'windows_first' bias. There is a heavier focus on Windows-specific terminology (e.g., 'command prompt') and some references to Windows in tables and explanations. However, Linux is also covered in most places, and Bash examples are provided. There are no explicit PowerShell examples, but the presence of Cmd tabs and references to 'command prompt' may be interpreted as a Windows-centric approach. No Linux-specific tools or troubleshooting are highlighted, and there are no explicit Linux-only examples or guidance, which could be seen as a 'missing_linux_example' bias.
Recommendations
- Ensure that all command-line examples are presented with equal prominence for both Bash (Linux/macOS) and Cmd (Windows), and consider including PowerShell where appropriate.
- Avoid using Windows-centric terminology like 'command prompt' without also mentioning 'terminal' or 'shell' for Linux/macOS users.
- Where OS-specific instructions are necessary, provide clear, parallel guidance for both Windows and Linux, including troubleshooting steps.
- Highlight any Linux/macOS-specific considerations, such as file permissions, case sensitivity, or environment variable differences.
- Consider including a section or appendix specifically addressing Linux/macOS development environments, common issues, and best practices.
- When referencing supported Java versions or runtime behaviors, ensure that Linux and Windows are given equal detail and placement in tables and explanations.
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 configuration steps are often mentioned before or more prominently than their Linux equivalents. Examples of Azure CLI and PowerShell commands are provided, but PowerShell and Windows-specific configuration (such as netFrameworkVersion and win-x64) are frequently foregrounded. Some sections, such as ReadyToRun and deployment, provide more detailed or explicit instructions for Windows than for Linux. Linux instructions are present but sometimes less detailed or appear after Windows instructions. There are few, if any, explicit Linux shell (bash) examples, and PowerShell is referenced as a primary automation tool.
Recommendations
- Ensure that for every Windows-specific example or tool (e.g., PowerShell, win-x64), an equivalent Linux example (e.g., bash, linux-x64) is provided with equal prominence and detail.
- When listing deployment or configuration options, alternate the order or present both Windows and Linux options side-by-side, rather than defaulting to Windows first.
- Add explicit bash shell examples for common CLI operations, not just Azure CLI syntax blocks, to clarify usage on Linux/macOS.
- Where PowerShell is mentioned as an automation tool, also mention bash or other cross-platform scripting options.
- In tables and instructions, avoid assuming Visual Studio (Windows) as the default IDE; give equal weight to VS Code and CLI workflows.
- Review all sections for subtle language that prioritizes Windows (e.g., 'On Windows, ...'), and balance with Linux/macOS notes.
- Where configuration settings differ (e.g., netFrameworkVersion vs. linuxFxVersion), provide clear, parallel explanations and examples for both platforms.
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
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation demonstrates some Windows bias, particularly in the Java section, where command examples are provided for Bash, PowerShell, and Cmd, with PowerShell and Cmd (Windows shells) given equal or greater prominence than Bash (Linux/macOS). The use of terms like 'command prompt' and explicit mention of Windows-specific shells and tools (PowerShell, Cmd) without equivalent emphasis on Linux shells or tools further reinforces this bias. However, most other sections use cross-platform tools (Azure CLI, func) and generic 'terminal or command prompt' language, and the inclusion of Bash examples does provide some Linux support.
Recommendations
- For all code examples, consistently provide Bash (Linux/macOS) as the first/default example, followed by PowerShell and Cmd as alternatives.
- When referencing the terminal, use 'terminal' or 'shell' instead of 'command prompt' to be more platform-neutral.
- Where PowerShell or Cmd examples are given, ensure that equivalent Bash examples are always present and shown first.
- Explicitly mention Linux/macOS compatibility and provide troubleshooting notes for those platforms where relevant.
- If referencing Windows-specific environment variables or paths (e.g., JAVA_HOME), also show Linux/macOS equivalents.
- Consider adding a short section or note about cross-platform compatibility and any OS-specific considerations.
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 maintains good cross-platform parity, providing both Bash and Windows CMD examples for command-line operations. However, there is a subtle Windows bias: Windows CMD examples are always present and often appear alongside or before Bash, and there is no mention of Linux-specific shells or tools (e.g., zsh, fish). Visual Studio Code, IntelliJ, and Eclipse are mentioned as IDEs, but Windows-centric tools or patterns (such as the use of CMD and references to 'command prompt') are consistently included. There are no PowerShell-specific examples, but the presence of Windows CMD tabs and terminology like 'command prompt' reflects a mild Windows-first approach. Linux is supported and mentioned (e.g., in Java version tables), but not prioritized.
Recommendations
- Ensure that Bash examples are always listed before CMD/Windows examples to avoid the perception of Windows-first bias.
- Explicitly mention that Bash examples work on Linux and macOS, and clarify that CMD examples are for Windows users.
- Include references to Linux-specific shells (e.g., zsh) or terminal environments where relevant.
- Where 'command prompt' is mentioned, add 'terminal' or 'shell' to be inclusive of Linux/macOS users.
- Consider providing a short section or note on any Linux/macOS-specific considerations, even if minimal, to reinforce parity.
- If possible, add troubleshooting or environment setup notes for Linux/macOS users (e.g., JAVA_HOME setup, Maven installation).
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 mild Windows bias. Windows-specific tools and configuration steps are often mentioned first or exclusively, such as in ReadyToRun instructions, .NET preview version setup, and process architecture checks. PowerShell and Visual Studio are highlighted as primary tools, with Linux equivalents either mentioned later, less prominently, or not at all. Some CLI examples are Windows-centric, and Linux-specific nuances are sometimes relegated to notes or tabs. There are also areas where Linux-specific deployment or debugging workflows are not fully detailed.
Recommendations
- Ensure all tool and command-line examples are provided for both Windows and Linux, ideally side-by-side or with equal prominence.
- When listing options for creating or deploying resources, alternate the order (e.g., sometimes list Linux/CLI first, not always Windows/Visual Studio).
- Include Linux-specific instructions for debugging, deployment, and configuration wherever Windows instructions are given.
- Provide explicit bash and PowerShell examples for CLI commands, especially for scripting or automation.
- Clarify any differences in behavior or requirements between Windows and Linux environments, especially for advanced features like ReadyToRun, cold start optimizations, and .NET preview support.
- Where Visual Studio is mentioned, also mention cross-platform alternatives (e.g., Visual Studio Code, JetBrains Rider) and ensure parity in guidance.
- Review all references to Azure PowerShell and ensure Azure CLI (which is cross-platform) is given equal or greater prominence.
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 demonstrates a mild Windows bias in several areas: Windows terminology ("command prompt") is used alongside or before cross-platform terms ("terminal"), and Windows-specific recommendations are made (e.g., suggesting remote build when developing on Windows, discouraging local builds on Windows). The documentation refers to the 'command prompt' and 'Visual Studio Code' as primary development environments, which are more common on Windows. There is also a subtle bias in the order of mentioning Windows-specific tools or patterns before their Linux equivalents, and in some cases, the documentation assumes a Windows context before clarifying Linux is required for hosting. However, Linux support is well-documented, and many examples are cross-platform.
Recommendations
- Use fully cross-platform terminology throughout (e.g., always say 'terminal' instead of 'command prompt').
- When listing development environments or tools, avoid putting Windows-specific options first or exclusively; instead, clarify cross-platform support and order neutrally.
- Where recommendations are made (e.g., for remote vs. local build), explain the rationale for all platforms, not just Windows.
- Explicitly provide Linux/macOS shell examples (e.g., bash/zsh) alongside any Windows-specific instructions, if any.
- Clarify that Visual Studio Code is cross-platform, and suggest other editors (e.g., Vim, Emacs, PyCharm) where appropriate.
- Avoid language like 'Use remote build when you're developing Python apps on Windows' without also explaining the implications for Linux/macOS users.
- Ensure that all CLI commands are shown in a cross-platform way (e.g., use $ for shell prompts, not C:\> or cmd).
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
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation demonstrates some Windows bias, particularly in the Java section, where PowerShell and Cmd examples are given alongside Bash, and Windows path conventions (e.g., backslashes in file paths) are referenced. The order of examples and mention of Windows-specific tools (PowerShell, Cmd) before or alongside Bash may suggest a Windows-first approach. However, the core CLI commands are generally cross-platform, and Linux tools like jq are mentioned. There are no outright missing Linux examples, but parity and prominence could be improved.
Recommendations
- Present Bash (Linux/macOS) examples before PowerShell and Cmd in all code tabs to reinforce cross-platform parity.
- Use platform-agnostic path conventions or provide both Windows (backslash) and Linux/macOS (slash) examples when referencing file paths.
- Where PowerShell or Cmd is shown, ensure equivalent Bash or shell commands are always present and clearly labeled.
- Avoid language that defaults to 'command prompt' or 'PowerShell'—use 'terminal' or 'shell' as the primary term.
- Highlight Linux/macOS compatibility and usage tips, especially for environment variables, file permissions, and shell scripting.
- Consider adding explicit notes or callouts for any platform-specific behavior or requirements.
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 configuration steps are often mentioned first or exclusively, such as in deployment, debugging, and performance optimization sections. PowerShell and Visual Studio are frequently referenced, sometimes without equivalent Linux or cross-platform alternatives. Some CLI examples are provided, but Windows-centric instructions (e.g., netFrameworkVersion, win-x64, Visual Studio) are more prominent and detailed. Linux equivalents are present but often secondary or less emphasized.
Recommendations
- Ensure all tool and deployment instructions are presented for both Windows and Linux, ideally side-by-side or with equal prominence.
- Provide Linux-specific examples (e.g., bash scripts, Linux file paths, VS Code workflows) wherever Windows/PowerShell or Visual Studio examples are given.
- When referencing configuration settings (like netFrameworkVersion for Windows), always include the Linux equivalent (like linuxFxVersion) in the same context.
- Avoid listing Windows tools or workflows (e.g., Visual Studio, PowerShell) before cross-platform or Linux-native tools (e.g., VS Code, Azure CLI, bash).
- Expand on Linux container deployment and debugging scenarios to match the detail given for Windows/Visual Studio.
- Where possible, use cross-platform language and tools (e.g., Azure CLI, VS Code) as the default or first example, with OS-specific notes as needed.
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, primarily by presenting Windows command-line environments (Cmd, PowerShell) before or alongside Linux/macOS equivalents, and by providing detailed PowerShell-specific instructions and code pivots. While Linux/macOS instructions are present, Windows environments are often given equal or greater prominence, and Windows-specific tools and patterns (e.g., PowerShell, Cmd) are explicitly called out. There are no major missing Linux examples, but the ordering and emphasis suggest a Windows-first perspective.
Recommendations
- When presenting command-line instructions, list Linux/macOS (bash) examples first, followed by Windows (Cmd/PowerShell) to reflect the cross-platform nature of modern development.
- Avoid giving extra prominence to PowerShell or Cmd unless absolutely necessary; group all OS-specific instructions together and clarify their applicability.
- Where possible, use OS-agnostic commands or note any differences succinctly, rather than duplicating large blocks for each platform.
- Ensure that Linux/macOS users are not required to mentally filter out Windows-specific terminology or tools.
- Consider adding explicit notes or tables summarizing command differences across platforms for clarity.
- Review the use of terms like 'command prompt' and clarify that 'terminal' applies to all platforms, not just Windows.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/create-first-function-vs-code-other.md
...azure-functions/create-first-function-vs-code-other.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation generally maintains cross-platform parity, but there are subtle Windows biases. Windows-specific instructions (such as .exe suffixes and use of 'set' in cmd) are often mentioned first or in more detail. The documentation refers to Windows conventions (e.g., 'handler.exe') before Linux ones, and Windows-specific build steps are called out with more explicit instructions. There is also a slight assumption of familiarity with Windows tools and patterns, such as referencing 'cmd' and using Windows-style environment variable setting. However, Linux and macOS instructions are present and correct, and the documentation does not omit Linux examples.
Recommendations
- When referring to executable names, mention the Linux version first or present both equally (e.g., 'handler (Linux/macOS) or handler.exe (Windows)').
- Group platform-specific instructions together and avoid listing Windows first by default.
- For environment variable setting, provide cross-platform commands side by side (e.g., 'export' for Linux/macOS and 'set' for Windows), or use table/tabbed formatting.
- Avoid assuming Windows conventions (such as .exe suffix) as the default; clarify when each is needed.
- Where possible, use platform-agnostic language and tools, or clearly indicate when a step is platform-specific.
- Ensure that all screenshots and terminal outputs include Linux/macOS examples, not just Windows.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-deployment-technologies.md
...s/azure-functions/functions-deployment-technologies.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates a Windows bias in several ways: Windows-based deployment methods and tools (such as Visual Studio and Visual Studio Code) are consistently mentioned first, and in some cases exclusively, before Linux equivalents. There is a strong emphasis on Windows-specific infrastructure (such as Kudu/SCM site) and deployment methods (like Source Control and Local Git) that are marked as 'Windows-only' in the availability table, with less detail or guidance for Linux users. Examples and instructions often default to Windows-centric tools and patterns, and Linux-specific considerations are sometimes relegated to notes or secondary sections. There are few, if any, Linux-specific command-line examples or explicit parity in walkthroughs.
Recommendations
- Ensure that for every deployment method, both Windows and Linux instructions/examples are provided side-by-side or with equal prominence.
- Avoid listing Windows tools (e.g., Visual Studio, Kudu) before cross-platform or Linux-native tools (e.g., Azure CLI, Core Tools, VS Code on Linux). Instead, present cross-platform tools first or in parallel.
- Add explicit Linux command-line examples (e.g., bash scripts, Linux CLI usage) where only Windows or PowerShell examples are given.
- Clarify in each deployment method section which OSes are supported, and provide alternative guidance for Linux where a method is Windows-only.
- Highlight any differences in deployment experience or requirements for Linux users, and provide troubleshooting or best practices specific to Linux environments.
- Where possible, avoid using language that implies Windows is the default or preferred environment.