### Example form data for a general work item

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/task-template.md

Example form data as a user would supply when filing a general work item. Shows the title and the required task description text.

```text
Title: Backfill triage instructions for networking issues

Task description:
Update the triage checklists so networking issues get routed to the
docker-desktop-networks channel. Related: docker/desktop-feedback#4,
docs.docker.com/desktop/troubleshoot-and-support/.

```

--------------------------------

### Example 2: Error handling - submitting from the CLI and detecting failure

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/bug-template.md

Shows a CLI submission using `gh issue create` with a body and labels. The `type` and per-field values are not first-class `gh` arguments; only body and labels map 1:1. If validation fails (e.g., empty body), the command exits non-zero with HTTP 422.

```bash
title="Volume mounts slow after waking from sleep"
body=$(cat <<'EOF'
## Bug description
`docker compose up` takes ~40s after wake from sleep.

## Reproduction steps
1. Wake the Mac
2. Run `docker compose up`
EOF
)

if gh issue create \
  --repo docker/desktop-feedback \
  --title "$title" \
  --body "$body" \
  --label kind/bug --label needs-triage; then
  echo "issue created"
else
  status=$?
  echo "github issue creation failed (exit $status)" >&2
  # e.g. exit 1 with "HTTP 422: Validation Failed" when --body is empty
fi
```

--------------------------------

### Example 1: Basic call - filing a bug through the form

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/bug-template.md

Shows the form data as a user would supply it, including title, bug report, platform, version information, and diagnostics ID. The issue type 'bug' is attached, labels 'kind/bug' and 'needs-triage' are auto-applied, and the four collected values are stored in the issue body.

```text
Title: Volume mounts slow after waking Mac from sleep

Bug report:
## Bug description
`docker compose up` takes ~40s after the laptop wakes from sleep; it was instant before.

## Reproduction steps
1. Open lid / wake Mac from sleep
2. Run `docker compose up` in a project with a bind mount
3. Observe 40s delay before containers start

Platform: macOS

Version information:
Client:
 Version:           27.5.1
 API version:       1.47
 OS/Arch:           darwin/arm64
Server: Docker Desktop 4.39.0 (184744)
 Engine:
  Version:          28.0.1
  OS/Arch:          linux/arm64

Diagnostics ID: 8a1b2c3d-4e5f-49a6-8b7c-9d0e1f2a3b4c
```

--------------------------------

### Collect version information with docker version && docker info

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/bug-template.md

Command shown in the version textarea's collapsible details block to collect version and environment information. Users are instructed to run it in their terminal and paste the output into the form.

```bash
docker version && docker info
```

--------------------------------

### Configure issue-template chooser with contact links

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/configuration.md

YAML configuration for the GitHub issue-template chooser. Sets blank_issues_enabled to false to hide the blank issue option and defines three contact links: Security and Vulnerabilities, Questions and Discussions, and Join the Docker Community on Slack. The first link points to the SECURITY.md file in the repository.

```yaml
blank_issues_enabled: false
contact_links:
  - name: Security and Vulnerabilities
    url: https://github.com/docker/desktop-feedback/blob/master/SECURITY.md
    about: Please report any security issues or vulnerabilities responsibly to the Docker security team. Please do not use the public issue tracker.
  - name: Questions and Discussions
    url: https://github.com/docker/desktop-feedback/discussions/new
    about: Use Github Discussions to ask questions and/or open discussion topics.
  - name: Join the Docker Community on Slack
    url: http://dockr.ly/comm-slack
    about: Join the Docker Community on Slack and head to a docker-desktop- channel.
```

--------------------------------

### Issue labeler workflow YAML

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/configuration.md

GitHub Actions workflow that triggers on issue open, parses the bug template, and applies platform labels. Requires issues:write permission; actions:read and contents:read are needed for private repositories. Uses pinned action SHAs with version comments.

```yaml
name: issue-labeler
on:
  issues:
    types: [ opened ]

jobs:
  label-component:
    runs-on: ubuntu-latest

    permissions:
      # required to set labels on issues
      issues: write

      # only required for workflows in private repositories
      actions: read
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Parse issue form
        uses: stefanbuck/github-issue-parser@2ea9b35a8c584529ed00891a8f7e41dc46d0441e # v3.2.1
        id: issue-parser
        with:
          template-path: .github/ISSUE_TEMPLATE/bug.yml

      - name: Set labels based on platform field
        uses: redhat-plumbers-in-action/advanced-issue-labeler@39087a4b30cb98d57f25f34d617a6af8163c17d9 # v3.2.1
        with:
          issue-form: ${{ steps.issue-parser.outputs.jsonString }}
          token: ${{ secrets.GITHUB_TOKEN }}
          config-path: .github/advanced-issue-labeler.yml
          template: bug.yml

```

