open-telemetry / open-telemetry/opentelemetry-python

Discuss using AI to help in the review process of issues and PRs

Open
#5,343 7 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature-request
Dominant language
Python
Stars
2.6k
Forks
1k
Avg merge
4d 15h
Merged PRs (30d)
19

Description

Is your feature request related to a problem?

This repo has been receiving more issues and pull requests than maintainers can handle. As the project grows, keeping up with the review queue is increasingly difficult with the current maintainer bandwidth.

Describe the solution you'd like

I would like to explore ways to use AI responsibly to help triage and review incoming issues and PRs, so maintainers can focus their attention where it matters most.

Describe alternatives you've considered

Automated triage and labeling

A GitHub Action triggered on new issues and PRs could use a model to read the submission and suggest labels, assign a category (bug report, feature request, question, documentation gap), and route it to the right area of the codebase. This would reduce the time maintainers spend on the mechanical parts of triage and help new submissions surface in the right queue faster.

AI-assisted first review

Rather than waiting for a maintainer to open a PR, a bot could post an initial structured review: does the description explain the motivation? Is there a linked issue? Does the diff match the stated intent? Are there obvious gaps like missing tests or changelog entries? This gives the contributor immediate, actionable feedback and means that by the time a maintainer looks at it, the submission is already in better shape.

Clarifying questions on incomplete submissions

Many issues stall because they are missing reproduction steps, environment details, or version information. A model could detect when a submission is likely incomplete and post a friendly comment asking for the missing context before a maintainer ever sees it. This keeps the queue from filling up with issues that cannot be acted on yet.

Duplicate and related issue detection

When a new issue is opened, a model could search the existing issue tracker for semantically similar open or closed issues and surface them in a comment. This helps contributors find prior discussion before a maintainer has to do it manually, and reduces duplicate work across the board.

Contribution policy

Beyond tooling, we could adopt lightweight policies that raise the quality floor before automation or a maintainer ever gets involved:

  • Require a linked issue for every PR. A PR without a corresponding issue cannot be reviewed because there is no agreed-upon problem statement to evaluate the change against. Requiring this upfront ensures that the motivation for a change has been discussed and accepted before implementation work begins.
  • Require the PR author to be assigned to the linked issue. This establishes that the contributor has signaled intent and received at least implicit acknowledgment from the project before opening a PR. It prevents duplicate work and gives maintainers a natural checkpoint to redirect effort before code is written.
  • Automatically close submissions that do not meet requirements. PRs or issues that are missing required information would be closed automatically after a grace period, with an AI-generated comment explaining exactly what is missing and what the author needs to do to have the submission reconsidered. The close is not a rejection — it is an invitation to return once the requirements are met. This keeps the queue actionable without requiring maintainer time on submissions that are not yet ready for review.
Additional Context

Whatever approach we adopt should be transparent — if automation acts on a submission, it should say so clearly — and should keep a human in the loop for any consequential decisions. I am interested in hearing from the community: if you have seen this handled well in other projects, or have ideas around tooling or process, please share them here.

Would you like to implement a fix?

Yes

Tip

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or implementation entry points are identified. Start by reviewing the proposed GitHub Action workflows for issue and PR triage, then clarify which automation is in scope, how human review remains involved, and what transparent behavior would count as an acceptable outcome.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ai, ci-cd, devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.