52
Total Pages
41
Linux-Friendly Pages
11
Pages with Bias
21.2%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues (15)

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides only Azure Portal (GUI) instructions and screenshots, with no command-line examples for either Windows (PowerShell/Command Prompt) or Linux (Bash/CLI). However, it implicitly favors Windows by referencing Visual Studio Code as the code editor and omitting any mention of Linux tools, CLI commands, or cross-platform workflows. There are no examples or guidance for users who prefer or require Linux-based automation or scripting.
Recommendations:
  • Add Azure CLI examples for enabling diagnostic settings and downloading logs, as Azure CLI is cross-platform and widely used on Linux.
  • Include sample Bash commands for downloading blobs from Azure Storage (e.g., using az storage blob download or tools like wget/curl with SAS URLs).
  • Mention and provide examples for opening JSON logs with common Linux editors (e.g., nano, vim, less, jq) in addition to Visual Studio Code.
  • Explicitly state that all steps can be performed on Linux, macOS, or Windows, and provide parity in instructions where possible.
  • Where screenshots are used, consider including CLI output or terminal screenshots to complement GUI steps.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation exclusively describes integration and log analysis using Azure Portal UI and Azure-native tools (Log Analytics Workspace, KQL), with no mention of command-line or scripting options for Linux users (such as Azure CLI, Bash, or REST API). There are no PowerShell or Windows-specific commands, but the absence of Linux-friendly examples or cross-platform CLI instructions creates an implicit bias toward Windows/GUI workflows.
Recommendations:
  • Add Azure CLI examples for enabling diagnostic settings and querying logs, which work cross-platform (Windows, Linux, macOS).
  • Include sample Bash scripts or REST API calls for automating log export and analysis.
  • Mention that all Azure Portal features are accessible from any OS with a browser, but provide parity for users who prefer or require CLI/scripted workflows.
  • If screenshots are used, consider including at least one from a Linux environment or clarify that the UI is OS-agnostic.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation presents deployment options for AKS (Azure Kubernetes Service) and Windows, but does not mention or provide instructions for deploying the GCZ service on Linux (outside of AKS). The 'Windows' deployment option is specifically called out for development/testing, but there is no equivalent guidance for Linux environments, which are common for development and testing. This creates a Windows-first impression and omits Linux parity.
Recommendations:
  • Add a section or pivot for deploying the GCZ service on Linux (e.g., Ubuntu) for development and testing, similar to the Windows option.
  • If the service can run on Linux, provide step-by-step instructions or reference scripts for Linux-based deployment.
  • Ensure that any scripts, commands, or tooling mentioned for Windows (such as PowerShell or Windows-specific paths) have Linux equivalents (e.g., Bash scripts, Linux file paths).
  • Explicitly mention Linux as a supported platform for development/testing if applicable, or clarify if there are technical limitations.
  • Review included files (e.g., deploy-gcz-on-windows.md) to ensure Linux users are not excluded from development/test scenarios.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a moderate Windows bias by focusing exclusively on Postman (a GUI tool most commonly used on Windows) for API interactions, and by not providing explicit Linux command-line examples for key steps such as file uploads or API calls. While the use of bash scripts and Python-based sdutil suggests some cross-platform intent, there are no Linux-specific instructions or examples, and the initial setup and workflow are described primarily through GUI-based tools rather than CLI alternatives that are more common in Linux environments.
Recommendations:
  • Provide explicit Linux command-line examples for all API interactions, especially for uploading files and making API calls (e.g., using curl or httpie).
  • Include instructions for installing and using Postman on Linux, or suggest alternative CLI tools for Linux users.
  • When referencing scripts (such as prepare-records.sh), clarify any OS-specific dependencies or steps, and provide troubleshooting tips for Linux environments.
  • Ensure that all steps that can be performed via CLI (such as sdutil commands or curl requests) are documented with equivalent Linux shell commands and not just GUI screenshots.
  • Add a section or callouts highlighting any differences or considerations for Linux users, such as file path conventions or required dependencies.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a bias towards Windows by exclusively referencing the Azure Portal (a web GUI) and not providing any command-line examples. There are no examples using cross-platform tools such as Azure CLI, Azure PowerShell, or REST APIs, which are commonly used on Linux and macOS. The documentation implicitly assumes a GUI/Windows-centric workflow, omitting Linux-friendly automation or scripting options.
Recommendations:
  • Add step-by-step instructions using Azure CLI for all key management and configuration tasks, as Azure CLI is cross-platform and widely used on Linux.
  • Include PowerShell examples as an alternative, but ensure CLI examples are presented first or alongside PowerShell to avoid Windows-first bias.
  • Provide REST API examples for advanced users who may want to automate these tasks from any OS.
  • Explicitly mention that all operations can be performed from Linux, macOS, or Windows, and provide links to relevant CLI or API documentation.
  • Where screenshots are used, consider including terminal output or code snippets to complement GUI steps.

