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 426-450 of 1023 flagged pages
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 page demonstrates a mild Windows bias. Visual Studio (a Windows-centric IDE) is consistently listed first in C# sections, and PowerShell is highlighted as an HTTP test tool before cross-platform alternatives like curl. Microsoft Edge's Network Console is also mentioned, which is Windows-specific. While the page does mention cross-platform tools and support for Linux/macOS, Windows tools and patterns are often prioritized or listed before their Linux equivalents.
Recommendations
- List cross-platform tools (such as Visual Studio Code and command-line/terminal) before Windows-only tools (like Visual Studio) in environment tables and tool recommendations.
- When mentioning HTTP test tools, list curl (cross-platform) before PowerShell and Microsoft Edge, or group them by platform.
- Explicitly note platform compatibility for each tool, especially when referencing Windows-only options.
- Provide Linux/macOS-specific examples or notes where appropriate (e.g., for changing ports, running emulators, or using command-line tools).
- Balance PowerShell examples with bash/zsh or other Linux shell equivalents where command-line usage is discussed.
Create Pull Request
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 Maven and Azure CLI commands, but consistently lists Windows CMD after Bash, which is a positive sign. However, there are some subtle Windows biases: (1) The term 'command prompt' is used alongside 'terminal', which is a Windows-centric term; (2) There are no explicit Linux-specific instructions or troubleshooting notes, and no mention of Linux tools or shell environments beyond Bash; (3) In the Java version support table, Windows is listed before Linux, and for Functions 2.x, Linux is marked as 'n/a' without further explanation or guidance. There are no PowerShell-specific examples, but the documentation does not provide parity for Linux-specific scenarios or tools, and does not address potential differences in environment setup or troubleshooting for Linux users.
Recommendations
- Use neutral terminology such as 'terminal' instead of 'command prompt' unless specifically referring to Windows.
- Provide explicit Linux troubleshooting notes or callouts where behavior may differ (e.g., file permissions, environment variable setup).
- Add examples or notes for common Linux shells (e.g., zsh, fish) if relevant, or clarify that Bash examples are applicable to most Linux environments.
- In tables and lists, alternate the order of Windows and Linux, or use alphabetical order to avoid implicit prioritization.
- For any features not supported on Linux (e.g., Functions 2.x), provide a brief explanation or workaround if possible.
- Where environment variables or file paths are referenced, show both Windows and Linux formats, or clarify 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 generally maintains good cross-platform parity, but there are subtle signs of Windows bias. References to 'command prompt' and development 'on Windows' appear before or instead of explicit mentions of Linux or macOS. The guidance for remote build specifically recommends it for Windows users, and the use of 'command prompt' as a generic term may confuse Linux/macOS users. There are no explicit PowerShell-only examples, but the documentation does not always clarify CLI usage across platforms. Visual Studio Code is the only editor mentioned, which is cross-platform, but no Linux-specific editors or shell environments are referenced. There are no missing Linux examples, and the documentation does emphasize that Azure Functions for Python is Linux-hosted.
Recommendations
- Replace or supplement 'command prompt' with 'terminal' or 'shell', and clarify that all CLI commands work on Linux/macOS as well as Windows.
- When referencing development environments, explicitly mention Linux and macOS alongside Windows, especially in sections about local development and publishing.
- Avoid language such as 'use remote build when you're developing Python apps on Windows' without providing equivalent guidance for Linux/macOS users.
- Add examples or notes for Linux/macOS users where file paths, environment variables, or shell commands may differ.
- Consider mentioning other popular cross-platform editors (e.g., PyCharm, Vim) or at least clarify that Visual Studio Code is available on all platforms.
- Review all CLI command examples to ensure they are not Windows-specific (e.g., avoid backslashes in paths, use forward slashes or note both).
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 attempts to be cross-platform, but there are several areas where Windows-specific tools, shells, or patterns are given prominence or appear before Linux/macOS equivalents. PowerShell and Windows Command Prompt (Cmd) are often featured, sometimes before bash or Linux-native instructions. In addition, the use of 'command prompt' as a generic term can be confusing for Linux users, and some sections (such as virtual environment activation) provide more detailed or multiple Windows options compared to Linux/macOS.
Recommendations
- Ensure that Linux/macOS instructions are always presented alongside Windows instructions, and avoid listing Windows options first by default.
- Use neutral terminology such as 'terminal' instead of 'command prompt' when referring to the shell, or clarify when a step is OS-specific.
- Where multiple shell options are shown (e.g., bash, Cmd, PowerShell), always include Linux/macOS bash first, or present all options in parallel tabs.
- For PowerShell-specific examples, provide equivalent bash or shell commands for Linux/macOS users where possible.
- Review all code snippets and instructions to ensure parity in detail and clarity for both Linux/macOS and Windows users.
- Consider adding a short section at the start clarifying that all steps are supported on Linux, macOS, and Windows, and that examples are provided for each.
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
Missing Linux Example
Summary
The documentation demonstrates a mild Windows bias. In several places, Windows-specific tools, paths, or behaviors are mentioned before or instead of Linux equivalents. For example, the use of Windows-style environment variable syntax (e.g., %HOME%\typescript), the explicit mention of Windows-only settings (e.g., WEBSITE_NODE_DEFAULT_VERSION), and the use of Windows paths (e.g., d:\home\data\SitePackages) without always providing Linux alternatives. Some instructions and examples are Windows-centric or lack Linux-specific guidance, even though Azure Functions is cross-platform.
Recommendations
- For every Windows-specific example or path (e.g., %HOME%\typescript, d:\home\data\SitePackages), provide the Linux equivalent (e.g., $HOME/typescript, /home/site/wwwroot/SitePackages).
- When describing OS-specific behaviors (such as environment variable delimiters), always mention Linux behavior first or equally, and clarify differences explicitly.
- For settings that are Windows-only (e.g., WEBSITE_NODE_DEFAULT_VERSION), clearly state the Linux alternative or note if not applicable.
- When referencing tools (e.g., Azure PowerShell), mention Azure CLI alongside it, and provide CLI examples where possible.
- Audit all sample values and code snippets to ensure parity between Windows and Linux, especially for file paths and environment variable syntax.
- Add explicit Linux examples for local development and deployment scenarios, not just references to local.settings.json.
- Review and update legacy references (such as d:\ paths) to clarify their relevance for Windows only, and provide Linux context.
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 before their Linux equivalents, and some instructions (such as ReadyToRun and debugging) provide more detail or default to Windows scenarios. Azure PowerShell and Visual Studio (Windows-only) are listed as primary options for resource creation and deployment, while Linux-specific workflows and tools are less emphasized or only mentioned after Windows. Some CLI examples default to Windows, and Linux-specific nuances are not always explained in equal depth.
Recommendations
- Ensure that all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
- When listing tools or workflows (e.g., Visual Studio, PowerShell), always include Linux-friendly alternatives (e.g., VS Code, Azure CLI, Bash scripts) and avoid listing Windows options first by default.
- For sections like ReadyToRun, debugging, and deployment, provide Linux-specific instructions and troubleshooting tips alongside Windows ones, not just as afterthoughts or in separate tabs.
- Highlight cross-platform tools (such as Azure CLI and VS Code) as primary options, and clarify when a tool is Windows-only.
- Where PowerShell is mentioned, provide Bash or shell equivalents for Linux users.
- Audit all code snippets and command-line instructions to ensure Linux users can follow along without ambiguity or extra research.
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 mild Windows bias by listing Windows-centric tools (Visual Studio, PowerShell) before cross-platform or Linux-native alternatives, and by providing more detailed instructions and references for Windows-specific development environments. While the document does mention Linux and macOS support in several places and includes cross-platform tools like Visual Studio Code and Core Tools, Windows tools and patterns (such as Visual Studio and PowerShell) are often mentioned first or given more prominence. There are also more detailed instructions for changing settings in Visual Studio (a Windows-first IDE), and PowerShell is listed as a recommended HTTP test tool before Linux-native alternatives like curl.
Recommendations
- Ensure that Linux and macOS development environments are given equal prominence to Windows tools in all tables and lists (e.g., mention Visual Studio Code and CLI before or alongside Visual Studio).
- Provide Linux/macOS-specific instructions or examples where Windows-specific instructions are given (e.g., changing ports or settings in Visual Studio).
- When listing HTTP test tools, list cross-platform or Linux-native tools (such as curl or HTTPie) before or alongside Windows tools like PowerShell.
- Explicitly mention Linux/macOS terminal usage and provide example commands where relevant, not just 'command prompt or terminal'.
- Where possible, include screenshots or walkthroughs for Linux/macOS environments, not just Windows/Visual Studio.
- Avoid assuming Visual Studio is the default or primary development environment; clarify that Visual Studio Code and CLI are first-class options on all platforms.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-bindings-expressions-patterns.md
...e-functions/functions-bindings-expressions-patterns.md
High Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Powershell Heavy
Summary
The documentation page focuses exclusively on C# and .NET examples, with all code samples and explanations tailored to these technologies. There are no examples or references to Linux-specific tools, shell commands, or cross-platform development environments. The only mention of local development refers to 'local.settings.json', which is not platform-specific, but all code and context are .NET-centric. There is a placeholder for a JavaScript example, but it is not provided. No Linux shell, bash, or non-Windows development workflows are mentioned, and the documentation implicitly assumes a Windows/.NET development environment.
Recommendations
- Add equivalent examples for JavaScript, Python, and other supported languages, especially for Linux/macOS users.
- Include instructions or notes about using Azure Functions on Linux and macOS, such as differences in local development or deployment.
- Provide shell (bash) command examples for managing app settings or local development, alongside any PowerShell or Windows-specific instructions.
- Ensure that any references to file paths, environment variables, or tooling are cross-platform or include both Windows and Linux/macOS variants.
- Complete the TODO for JavaScript examples and consider adding Python examples 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 provides both Bash and Windows CMD examples for Maven and Azure CLI commands, but consistently lists Windows CMD examples after Bash, which is a positive sign. However, there are some subtle signs of Windows bias: (1) The documentation refers to 'command prompt' alongside 'terminal', which is a Windows-centric term; (2) The use of 'cmd' tabs and examples is prevalent, but there are no explicit PowerShell examples, which is good; (3) In the Java versions table, Windows is listed before Linux, and for Functions 2.x, Linux support is marked as 'n/a' without further explanation; (4) Some instructions refer to 'command prompt, Bash, or Terminal', but do not always clarify Linux-specific nuances; (5) There are no Linux-specific troubleshooting or environment setup notes, and the documentation does not mention WSL or common Linux distributions.
Recommendations
- Clarify that 'command prompt' refers to Windows and 'terminal' to Linux/macOS, or use 'terminal' as a generic term.
- Wherever possible, provide parity in troubleshooting steps for both Windows and Linux, especially for environment variables and file paths.
- In tables (such as Java version support), consider listing Linux before or alongside Windows, or alphabetically, to avoid implicit prioritization.
- Add Linux-specific notes where relevant, such as differences in environment variable setup, file permissions, or common issues on Linux.
- Consider including at least one example using PowerShell (if relevant), but ensure Bash and Linux-native instructions are always present and up-to-date.
- Explicitly mention support for WSL (Windows Subsystem for Linux) if applicable, and provide guidance for users on that platform.
- Where 'n/a' is used in tables (e.g., Functions 2.x on Linux), provide a brief explanation for the lack of support.
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 subtle Windows bias in several areas. References to 'command prompt' and 'Terminal or command prompt' are used throughout, which implicitly prioritizes Windows terminology over cross-platform or Linux-native terms (such as 'shell' or 'terminal'). In the publishing section, remote build is recommended specifically for users developing on Windows, and local build is discouraged for Windows users, but there is no explicit guidance for Linux/macOS users. The documentation also references Visual Studio Code and Azure Functions Core Tools, which are cross-platform, but does not mention Linux-specific shells or package managers. There are no explicit PowerShell-only examples, but the overall pattern is to mention Windows/Windows tools and terminology first or exclusively.
Recommendations
- Replace 'command prompt' with 'terminal' or 'shell', or use 'terminal (command prompt on Windows)' to clarify cross-platform usage.
- When discussing publishing and build options, provide explicit instructions and recommendations for Linux/macOS users, not just Windows.
- Where tools are referenced (e.g., Visual Studio Code, Azure Functions Core Tools), clarify their cross-platform availability and provide Linux/macOS installation links or notes.
- Include Linux/macOS-specific notes or examples where relevant, such as using Bash, zsh, or common Linux file paths.
- Avoid phrases like 'develop locally on Windows' without also mentioning Linux/macOS, or add parallel statements for those platforms.
- Review all code snippets and command-line instructions to ensure they are platform-neutral (e.g., use $ for shell prompts, avoid Windows path separators unless necessary).
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 or in more detail than their Linux equivalents. Some CLI examples and configuration steps are provided only for Windows or are presented with Windows first, and PowerShell/Azure PowerShell is referenced as a primary method for resource creation. Linux-specific instructions are present but sometimes less prominent or detailed. There are also sections where Linux deployment/configuration is only briefly mentioned or lacks parity in example depth.
Recommendations
- Ensure that all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
- When listing tools or methods (e.g., Visual Studio, Visual Studio Code, CLI, PowerShell), alternate the order or present them in parallel lists/tables to avoid always listing Windows-first.
- Where PowerShell is mentioned, ensure Bash/Azure CLI equivalents are also included and shown with equal detail.
- For deployment and configuration commands, provide both Windows and Linux command-line examples side by side, not just as tabs.
- Explicitly mention any differences or caveats for Linux users, especially for local development, debugging, and deployment.
- Audit all code snippets and walkthroughs to ensure Linux users are not required to infer steps or commands from Windows-centric instructions.
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
Summary
The documentation is generally cross-platform, but there are subtle Windows biases. In several places, Windows-specific tools or patterns are mentioned first or exclusively (e.g., PowerShell, Windows environment variable delimiters, and Windows-specific settings like WEBSITE_NODE_DEFAULT_VERSION). PowerShell is listed as a first-class language, and some settings (like AzureWebJobs_TypeScriptPath) use Windows path syntax. In a few cases, Windows-specific behaviors or settings are described in more detail than Linux equivalents. However, Linux is referenced in many places, and Linux-specific settings are present, but parity in examples and ordering could be improved.
Recommendations
- When listing environment variable delimiters or behaviors, always present Linux and Windows equally (e.g., mention both colon and double-underscore, and clarify differences).
- For settings that have OS-specific values (like WEBSITE_TIME_ZONE), always provide both Windows and Linux examples side by side.
- Avoid using Windows path syntax (e.g., %HOME%\typescript) in examples unless also providing the Linux equivalent (e.g., $HOME/typescript).
- When referencing tools for managing settings (e.g., Azure CLI, Azure PowerShell), list cross-platform tools first or equally, and avoid suggesting PowerShell as the default.
- For settings that are Windows-only (like WEBSITE_NODE_DEFAULT_VERSION), clearly label them and, where possible, provide the Linux alternative or clarify the Linux behavior.
- Review ordering of language runtimes and examples to ensure Linux-native languages and tools (e.g., bash, Python) are not always listed after Windows/PowerShell.
- Where PowerShell is referenced for dependency management or configuration, provide equivalent bash or shell script examples for Linux 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 largely cross-platform in its use of Visual Studio Code and JavaScript, but there are subtle signs of Windows bias. The troubleshooting section specifically references Windows (e.g., default terminal shell and WSL Bash) without mentioning Linux or macOS equivalents. There are no explicit Linux/macOS-specific instructions, nor are there examples or troubleshooting tips for those platforms. Windows-specific issues are mentioned first and exclusively, and there is an implicit assumption that users are familiar with Windows tools and patterns.
Recommendations
- Add troubleshooting steps and notes for Linux and macOS users, such as common issues with permissions, shell environments, or dependencies.
- When referencing terminal shells, mention Linux/macOS shells (e.g., bash, zsh) alongside Windows shells (e.g., Command Prompt, PowerShell, WSL Bash).
- Ensure that any platform-specific instructions or caveats are provided for all supported operating systems, not just Windows.
- Explicitly state that the instructions apply to Windows, Linux, and macOS, and provide parity in examples and troubleshooting.
- Consider adding a table or section summarizing any OS-specific differences in setup, usage, or troubleshooting.
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 (Linux/macOS) and Cmd (Windows) examples for command-line operations, but there is a consistent pattern of presenting Windows (Cmd) examples alongside or immediately after Bash, sometimes with more detailed instructions for Windows users. There is also a notable absence of explicit Linux-specific troubleshooting, environment setup, or tool references, and no mention of Linux-specific editors or shell environments beyond Bash. PowerShell is not directly referenced, but the presence of Cmd examples and the 'windows_first' ordering in some tables and explanations indicates a subtle Windows bias.
Recommendations
- Ensure that Linux/Bash examples are always presented first, or alternate the order to avoid implicit prioritization of Windows.
- Include explicit Linux troubleshooting steps or notes where environment variables, file paths, or permissions may differ from Windows.
- Reference Linux-native editors (such as Vim, Emacs, or GNOME Text Editor) in addition to Windows-centric IDEs.
- Where Cmd examples are given, consider also providing PowerShell and Zsh/Fish shell equivalents for completeness.
- Add a section on common Linux-specific issues (e.g., case sensitivity, file permissions) that may affect Java Azure Functions development.
- Highlight any differences in local development experience between Windows and Linux, especially regarding Java version management and environment setup.
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 page demonstrates some Windows bias by listing Windows-centric tools (such as Visual Studio and PowerShell) before cross-platform or Linux-native alternatives, and by providing more detailed instructions or references for Windows-specific environments. PowerShell is mentioned as an HTTP test tool, and Visual Studio (Windows-only) is consistently listed first in environment tables, even when cross-platform options like VS Code are available. There are no explicit Linux-only examples or tools, and Linux is only mentioned as a supported platform, not as a first-class development environment.
Recommendations
- List cross-platform tools (such as Visual Studio Code and Azure Functions Core Tools) before Windows-only tools in tables and lists to avoid implying Windows primacy.
- Include Linux-specific examples or screenshots where relevant, especially for command-line usage and environment setup.
- Mention Linux-native HTTP testing tools (such as httpie or wget) alongside curl and PowerShell.
- Clarify when a tool or workflow is Windows-only, and provide equivalent Linux/macOS instructions or alternatives.
- Add a section or callout highlighting Linux development workflows, including package installation commands and common troubleshooting tips for Linux users.
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 command-line environments (Cmd, PowerShell) are listed before Linux/macOS equivalents, and PowerShell is given its own language pivot. Windows-specific tools and patterns (such as .venv activation paths and command syntax) are described in detail, sometimes before or with more prominence than Linux/macOS equivalents. The presence of a dedicated PowerShell language pivot, and the inclusion of both Cmd and PowerShell tabs for commands, further highlights a Windows-centric approach. However, Linux/macOS instructions are present and functional throughout.
Recommendations
- Ensure that Linux/macOS examples are always presented with equal prominence and, where possible, listed before or alongside Windows examples.
- Where multiple OS-specific tabs are used, consider listing Linux/macOS first, or randomizing order to avoid implicit prioritization.
- Review the use of PowerShell as a primary language pivot; ensure that Linux shell scripting or Bash is equally represented where relevant.
- Audit all command examples to ensure that Linux/macOS paths and conventions are accurate and not derived from Windows-centric assumptions.
- Where possible, provide cross-platform (e.g., Bash, PowerShell Core) command examples that work on all systems, or clearly indicate OS-specific differences.
- Explicitly state in the prerequisites or introduction that all major platforms are supported and that instructions are provided for each.
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 the Azure Functions extension, which are available on Windows, macOS, and Linux. However, there are subtle signs of Windows bias: troubleshooting steps specifically mention Windows and WSL Bash, and there are no explicit Linux- or macOS-specific instructions or examples. The documentation does not provide parity in addressing potential Linux/macOS issues or terminal usage, and references to shell environments are Windows-centric.
Recommendations
- Add explicit notes or troubleshooting steps for Linux and macOS users, such as common issues with permissions, shell environments, or dependencies.
- When mentioning Windows-specific issues (e.g., WSL Bash), also mention possible Linux/macOS equivalents or clarify if the issue is Windows-only.
- Include example terminal commands or screenshots for Linux/macOS where relevant, especially in sections about running or deploying functions.
- Ensure that all references to tools (such as Azure Functions Core Tools) clarify their cross-platform availability and provide installation instructions for all supported OSes.
- Consider adding a table or section that highlights any OS-specific considerations for Visual Studio Code and Azure Functions development.
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 Cmd (Windows Command Prompt) examples for command-line operations, but Cmd/Windows examples are consistently presented alongside or immediately after Bash, sometimes with more detailed explanations. There is a notable absence of explicit Linux-specific tools, troubleshooting, or environment setup guidance. No PowerShell-specific examples are present, but the documentation does not mention or show Linux-specific package managers, shell peculiarities, or troubleshooting steps. The focus on Visual Studio Code, IntelliJ, and Eclipse is cross-platform, but some references (such as environment variable setup and folder structure) assume familiarity with Windows conventions. There are no Linux-only examples or sections, and some tables and explanations list Windows before Linux.
Recommendations
- Ensure Linux examples are always presented alongside Windows examples, and not only as Bash tabs but also in narrative explanations.
- Include Linux-specific troubleshooting tips, such as permissions, file paths, and environment variable setup (e.g., export JAVA_HOME).
- Add explicit notes about differences in file system case sensitivity, path separators, and common issues on Linux.
- When listing supported OS or Java versions, alternate the order or present Linux first in some cases.
- Provide examples using Linux package managers (apt, yum) for installing Java or Maven where appropriate.
- Clarify that all CLI commands work on both Windows and Linux, and highlight any OS-specific caveats.
- Consider adding a dedicated section for Linux/macOS development environment setup and common pitfalls.
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, primarily in the way it presents development and publishing workflows. Windows terminology ("command prompt") is used alongside "terminal" without explicit mention of Linux or macOS. Remote build is recommended for Windows users, and local build is discouraged on Windows, but there is little explicit guidance for Linux users. The documentation references Visual Studio Code and Azure Functions Core Tools, which are cross-platform, but does not provide Linux-specific examples, terminal commands, or troubleshooting tips. There are no PowerShell-specific examples, but the overall pattern assumes a Windows-first perspective.
Recommendations
- Explicitly mention Linux and macOS in all references to 'terminal or command prompt', and provide example commands using bash/zsh where appropriate.
- Include Linux-specific troubleshooting tips, such as file permission issues, case sensitivity, or common dependency installation problems.
- When discussing publishing and build workflows, clarify which steps or recommendations apply to Linux, macOS, and Windows, and provide parity in guidance.
- Add explicit examples of using Azure Functions Core Tools and CLI commands in a Linux shell environment.
- Where folder structures are shown, use generic or Linux-style paths (e.g., forward slashes) or provide both Windows and Linux path examples.
- Highlight any differences in behavior or requirements when developing and deploying from Linux/macOS versus Windows.
- Consider including a section or callout for Linux/macOS users with tips or known issues.
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 mild Windows bias. Visual Studio (Windows-only) is consistently listed first in environment tables, and Windows-specific tools like PowerShell and Visual Studio are highlighted before cross-platform or Linux-native alternatives. The HTTP test tools section lists PowerShell and Microsoft Edge (Windows-centric) before curl, which is more common on Linux. There are no explicit Linux-only examples or tools, and Linux is generally mentioned as 'also supported' rather than as a primary platform.
Recommendations
- In environment tables, alternate the order of Windows and cross-platform tools, or list cross-platform tools (like VS Code and CLI) first to emphasize parity.
- In the HTTP test tools section, list curl and Bruno before PowerShell and Microsoft Edge, or group tools by platform.
- Include explicit Linux/macOS terminal examples (e.g., bash commands) alongside or before Windows/Powershell examples.
- Highlight Linux/macOS support more prominently, not just as a secondary note.
- Where Visual Studio is mentioned, clarify that it is Windows-only and suggest equivalent Linux/macOS workflows (e.g., JetBrains Rider, VS Code, CLI).
- Add a section or callout specifically for Linux/macOS users, summarizing recommended tools and 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 are subtle Windows biases. Command-line examples are consistently provided for both Bash (Linux/macOS) and Cmd (Windows), but the Windows/Cmd tabs are always listed after Bash, which is positive. However, there is a notable absence of explicit PowerShell examples, which is good, but the documentation refers to 'command prompt' (a Windows term) alongside 'terminal' in some places. Some sections, such as Java version support, list Windows before Linux, and the table for supported Java versions is headed 'Java versions (Windows)' before 'Java versions (Linux)'. There are no Linux-specific tools or troubleshooting steps, and the documentation does not mention Linux-specific differences or caveats. While the documentation is not overtly Windows-centric, it does not provide Linux-first or Linux-specific guidance, and some language and ordering choices subtly prioritize Windows.
Recommendations
- When referencing command-line development, use 'terminal' or 'shell' instead of 'command prompt' to avoid Windows-centric language.
- In tables and lists, alternate the order of Windows and Linux, or use alphabetical order to avoid always listing Windows first.
- Add Linux-specific troubleshooting tips or notes where relevant, especially for environment variables, file paths, or permissions.
- Explicitly mention that all CLI and Maven commands work identically on Linux, macOS, and Windows, and highlight any OS-specific caveats.
- Consider including PowerShell examples only if there are unique steps, and always provide Bash equivalents.
- Where IDEs are mentioned, clarify that all are cross-platform (e.g., IntelliJ, Eclipse, VS Code) and that the experience is consistent across OSes.
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
Powershell Heavy
Summary
The documentation generally provides both Bash (Linux/macOS) and Cmd (Windows) examples for command-line operations, but Windows/Cmd examples are consistently presented alongside or immediately after Bash, sometimes with slightly more detail. There is a mild 'windows_first' bias in the order of presentation (e.g., Visual Studio Code and Windows-specific tools are often mentioned before Linux alternatives), and the inclusion of Cmd tabs and examples throughout. However, Linux is not neglected: Bash examples are present, and Linux-specific details (such as Java 21 support) are included. There are no sections that are Windows-only or that omit Linux equivalents, but the parity could be improved for a more neutral, cross-platform experience.
Recommendations
- Ensure that Bash (Linux/macOS) examples are always presented first, or alternate the order with Cmd examples to avoid implicit prioritization.
- Wherever command-line examples are given, explicitly mention that Bash examples apply to Linux/macOS and Cmd to Windows, to clarify for users.
- Add explicit references to Linux terminal environments (e.g., GNOME Terminal, Konsole) in the introductory sections, not just 'Terminal'.
- In the 'Getting started' and 'Next steps' sections, include links or notes about Linux-specific development environments or workflows, if available.
- Review the order of tool mentions (e.g., Visual Studio Code, IntelliJ, Eclipse) to ensure no implicit Windows preference.
- Consider adding troubleshooting or environment setup notes specific to Linux (e.g., setting JAVA_HOME in .bashrc/.zshrc, common Linux JDK installation commands).
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-dotnet-class-library.md
...cles/azure-functions/functions-dotnet-class-library.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Missing Linux Example
Summary
The documentation page exhibits a moderate Windows bias. Visual Studio (a Windows-centric IDE) is mentioned first and most frequently, with Visual Studio Code and command-line options listed after. Examples for installing packages are provided for Command Prompt and PowerShell, but there are no explicit Bash or Linux shell examples. The ReadyToRun publishing example uses a Windows runtime identifier (win-x86) without showing cross-platform equivalents. The section on Azure Functions Core Tools references the Windows installer (MSI) and Windows-specific paths, with no mention of Linux or macOS installation or file locations. There are no explicit Linux/macOS command-line or tooling examples, and Windows tools/patterns are referenced before or instead of cross-platform alternatives.
Recommendations
- Provide Bash/Linux/macOS equivalents for all command-line examples, including package installation and project setup.
- Include cross-platform runtime identifiers (e.g., linux-x64, osx-x64) in ReadyToRun and publishing examples, or show a table of common options.
- When listing development environments, alternate the order or explicitly state parity between Visual Studio, Visual Studio Code, and CLI, and provide equal depth of guidance for each.
- Reference cross-platform installation instructions for Azure Functions Core Tools, including npm and manual installation for Linux/macOS, and mention relevant file paths for non-Windows systems.
- Add explicit notes or callouts where behaviors or file locations differ between Windows and Linux/macOS.
- Ensure all tooling and workflow sections mention and show examples for both Windows and Linux/macOS users.
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-develop-local.md
...in/articles/azure-functions/functions-develop-local.md
High Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Powershell Heavy
Summary
The documentation demonstrates some Windows bias by listing Windows-centric tools (Visual Studio, PowerShell) prominently, often before cross-platform or Linux-native alternatives. Visual Studio (Windows-only) is always listed first for C#, and PowerShell is highlighted as an HTTP test tool before more universal tools like curl. While the documentation does mention Linux and macOS support and includes cross-platform tools (VS Code, Core Tools, curl), Windows tools and patterns are often given priority or more detailed coverage.
Recommendations
- When listing development environments, avoid always listing Visual Studio (Windows-only) first. Consider grouping cross-platform tools (VS Code, Core Tools) before Windows-only tools, or clearly marking platform exclusivity.
- In tables and lists, alternate the order of tools or use alphabetical order to avoid implicit prioritization of Windows tools.
- For HTTP test tools, list curl (ubiquitous on Linux/macOS) before PowerShell, or group tools by platform compatibility.
- Where PowerShell is mentioned, also mention Bash or other Linux-native shells for parity.
- Explicitly call out Linux/macOS-specific workflows or tips where relevant, not just in passing.
- Ensure that all example commands and workflows are shown for both Windows and Linux (e.g., both PowerShell and Bash command lines where appropriate).
Azure Functions
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/create-first-function-azure-developer-cli.md
...functions/create-first-function-azure-developer-cli.md
High Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Windows Tools
Summary
The documentation generally aims for cross-platform parity, but there are subtle signs of Windows bias. Windows command-line environments (Cmd, PowerShell) are often mentioned explicitly and sometimes before Linux/bash equivalents. PowerShell is given a dedicated programming language pivot, and Windows-specific instructions (such as activating Python venvs) are provided in detail. There is also a tendency to refer to 'terminal or command prompt' rather than just 'terminal', and some examples use Windows-centric terminology or tools.
Recommendations
- Ensure that Linux/bash instructions are always presented before or alongside Windows/Cmd/PowerShell examples, not after.
- Use neutral language such as 'terminal' instead of 'command prompt' unless specifically referring to Windows.
- Where PowerShell is given as a primary example, ensure bash/zsh equivalents are equally prominent.
- For all code snippets, provide both bash and Windows (Cmd/PowerShell) versions side-by-side, and make it clear which is which.
- Review all references to tools and paths (e.g., file paths, activation commands) to ensure Linux and macOS users are not disadvantaged.
- Consider adding explicit notes about cross-platform compatibility and any platform-specific caveats.