Ma77Ball opened a new issue, #5591:
URL: https://github.com/apache/texera/issues/5591
### Feature Summary
Today, our only reviewer-routing affordance is the author-driven
`/request-review @user` comment command. There is no help for *who* to request,
and any naive "auto-assign a reviewer" behavior has a real downside: it can
ping a past contributor who no longer wants review requests. For example, if
Alice edited a file five years ago and has since moved on, auto-requesting her
on every PR that touches that file is noise she can't opt out of.
We want PRs to *suggest* relevant reviewers (so authors know who has
context) while keeping the author fully in control of who actually gets pinged,
and without bothering anyone who isn't deliberately contacted.
### Proposed Solution or Design
Add a `Suggest reviewers` GitHub Actions workflow that runs when a PR is
opened or updated and posts a single, self-updating comment. It does **not**
request any review automatically.
Behavior:
1. On `pull_request_target` (opened / reopened / synchronize /
ready_for_review), compute candidate reviewers from the recent commit history
of the files the PR changes (via `repos.listCommits` per file, which returns
the GitHub login directly, so there is no unreliable git-email-to-login
mapping). Exclude the PR author and bots; rank by recent-commit count; take the
top few.
2. Flag which candidates are **committers** (write/maintain/admin access),
since GitHub only lets an author formally request review from collaborators.
Non-committers are still listed because they have context.
3. Post/update one marker-tagged comment, e.g.:
> ### Suggested reviewers
> Based on recent commit history of the files this PR changes:
> - `@bob` (committer)
> - `@alice`
> - `@carol`
>
> **Author:** request a committer's review by commenting `/request-review
@bob`. GitHub only lets you request review from committers; to loop in the
others for context, mention them in a normal comment (e.g. `cc @alice @carol`).
4. Crucial property: every suggested login is rendered inside a code span
(`` `@user` ``), which GitHub does **not** turn into a notification. The
suggestion bothers nobody. Only the author's explicit `/request-review`
(handled by `comment-commands.yml`) or a manual `cc` actually reaches out, so
the author stays in control and past contributors aren't pinged against their
will.
5. The comment is idempotent: subsequent PR updates edit the same comment
instead of posting new ones.
Open question for discussion: committer detection uses
`getCollaboratorPermissionLevel`, which the default `GITHUB_TOKEN` usually
permits; if it proves unreliable, alternatives are a checked-in committers list
or a `CODEOWNERS` file (the repo has neither today). The workflow degrades
gracefully (treats unknown as non-committer) on failure.
### Affected Area
Deployment / Infrastructure
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
