Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

fix(automation): prioritize demonstrated user pain

Aperta
  • Qualcosa non va?
#705 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github, javascript, python
Ambito
developer-experience, testing-qa, tooling

Direzione di ricerca

Start with skills/github-issue-triage/scripts/worker.py and skills/github-pr-reviewer/scripts/worker.py, then read their contract tests in tests/test_github_triage_delivery.py and tests/test_github_reviewer_delivery.py. Run uv run pytest -q tests/test_github_triage_delivery.py tests/test_github_reviewer_delivery.py before inspecting the related README files and bundle build. Done means the specified priority, handoff, invalid-reference, documentation, and regression-test behavior passes, with automations/bundle-index.js regenerated.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

priority:low ready-for-dev

Problem

Issue triage currently classifies too many issues as medium or high priority without evidence of user pain, distorting backlog ordering. The reviewer handoff also treats approved low-priority work the same as higher-priority work.

Scope

  • Default issue triage to priority:low.
  • Require recorded user pain or demonstrated product impact before escalating priority.
  • Avoid maintainer handoff after approval when the PR closes a low-priority issue, while preserving handoff for maintainer-decision scope stops.
  • Handle invalid linked issue references without failing the reviewer scan.
  • Add regression coverage.

Implementation: #681.

This issue was created by an AI agent (OpenHands) on behalf of Graham Neubig.

OpenHands AI triage

The following comments and acceptance criteria were added by the OpenHands AI agent.

Triage

Bounded scope: a policy change to two existing automations in this repository, plus their contract tests. The issue-triage worker prompt in skills/github-issue-triage/scripts/worker.py currently tells the agent to prioritize "high or normal"; the PR reviewer's _finish_completed_review in skills/github-pr-reviewer/scripts/worker.py requests a maintainer after any exact-head approval or maintainer-decision scope stop. No user-pain evidence (a real user report, support or customer evidence, production impact, or a reproduced failure in the actual product or workflow) is recorded on this issue, so it is prioritized priority:low.

Interpretation: "closes a low-priority issue" means at least one same-repository closing reference in the PR body (a close[sd]/fix(e[sd])/resolve[sd] keyword followed by #N) resolves to an issue carrying priority:low, matching the adjacent implementation. A closing reference that cannot be resolved in the repository (a nonexistent number, or a reference to another repository) is skipped and must not abort the scan. The suppression applies to approvals only; a 🛑 MAINTAINER DECISION REQUIRED scope stop still requests a maintainer.

Non-goals: changing the reviewer's required-check gate, per-scan intake bound, review publication, or stale-head handling; changing the triage acceptance-criteria or DECISION NEEDED behavior beyond priority selection; adding any label beyond the existing priority:high/priority:medium/priority:low; and implementing or merging PR #681.

Acceptance Criteria
  • The issue-triage worker prompt (skills/github-issue-triage/scripts/worker.py) instructs the agent to default to priority:low, and to assign priority:medium or priority:high only when the issue or human discussion records clear user pain or demonstrated product impact, naming the qualifying evidence (a real user report, support or customer evidence, production impact, or a reproduced failure in the actual product or workflow).
  • The triage prompt states that technical possibility, code inspection, or a synthetic/unit reproduction alone stays priority:low, and lists priority:high, priority:medium, and priority:low among the labels it may create while preserving unrelated labels, replacing any existing priority label, and keeping ready-for-dev gated on the scope/criteria standard.
  • After an exact-head approval of a PR whose same-repository closing issue carries priority:low, the reviewer (skills/github-pr-reviewer/scripts/worker.py) does not request a maintainer review, and the PR is otherwise completed as today (label cleared / scan not redelivered).
  • A 🛑 MAINTAINER DECISION REQUIRED scope stop still requests a maintainer review even when the PR's linked issue carries priority:low (the suppression applies to approvals only, not to scope stops).
  • A PR whose linked issue is not priority:low (for example priority:medium, priority:high, or no priority label) still requests a maintainer review after approval, preserving existing behavior.
  • When a PR body contains a closing reference to an issue that cannot be resolved in the repository (a nonexistent number, or a reference to another repository), the reviewer scan skips that reference, does not raise, and continues so the PR's review completion and handoff are unaffected.
  • Regression coverage: contract tests in tests/test_github_triage_delivery.py and tests/test_github_reviewer_delivery.py assert the triage prompt's default-to-low and evidence wording, the reviewer handoff suppression for an approval that closes a priority:low issue, the preserved handoff for a maintainer-decision scope stop and for a non-low-priority linked issue, and that an unresolvable closing reference does not fail the scan.
  • uv run pytest -q tests/test_github_triage_delivery.py tests/test_github_reviewer_delivery.py passes, and npm run build:automations regenerates automations/bundle-index.js so the bundled triage and reviewer sources match the edited sources (the automation bundles inline these files).
  • Per AGENTS.md ("If you change a skill's behavior or scope, update its README.md accordingly"), skills/github-issue-triage/README.md and skills/github-pr-reviewer/README.md (and any catalog manifest.json description of the handoff) are updated to describe the new priority default and the narrowed approval handoff.
Lingua principale
Python
Stelle
172
Fork
117
Merge medio
1g 7h
PR unite (30g)
56

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenHands/extensions

Tutte le issue di OpenHands/extensions

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.