Page-Level Analysis

Missing Linux Example Windows First
Summary:
The documentation page demonstrates a bias towards Windows environments by focusing exclusively on GUI tools (Postman desktop app) and Python-based utilities (sdutil) without providing explicit Linux command-line examples or mentioning Linux-native tools. The instructions assume the use of desktop applications and do not address Linux-specific installation or usage considerations. There is no mention of Linux package managers, shell commands, or alternative workflows that are common in Linux environments.
Recommendations:
  • Provide explicit Linux command-line examples for each step, such as using curl or wget for API calls and file uploads.
  • Include instructions for installing and running Postman and sdutil on Linux, including any dependencies or package manager commands (e.g., apt, yum, snap).
  • Mention and demonstrate how to use native Linux tools (e.g., curl, jq) as alternatives to Postman for API interactions.
  • Clarify that sdutil and Postman are cross-platform, and provide troubleshooting tips for Linux users (e.g., permissions, environment variables).
  • Add a section or callouts for Linux users, highlighting any differences or additional steps required on Linux systems.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation provides deployment instructions for Azure Kubernetes Service (AKS) and Windows, but does not mention or provide instructions for deploying the GCZ service on Linux (outside of AKS). The 'Windows' deployment option is presented as the only non-AKS alternative, with no equivalent Linux instructions for development or testing environments. This creates a Windows-first impression and omits Linux users who may wish to deploy locally or outside Kubernetes.
Recommendations:
  • Add a section or pivot for deploying the GCZ service on Linux (e.g., Ubuntu), including step-by-step instructions or a link to a Linux deployment guide.
  • Wherever a 'Windows' deployment is mentioned, also mention 'Linux' as a supported platform if possible, or clarify platform limitations.
  • If there are scripts or tools provided for Windows (e.g., PowerShell), provide equivalent Bash or shell scripts for Linux users.
  • Explicitly state platform support and any limitations for each deployment option to help users on all major operating systems.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by exclusively referencing Windows tools (Postman desktop app) and providing screenshots and instructions that assume a Windows environment. There are no explicit Linux-specific instructions, examples, or screenshots, and setup steps for tools like Postman and sdutil do not address Linux installation or usage. The documentation does not mention or show parity for Linux users, such as using Postman on Linux, or provide Linux command-line alternatives or troubleshooting.
Recommendations:
  • Include explicit instructions and screenshots for installing and using Postman on Linux, or clarify that Postman is cross-platform.
  • Provide Linux-specific setup notes for sdutil, including installation steps and any OS-specific dependencies.
  • When referencing tools, avoid language that implies Windows is the default (e.g., 'Download and install the Postman desktop app' could be 'Download and install the Postman desktop app for your OS').
  • Add troubleshooting tips or notes for common Linux issues (e.g., permissions, Python environment setup for sdutil).
  • Where screenshots are shown, consider including at least one from a Linux environment or clarify that the UI is the same across platforms.
  • Explicitly state that all command-line examples (bash scripts, sdutil commands) are valid on Linux and provide any necessary adjustments for Windows users if needed.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides only GUI-based instructions and KQL query examples, with no mention of command-line tools, scripts, or workflows for either Windows or Linux. However, there is a lack of parity for Linux users in that there are no CLI (e.g., Azure CLI, Bash) or automation examples, which are commonly used in Linux environments. There is also no mention of PowerShell or Windows-specific tools, so explicit Windows bias is minimal, but the absence of Linux/CLI examples may disadvantage Linux users.
Recommendations:
  • Add Azure CLI command examples for configuring diagnostic settings and exporting logs, as Azure CLI is cross-platform and widely used in Linux environments.
  • Include sample Bash scripts for automating log export or querying operations.
  • Mention how to access and analyze logs from the storage account using Linux tools (e.g., azcopy, jq, grep).
  • Clarify that all steps can be performed from any OS using the Azure Portal, but provide parity by showing how to accomplish the same tasks via CLI for users who prefer or require non-GUI workflows.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation exclusively describes GUI-based steps using the Azure Portal and does not provide any command-line examples for enabling diagnostic settings or downloading logs. There are no references to Windows-specific tools (such as PowerShell), but the instructions implicitly assume use of the Azure Portal, which is most commonly accessed from Windows environments. There are no CLI (az), PowerShell, or Linux shell examples, nor is there mention of how to perform these tasks from Linux or cross-platform environments.
Recommendations:
  • Add equivalent command-line instructions using Azure CLI (az), which is cross-platform and works on Linux, macOS, and Windows.
  • Include examples for downloading logs using az storage blob commands or other cross-platform tools (e.g., curl, wget, or Azure Storage Explorer).
  • Explicitly mention that all steps can be performed from any OS, and provide links to CLI documentation for users who prefer or require non-GUI workflows.
  • If PowerShell examples are added, ensure that Bash/Linux shell equivalents are also provided.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation consistently instructs users to run commands in 'Azure Cloud Shell', which by default is a Bash environment but is tightly integrated with Azure and often associated with Windows-centric workflows. There are no explicit PowerShell or Windows command examples, but the documentation does not mention or provide guidance for running these commands in a generic Linux/macOS terminal or on-premises shell. The screenshots and instructions focus exclusively on Azure/Microsoft tools and environments, with no mention of Linux-native authentication or CLI workflows outside of Azure's ecosystem.
