Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

feat(review): read-only conversational /ask for non-write users

Đang mở
#331 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
github, java
Lĩnh vực
authentication, backend

Hướng nghiên cứu

Start with ManualReviewAuthorizer, MaintainerReplyService, TriggerDetector, and WebhookController.maybeDispatchConversationalMention; trace how authorization and mention routing work, then review the related spend cap and pause behavior in #42. Done means the config, README, and tests cover read-only question routing while slash commands remain write-gated and the ask path creates no reviews, findings, or check runs.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement java
Problem Statement

Today all commands except /help require write access (CommentCommandService.HELP_TEXT, ManualReviewAuthorizer). Conversational @mention replies on PRs and review threads use the same authorizer (MaintainerReplyService → ManualReviewAuthorizer.isAuthorized), so read-only collaborators cannot ask questions without triggering spend-heavy review commands.

This is an intentional simplicity tradeoff (prevent drive-by AI spend) documented in PLAN.md → Simplicity tradeoffs, but teams with many read-only reviewers (docs, QA, security readers) want a question-only path that does not post findings, suggestions, check runs, or merge-blocking verdicts.

Proposed Solution

Add a read-only ask mode for conversational mentions (not slash commands):

  • Eligible users: any collaborator with read access (or higher) on the repo — confirmed via GitHub collaborator permission API (same pattern as write check in ManualReviewAuthorizer, but accept read/triage/write/admin).
  • Trigger: bare @bot … mention on a PR comment or review thread (WebhookController.maybeDispatchConversationalMention / review-thread path) where the body is a question (no command verb like review, describe, etc. — reuse TriggerDetector command detection to reject command-shaped mentions).
  • Behavior: single conversational reply (MaintainerReplyService) — no check run, no inline findings, no REQUEST_CHANGES, no label mutations. Optional disclosure footer: "Read-only ask — for a full review, a maintainer with write access can run /review."
  • Spend controls: honor #42 caps and /pause; consider a separate lower token budget config for ask-only replies.
  • 👀 ack: if #315 lands first, read-only asks should not get 👀 (per #315 scope: commands only) — document clearly.

Config knob, e.g. thrillhousebot.review.read-only-ask-enabled (default: false to preserve current fail-closed behavior).

Related issues
  • #315 — 👀 on commands only (explicitly excludes conversational asks)
  • #322–#323 — other simplicity-tradeoff knobs (same milestone theme)
  • #42 — spend cap
  • #50 — model config / budgets
Acceptance criteria
  • Read-only collaborator can get a conversational answer when read-only-ask-enabled=true
  • Read-only user still cannot run /review, /describe, or other write-gated slash commands
  • Ask path never creates or updates check runs, PR reviews, or inline finding comments
  • Write users unchanged — existing authorized conversational + command behavior
  • Config + README documented; tests for auth gate and command-vs-ask routing
Alternatives considered
  • Allow /ask slash command — clearer UX but expands command surface; mention-only keeps parity with "ask the bot a question" flow.
  • Open conversational replies to everyone — rejected; still need collaborator check to limit spam.
Priority

Important — simplicity tradeoff evolution; target v0.5.0 with other configurability work (#322, #324).

Code of Conduct
  • I have searched for existing issues and this is not a duplicate.
Ngôn ngữ chính
Java
Star
35
Fork
7
Merge trung bình
9 giờ 23 phút
Pull request đã merge (30 ngày)
154

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của devops-thiago/ThrillhouseBot

Tất cả issue của devops-thiago/ThrillhouseBot

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.