--------------------------------

### Basic call: filing an enhancement suggestion

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/enhancement-template.md

Shows the form data a user supplies to file an enhancement suggestion. The title and enhancement description are the only collected values; the issue type and labels are assigned by the form, not the user.

```text
Title: Add `docker events` command

Enhancement description:
## Enhancement description
A first-class command to stream container lifecycle events, so tooling does not
have to poll `docker ps`.

## Sample UX
docker events --follow --filter container=app

## Diagram
[visual mock-up / sketch]
```

--------------------------------

### Enhancement suggestion issue form schema (YAML)

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/enhancement-template.md

Defines the GitHub issue form for enhancement suggestions. Includes markdown intro, a required textarea for the enhancement description, and applies the labels 'kind/enhancement' and 'needs-triage'. The textarea placeholder includes a sample CLI command.

```yaml
name: 🐳 Enhancement suggestion
description: Suggest an enhancement
type: "enhancement"
labels:
  - "kind/enhancement"
  - "needs-triage"
body:
  - type: markdown
    attributes:
      value: |
        🐳 **Thanks for suggesting an enhancement to Docker Desktop!**

        What’s missing or could be improved? Tell us what would make your experience better.

        To make your idea easier to evaluate, consider including:
        - **What problem does this solve?**
          Help us understand the pain point you're addressing.
        - **Sample CLI or UX**
          Share how you'd imagine using this feature.
        - **Screenshots or Diagrams** 
          Visuals help us *sea* the full picture
  - type: textarea
    attributes:
      label: Enhancement description
      description: |
        Please provide a description of the enhancement.
      placeholder: |
        ## Enhancement description
        What would you like to see improved or added?

        ## Sample UX
        How would you imagine using this feature?
        ```bash
        docker newfeature --flag value 
        ```

        ## Diagram
        If it helps, include a diagram or visual mock-up.
    validations:
      required: true
```

--------------------------------

### End-to-end data flow for issue labeling

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/configuration.md

Shows the sequence of events and actions when an issue is opened, from the `opened` event through the issue-labeler workflow, the github-issue-parser, and the advanced-issue-labeler, ending with labels applied to the issue. The flow requires `issues: write` permission and uses the `bug.yml` template.

```text
issue "opened" event
  -> workflow issue-labeler (issues.types: [opened])
  -> stefanbuck/github-issue-parser  (template-path: bug.yml)
        reads bug.yml, extracts form fields -> outputs.jsonString
  -> redhat-plumbers-in-action/advanced-issue-labeler
        (issue-form, token, config-path, template: bug.yml)
        reads policy: template ["bug.yml"], section id [platform]
        value "Windows"|"macOS"|"Linux"|"Other" -> platform/* label
  -> labels set on the issue (permissions: issues: write)
```

--------------------------------

### Error handling: submitting from the CLI and detecting failure

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/enhancement-template.md

Detects a failed submission from the CLI. The CLI cannot set the issue type; a bodyless submission fails with HTTP 422 and a non-zero exit, which the script checks.

```bash
if gh issue create \
  --repo docker/desktop-feedback \
  --title "Add docker events command" \
  --body "" \
  --label kind/enhancement --label needs-triage; then
  echo "issue created"
else
  status=$?
  echo "submission rejected (exit $status; empty body -> HTTP 422)" >&2
fi
```

--------------------------------

### Label policy YAML for advanced-issue-labeler

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/configuration.md

Defines a policy rule for the `redhat-plumbers-in-action/advanced-issue-labeler` action. It applies to the `bug.yml` template and inspects the `platform` form field, assigning labels like `platform/windows` when the field value matches. The `block-list` is empty, and the dropdown restricts values to exactly four options, so every bug issue matches exactly one rule.

```yaml
policy:
  - template: ["bug.yml"]
    section:
      - id: [platform]
        block-list: []
        label:
          - name: "platform/windows"
            keys: ["Windows"]
          - name: "platform/macos"
            keys: ["macOS"]
          - name: "platform/linux"
            keys: ["Linux"]
          - name: "platform/other"
            keys: ["Other"]
```

