otel-issue-draft

OTel Issue Draft

Draft ready-to-paste GitHub issues for opentelemetry.io, matching OTel issue templates and conventions.

When to Use

• After investigating a problem in the OTel codebase
• When a conversation reveals a bug, docs gap, or feature need
• When the user wants to file an issue based on current findings
• When drafting a blog post proposal for OTel

Issue Types

Auto-detect from context, or accept explicit type from the user.

Type	Title Prefix	When to Use
docs	[Docs]:	Documentation errors, missing content, outdated info
bug	bug:	Site bugs, broken functionality, CI/workflow issues
feature	feat:	New site features, tooling improvements
blog	blog:	Blog post proposals

Template Structures

Docs Update (most common)

### What needs to be changed?

<clear description of the docs issue>

### Page path

`content/en/docs/...`

### Additional context

<any supporting details, screenshots, links>

Bug Report

### What happened?

<clear description of the bug>

### What did you expect would happen?

<expected behavior>

### Page path

<URL or file path where the bug occurs>

### Browser, OS, and platform

<environment details if relevant>

Feature Request

### Desired feature or idea

<description of the feature>

### Additional context

<supporting details, motivation, alternatives considered>

Blog Post Proposal

### Blog Post Title

<proposed title>

### Blog Post Outline

<structured outline with sections>

### Related SIGs

<relevant SIGs>

### Technologies Used

<technologies covered in the post>

Label Taxonomy

Suggest appropriate labels based on the issue content.

Area Labels

• CI/infra, Github actions, github_actions — workflow/CI issues
• blog — blog content
• docs — documentation
• registry — registry entries
• i18n — internationalization
• site:accessibility, site:design/style, ux — frontend/site
• cleanup/refactoring — cleanup work
• upstream, upstream:docsy, upstream:hugo — upstream dependencies

SIG Labels

sig:android, sig:collector, sig:cpp, sig:demo, sig:dotnet, sig:enduser, sig:erlang, sig:faas, sig:go, sig:helm, sig:java, sig:javascript, sig:kotlin, sig:obi, sig:operator, sig:php, sig:profiling, sig:python, sig:ruby, sig:rust, sig:security, sig:semconv, sig:spec, sig:swift

Localization Labels

lang:bn, lang:es, lang:fr, lang:ja, lang:pt, lang:ro, lang:uk, lang:zh

Effort Estimates

e0-minutes, e1-hours, e2-days, e3-weeks, e4-months

Priority

p0-critical, p1-high, p2-medium, p3-low

Triage

triage:accepted, triage:accepted:needs-pr, triage:deciding, triage:deciding:blocked, triage:deciding:needs-info

Type

type:copyedit, good first issue, help wanted

Formatting Rules

• Title uses the appropriate prefix for the issue type
• Body uses markdown with clear sections matching the template
• References to other issues/PRs: #1234 for same repo, full URL for cross-repo
• Code snippets use fenced blocks with language tags
• File paths relative to repo root
• Concise, actionable descriptions — no filler
• Line wrap at 80 characters (except URLs and code blocks)

Output Format

The final output is a fenced markdown block with title, labels, and body:

**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.

### Relevant files

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

### Additional context

Related to #1234.