Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#331 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
github, java
Domain
authentication, backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Java
Stars
35
Forks
7
Avg merge
9h 32m
Merged PRs (30d)
144

Getting set up

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.

More from devops-thiago/ThrillhouseBot

All issues in devops-thiago/ThrillhouseBot

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.