--------------------------------

### Task issue form schema (task.yml)

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/task-template.md

The complete task issue form schema from `.github/ISSUE_TEMPLATE/task.yml`. It defines the issue type `"task"`, applies labels `kind/task` and `needs-triage`, and includes a markdown intro plus a required textarea for the task description.

```yaml
name: 📋 General work item
description: A general work item (not a bug or enhancement)
type: "task"
labels:
  - "kind/task"
  - "needs-triage"
body:
  - type: markdown
    attributes:
      value: |
        Describe what needs to be done and why. Include links to related work if helpful.
  - type: textarea
    attributes:
      label: Task description
      description: |
        Please provide a description of the task.
      placeholder: |
        Describe the task. What needs to be done and why?
    validations:
      required: true

```

--------------------------------

### Bug report issue form schema (bug.yml)

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/bug-template.md

Defines the Bug report issue form for the docker/desktop-feedback repository. It includes a markdown intro, a required bug description textarea, a required platform dropdown, a required version textarea with a bash-rendered placeholder, and an optional diagnostics ID input. The form is consumed by GitHub's issue-forms feature and the issue-labeler workflow.

```yaml
name: 🐞 Bug report
description: Report a bug
type: "bug"
labels:
  - "kind/bug"
  - "needs-triage"
body:
  - type: markdown
    attributes:
      value: |
        **Thanks for taking the time to report a bug!**

        If this is a security issue, please email the [Docker Security team](mailto:security@docker.com) instead of opening a public issue.

        To help us investigate faster, please include:
        - A clear description of the bug: what you expected vs. what actually happened.
        - Steps to reproduce the issue.
        - Version and system information.
  - type: textarea
    attributes:
      label: Bug report
      description: |
        Please provide a description of the bug and reproduction steps.
      placeholder: |
        ## Bug description
        What's going wrong? What were you expecting to happen instead?

        ## Reproduction steps
        Step-by-step instructions to make the bug appear.
    validations:
      required: true
  - type: dropdown
    id: platform
    attributes:
      label: Platform
      multiple: false
      description: |
        Which platform are you using?
      options:
        - Windows
        - macOS
        - Linux
        - Other
    validations:
      required: true
  - type: textarea
    id: version
    attributes:
      label: Version information
      description: |
        Please provide version and environment information.

        <details>
        <summary>⌨️ Collect version information from terminal</summary>

        Run the following commands in your favorite terminal and paste the output below:
        ```bash
        docker version && docker info
        ```

        </details>

      render: bash
      placeholder: |
        Client:
        Version:           27.5.1
        API version:       1.47
        Go version:        go1.22.11
        Git commit:        abcdef1
        Built:             Wed Jan 22 13:37:19 2025
        OS/Arch:           darwin/arm64
        Context:           desktop-linux

        Server: Docker Desktop 4.39.0 (184744)
        Engine:
          Version:          28.0.1
          API version:      1.48 (minimum version 1.24)
          Go version:       go1.23.6
          Git commit:       1234567
          Built:            Wed Feb 26 10:40:57 2025
          OS/Arch:          linux/arm64
          Experimental:     false
        containerd:
          Version:          1.7.25
          GitCommit:        123456789a
        runc:
          Version:          1.2.4
          GitCommit:        123456789a
        docker-init:
          Version:          0.19.0
          GitCommit:        123456789a
        ... (more output) ...
    validations:
      required: true
  - type: input
    id: diagnostics
    attributes:
      label: Diagnostics ID
      description: |
        [Generate a diagnostics ID](https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/#diagnose) either from inside the app or from the command line.
    validations:
      required: false

```

--------------------------------

### Create task issue with gh CLI and detect failure

Source: https://github.com/docker/desktop-feedback/blob/main/_autodocs/api-reference/task-template.md

Shell script that creates a task issue via the GitHub CLI, explicitly setting the labels `kind/task` and `needs-triage`. The issue type is assigned by the form on the web. Detects a rejected payload (e.g., empty body) via the exit status and prints an error message.

```bash
if gh issue create \
  --repo docker/desktop-feedback \
  --title "Backfill triage instructions for networking issues" \
  --body "$(cat <<'EOF'
Describe the task. What needs to be done and why?
Update the triage checklists for networking issues.
EOF
)" \
  --label kind/task --label needs-triage; then
  echo "issue created"
else
  status=$?
  echo "submission rejected (exit $status) — retry with a non-empty body" >&2
fi

```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.