Draft Issue

Draft Issue

Drafts ready-to-paste GitHub issues for open-telemetry/opentelemetry.io. The templates under .github/ISSUE_TEMPLATE/ and the live label set are the sources of truth — when this skill drifts from them, trust the source.

Arguments {#arguments}

• If $ARGUMENTS is empty, infer context from the conversation. If there is insufficient context, ask the user what issue to draft.
• Otherwise, treat the full $ARGUMENTS string as the description. There are no flags.

When to use

• After investigating a problem in the OTel site codebase.
• When a conversation reveals a bug, docs gap, or feature need.
• When drafting a blog post proposal for OTel.

Issue types {#issue-types}

The repo has five issue templates. Auto-detect type from context, or accept an explicit type from the user.

When drafting, read the chosen template under .github/ISSUE_TEMPLATE/ and mirror its section labels verbatim so GitHub maps the body back to template form fields. Required fields are marked in the template.

For writing or reviewing the post itself after a blog: proposal lands, see the review-blog-post skill.

Drafting rules

From content/en/docs/contributing/issues.md:

• Be specific. Describe what is missing, out of date, wrong, or needs improvement. "Fix the security docs" is too broad; "Add details to the 'Restricting network access' topic" is actionable.
• Right-size the scope. One issue = one reasonable unit of work; break broad problems into smaller, reviewable issues.
• Search first. Check existing issues for duplicates before filing.
• Reference related issues and PRs with #1234 for the same repo, or the full URL for cross-repo references.
• Concise, actionable descriptions; no filler.

Other guidance:

• Format: do not hard line-wrap (prettify) issue body prose, instead let GitHub flow paragraph text naturally.

Labels {#labels}

The repo's labels evolve; do not maintain a copy in this skill. Discover the live set with:

gh label list --repo open-telemetry/opentelemetry.io --limit 200

Path-based auto-labeling (e.g. blog, registry, i18n, lang:*, several sig:*) is defined in .github/component-label-map.yml and applies on PRs only. You can still suggest these on issues manually.

Governance for the triage:*, type:*, priority:*, and sig:* families lives in content/en/docs/contributing/sig-practices.md. Skip type:discussion — its own label description says "Do not use, convert discussion issues into real Discussions."

Output format

Produce a fenced block with title, suggested labels, and body. Labels are comma-separated so they can be passed directly to gh issue create --label "<comma,separated>".

**Title**: `bug: pr-approval-labels workflow adds ready-to-be-merged despite requested changes`

**Labels**: `CI/infra`, `Github actions`, `p2-medium`

---

### What happened?

The `pr-approval-labels` workflow currently adds the `ready-to-be-merged`
label when a PR receives an approving review, but it does not check whether
other reviewers have requested changes.

### What did you expect would happen?

The workflow should skip adding the `ready-to-be-merged` label if any
reviewer has a pending "changes requested" status on the PR.

### Name + path of the page

.github/workflows/pr-approval-labels.yml

### Additional context

Related to #1234.

References {#references}

• .github/ISSUE_TEMPLATE/*.yml — five real templates; mirror their section labels verbatim.
• content/en/docs/contributing/issues.md — user-facing guidance on filing great issues.
• content/en/docs/contributing/sig-practices.md — label and triage governance.
• .github/component-label-map.yml — path-based PR auto-labeling.
• gh label list --repo open-telemetry/opentelemetry.io --limit 200 — live label set.