Recommendations:
  • Explicitly state that the curl commands can be run from any Bash-compatible shell on Linux, macOS, or Windows (with WSL or Git Bash), not just Azure Cloud Shell.
  • Provide examples or notes for running the commands in native Linux/macOS terminals, including any prerequisites (e.g., curl installation, environment variable setup).
  • If authentication steps differ for Linux/macOS (e.g., using Azure CLI on Linux), include those instructions or references.
  • Avoid implying that Azure Cloud Shell is the only or primary environment for these operations; mention alternatives such as local terminals.
  • If screenshots are necessary, consider including examples from both Windows and Linux environments to demonstrate cross-platform compatibility.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a bias towards Microsoft and Windows-centric tools and workflows. It exclusively mentions Microsoft products (SharePoint, Synapse, Power BI, Entra ID) for integration and extensibility, with no mention of Linux-based tools, open-source alternatives, or cross-platform command-line examples. The documentation assumes the use of the Microsoft ecosystem, which is more common on Windows, and does not provide parity for Linux users.
Recommendations:
  • Include examples and references to cross-platform or Linux-native tools for data ingestion, transformation, and visualization (e.g., Apache NiFi, Jupyter, Grafana).
  • Mention compatibility with open-source identity providers or authentication mechanisms commonly used on Linux.
  • Provide command-line examples for both Windows (PowerShell) and Linux (Bash) in future quickstart or how-to guides.
  • Highlight integration possibilities with non-Microsoft applications and services to demonstrate platform openness.
  • Clarify whether the platform supports Linux-based workflows and tools, and provide documentation or links for Linux users.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation exclusively demonstrates manifest-based file ingestion using the Postman desktop app, without providing any command-line or scripting examples (such as curl, HTTPie, or shell scripts) that would be more familiar or accessible to Linux users. There is no mention of Linux-specific tools or workflows, nor are there instructions for performing the same tasks outside of a GUI environment. This may disadvantage users who prefer or require non-GUI, scriptable, or Linux-native approaches.
Recommendations:
  • Provide equivalent examples using command-line tools such as curl or HTTPie for each API call demonstrated in Postman.
  • Include sample shell scripts (bash) to automate the ingestion workflow, making it easier for Linux users to follow along.
  • Mention that the API can be accessed from any platform and that Postman is just one of several possible tools.
  • If possible, provide instructions for installing and using Postman on Linux, or suggest alternative Linux-friendly API clients.
  • Ensure that any downloadable resources (such as sample files) are accessible and usable from the Linux command line.

Page-Level Analysis

Powershell Heavy Windows First
Summary:
The documentation introduces the tutorial as using PowerShell to work with Reservoir DDMS APIs, suggesting a Windows-first approach. However, all provided command-line examples use Bash and Docker, which are cross-platform, but the initial framing may mislead Linux or Mac users into thinking the tutorial is Windows-centric.
Recommendations:
  • Remove or generalize the reference to PowerShell in the introduction. Instead, state that the tutorial uses cross-platform command-line tools.
  • Explicitly mention that the Bash and Docker commands work on Linux, macOS, and Windows (with WSL or compatible terminals).
  • If there are any platform-specific steps (such as Docker Desktop installation), provide links or notes for both Windows and Linux/macOS users.
  • Consider providing PowerShell equivalents only if there are Windows-specific nuances, otherwise keep examples in Bash for maximum portability.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by listing Windows prerequisites and tools first, referencing Windows-specific tools (e.g., Microsoft C++ Build Tools, WSL), and providing activation commands for Windows before Linux. Some instructions and notes are tailored to Windows or WSL users, and there is a lack of parity in detailed Linux/Mac-specific guidance, especially regarding package management and environment setup.
Recommendations:
  • List Linux and Mac prerequisites before or alongside Windows, not after.
  • Provide Linux and Mac equivalents for all Windows-specific tools and commands (e.g., recommend GCC or Clang for C++ build tools on Linux, and clarify how to install dependencies using native package managers).
  • Avoid referencing WSL as the primary Linux environment for Windows users; instead, treat native Linux and WSL as separate, equally valid platforms.
  • Ensure all command examples (such as activating virtual environments) are shown for all platforms, and not just Windows first.
  • Expand on Linux/Mac installation steps, including common package manager commands (apt, yum, brew) and troubleshooting tips.
  • Where possible, use cross-platform commands and avoid Windows-centric paths or syntax.
  • Add explicit sections or callouts for Linux/Mac users wherever there are differences in workflow or tooling.